• 다음과 같이 불린다.
    • 사이드카
    • 사이드킥

개요

주 애플리케이션과 응집력 있는 작업 집합을 공동 배치하지만 자체 프로세스 또는 컨테이너 내에 배치하여 언어 간 플랫폼 서비스에 대한 동질적인 인터페이스를 제공합니다. 1

From: 소프트웨어 아키텍처 101

앞서 마이크로서비스가 커플링보다 복제를 선호한다고 했습니다. 그러면 모니터링, 로깅, 회로 차단기 등의 운영 관심사와 같이 실제로 커플링이 더 유리한 아키텍처 부분은 어떻게 처리해야 할까요? 전통적인 서비스 지향 아키텍처의 철학에 따르면 도메인이든 운영이든 가급적 많은 기능을 재사용하는 것이 좋습니다. 마이크로서비스 아키텍트는 이 두 가지 관심사를 분리하고자 합니다.

여러 마이크로서비스를 구축한 이후에 잘 살펴보면 각 마이크로서비스에 공통적인 요소가 있고 그 유사성을 활용하면 더 유리한 부분이 있음을 알게 됩니다. 예를 들어, 서비스 팀마다 자체 모니터링 체제를 구축하도록 허용하면 팀별로 알아서 잘하리라 장담할 수 있을까요? 또 업그레이드 같은 문제는 어떻게 처리할까요? 모니터링 도구를 새 버전으로 업그레이트하는 작업을 각 팀별 책임으로 부과해야 할까요? 그리고 그 작업은 얼마나 오래 걸릴까요?

이 문제를 해결하는 방법이 바로 사이드카 패턴sidecar pattern입니다.

[그림 17-2]에서 보다시피, 공통 운영 관심사를 각 서비스마다 별도의 컴포넌트에 두고, 해당 팀이나 공유 인프라팀이 소유할 수 있도록 합니다. 사이드카 컴포넌트는 팀이 서로 커플링되면 더 유리한 모든 운영 관심사를 도맡아 처리합니다. 따라서 가령 모니터링 도구를 업그레이드할 때가 되면 공유 인프라팀이 사이드카를 업데이트하는 방식으로 각 마이크로서비스는 신기능을 받아 사용할 수 있습니다.

각 서비스에는 공통 사이드카가 포함돼 있으므로 서비스 메시service mesh를 구축하면 로깅, 모니터링 등의 관심사를 아키텍처 전체적으로 일원화하여 제어할 수 있습니다. 공통 사이드카 컴포넌트는 모든 마이크로서비스에 대해 일관된 운영 인터페이스를 제공합니다. 2

From: 소프트웨어 아키텍처 The Hard Parts

사이드카 패턴은 기술(인프라) 로직과 도메인 로직을 분리한다는, [[/architecture/hexagonal]]{육각형 아키텍처}와 동일한 개념을 응용한 것입니다. 예를 들어, [그림 8-13]처럼 두 마이크로서비스가 있다고 합니다.3

두 서비스 모두 운영 관심사(서비스 아랫 부분의 규모가 더 큰 컴포넌트)와 도메인 관심사('도메인'이라고 표시된 서비스 윗쪽의 박스들)가 서로 분리돼 있습니다. 운영 기능의 일관성을 중시하는 아키텍트라면 분리 가능한 파트를 사이드카 컴포넌트에 집어넣을 것입니다. 사이드카는 오토바이 옆에 나란히 붙어 있는 사이드카sidecar를 비유적으로 표현한 명칭입니다. 사이드카의 구현부는 팀별로 알아서 공유하거나 별도의 인프라 팀이 관리합니다. 아키텍트가 모든 서비스에 사이드카를 두기로 했다면 서비스 플레인service plane을 통해 부착된 사이드카가 모든 서비스를 통틀어 일관된 운영 인터페이스 역할을 합니다.

모든 서비스가 (피트니스 함수로 관리되는) 사이드카 컴포넌트를 갖고 있다는 전제하에 전체적으로는 [그림 8-15]와 같은 서비스 메시service mesh 구조가 됩니다. 각 서비스 우측에 있는 사이드카 박스에 서로 맞물려 말 그대로 '메시mesh(그물, 망(網))'가 형성되는 것입니다.

