1228 마이크로서비스 아키텍처(MSA) 배포와 미래: 서버리스, 서비스 메시
✅ 1. MSA 배포 전략: CI/CD 파이프라인
-
CI/CD (지속적 통합/배포)는 마이크로서비스 아키텍처를 성공적으로 운영하기 위한 필수적인 전제조건입니다. 수십 개의 서비스를 수동으로 배포하고 관리하는 것은 불가능하기 때문입니다.
-
마이크로서비스 환경에서의 CI/CD 파이프라인:
- 서비스별 독립 파이프라인: 각 마이크로서비스는 자신만의 독립적인 Git 리포지토리와 독립적인 CI/CD 파이프라인을 가집니다.
- 빌드 및 컨테이너화: 개발자가 특정 서비스의 코드를 푸시하면, 해당 서비스의 파이프라인이 트리거되어 코드를 빌드하고, 테스트한 후, Docker 이미지를 생성합니다.
- 이미지 레지스트리: 생성된 이미지는 버전 태그와 함께 중앙 이미지 레지스트리(AWS ECR 등)에 푸시됩니다.
- 배포 (Kubernetes 연동): CD 단계에서는
kubectl과 같은 도구를 사용하여, 운영 중인 쿠버네티스 클러스터의 Deployment 오브젝트가 사용하는 이미지 버전을 새로운 버전으로 업데이트합니다. - 롤링 업데이트: 쿠버네티스는 이 변경을 감지하고, 무중단 롤링 업데이트 전략에 따라 점진적으로 구버전 Pod를 새 버전 Pod로 교체하여 배포를 완료합니다.
-
핵심: 개발자는 자신의 서비스 코드만 푸시하면, 이 모든 과정이 자동으로 이루어져 몇 분 안에 변경 사항이 운영 환경에 반영됩니다.
✅ 2. 서버리스 컴퓨팅 (Serverless Computing)
-
서버리스는 개발자가 서버를 직접 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 컴퓨팅 실행 모델입니다. "서버가 없다"는 뜻이 아니라, 서버의 프로비저닝, 스케일링, 패치, 유지보수 등 서버 관리에 대한 모든 책임을 클라우드 공급자(AWS 등)에게 위임하는 것입니다.
-
FaaS (Function as a Service): 서버리스의 가장 대표적인 형태로, 특정 이벤트가 발생했을 때만 실행되는 작은 코드 조각(함수)을 작성하여 배포하는 방식입니다.
- 대표적인 서비스: AWS Lambda
➕ 서버리스의 특징 및 장점
- 이벤트 기반 실행: 코드는 요청이나 특정 이벤트가 발생했을 때만 실행됩니다. 평소에는 아무런 리소스도 차지하지 않습니다.
- 자동 확장 (Auto-scaling): 요청이 1초에 0개이든 1000개이든, 클라우드 공급자가 알아서 필요한 만큼의 컴퓨팅 자원을 순식간에 할당하고 확장해줍니다.
- 비용 효율성 (Pay-per-use): 코드가 실제로 실행된 시간(밀리초 단위)과 호출 횟수에 대해서만 비용을 지불합니다. 유휴(idle) 상태의 서버에 대한 비용이 전혀 없습니다.
- 운영 부담 감소: 개발자는 인프라 관리가 아닌, 오직 비즈니스 로직(함수 코드) 작성에만 집중할 수 있습니다.
➕ MSA와 서버리스
- 서버리스(FaaS)는 작고, 독립적이며, 특정 기능에 집중한다는 점에서 마이크로서비스의 철학과 매우 잘 맞습니다.
- API 게이트웨이와 연동하여, 특정 API 엔드포인트에 대한 요청을 AWS Lambda 함수가 처리하도록 구성하는 것은 매우 일반적인 서버리스 MSA 패턴입니다.
✅ 3. 서비스 메시 (Service Mesh)
-
문제점: 마이크로서비스의 수가 수십, 수백 개로 늘어나면, 서비스 간의 네트워크 통신이 매우 복잡해집니다.
- 서비스 간의 통신을 어떻게 암호화할 것인가?
- A 서비스가 B 서비스를 호출할 때, 타임아웃과 재시도는 어떻게 처리할 것인가?
- 어떤 서비스 간에 트래픽이 얼마나 오고 가는지 어떻게 모니터링할 것인가?
- 이러한 네트워크 관련 공통 기능(Cross-cutting Concerns)들을 모든 서비스의 비즈니스 코드 안에 중복해서 구현하는 것은 매우 비효율적입니다.
-
서비스 메시:
- 개념: 이러한 네트워크 관련 기능들을 비즈니스 로직으로부터 분리하여, 인프라 레벨에서 처리하고 관리하기 위한 전용 인프라 계층입니다.
- 동작 방식 (Sidecar Proxy):
- 서비스 메시는 애플리케이션 컨테이너(Pod)와 함께 "사이드카(Sidecar)"라고 불리는 매우 가벼운 프록시 컨테이너를 자동으로 배포합니다. (e.g., Envoy)
- 이제 모든 마이크로서비스는 다른 서비스와 직접 통신하는 것이 아니라, 자신의 옆에 있는 사이드카 프록시를 통해서만 모든 네트워크 트래픽을 주고받게 됩니다.
- 이 사이드카 프록시들의 네트워크를 데이터 플레인(Data Plane)이라고 하며, 이 프록시들의 동작을 중앙에서 제어하고 설정하는 부분을 컨트롤 플레인(Control Plane)이라고 합니다.
- 대표적인 솔루션: Istio, Linkerd
➕ 서비스 메시의 주요 기능
- 트래픽 관리: A/B 테스팅, 카나리 배포 등 정교한 트래픽 라우팅.
- 가시성 (Observability): 서비스 간의 요청/응답 시간, 성공/실패율 등 상세한 메트릭을 자동으로 수집하여 분산 추적 및 모니터링을 지원.
- 보안 (Security): 서비스 간의 모든 통신을 상호 TLS(mTLS)로 자동 암호화.
- 회복탄력성 (Resilience): 타임아웃, 재시도, 서킷 브레이커와 같은 기능을 비즈니스 코드 수정 없이 인프라 레벨에서 적용.
📌 요약
- MSA의 CI/CD 파이프라인은 각 서비스별로 독립적으로 구성되며, Git 푸시부터 쿠버네티스 클러스터에 롤링 업데이트로 배포되는 전 과정을 자동화합니다.
- 서버리스(AWS Lambda)는 서버 관리에 대한 부담 없이, 이벤트 기반으로 코드를 실행하고 사용한 만큼만 비용을 지불하는 매우 효율적인 컴퓨팅 모델로, MSA 구현에 적합합니다.
- 서비스 메시(Istio)는 사이드카 프록시를 이용하여, 서비스 간의 복잡한 네트워크 통신(트래픽 관리, 보안, 모니터링)을 비즈니스 로직과 분리하여 인프라 레벨에서 처리하는 MSA의 고급 네트워킹 솔루션입니다.
