Infrastructure

[MSA] MSA의 구성요소

feel2 2025. 9. 24. 16:02

1. API Gateway

API Gateway란?

API Gateway(게이트웨이)는 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고, API에 대한 인증과 인가 기능에서 메시지에 따라서 여러 서버로 라우팅하는 고급기능까지 많은 기능을 담당할 수 있습니다. - MSA school

 

여기서 key point 는

  • 엔드포인트를 단일화
  • 인증과 인가 기능
  • 라우팅

로 볼 수 있다.

 

출처: Gatner에서 발표한 MSA components

 

다양한 사용자(Mobile, Brower, Other Service..)들이 External Gateway를 통해서 service에 접근하는 것을 볼 수 있다.

 

보통 MSA에서 API Gateway를 얘기하면 External Gateway를 말한다.

 

Why Use an API Gateway?

 

다음과 같은 이유로 API Gateway를 사용한다.

  • 단일 API 도메인을 노출하여 유지 관리할 수 있다.
  • 모든 클라이언트에 하나의 진입점을 제공하여, 사용자 요청에 따라 다른 버전의 API로 라우팅이 가능하다.
  • 단일 클라이언트 요청에 대해 여러 마이크로 서비스를 호출하고 결과를 한번에 모아 응답 가능

 

출처:  https://www.nginx.com/learn/api-gateway/

 

단일 클라이언트 요청에 여러 마이크로 서비스를 호출하여 결과를 집계하는것을 볼 수 있다.

 

Basic Capabilities of an API Gateway

 

API Gateway는 다음과 같은 기본 기능을 가지고 있다.

  • API 호출을 하는 요청자 인증(Authentication)
  • 요청자에게 요청을 할 수 있는 권한이 있는지 확인(Authorization)
  • 적절한 백엔드로 요청 라우팅(routing)
  • 시스템 과부하를 방지하기 위해 속도 제한 적용(rate limits to prevnet overloading)
  • DDoS 공격 완화를 위해 속도 제한 적용(rate limits to migrate DDoS attack)
  • 성능 향상을 위해 SSL/TLS 트래픽 완화(Offloading SSL/TLS traffic)
  • 오류 및 예외 처리(Handling errors and exceptions)

 

API Gateway and MSA

마이크로서비스 기반 애플리케이션의 경우 API 게이트웨이는 시스템에 대한 단일 진입점 역할을 한다.

마이크로서비스 앞에 위치하여, 클라이언트로부터 앱의 복잡성을 분리하여 클라이언트 구현과 마이크로서비스 앱을 모두 단순화(simplify)한다.

마이크로서비스 아키텍처에서 API 게이트웨이는 라우팅, 구성 및 정책 시행을 담당한다.

  • 일부 요청은 적절한 백엔드 서비스로 라우팅하여 처리하고, 다른 요청은 여러 백엔드 서비스를 호출하고 결과를 집계하여 처리한다.
  • 인증, 권한 부여, 모니터링, 로드 밸런싱, 응답 처리와 같은 마이크로서비스를 위한 다른 기능을 제공한다.
    • 비기능적 요구 사항 구현을 인프라 계층으로 오프로드하고, 개발자가 핵심 비즈니스 로직에 집중하여 앱 개발 속도를 높일 수 있다.

 

API Gateway for Kubernetes

 

시스템 이카텍처와 앱 요구 사항에 따라 크게 3가지 배포 형태를 가지고 있다.

  1. Kubernetes 클러스터 앞에 로드 밸런서(multi-cluster level)로 배포
    • External Gateway라고 생각하면 됨
  2. 클러스터의 경계에 Ingress Controller(cluster-level)로 배포
  3. 서비스 메시(service-level)로 배포

 

출처:https://www.nginx.com/learn/api-gateway/

 

2, 3번의 경우 Service Mesh에서 다시 한번 설명하겠다.

 

API Gateway vs Service Mesh

 

공통

  • Resilience: 두 가지 기술 중 하나 또는 두 가지를 모두 사용하면 클라우드 네이티브 애플리케이션에서 발생하는 어려움이나 실패로부터 애플리케이션을 신속하게 복구할 수 있다.
  • Traffic management: 분산 애플리케이션으로서 트레픽 관리가 가능
  • Enhanced Security Features: 강력한 보안 기능을 제공
  • Observability and Monitoring: 두 구성 요소 모두 모니터링 및 로깅 기능을 제공함.

 

