운영 환경에 마이크로서비스 구현하기

인포매텍 디지털 » Recursos » 운영 환경에 마이크로서비스 구현하기

실제 환경에서 마이크로서비스 아키텍처를 도입하는 것은 단순히 모놀리식 아키텍처를 더 작은 조각으로 나누는 것만이 아닙니다. 인프라, 팀, 프로세스, 데이터, 보안 및 운영 방식을 재고하는 것을 의미합니다 . 시스템이 이론에서 프로덕션 클러스터로 이전될 때 서비스 검색, 팀 간 계약, CI/CD, 관찰 가능성, 복원력 및 확장성과 관련된 문제가 발생합니다. 이러한 문제를 제대로 해결하지 못하면 마이크로서비스가 분산된 혼란으로 이어질 수 있습니다.

다행히도 오늘날 우리는 넷플릭스, 아마존, 구글 등 수백 개의 마이크로서비스를 운영해 온 대기업들로부터 축적된 풍부한 경험을 보유하고 있습니다 . 이러한 경험과 쿠버네티스 및 오픈시프트를 활용한 엔터프라이즈 환경의 모범 사례를 바탕으로, 우리는 제어력을 잃지 않고 대규모 마이크로서비스를 설계, 배포 및 운영하는 매우 견고한 접근 방식을 개발할 수 있습니다.

마이크로서비스를 프로덕션 환경에 배포해야 하는 이유(그리고 배포할 가치가 없는 경우는 언제일까요?)

잘 설계된 마이크로서비스 아키텍처를 사용하면 작고 자율적이며 다양한 기능을 갖춘 팀이 엔드투엔드 서비스를 책임지고 운영할 수 있습니다. 각 팀은 명확하게 정의된 컨텍스트 내에서 운영되고, 빈번하게 배포할 수 있으며, 서비스에 대한 완전한 책임을 지므로 개발 주기를 단축하고 새로운 기능 제공 속도를 높일 수 있습니다.

또 다른 핵심 이점은 서비스별 독립적인 확장이 가능 하다는 것입니다 . 카탈로그, 결제 또는 공용 API에서만 트래픽 급증이 발생하더라도 전체 애플리케이션의 규모를 과도하게 키울 필요가 없습니다. 각 마이크로서비스를 부하 패턴에 따라 수평적 또는 수직적으로 조정하고, 각 기능의 비용을 정확하게 측정하며, 특정 영역의 사용량이 급증하더라도 가용성을 유지할 수 있습니다.

이러한 서비스의 패키징 및 배포 방식은 지속적이고 위험 부담이 적은 구현을 가능하게 합니다 . 각 마이크로서비스를 독립적으로 릴리스함으로써 새로운 아이디어를 테스트하고 문제가 있는 버전을 되돌리는 작업이 훨씬 간편해집니다. 카나리 배포, 블루/그린 롤백, 자동 롤백을 통해 장애 비용을 줄이고 실험의 여지를 확보할 수 있습니다.

기술적인 관점에서 마이크로서비스는 각 서비스에 사용할 언어, 프레임워크, 데이터베이스를 자유롭게 선택할 수 있도록 해줍니다 . 모든 요구 사항이 동일한 기술 스택에 맞는 것은 아닙니다. 비즈니스 서비스는 .NET이나 Java로, 데이터 처리는 Scala/Spark로, 특수 서비스는 Python이나 F#으로, AI 마이크로서비스는 R로 구현할 수 있습니다. 이러한 다양성을 통해 전체 애플리케이션을 기술적으로 완전히 바꾸지 않고도 각 상황에 맞는 적절한 도구를 사용할 수 있습니다.

또한, 시스템을 작고 명확하게 정의된 단위로 분해하면 기능을 빌딩 블록처럼 재사용 할 수 있습니다 . 더 큰 기능의 일부로 처음 개발된 마이크로서비스는 나중에 로직을 다시 작성하지 않고도 시스템의 다른 부분에서 필요한 요소로 재사용할 수 있습니다. 그리고 서비스들이 서로 격리되어 있기 때문에, 처음부터 복원력이 설계되었다면, 하나의 서비스에 장애가 발생하더라도 전체 시스템 장애가 아닌 부분적인 시스템 성능 저하로 이어지는 경우가 많습니다.