아키텍트와 데브옵스 담당자는 이러한 메시를 이용해 대시보드를 만들거나 확장성 같은 운영 특성을 제어하는 등 여러 가지 일을 할 수 있습니다. 4

From: learn.microsoft.com

이 패턴은 오토바이에 연결된 사이드카와 유사하므로 사이드카라고 합니다. 패턴에서 사이드카는 부모 애플리케이션에 연결되고 애플리케이션에 대한 지원 기능을 제공합니다. 또한 사이드카는 부모 애플리케이션과 동일한 수명 주기를 공유하며, 부모와 함께 생성 및 사용 중지됩니다. 사이드카 패턴은 사이드킥 패턴이라고도 하며 분해 패턴입니다. 1

From: 마스터링 분산 추적

도커에 의해 대중화된 컨테이너의 출현으로 사이드카라는 새로운 아키텍처 패턴이 등장했다. 이 패턴에서는 주요 애플리케이션 기능을 보완하는 태스크(task)와 분산 애플리케이션 내의 여러 서비스에서 공통으로 사용되는 태스크는 각 서비스에 함께 배치되지만 자체 경량 프로세스 또는 컨테이너 내에 위치한다. 이를 통해 다양한 언어들에 대한 플랫폼 서비스를 위한 동종 서비스를 제공할 수 있다. 중앙의 ESB5를 통과하는 모든 서비스 간 통신 대신, 서비스 탐색이나 라우팅 등과 같은 통신에 필요한 인프라 요구사항을 처리하는 각 마이크로서비스 옆에 사이드카 컨테이너가 배포된다. 사이드카 패턴을 사용하면 다음과 같은 이점이 있다.

  • 사이드카는 메인 애플리케이션과 별도로 자체 언어로 구현할 수 있다.
  • 사이드카는 메인 애플리케이션과 함께 배치된다. 따라서 두 애플리케이션 사이에 큰 시간 지연은 없다(약간의 시간 지연은 있다).
  • 사이드카 각각은 단일 서비스의 단일 인스턴스만 처리하므로 오작동하는 사이드카 프로세스가 해당 인스턴스의 상태에 영향을 미칠 수 있지만 나머지 애플리케이션에는 영향을 미치지 않는다(전역 환경설정을 잘못 변경할 경우 이론상 모든 사이드카에 동시에 영향을 미칠 수는 있다).
  • 사이드카는 애플리케이션 자체가 확장 기능을 제공하지 않더라도 메인 애플리케이션의 확장 메커니즘으로 작동한다. 예를 들어, 외부 애플리케이션은 모니터링 신호를 노출하지 않을 수 있지만 사이드카는 이를 보완할 수 있다.
  • 사이드카의 수명주기 및 ID는 메인 애플리케이션의 수명주기 및 ID와 관련돼 있어서 사이드카가 인증 및 트랜스포트-레벨의 보안과 같은 의무사항들을 수행할 수 있다.

6

참고문헌

  • Sidecar pattern(learn.microsoft.com)
  • 소프트웨어 아키텍처 101 / 마크 리처즈, 닐 포드 저/이일웅 역 / 한빛미디어 / 초판 1쇄 발행 2021년 11월 01일 / 원제: Fundamentals of Software Architecture
  • 소프트웨어 아키텍처 The Hard Parts / 닐 포드, 마크 리처즈, 프라모드 세달라지, 세막 데그하니 저/이일웅 역 / 한빛미디어 / 초판1쇄 발행: 2022년 10월 01일 / 원제: Software Architecture: The Hard Parts
  • 마스터링 분산 추적 / 유리 슈쿠로 저/홍성민, 남궁영환 역 / 위키북스 / 초판 발행: 2020년 02월 21일 / 원제: Mastering Distributed Tracing by Yuri Shkuro

주석

  1. 사이드카 패턴(learn.microsoft.com) ↩ ↩2

  2. 소프트웨어 아키텍처 101. 17.6장. 307쪽. ↩

  3. 이 이미지는 '소프트웨어 아키텍처 101'의 그림 17-2와 똑같으므로 생략. ↩

  4. 소프트웨어 아키텍처 The Hard Parts. 8.4장. 289쪽. ↩

  5. ESB(Enterprise Service Bus) ↩

  6. 마스터링 분산 추적. 7장. 215쪽. ↩