차이점

  API Gateway  Service Mesh
목적 내부/외부 및 심지어 DB 엑세스 위한 API 호출까지도 라우팅 할 수 있도록 설계 내부 엔터프라이즈 시스템 및 마이크로 서비스 내의 이식성을 개선하도록 설계
동작 범위 API에 대한 외부 클라이언트 액세스를 관리하도록 설계 주로 동일한 애플리케이션 내의 마이크로서비스 간 통신에 중점
책임 외부 클라이언트에 대한 요청 라우팅, 인증, 응답 변환과 같은 더 높은 수준의 문제를 처리 서비스 검색, 서비스 간 인증, 트래픽 암호화와 같은 낮은 수준의 통신 문제를 처리
복잡성 외부 API 에 대한 접근만 제어하면 되서 단순하지만, 제대로 설계되지 않으면 단일 실패 지점이 발생함 각 마이크로서비스에 대한 추가 구성 요소 사이드카 형태로 붙어 복잡함
사용 사례 외부 클라이언트가 서비스에 액세스할 수 있도록 제어되고 안전한 진입점을 제공하는 데 적합 대규모 분산 시스템에서 내부 마이크로서비스 통신의 복잡성을 관리하는 데 매우 적합
기술 성숙도 성숙한 기술

신 기술

 

API Gateway 종류

 

2. Service Mesh

Service Mesh란?

서비스 메시는 애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층입니다. 이 계층은 컨테이너화된 마이크로서비스로 구성됩니다. … 서비스 메시는 서비스 간 연결을 관리하기 위해 모니터링, 로깅, 추적, 트래픽 제어와 같은 새로운 기능을 제공합니다. 이러한 기능은 각 서비스의 코드와 독립적이므로 네트워크 경계를 넘어 여러 서비스 관리 시스템에서 작동할 수 있습니다.
- aws -

 

출처:  nginxstore , Service Mesh의 Control Plane은 Data Plane의 사이드카 프록시에 구성을 배포합니다.

 

 

여기서 key point 는

  • 서비스 레벨에서의 모든 통신을 처리
  • 모니터링, 로깅, 트래픽 제어
  • 서비스의 코드와 독립적(종속성 완화)

로 볼 수 있다.

 

Why Use Service Mesh?

 

마이크로서비스 아키텍처를 사용하면 개발자는 전체 재배포 없이도 각 앱 서비스를 변경할 수 있습니다.

다른 아키텍처의 앱 개발과 달리 개별 마이크로서비스는 자체 도구와 코딩 언어를 선택할 수 있는 유연성을 갖춘 소규모 팀에 의해 구축됩니다.

기본적으로 마이크로서비스는 독립적으로 구축되고, 서로 통신하며, 애플리케이션 전체의 중단으로 확대되지 않고 개별적으로 실패할 수 있습니다.

 

출처:  RedHat  , 서비스 메쉬가 없는 마이크로서비스

 

서비스 간 통신은 마이크로서비스를 가능하게 합니다.

통신을 관리하는 논리는 서비스 메시 계층 없이 각 서비스에 코딩될 수 있습니다.

그러나 마이크로서비스간의 통신이 더욱 복잡해질수록 서비스 메시의 가치는 더욱 커집니다.

마이크로서비스 아키텍처에 구축된 클라우드 네이티브 앱의 경우 서비스 메시는 수많은 개별 서비스를 기능적 애플리케이션으로 구성하는 방법입니다.

그래서 등장한 것이 서비스 매쉬다.

서비스 매쉬는 공통 관심사를 애플리케이션으로부터 분리하고, 인프라 계층으로 옮겼다.

그럼으로 다음과 같은 특징을 가질 수 있게 되었다.

 

Traffic management

  • 트래픽 라우팅은 ****서비스 간 트래픽 흐름과 API 호출을 쉽게 제어할 수 있습니다.
  • 서비스 수준 속성의 구성을 단순화하고 A/B 테스트, 카나리아 배포, 백분율 기반 트래픽 분할을 통한 단계적 출시와 같은 중요한 작업을 쉽게 설정할 수 있도록 해줍니다.

 

