기본 콘텐츠로 건너뛰기

[Container] Multi-Container Design Patterns 간략 비교

Multi-Container Design Patterns 정리

지난 몇 년동안 컨테이너 기술은 코드를 패키징하고 배포하는 대중적인 기술로 발전했다. 여기서도 컨테이너를 통해 분산 응용 프로그램을 구축하는 방법의 변화에 대해 주목할 필요가 있다.

이번에는 마아크로 서비스 아키텍처에서 컨테이너늘 다루는데 사용할 수 있는 디자인 패턴 3가지에 대해서 정리해 본다.

Sidecar Pattern

하나의 컨테이너는 하나의 책임만 가지고 있어야 한다.

예를 들면 웹 서버와 로그 수집기가 같이 존재하는 컨테이너가 있다고 가정했을 때 다음과 같은 고민을 하게 된다.

  • 웹 서버를 수정할 때 로그 수집기의 종속성을 고려해야 한다.
  • 직접적인 관련은 없더라도 오류가 발생했을 때 어디서 문제가 발생했는지 빠르게 파악하지 못할 수도 있다.

위의 같이 상관이 없음에도 고려할 부분이 생길 수 있기 때문에 서로 다른 역할을 하는 서비스는 각각의 컨테이너로 분리해 주는 것이 좋으며, 이런 상황에서 활용할 수 있는 패턴이 Sidecar Pattern이다.

Sidecar Pattern in Pod

Pod 내의 메인 컨테이너 (위의 그림에서는 Web Server Container)를 확장하고 향상 및 개선하는 역할을 컨테이너를 Sidecar Container라고 하고, 이렇게 적용하는 패턴을 Sidecar Pattern 이라고 한다.

서로 다른 컨테이너이며 단지 Pod내에 묶여 있는 것이기 때문에 서로 간에 종속성이나 간섭의 문제가 생기지 않는다. 당연히 Web Server를 교체하더라도 로그 수집기 컨테이너는 변경이 없고 특정 기능을 활용하도록 재 사용성이 증가하는 효과를 가져오게 된다.

Ambassador Pattern

메인 컨테이너의 네트워크 연결을 전담하는 프록시 컨테이너를 두는 패턴이다.
Sidecar Pattern 이 이미 완성되고 동작하는 애플리케이션에 기능 추가를 위한 변경이 없이 보조 기능으로 추가해서 활용하는 측면을 강조한 것이라면 Ambassador Pattern은 개별 기능만을 중점적으로 처리하는 기능 모듈과 같은 패턴이다.

따라서 Sidecar Pattern 과는 달리 사용할 기능을 가진 모듈에 종속성이 존재하게 된다.

Ambassador Pattern in Pod

위의 그림에서와 같이 Pod 내에서 메인 어플리케이션 컨테이너는 자체 기능에 집중하고 네트워크와 관련된 부분은 Proxy Ambassador 컨테이너가 전담하는 방식이다.

Adapter Pattern

Adapter Pattern은 메인 애플리케이션의 기능을 표준화해서 다양한 기능들을 표준화에 맞춰서 연결하는 패턴을 의미한다.

Adapter Pattern in Pod

위의 그림과 같이 동작하고 있는 애플리케이션에 대한 모니터링 정보를 수집하는 경우에 직접 구현하는 것이 아니라 표준화된 모니터링 데이터 I/O 를 정의해 놓고 실제 기능은 Adapter 에처 처리하는 방식으로 원하는 기능을 표준화해서 다양한 유형으로 연계하는 방식이다.

3가지 패턴의 차이점

3가지 패턴은 딱 구별하기 힘들다. 어떤 패턴을 쓰더라도 원하는 기능은 만족시킬 수가 있다. 따라서 패턴의 차이점은 목적이 무엇인지를 기준으로 차이점을 볼 수 있다.

  • Sidecar Pattern : 메인 컨테이너의 변경없이 기능을 확장 또는 향상 시키는 목적
  • Ambassador Pattern : 메인 컨테이너의 특정 기능을 전담하는 종속성을 특화 시키는 목적 (물론 다른 애플리케이션에도 사용할 수 있도록 독립적이어야 한다)
  • Adapter Pattern : 메인 컨테이너의 입/출력 표준화를 통한 다양한 연계 구성을 교체가능하도록 하는 목적 (ex. Databases, Files, ...)

참고 자료

댓글