Service per-Container

“Service per-Container” 패턴은 마이크로서비스 아키텍처(MSA)의 배포 전략 중 하나로, 각 마이크로서비스를 독립적인 컨테이너에 배포하는 방식이다.

주요 특징

  1. 독립성: 각 서비스는 독립적인 컨테이너에 배포되어 자체적으로 실행된다. 이는 서비스 간의 격리를 보장하고, 각 서비스의 독립적인 확장과 관리를 가능하게 한다.
  2. 경량화: 컨테이너는 가상 머신에 비해 훨씬 가볍고 빠르게 시작할 수 있다. 이는 리소스 사용을 최적화하고 배포 속도를 향상시킨다.
  3. 이식성: 컨테이너화된 서비스는 개발, 테스트, 프로덕션 환경 간에 쉽게 이동할 수 있다. 이는 “한 번 빌드하고 어디서나 실행"이라는 원칙을 실현한다.
  4. 버전 관리: 각 서비스의 컨테이너 이미지는 독립적으로 버전 관리될 수 있어, 서비스별로 다른 버전을 쉽게 배포하고 롤백할 수 있다.

장점

  1. 확장성: 각 서비스를 독립적으로 확장할 수 있어, 특정 서비스의 부하 증가에 효과적으로 대응할 수 있다. 예를 들어, 사용자 서비스에 부하가 집중될 경우 해당 서비스의 컨테이너만 추가로 배포할 수 있다.
  2. 장애 격리: 한 서비스의 문제가 다른 서비스로 전파되는 것을 방지한다. 특정 서비스에 문제가 발생해도 다른 서비스는 정상적으로 작동할 수 있다.
  3. 기술 스택 다양성: 각 서비스는 독립적인 컨테이너에서 실행되므로, 서비스별로 다른 기술 스택을 사용할 수 있다. 예를 들어, 한 서비스는 Node.js를, 다른 서비스는 Java를 사용할 수 있다.
  4. 배포 유연성: 각 서비스를 독립적으로 배포할 수 있어, 전체 시스템을 중단하지 않고도 특정 서비스만 업데이트하거나 롤백할 수 있다.

단점

  1. 복잡성 증가: 여러 컨테이너를 관리하고 조율해야 하므로 시스템의 전반적인 복잡성이 증가할 수 있다. 이는 모니터링, 로깅, 네트워킹 등의 영역에서 추가적인 관리 부담을 초래할 수 있다.
  2. 리소스 오버헤드: 각 서비스가 독립적인 컨테이너에서 실행되므로, 전체적인 리소스 사용량이 증가할 수 있다.
  3. 통신 오버헤드: 서비스 간 통신이 네트워크를 통해 이루어지므로, 단일 프로세스 내 통신에 비해 오버헤드가 발생할 수 있다.

구현 시 고려사항

  1. 컨테이너 오케스트레이션: Kubernetes와 같은 컨테이너 오케스트레이션 도구를 사용하여 여러 컨테이너의 배포, 확장, 관리를 자동화할 수 있다.
  2. 서비스 디스커버리: 동적으로 변화하는 컨테이너 환경에서 서비스 간 통신을 위해 서비스 디스커버리 메커니즘이 필요하다. Kubernetes의 Service 리소스나 별도의 서비스 메시 솔루션을 활용할 수 있다.
  3. 로깅 및 모니터링: 분산된 환경에서의 효과적인 로깅과 모니터링을 위해 중앙화된 로깅 시스템과 모니터링 도구의 사용이 필요하다.
  4. 보안: 각 컨테이너의 보안을 개별적으로 관리해야 하며, 네트워크 보안, 이미지 보안, 런타임 보안 등 다양한 측면을 고려해야 한다.
  5. 컨테이너 이미지 최적화
    1. 기반 이미지 최소화
    2. 멀티 스테이지 빌드 적용
    3. 캐시 레이어 최적화
    4. 불필요한 파일 제거
  6. 네트워킹
    1. 서비스간 통신 설정
    2. 네트워크 보안 정책
    3. 로드 밸런싱

구현 방법

  1. 컨테이너 이미지 생성:
    • 각 마이크로서비스를 독립적인 컨테이너 이미지로 빌드한다.
    • Docker와 같은 도구를 사용하여 필요한 라이브러리와 종속성을 포함한 이미지를 생성한다.
  2. 컨테이너 오케스트레이션:
    • Kubernetes, Docker Swarm 등의 오케스트레이션 도구를 사용하여 컨테이너의 배포, 확장, 관리를 자동화한다.
    • 서비스 디스커버리, 로드 밸런싱, 자동 복구 등의 기능을 활용한다.
  3. 모니터링 및 로깅 설정:
    • Prometheus, ELK 스택 등 모니터링 및 로깅 도구를 사용하여 각 서비스의 상태와 로그를 중앙에서 수집하고 분석한다.

예시

예를 들어, 온라인 쇼핑몰 애플리케이션에서 주문 처리 서비스와 결제 서비스를 각각 독립적인 컨테이너로 패키징하여 배포할 수 있다. 이렇게 하면 주문 처리 서비스에 대한 업데이트나 확장을 결제 서비스에 영향을 주지 않고 수행할 수 있으며, 각 서비스의 부하에 따라 독립적으로 확장할 수 있다.

실제 운영 시나리오

  1. 배포 프로세스
    1. 이미지 빌드
    2. 이미지 테스트
    3. 컨테이너 배포
    4. 헬스 체크
  2. 모니터링과 로깅
    • 컨테이너 수준의 모니터링
    • 로그 집중화
    • 성능 메트릭 수집
  3. 장애 처리
    1. 장애 감지
    2. 상태 저장
    3. 새 컨테이너 시작
    4. 트래픽 전환

참고 및 출처