건축 및 서비스 디자인

마이크로서비스가 실제 운영 환경에서 제대로 작동하려면 서비스 경계와 책임 범위를 신중하게 설계하는 것부터 시작해야 합니다 . 실질적으로 이는 기존 모놀리식 시스템 내에서 논리적으로 어느 정도 분리된 대규모 기능 영역이나 비즈니스 도메인(예: 주문, 카탈로그, 사용자, 청구)과 같은 세분화되지 않은 서비스를 식별하는 것에서 시작됩니다.

이러한 큰 구성 요소에서 시작하여, 설계를 다듬어 일관된 데이터 세트를 기반으로 작동하고 , 자체 모델을 보유하며, 다른 서비스에서 읽거나 써야 할 내용을 정확히 알고 있는 세분화된 마이크로서비스를 얻는 과정이 포함됩니다. 이 과정은 일반적으로 도메인 주도 설계(DDD) 개념과 경계 컨텍스트를 활용하여 마이크로서비스가 "미니 모놀리스"가 되는 것을 방지합니다.

이러한 서비스를 제공하는 API는 잘 정의되고 안정적인 계약을 갖춰야 합니다 . 이는 엄격한 문서화(OpenAPI를 사용하는 REST, .proto 파일을 사용하는 gRPC 등), 명확한 버전 관리, 가능한 한 하위 호환성 유지, 그리고 프로덕션 환경에 배포되기 전에 호환성을 깨뜨리는 변경 사항을 감지하기 위한 자동화된 계약 검증을 의미합니다.

수십 또는 수백 개의 서비스가 있는 환경에서는 시스템이 부분적인 장애에 대비할 수 있도록 설계 단계부터 복원력 패턴을 통합하는 것이 매우 중요합니다 . 회로 차단기, 백오프를 사용한 재시도, 명확하게 정의된 타임아웃, 벌크헤드, 역압과 같은 패턴은 하나의 서비스 장애가 나머지 서비스에 영향을 미치는 것을 방지하는 데 도움이 됩니다. ChaosMonkey 또는 Gremlin과 같은 카오스 엔지니어링 도구는 시뮬레이션된 장애 상황에서 플랫폼의 동작을 실질적으로 테스트하는 데 유용합니다.

많은 복잡한 시스템은 비교적 간단한 CRUD 서비스와 진화하는 비즈니스 규칙을 처리하는 더욱 정교한 서비스를 결합합니다. 모든 마이크로서비스가 복잡한 내부 아키텍처를 필요로 하는 것은 아닙니다 . 일부는 기본적인 데이터 접근을 제공하는 간단한 HTTP 컨트롤러일 수 있으며, 주문 또는 청구 서비스와 같은 다른 서비스는 DDD, CQRS, 도메인 이벤트 등과 같은 고급 패턴을 활용할 수 있습니다.

운영 인프라: 클라우드, 컨테이너 및 Kubernetes/OpenShift

실제 경험에 따르면 마이크로서비스는 격리된 가상 머신보다 컨테이너와 오케스트레이션 기능을 갖춘 클라우드 인프라 에 배포했을 때 훨씬 더 나은 성능을 보여줍니다 . Kubernetes 및 OpenShift와 같은 플랫폼은 서비스를 컨테이너로 패키징하고, 확장, 업데이트, 로드 밸런싱 및 고가용성 관리를 위한 필수적인 기본 요소를 제공합니다.

일반적으로 각 마이크로서비스는 인프라 팀에서 관리하는 회사 기본 이미지(예: Java 서비스의 경우 OpenJDK 21)를 기반으로 하는 컨테이너 이미지로 패키징 됩니다 . 이 기본 이미지는 보안 패치로 최신 상태로 유지되며, 새 버전이 출시되면 개발 팀은 해당 환경에 서비스를 다시 빌드하고 재배포해야 합니다.

