Article Source

• 사이드카 패턴

Sidecar Pattern

격리 및 캡슐화를 제공하는 별도의 프로세스 또는 컨테이너에 애플리케이션 구성 요소를 배포합니다. 이 패턴을 사용하면 애플리케이션을 서로 다른 유형의 구성 요소 및 기술로 구성할 수도 있습니다.

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

컨텍스트 및 문제

애플리케이션 및 서비스에는 모니터링, 로깅, 구성 및 네트워킹 서비스 등의 관련 기능이 필요한 경우가 있습니다. 이러한 주변 작업은 별도 구성 요소 또는 서비스로 구현할 수 있습니다.

이러한 작업이 애플리케이션에 긴밀하게 통합된 경우 애플리케이션과 동일한 프로세스에서 실행되어 공유 리소스를 효과적으로 사용할 수 있습니다. 그러나 이는 제대로 격리되지 않았음을 의미하며 이러한 구성 요소 중 하나가 중단되면 다른 구성 요소 또는 전체 애플리케이션에 영향을 줄 수 있습니다. 또한 일반적으로 상위 애플리케이션과 동일한 언어를 사용하여 구현해야 합니다. 결과적으로 구성 요소 및 애플리케이션은 서로 긴밀하게 상호 종속됩니다.

애플리케이션을 서비스로 분해할 경우 각 서비스를 다른 언어와 기술을 사용하여 빌드할 수 있습니다. 이렇게 하면 유연성이 높아지지만 각 구성 요소에 고유 종속성이 있으며 상위 애플리케이션과 공유되는 모든 리소스 및 기본 플랫폼에 액세스하는 데 언어별 라이브러리가 필요하게 됩니다. 또한 이러한 기능을 별도 서비스로 배포하면 애플리케이션에 대기 시간이 추가될 수 있습니다. 이러한 언어별 인터페이스에 대한 코드 및 종속성 관리로 인해 상당한 복잡성이 추가될 수도 있습니다(특히 호스팅, 배포 및 관리의 경우).

해결 방법

기본 애플리케이션과 결합되는 작업 집합을 함께 배치하지만 해당 프로세스 또는 컨테이너 내에 배치하여 여러 언어 간에 플랫폼 서비스에 같은 유형의 인터페이스를 제공합니다.

사이드카 서비스는 애플리케이션의 일부일 필요는 없지만 애플리케이션에 연결되어 있습니다. 상위 애플리케이션의 이동 위치로 어디든 이동합니다. 사이드카는 기본 애플리케이션을 사용하여 배포되는 프로세스 또는 서비스를 지원합니다. 오토바이의 경우 사이드카는 하나의 오토바이에 연결되고 각 오토바이는 자체 사이드카를 가질 수 있습니다. 마찬가지로 사이드카 서비스는 해당 상위 애플리케이션과 함께 운용됩니다. 애플리케이션의 각 인스턴스에 대해 사이드카의 인스턴스가 배포되고 그 옆에 호스트됩니다.

사이드카 패턴 사용의 장점은 다음과 같습니다.

• 사이드카는 런타임 환경 및 프로그래밍 언어와 관련하여 해당 기본 애플리케이션과 독립적이므로 언어마다 하나의 사이드카를 개발할 필요가 없습니다.
• 사이드카는 기본 애플리케이션과 동일한 리소스에 액세스할 수 있습니다. 예를 들어 사이드카는 사이드카 및 기본 애플리케이션 둘 다에서 사용하는 시스템 리소스를 모니터링할 수 있습니다.
• 기본 애플리케이션에 근접하기 때문에 둘 간에 통신할 때 상당한 대기 시간이 없습니다.
• 확장성 메커니즘을 제공하지 않는 애플리케이션의 경우에도 사이드카를 사용하여 기본 애플리케이션과 동일한 호스트 또는 하위 컨테이너에서 자체 프로세스로 연결하여 기능을 확장할 수 있습니다.

사이드카 패턴은 컨테이너와 함께 사용되는 경우가 많으며 사이드카 컨테이너 또는 사이드킥 컨테이너라고도 합니다.

문제 및 고려 사항