Resilience

  • 오류, 지연 및 네트워크 문제의 영향을 완화하는 회로 차단(circuit breaking), 재시도 및 시간 초과와 같은 기능을 제공하여 마이크로서비스 기반 애플리케이션의 전반적인 복원성을 높이는 데 도움이 됩니다.
  • 복원력의 궁극적인 목표는 특정 마이크로서비스 인스턴스의 오류나 성능 저하로 인해 전체 분산 시스템의 가동 중지 시간을 초래하는 연쇄 오류가 발생하지 않도록 하는 것입니다.

 

Observability

  • 서비스 메시는 4가지 주요 메트릭을 모두 수집하고, 그래픽 대시보드(ex) istio kiali)를 통해 보고 다른 도구에서 사용하기 위해 API를 통해 내보내는 등 메트릭에 액세스하는 기타 추가 방법을 지원합니다.

 

Security

  • ****TLS(전송 계층 보안)를 사용하여 포드 간 통신을 보호함으로써 보안을 제공합니다.
    • TLS는 암호화를 사용하여 통신 중인 정보를 다른 사람이 모니터링하거나 변경할 수 없도록 보장합니다.
  • 앱 외부와 내부에서 이루어진 요청을 승인 및 인증하고, 검증된 요청만 인스턴스에 전송함으로써 인증 및 권한 부여에 도움을 줍니다.

 

How it Works

 

서비스 매쉬는 크게 2가지 요소로 구성되어 있다.

 

출처:  istio , Istio Architecture

 

데이터 플레인은 서비스 간 통신 역할을 합니다.

서비스 메시는 프록시를 사용하여 모든 네트워크 트래픽을 가로채므로 설정한, 구성에 따라 광범위한 애플리케이션 인식이 가능합니다.

Envoy 프록시는 클러스터에서 시작하는 각 서비스와 함께 배포되거나, VM에서 실행되는 서비스와 함께 실행됩니다.

컨트롤 플레인은 서비스메쉬의 두뇌 역할입니다.

원하는 구성과 서비스를 프록시 서버를 동적으로 프로그래밍하여 규칙이나 환경 변화에 따라 업데이트합니다.

 

사이드카 패턴

 

출처:  msaschool , 사이드카 적용 모습

 

 

Sidecar 방식은 Envoy와 함께 Istio에서 사용하는 방식입니다.

 

Sidecar 배포에서 모든 응용 프로그램 컨테이너에 추가로 Sidecar 컨테이너가 배포됩니다. Sidecar는 응용 프로그램 컨테이너로 들어오거나 나가는 모든 네트워크 트래픽을 처리합니다. 이 방식은 라이브러리와 노드에이전트 방식과 큰 차이점을 가집니다.

 

예를 들어 모든 노드에서 새 에이전트를 실행할 필요 없이 Sidecar를 배포할 수 있으므로(노드 에이전트를 배포하기 위해 인프라 전반에 협업이 필요하지 않음) 동일한 Sidecar의 복사 본을 여러 개 실행합니다. 또한 Linkerd에서 마이크로서비스 그룹에 하나의 Service Mesh만을 사용하던 것과 달리 다른 Service Mesh와 같이 사용할 수 있습니다.

 

Sidecar 방식에서 GKE의 경우, POD 정의에 프록시가 정의됩니다. 일반적으로 1Container 당 1 Sidecar 방식으로 사용되며, 단일 호스트로의 proxy오류 가능성을 제한하며, 동일한 호스트의 단일 호스트에는 영향을 미치지 않습니다.

 

Data flow

   Incoming Request
          |
          v
[ Ingress controller ] 
          |          - cluster 내부로 들어오는 트레픽 제어
          v
     [ Gateway ]  
          |        - Gateway는 메쉬 외부로부터 들어오는 트래픽을 제어합니다.
          v
[ Virtual Service ] 
          |        - Virtual Service는 Gateway로부터 받은 트래픽을 어느 서비스로 라우팅할지 결정합니다.
          v
[ Destination Rule ] 
          |        - Destination Rule은 특정 'destination' 서비스에 대한 트래픽 행동을 세부적으로 정의합니다.
          v
     [ Service ]

 

 