Kubernetes/OpenShift에서 기본 배포 단위는 Pod이며, Pod는 하나 이상의 컨테이너를 캡슐화합니다 . 일반적으로 마이크로서비스는 Pod 유형에 해당하며, Deployment(상태 비저장 서비스용) 또는 StatefulSet(상태가 연결된 서비스용)과 같은 리소스를 사용하여 배포됩니다. 테스트, 사전 프로덕션 및 프로덕션 환경이 중요도에 적합한 가용성 수준을 확보할 수 있도록 처음부터 환경별 최소 복제본 수를 정의합니다.

자동 스케일링은 CPU, 메모리 또는 기타 사용자 지정 메트릭과 같은 지표를 기반으로 복제본 수를 조정하는 HorizontalPodAutoscaler(HPA)를 사용하여 구현됩니다 . 또한 플랫폼은 동일한 서비스의 복제본을 여러 노드에 분산하여 단일 노드 장애로 인해 모든 인스턴스가 다운되는 것을 방지하기 위해 Pod 안티 어피니티 규칙을 구성해야 합니다.

수직적 크기 조정과 관련하여 resources.requests 및 resources.limits 는 파드가 사용할 수 있는 CPU 및 메모리 범위를 정의하는 데 사용됩니다. 예를 들어, Java 서비스의 경우 최소 100MB의 CPU와 256MB의 메모리를 예약하고 각각 최대 500MB와 2GB까지 허용하려면 JVM(Xms, Xmx, Xss)을 조정하여 컨테이너 리소스를 효율적으로 사용할 수 있습니다.

상태 관리: 상태 비저장 및 상태 저장 마이크로서비스

대부분의 비즈니스 마이크로서비스는 상태 비저장 서비스 로 설계됩니다 . 즉, 파드는 재부팅 후에도 유지되어야 하는 정보를 저장하지 않습니다. 상태는 외부 데이터베이스, 메시지 큐 또는 기타 저장소에 저장됩니다. 이러한 접근 방식은 모든 복제본이 모든 요청을 처리할 수 있으므로 동적 수평 확장과 원활한 배포를 가능하게 합니다.

하지만 상태를 저장하는 마이크로서비스를 영구 볼륨으로 지원 해야 하는 시나리오도 있습니다 . 일부 데이터베이스, 분산 파일 시스템 또는 로컬 데이터 유지가 필요한 구성 요소가 이에 해당합니다. 이러한 파드는 일반적으로 StatefulSet으로 배포되고 PersistentVolumeClaims를 사용하여 PersistentVolume에 연결되며 수평 확장보다는 수직 확장을 수행합니다.

마이크로서비스에 영구 저장소가 필요한 경우, 크기, 접근 모드 및 사용 목적을 명시하여 PersistentVolumeClaim(PVC)을 요청합니다. 운영팀은 플랫폼 정책에 따라 PVC를 프로비저닝합니다. 이 PVC는 배포 매니페스트에 참조되고 파드에 마운트되어 서비스가 데이터를 영구적으로 읽고 쓸 수 있게 됩니다.

상태 저장 모델이 특정 상황에서는 필요할 수 있지만, 일반적으로는 가능한 한 많은 서비스를 상태 비저장 방식으로 유지하는 것이 좋습니다 . 이렇게 하면 배포, 확장, 복원력 및 재해 복구가 간소화되고, 마이크로서비스가 많은 환경에서 운영 복잡성이 줄어듭니다.

데이터 분산화 및 서비스 주권

기존 인프라에서는 효율성을 극대화하기 위해 데이터베이스와 스토리지를 중앙 집중화하는 것이 일반적입니다. 하지만 마이크로서비스 환경에서는 이러한 접근 방식이 팀의 자율성과 서비스 간 결합도 저하와 충돌합니다 . 여러 서비스가 동일한 관계형 스키마를 공유하는 경우, 구조적 변경으로 인해 여러 팀의 작업이 중단되거나 의도치 않게 호환성이 깨질 수 있습니다.