• 서비스, 프로세스 또는 컨테이너를 배포하는 데 사용할 배포 형식 및 패키지 형식을 고려합니다. 특히 컨테이너는 사이드카 패턴에 매우 적합합니다.
• 사이드카 서비스를 디자인할 때는 프로세스 간 통신 메커니즘을 신중하게 결정합니다. 성능 요구 사항으로 불가능하게 되는 경우가 아니라면 언어(또는 프레임워크) 중립적 기술을 사용해 봅니다.
• 사이드카에 기능을 설정하기 전에 별도 서비스 또는 전형적인 디먼 중 어느 것으로 더 잘 작동할지 고려합니다.
• 또한 기능을 라이브러리로 구현할 수 있는지 또는 전형적인 확장 메커니즘을 사용하여 구현할 수 있는지도 고려합니다. 언어별 라이브러리는 심도 있게 통합되어 있으며 네트워크 오버헤드는 적습니다.

이 패턴을 사용해야 하는 경우

다음 경우에 이 패턴을 사용합니다.

• 기본 애플리케이션이 다른 유형의 언어 세트 및 프레임워크를 사용합니다. 사이드카 서비스에 있는 구성 요소는 다양한 프레임워크를 사용하여 서로 다른 언어로 작성된 애플리케이션에서 사용할 수 있습니다.
• 구성 요소가 원격 팀 또는 다른 조직에 있습니다.
• 구성 요소 또는 기능을 애플리케이션과 동일한 호스트에 함께 배치해야 합니다.
• 주 애플리케이션의 전체 수명 주기를 공유하지만 개별적으로 업데이트할 수 있는 서비스가 필요합니다.
• 특정 리소스 또는 구성 요소에 대한 리소스 제한을 세부적으로 제어해야 합니다. 예를 들어 특정 구성 요소가 사용하는 메모리의 양을 제한할 수 있습니다. 사이드카로 구성 요소를 배포하고 주 애플리케이션과 별개로 메모리 사용량을 관리할 수 있습니다.

다음 경우에는 이 패턴이 적합하지 않을 수 있습니다.

• 프로세스 간 통신을 최적화해야 할 경우. 상위 애플리케이션과 사이드카 서비스 간의 통신에 일부 오버헤드(특히 호출 시 대기 시간)가 포함됩니다. 이에 대해서는 자주 발생하는 인터페이스에서 절충이 허용될 수 없습니다.
• 각 인스턴스에 대한 사이드카 서비스를 배포하는 리소스 비용에 격리를 통한 이점만큼 가치가 있지 않은 소규모 애플리케이션의 경우
• 서비스를 주 애플리케이션과 다르거나 독립적으로 확장해야 할 경우. 이 경우에는 별도 서비스로 기능을 배포하는 것이 나을 수도 있습니다.

예제

사이드카 패턴은 많은 시나리오에 적용할 수 있습니다. 일부 일반적인 예는 다음과 같습니다.

• 인프라 API. 인프라 개발 팀은 인프라에 액세스할 언어별 클라이언트 라이브러리 대신 각 애플리케이션과 함께 배포되는 서비스를 만듭니다. 서비스는 사이드카로 로드되고 로깅, 환경 데이터, 구성 저장소, 검색, 상태 검사 및 watchdog 서비스를 비롯한 인프라 서비스에 대한 공통 계층을 제공합니다. 또한 사이드카는 상위 애플리케이션의 호스트 환경 및 프로세스(또는 컨테이너)를 모니터링하고 중앙 집중식 서비스에 정보를 기록합니다.
• NGINX/HAProxy 관리. 환경 상태를 모니터링한 다음 NGINX 구성 파일을 업데이트하고 상태 변경이 필요한 경우 프로세스를 재활용하는 사이드카 서비스를 사용하여 NGINX를 배포합니다.
• 특사 사이드카. 특사 서비스를 사이드카로 배포합니다. 애플리케이션이 요청 로깅, 라우팅, 회로 차단 및 기타 연결 관련 기능을 처리하는 특사를 통해 호출합니다.
• 오프로드 프록시. 서비스에 대한 사용 중인 정적 파일 콘텐츠를 처리하도록 NGINX 프록시를 node.js 서비스 인스턴스 앞에 배치합니다.

관련 지침

• 특사 패턴 : 소비자 서비스 또는 애플리케이션을 대신하여 네트워크 요청을 보내는 도우미 서비스를 만드는 Ambassador Pattern