3. 컨테이너 관리

 

왜 컨테이너 관리가 중요한가?

 

MSA 환경에서는 하나의 서비스를 여러 개의 마이크로서비스로 나누어 운영합니다.

각 서비스는 독립적으로 배포되며, 일반적으로 컨테이너(Docker 등) 안에서 실행됩니다.

 

문제는 서비스 수가 많아질수록 컨테이너도 수십, 수백 개 이상으로 늘어나면서 다음과 같은 어려움이 발생한다는 점입니다.

 

  • 자동 배포: 새로운 버전의 컨테이너를 빠르게 배포해야 함
  • 스케일링: 트래픽 증가 시 컨테이너를 자동으로 늘리고, 줄이는 작업 필요
  • 서비스 디스커버리: 어떤 컨테이너가 살아있는지, 어디에 있는지 추적해야 함
  • 로드 밸런싱: 요청을 여러 컨테이너에 고르게 분산
  • 자원 최적화: CPU, 메모리 같은 리소스를 효율적으로 사용
  • 장애 복구: 죽은 컨테이너를 자동으로 다시 살려야 함

 

이 모든 과정을 사람이 수동으로 할 수는 없으므로 컨테이너 관리(Orchestration) 도구가 반드시 필요합니다.

 

 

 

컨테이너 관리 도구의 핵심 역할

 

컨테이너 오케스트레이션 도구는 다음 기능을 제공합니다:

 

  • 배포 자동화 (Deployment)
  • 새로운 컨테이너 이미지를 자동으로 배포 및 롤백 지원
  • 확장/축소 (Scaling)
  • 트래픽 상황에 따라 컨테이너 수를 자동 조정
  • 서비스 디스커버리 (Service Discovery)
  • 컨테이너 위치(IP, 포트)를 자동으로 관리
  • 로드 밸런싱 (Load Balancing)
  • 요청을 살아있는 컨테이너에 분산
  • 자원 관리 (Resource Management)
  • CPU, 메모리 사용량을 기반으로 컨테이너 배치 최적화
  • 자동 복구 (Self-Healing)
  • 컨테이너가 비정상 종료되면 자동으로 재시작

 

대표적인 도구

  • Kubernetes (K8s)
  • 사실상 표준. 구글에서 시작, CNCF 관리. 대부분의 기업이 사용.
  • Docker Swarm
  • 간단한 환경에서 쓰기 좋은 경량 오케스트레이션. 하지만 대규모 환경에서는 Kubernetes 선호.
  • Apache Mesos / Marathon
  • 대규모 분산 환경 관리에 사용되지만 최근엔 K8s로 많이 이동.

 

실제 사례

예를 들어, 전자상거래 서비스를 운영한다고 가정해 보겠습니다.

 

  • 상품 서비스, 주문 서비스, 결제 서비스가 각각 컨테이너로 배포됨
  • 블랙프라이데이 기간에는 주문 서비스 컨테이너를 자동으로 10배 확장
  • 트래픽이 끝난 뒤에는 다시 줄여 비용 절감
  • 만약 컨테이너 하나가 다운되면 Kubernetes가 자동으로 새로운 컨테이너를 생성
  • 개발자는 장애 걱정보다는 새로운 기능 개발에 집중할 수 있음

 

4. Backing Service

Backing Service란?

backing services는 앱이 실행중에 네트워크를 통해 사용하는 모든 서비스를 말합니다. 예로는 데이터 저장소(예: MySQL 또는 CouchDB), 메시징/대기열 시스템(예: RabbitMQ 또는 Beanstalkd), 아웃바운드 이메일용 SMTP 서비스(예: Postfix) 및 캐싱 시스템(예: Memcached, Redis)이 있습니다.

 

 

여기서 key point 는

  • 앱이 실행중에 네트워크를 통해 사용하는 모든 서비스

로 볼 수 있다.

 

출처:  12factor , 다양한 backing service들이 존재한다.

 

쉽게 backup(지원요청)을 위한 컴퍼넌트라고 생각하면 된다.

 

Microservices for Backing Service

 

이벤트드리븐 기반의 마이크로서비스(Event-Driven Microservices)에서 Backing Service 는 메세지의 송신자와 수신자가 직접 통신하지 않고 메시지큐를 활용한 비동기 통신 프로토콜을 사용합니다.