따라서 권장되는 방식은 각 마이크로서비스가 자체 데이터 모델과 데이터베이스를 소유하는 것 입니다 . 단, 개발 환경에서는 배포를 단순화하기 위해 해당 데이터베이스가 클러스터 내 컨테이너로 실행됩니다. 프로덕션 환경에서는 일반적으로 클라우드 관리형 인스턴스 또는 기타 고가용성 데이터베이스 서버를 사용하며, 항상 명확한 소유권 경계를 유지합니다.

이는 데이터 통합이 전혀 없다는 의미가 아닙니다. 서비스 간의 일관성은 이벤트와 비동기 메시징을 통해 관리되며 , 합리적인 경우 최종 일관성을 수용한다는 의미입니다. 마이크로서비스 간의 상태 변경을 전파하고 단일 데이터베이스에 대한 강력한 의존성을 줄이기 위해 이벤트 버스(RabbitMQ, Azure Service Bus, Kafka 등)를 사용하는 것이 일반적입니다.

클라우드 플랫폼을 사용하면 팀은 단일 기술에 얽매이지 않고 각 서비스에 최적의 데이터베이스 유형 (관계형, 문서형, 키-값형, 시계열형 등)을 쉽게 선택할 수 있습니다. 핵심은 다른 서비스와의 계약을 위반하지 않고 스키마와 구조를 마이그레이션할 수 있도록 설계하고, 각 마이크로서비스의 도메인 경계에 맞춰 데이터 관련 결정을 내리는 것입니다.

분산형 거버넌스, 팀 및 조직

조직 구조 변경 없이 마이크로서비스로 전환하는 것은 문제를 야기할 수 있습니다. 네트워크, 시스템, 데이터베이스, 개발, 운영과 같은 기존의 기능별 사일로 구조 대신 , 개발, QA, DevOps 전문가와 필요에 따라 비즈니스 또는 데이터 분석가를 통합하는 제품 팀 기반의 구조가 권장됩니다.

각 팀은 동일한 기능 영역 내의 하나 이상의 마이크로서비스를 담당하며, 개발과 운영(구축 및 실행)을 모두 처리합니다 . 즉, 팀은 CI/CD 파이프라인을 관리하고, 특정 요구 사항을 충족하기 위해 인프라 팀과 협력하며, 모니터링 및 장애 대응에 참여합니다. 인프라 및 클라우드 플랫폼은 공통적이고 표준화된 서비스를 제공하는 데 중점을 둡니다.

분산형 거버넌스가 무질서로 전락하는 것을 방지하기 위해서는 승인된 기본 이미지, 배포 패턴, 네임스페이스 및 서비스 명명 규칙, API 가이드라인, Dockerfile 및 Kustomize 템플릿 등과 같은 간소화된 표준 및 공유 카탈로그를 정의하는 것이 중요 합니다. 이러한 가이드라인은 팀의 의사 결정 능력을 저해하지 않으면서 방향을 제시하는 "가드레일" 역할을 합니다.

많은 기업 환경에서는 프로젝트 또는 도메인별로 별도의 네임스페이스를 사용하며 , 개발, 사전 프로덕션, 프로덕션 환경별로 최소 하나씩을 사용합니다. 대규모 프로젝트의 경우, 내부 통신이 적절하게 구성되고 보안 규칙이 준수된다면 마이크로서비스를 여러 네임스페이스에 분산시킬 수 있습니다.

CI/CD, 자동화 및 GitOps 모델

수십 또는 수백 개의 마이크로서비스로 구성된 아키텍처의 경우, 이를 안정적으로 운영하는 유일한 방법은 엔드투엔드 자동화 에 막대한 투자를 하는 것입니다 . 여기에는 일관된 CI/CD 파이프라인, 선언적 배포 정의, 자동화된 테스트 및 자동 롤백 메커니즘이 포함됩니다.

일반적인 지속적 통합 및 배포 파이프라인은 코드 컴파일, 테스트 실행, SonarQube와 같은 도구를 사용한 품질 분석 , 회사 Dockerfile을 기반으로 컨테이너 이미지 빌드, 배포 매니페스트 업데이트 등을 처리합니다. 이후 ArgoCD 또는 유사한 시스템이 GitOps 방식을 사용하여 클러스터에 변경 사항을 적용합니다.

