기본 콘텐츠로 건너뛰기

라벨이 adapter인 게시물 표시

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

Multi-Container Design Patterns 정리 지난 몇 년동안 컨테이너 기술은 코드를 패키징하고 배포하는 대중적인 기술로 발전했다. 여기서도 컨테이너를 통해 분산 응용 프로그램을 구축 하는 방법의 변화에 대해 주목할 필요가 있다. 이번에는 마아크로 서비스 아키텍처에서 컨테이너늘 다루는데 사용할 수 있는 디자인 패턴 3가지에 대해서 정리해 본다. Sidecar Pattern 하나의 컨테이너는 하나의 책임만 가지고 있어야 한다. 예를 들면 웹 서버와 로그 수집기가 같이 존재하는 컨테이너가 있다고 가정했을 때 다음과 같은 고민을 하게 된다. 웹 서버를 수정할 때 로그 수집기의 종속성을 고려해야 한다. 직접적인 관련은 없더라도 오류가 발생했을 때 어디서 문제가 발생했는지 빠르게 파악하지 못할 수도 있다. 위의 같이 상관이 없음에도 고려할 부분이 생길 수 있기 때문에 서로 다른 역할을 하는 서비스는 각각의 컨테이너로 분리해 주는 것이 좋으며, 이런 상황에서 활용할 수 있는 패턴이 Sidecar Pattern 이다. Pod 내의 메인 컨테이너 (위의 그림에서는 Web Server Container)를 확장하고 향상 및 개선하는 역할을 컨테이너를 Sidecar Container 라고 하고, 이렇게 적용하는 패턴을 Sidecar Pattern 이라고 한다. 서로 다른 컨테이너이며 단지 Pod내에 묶여 있는 것이기 때문에 서로 간에 종속성이나 간섭의 문제가 생기지 않는다. 당연히 Web Server를 교체하더라도 로그 수집기 컨테이너는 변경이 없고 특정 기능을 활용하도록 재 사용성이 증가하는 효과를 가져오게 된다. Ambassador Pattern 메인 컨테이너의 네트워크 연결을 전담하는 프록시 컨테이너를 두는 패턴이다. Sidecar Pattern 이 이미 완성되고 동작하는 애플리케이션에 기능 추가를 위한 변경이 없이 보조 기능으로 추가해서 활용하는 측면을 강조한 것이라면 Ambassador Pattern은 개별 기능만을 중점