마이크로서비스간의 통신이 필요한 비즈니스의 경우, 실시간으로 진행되도록 구성한 마이크로서비스들은 장애 발생, 트래픽 증가 또는 소스 반영 등의 이벤트가 발생할 수 있습니다.

이런 경우, 마이크로서비스는 오케스트레이션을 진행하며 또다른 마이크로서비스를 신규 생성, 재생성 등의 작업을 수행하게 됩니다.

기존의 강결합 구조의 서비스는 실시간 트랜잭션 기반의 서비스를 제공하면 트랜잭션이 끊어지기 때문에, 서비스 요청을 보존할 수 없고 에러가 발생하게 됩니다.

그래서 서비스 영속성을 지속하기 위하여 메시지 큐를 활용하고 리소스와의 결합을 느슨하게 하여 언제든지 붙이거나 떼어 낼 수 있도록 Backing Service를 구성하여야 합니다.

또한 마이크로서비스들간의 비동기 처리가 필요하거나 타 마이크로서비스의 데이터 접근이 빈번하여 API 호출 과다 발생 시에도, 데이터 공유 혹은 데이터 대상 리포팅을 준실시간 동기화를 수행하도록 합니다.

 

Apache Kafka?

 

출처:  https://velog.io/@jwpark06/Kafka-시스템-구조-알아보기

 

LinkedIn에서 개발된 pub-sub 모델의 메시지큐 방식 기반, 분산 메시징 시스템이다.

 

  • 대규모 트래픽 처리 및 분산 처리에 효과적
  • 클러스터 구성, Fail-over, Replication 같은 기능이 있음
  • 100Kb/sec 정도의 속도 (다른 메세지 큐 보다 빠름)
  • 디스크에 메세지를 특정 보관 주기동안 저장하여 데이터의 영속성이 보장되고 유실 위험이 적다. 또한 Consumer 장애 시 재처리가 가능하다.

 

Pub/ Sub 아키텍처 패턴

 

출처:  msaschool , 토픽 아키텍처

 

토픽 아키텍처의 경우 Pub/sub 구조에 교환기에서 direct로 메시지를 송신하지 않고 토픽을 게시하는 방식이다.

  • 토픽의 경우는 메시지를 게시하면 관심 있는 모든 구독자가 메시지 사본을 받게 됩니다.
  • Point-to-point 방식의 Message queue와 비교하여 가용성과 확장성이 좋으며, point-to-multipoint 방식으로 구성됩니다.
  • 게시자와 수신자의 정보를 서로 알고 있을 필요가 없으며, 메시지가 수신자에게 도착하면 게시자에게 알림이 전송됩니다.
  • 메시지는 토픽에서 직접 수신되지 않으며 구독에서 수신합니다.
  • 구독은 필터를 통하여 전달받는 메시지를 제한할 수 있습니다.

 

How it Works

출처: oreilly

 

모든 backing service는 URL을 통해 액세스할 수 있어야 합니다.

마이크로 서비스는 실행되는 동안 지속적으로 backing service와 통신을 해야합니다. 예를 들어 메시징 시스템에서 메시지를 듣거나 보내거나, 이메일을 보내거나, 데이터베이스에 데이터를 유지할 수 있습니다. 복잡한 통신 요구 사항 없이 URL을 통해 이러한 모든 서비스에 접근할 수 있어야 합니다.

 

 

 

 

5. Telemetry

Telemetry란?

마이크로서비스는 분산 환경에서 운영되며, 다수의 마이크로서비스가 동작하게 됩니다. 이러한 특징 때문에 장애, 운영 이관 등의 실행중인 프로세스에서 발생하는 이벤트의 흐름을 보고 원인을 파악하는데 오랜 시간이 소모 됩니다.
각 서비스별로 발생하는 이슈들을 Tracing 하기 위하여 Monitoring, Logging, Tracer 도구를 활용하여 지속적이고 자동으로 이슈에 대응할 수 있도록 환경을 구성합니다. -MSA school

 

 

여기서 key point 는

  • Monitoring
  • Logging
  • Tracer

로 볼 수 있다.

 

Main functions of Telemetry

 

Monitoring

 