각 마이크로서비스 저장소에는 일반적으로 표준화된 Dockerfile, 파이프라인 구성 파일(예: ci.json) , 품질 분석용 속성, 그리고 환경별로 구분된 Kubernetes 정의(Kustomize 또는 Helm)가 포함된 배포 디렉터리가 있습니다. 저장소의 웹훅은 태그 푸시 또는 병합 요청과 같은 이벤트가 발생할 때 파이프라인을 트리거합니다.

GitOps 패턴은 Git 저장소를 인프라 및 배포의 진실의 원천으로 설정합니다 . 배포, 서비스, 구성 맵, PVC, SealedSecret 및 기타 리소스에 대한 매니페스트는 Git 저장소에서 버전 관리되며, 특정 도구를 사용하여 클러스터 상태를 Git에 정의된 내용과 동기화합니다. 이를 통해 추적성, 풀 리퀘스트 검토 및 간편한 롤백 기능을 제공합니다.

설정, 비밀 및 보안

성숙한 마이크로서비스 플랫폼에서는 구성 관리가 민감하지 않은 매개변수에는 ConfigMap을, 기밀 정보에는 Secret을 사용합니다 . 각 마이크로서비스는 일반적으로 환경별 ConfigMap을 가지며, 여기에는 종속 서비스의 URL, 기능 플래그, 튜닝 매개변수와 같은 속성이 저장됩니다.

비밀 정보(자격 증명, 키, 토큰, 인증서)는 엄격한 보안 정책 에 따라 관리됩니다 . 중요도가 낮은 환경에서는 개발팀에서 관리하는 평문 형태로 보관하는 것이 허용될 수 있지만, 사전 프로덕션 및 프로덕션 환경에서는 Sealed Secrets와 같은 도구 또는 특정 클라우드 기반 외부 관리 도구를 사용하여 암호화하는 것이 좋습니다.

여러 서비스 간에 비밀 정보를 공유해야 하는 경우(예: OTEL Collector 자격 증명 또는 공통 키 저장소 ), 네임스페이스별 구성 저장소에 중앙 집중식으로 저장할 수 있습니다. 해당 네임스페이스를 공유하는 프로젝트들은 필요에 따라 저장소를 업데이트하고, 이러한 리소스를 읽거나 수정할 수 있는 권한을 관리합니다.

통신 보안 측면에서 가장 일반적인 패턴은 제로 트러스트(Zero Trust) 입니다 . 트래픽이 "내부"라고 해서 무조건 안전하다고 여겨서는 안 됩니다. 내부 및 외부 서비스 간의 모든 호출은 mTLS, JWT 토큰 또는 이와 동등한 메커니즘을 사용하여 인증 및 권한 부여를 받아야 합니다. 마이크로서비스는 보안을 API 관리자나 네트워크에 맹목적으로 위임하지 않고 자체적인 검사도 수행합니다.

마이크로서비스, API 및 메시징 간의 통신

성숙한 마이크로서비스 아키텍처에서 통신 계층은 여러 경우로 나뉩니다. 클라이언트(브라우저, 모바일 앱, 제3자)에서 백엔드로의 트래픽에는 API 관리자가 관리하는 공개 API가 사용됩니다 . 이러한 API는 일반적으로 RESTful 방식(종종 OpenAPI 사용)이거나, 경우에 따라 게이트웨이를 통해 노출되는 gRPC 방식입니다.

같은 네임스페이스에 있는 마이크로서비스 간 호출 또는 같은 프로젝트 내의 여러 네임스페이스 간 호출은 일반적으로 내부 DNS를 사용하는 내부 Kubernetes 서비스를 통해 처리됩니다 . 이러한 호출은 공개 API Manager를 거치지 않지만 보안, 인증 및 권한 부여 정책을 준수합니다. 이러한 시나리오에서는 공통 정책을 적용하는 서비스 메시 또는 내부 게이트웨이를 사용할 수 있습니다.