인프라 및 응용 프로그램 서비스 모니터링을 위해서는 매트릭 수집, 로깅 및 추적 이라는 세가지 도메인에서 데이터 수집, 저장 및 분석이 필요합니다. 또한 Alert 기능은 세가지 도메인의 기능을 서포팅 하기 위해 반드시 필요한 기능입니다.

Monitoring은 마이크로서비스 아키텍처의 성능이나 효율성을 확인합니다. AWS에서는 Amazon Cloudwatch가 있고, OSS로는 Prometheus, Grafana등이 있습니다. Monitoring은 각 대상에서 수집한 Metric을 통해 대상 리소스의 사용률 등을 수치로 표현하는 기능을 수행합니다.

 

 

Prometheus + Grafana

출처: linkerdin , Prometheus + Grafana

 

  1. 스프링 부트 액츄에이터와 마이크로미터를 사용하면 수 많은 메트릭을 자동으로 생성한다.
  2. 프로메테우스는 이렇게 만들어진 메트릭을 지속해서 수집한다.
  3. 프로메테우스는 수집한 메트릭을 내부 DB에 저장한다.
  4. 사용자는 그라파나 대시보드 툴을 통해 그래프로 편리하게 메트릭을 조회한다. 이때 필요한 데이터는
    프로메테우스를 통해서 조회한다.

Logging

Logging은 마이크로서비스 아키텍처에서 발생하는 Log들을 수집해서 보여줍니다.

Log는 실행 중인 프로세스에서 발생하는 이벤트의 흐름을 의미하며 마이크로서비스 아키텍처에서는 컨테이너에서 실행중인 프로세스들의 수가 모놀리식 아키텍처에 비해서 매우 많기 때문에 장애와 같은 이벤트 발생 시 파악하기가 힘이 들며 root cause를 찾기가 어렵습니다.

따라서 많은 로그들을 빠르게 수집하여 사용자에게 보여줌으로써 어느 마이크로 서비스에서 장애가 발생하였는지 쉽게 파악할 수 있습니다.

AWS에서는 Amazon Elastic Search 등이 Logging을 담당하는 요소이며, OSS로는 EFK(Elastic Search - FluentD - Kibana) 가 대표적입니다.

각 서비스에 심어진 Agent가 해당 서비스의 Log정보들을 수집하고, Log Server(Aggregator)를 통해 취합됩니다. 최종적으로 Kibana와 같은 툴을 통해 시각화된 데이터를 관리자에게 보여줍니다.

 

EFK(Elastic Search - FlunetD - Kibana)

출처:  medium , EFK 스택 구축

 

 

  1. 각 쿠버네티스 환경에 배포된 시스템에서 나오는 데이터를 fluentd가 수집한다
  2. fluentd가 이 데이터를 elasticsearch에서 보내주면, elasticsearch는 인덱싱하여 저장한다.
  3. elasticsearch와 연결된 kibana UI에서 해당 데이터를 볼 수 있다.

 

ELK(Elastic Search - Logstash - Kibana)

 

EFK와 동일하게 데이터 수집 및 시각화 목적의 스택이지만, fluentd 대신 logstash를 사용한다.

출처: guru99 , ELK 스택 구축

 

 

  1. 데이터 원천에 beat가 붙어서 데이터를 수집한다. EFK 아키텍쳐와 마찬가지로 여러 대의 데이터 원천 각각에 beats가 붙어서 데이터를 수집할 수 있다.
  2. beats가 수집한 데이터를 logstash에서 적절하게 처리한 뒤 es로 보낸다 ex) GMT 형식의 timestamp값을 KST로 변환 등
  3. elasticsearch는 이 데이터를 인덱싱하여 저장한다.
  4. elasticsearch와 연결된 kibana UI에서 해당 데이터를 볼 수 있다.

Tracing

Tracing은 마이크로서비스 아키텍처에서 발생한 Event를 발생한 순서대로 나열해서 보여줍니다.

AWS에서는 Amazon X-Ray가 있고, OSS로는 Zipking, Jaeger, Spring Cloud Sleuth ,pinpoint등이 있습니다. 시간 순으로 요청을 보여주고 어떤 단계에서 성공 혹은 실패를 했는지 보여줌으로써 어떤 구간에서 이벤트가 발생했는지 파악할 수 있습니다.

 

 