마이크로서비스가 서로 다른 기능 영역이나 프로젝트 에 속할 경우 , 조직 차원에서의 통신은 "공개적"인 것으로 간주됩니다. 이러한 경우, 계약, 할당량, 보안, 버전 관리 및 감사 기능을 관리하는 API 관리자 또는 상호 운용성 버스를 사용하는 것이 일반적이며, 이를 통해 독립적인 클러스터 또는 네임스페이스 간의 직접적인 결합을 방지할 수 있습니다.

기존 시스템이나 외부 시스템처럼 최신 API를 제공하지 않는 시스템과의 통합에는 상호 운용성 버스를 통한 특정 커넥터 사용이 일반적입니다 . 이러한 방식을 통해 마이크로서비스는 공통 언어(예: 이벤트 또는 내부 REST API)를 사용하고, 커넥터는 향상된 보안을 유지하면서 기존 시스템과의 데이터 변환을 처리합니다.

동기 통신 외에도 비동기 메시징은 중요한 역할을 합니다 . 이는 프로세스 간 결합도를 낮추고, 트래픽 급증을 흡수하며, 서비스 간 비즈니스 이벤트를 전파하고, 복원력을 향상시키는 데 사용됩니다. 각 이벤트는 일반적으로 잘 정의되고 버전 관리되는 체계를 가지며, 생산자와 소비자 간의 충돌을 방지하기 위한 추적 메커니즘이 마련되어 있습니다.

관측 가능성, OTEL 수집기 및 작동

마이크로서비스로 구성된 시스템에서는 제대로 된 관찰 가능성 없이는 문제를 진단하는 것이 거의 불가능합니다. 그렇기 때문에 설계 단계부터 메트릭, 중앙 집중식 로깅, 분산 추적 기능을 통합하여 서비스 수준과 플랫폼 수준 모두에서 발생하는 상황을 파악할 수 있도록 합니다.

이 체계의 핵심 구성 요소는 OpenTelemetry Collector(OTEL Collector) 입니다 . OTEL Collector는 네임스페이스 또는 중앙 집중식으로 배포되어 모든 구성 요소에서 메트릭, 로그 및 추적 정보를 수집합니다. 마이크로서비스는 텔레메트리 데이터를 Collector로 전송해야 한다는 사실만 알면 됩니다. 그러면 Collector는 서비스가 세부 정보를 알 필요 없이 해당 데이터를 관찰 시스템(Prometheus, Grafana, Jaeger, Elastic 등)으로 전달합니다.

인프라 계층에서는 노드 수준의 컬렉터와 익스포터를 사용하여 파드에서 CPU, 메모리, 디스크, 네트워크 및 로그 메트릭을 수집하고 각각 Prometheus와 Elasticsearch로 전송합니다. Grafana 및 Kibana와 같은 도구를 사용하여 이 정보를 시각화하고, 대시보드를 구축하고, 스마트 임계값 및 관련 런북을 통해 알림을 정의합니다.

프로젝트에서 메트릭이나 추적 데이터에 대한 매우 특정한 처리가 필요한 경우, 운영 승인을 받고 프로덕션 유지 관리 모델이 명확하다면 해당 네임스페이스에 OTEL Collector의 자체 인스턴스를 배포할 수 있습니다.

테스트 전략, 계약 및 현지 개발 경험

분산 마이크로서비스 아키텍처를 테스트하려면 모놀리식 아키텍처를 테스트하는 것보다 훨씬 정교한 테스트 전략이 필요합니다 . 단위 테스트는 여전히 필수적이지만, API 및 이벤트에 대한 계약 테스트, 서비스 간 통합 테스트, 그리고 전체 흐름을 포괄하는 엔드투엔드 테스트의 중요성이 점점 더 커지고 있습니다.

호환성 문제를 방지하기 위해 클라이언트가 API에 대한 기대치를 정의하고 서비스 제공자가 이를 충족하는 소비자 중심 계약 테스트 와 같은 기법이 사용됩니다 . 모든 계약 변경 사항은 CI 파이프라인 내에서 자동화된 테스트를 거쳐 알려진 소비자에게 문제를 일으키는 배포를 방지합니다.