Spring Cloud Sleuth + Zipkin

 

MSA 환경에서는 클라이언트의 호출은 내부적으로 여러 단계들을 거쳐서 일어나기 때문에 추적이 쉽지 않다.

추적을 하기 위로서는 서로 연관된 ID(span, trace)가 필요한데, 이를 자동으로 생성해주는 것이 Spring Cloud sleuth이다.

출처: callistaenterprise , zipkin 화면

 

Trace ID

  • 최초 호출시 실행되는 서비스에서 생성

Span ID

  • 하나의 작업 단위, 각 서비스 호출시 새로운 Span ID가 생성
  • Trace중 첫번째 생성된 Span ID를 Root Span이라 부름

 

출처:  https://happyer16.tistory.com/entry/Sleuth란

 

 

 

6. CI/CD

CI/CD란?

CI/CD 는 어플리케이션의 개발부터 제공 및 배포단계를 자동화 하여 고객에게 짧은 주기에 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합(Continuous Integration), 지속적인 서비스 제공(Continuous Delivery), 지속적인 배포(Continuous Deployment)입니다. - MSA school

 

지속적인 통합(Continuous Integration)

  • "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미
  • 이것은 모든 개발이 끝난 후에 코드 품질을 관리하는 고전적인 방식의 단점을 해결하기 위하여 나타났다.
  • 결론적으로 개발코드를 통합할때의 문제점을 해결하고, 자동화 시켜 지속적으로 유지 시키는 방법이 “CI” 이다.
    • 개발자가 코드를 커밋만 치면 자동으로 빌드, 통합을 하고, 테스트를 하는 과정을 의미한다.

 

지속적인 서비스 제공(Continuous Integration), 지속적인 배포(Continuous Deployment)

  • “CD"는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미
  • 어플리케이션을 항상 신뢰 가능한 수준으로 배포 될수 있도록 지속적으로 관리하자는 개념이다.
    • 두 가지 의미 모두 파이프라인의 단계에 대한 자동화를 뜻하지만, 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.
  • 지속적인 서비스 제공(Continuous Delivery)은 CI 프로세스를 통과 하는 모든 코드 변경 내용은 프로덕션 환경과 유사한 환경에 자동으로 게시하는 과정이다.
  • 지속적인 배포(Continuous Deployment)는 앞의 두 과정을 프로덕션 환경까지 자동 배포 혹은 의사결정에 의한 배포 할수 있는 환경을 구성하여 놓는 것이다.
  • 약간의 자동화 단계의 차이는 있지만 결국 “CD” 는 CI 가 이루어지고 난 후에 운영환경까지 배포를 하여, 실제 사용자가 사용할수 있게 만든다.

출처:continuous-integration-vs-delivery-vs-deployment

 

DevOps

  • DevOps란 개발(Dev)과 운영(Ops)을 따로 구분짓지않고 함께하는 것을 의미
  • 개발자와 운영을 담당담당자 사이의 소통, 협업, 통합 및 자동화를 강조하는 개발 방법론

 

DevOps의 이점

  • 속도: 작업속도가 빨라지면서 시장 변화에 더 잘 적응하고 효율적으로 비즈니스 성과를 창출 가능
  • 신속한 제공: 새로운 기능의 릴리즈와 버그 수정 속도가 빨라질수록 경쟁 우위를 차지할 수 있음
  • 안정성: APP 업데이트와 인프라 변경의 품질을 보장하며, CI/CD를 통해 변경 사항이 잘 적용됐는지 테스트 가능
  • 확장 가능: 규모에 따라 인프라와 개발 프로세스 운영, 관리 가능
  • 협업 강화: 개발자와 운영 부서 간의 협력을 통해 효과적인 팀 구축 가능
  • 보안: 자동화된 규정 준수 정책, 세분화된 제어 및 구성 관리 기술 사용 가능

 

참조

'Infrastructure' 카테고리의 다른 글

[Jenkins] Pipeline 기본 형식  (0) 2024.12.15
[Docker] Image 폐쇄망 옮기기  (0) 2024.11.30

'Infrastructure'의 다른글

  • 현재글[MSA] MSA의 구성요소

관련글

티스토리툴바