서비스 수가 100개를 넘어서면 전체 시스템을 로컬에 복제하는 것은 비현실적입니다. 따라서 개발은 종속 서비스의 시뮬레이션이나 원격 환경으로의 터널링 에 의존합니다 . 개발자는 일반적으로 마이크로서비스의 일부만 실행하고 나머지는 모의 객체, 가짜 객체 또는 시뮬레이터로 대체하거나 특정 호출을 공유 통합 환경으로 리디렉션합니다.

엔드투엔드 테스트는 기능 브랜치에서 생성된 임시 환경 또는 "미리 보기" 에 점점 더 의존하고 있습니다 . 이러한 환경은 해당 기능과 관련된 서비스만 포함된 격리된 환경을 구축합니다. 이를 통해 팀 간의 마찰을 최소화하고, "내 컴퓨터에서는 잘 작동하는데"라는 오류를 줄이며, 프로덕션 환경과 같이 비용이 많이 드는 환경에 도달하기 전에 통합 문제를 감지할 수 있습니다.

프로덕션 환경에서의 마이크로서비스 배포 패턴

Kubernetes 외에도 프로덕션 환경에서 사용되는 여러 마이크로서비스 배포 패턴이 있는데, 이러한 패턴들은 격리, 비용, 성숙도 측면에서 다양한 시나리오를 해결하기 때문에 알아두면 유용합니다 . 가장 오래된 패턴 중 하나는 호스트당 여러 서비스 인스턴스를 사용하는 방식입니다. 이 방식에서는 단일 물리적 또는 가상 호스트에서 여러 서비스의 인스턴스를 실행하며, 일반적으로 공유 애플리케이션 서버를 사용합니다.

VM 서비스 인스턴스별 패턴 에서는 각 서비스가 VM 이미지(예: EC2 AMI)로 패키징되어 자체 인스턴스에서 실행됩니다. 이는 높은 리소스 사용량과 느린 시작 시간을 감수해야 하지만 강력한 격리를 제공합니다. Packer와 같은 도구나 클라우드 제공업체별 솔루션을 사용하면 프로덕션 환경에 적합한 VM 이미지를 쉽게 생성할 수 있습니다.

오늘날 가장 널리 사용되는 패턴은 컨테이너별 서비스 인스턴스 방식 입니다 . 이 방식에서는 각 마이크로서비스가 컨테이너 이미지로 구축되어 오케스트레이터(Kubernetes, OpenShift 등)에 배포됩니다. 컨테이너는 가상 머신보다 가볍고 시작 속도가 매우 빠르며, 서비스에 필요한 모든 것을 패키징할 수 있어 배포를 간소화하고 자동 확장을 가능하게 합니다.

마지막으로, AWS Lambda와 같은 서버리스 방식이 인기를 얻고 있습니다. 이러한 방식은 HTTP 요청이나 다른 서비스(S3, DynamoDB, 큐 등)의 이벤트에 응답하는 함수들을 패키지화하며, 사용자는 사용한 만큼만 비용을 지불합니다. 이 방식은 특히 소규모 마이크로서비스나 수명이 짧은 이벤트 기반 작업에 적합하지만, 관찰 가능성, 콜드 스타트, 실행 시간 제한과 관련된 추가적인 고려 사항이 발생합니다.

실제로 많은 조직은 하이브리드 생태계를 구축하게 됩니다. 시스템의 핵심 부분은 컨테이너와 오케스트레이터에서 실행되고, 특정 보조 구성 요소는 서버리스 함수 또는 특수 VM으로 구현되며, 전체 시스템에 통합하기 위한 명확한 인터페이스와 잘 정의된 프로토콜을 항상 갖추게 됩니다.

이 모든 것을 실제 서비스에 적용할 때, 중요한 것은 단순히 기술을 선택하는 것뿐만 아니라 , 오류를 허용하고 필요에 따라 확장 가능하며 자동 배포되고 관찰 가능한 아키텍처를 구축하는 것입니다. 제품 중심의 팀, 효율적인 계약 관리, 분산된 데이터, 그리고 견고한 클라우드 플랫폼을 통해 마이크로서비스는 단순한 약속을 넘어 복잡한 애플리케이션을 수년간 효과적이고 지속 가능한 방식으로 발전시킬 수 있습니다.