격리 및 캡슐화를 제공하는 별도의 프로세스 또는 컨테이너에 애플리케이션 구성 요소를 배포합니다. 이 패턴을 사용하면 애플리케이션이 다른 유형의 구성 요소 및 기술로 구성될 수도 있습니다.
이 패턴은 오토바이에 연결된 사이드카와 유사하므로 사이드카라고 합니다. 패턴에서 사이드카는 부모 애플리케이션에 연결되고 애플리케이션에 대한 지원 기능을 제공합니다. 또한 사이드카는 부모 애플리케이션과 동일한 수명 주기를 공유하며, 부모와 함께 생성 및 사용 중지됩니다. 사이드카 패턴은 사이드킥 패턴이라고도 하며 분해 패턴입니다.
컨텍스트 및 문제점
애플리케이션 및 서비스에는 모니터링, 로깅, 구성 및 네트워킹 서비스와 같은 관련 기능이 필요한 경우가 많습니다. 이러한 주변 장치 작업은 별도의 구성 요소 또는 서비스로 구현할 수 있습니다.
애플리케이션에 긴밀하게 통합된 경우 애플리케이션과 동일한 프로세스에서 실행하여 공유 리소스를 효율적으로 사용할 수 있습니다. 그러나 이는 잘 격리되지 않으며 이러한 구성 요소 중 하나의 중단이 다른 구성 요소 또는 전체 애플리케이션에 영향을 줄 수 있음을 의미합니다. 또한 일반적으로 부모 애플리케이션과 동일한 언어를 사용하여 구현해야 합니다. 결과적으로 구성 요소와 애플리케이션은 서로 긴밀하게 상호 의존합니다.
애플리케이션을 서비스로 분해할 경우 각 서비스를 다른 언어와 기술을 사용하여 빌드할 수 있습니다. 이렇게 하면 유연성이 더 높지만 각 구성 요소에는 자체 종속성이 있으며 기본 플랫폼 및 부모 애플리케이션과 공유되는 모든 리소스에 액세스하려면 언어별 라이브러리가 필요합니다. 또한 이러한 기능을 별도 서비스로 배포하면 애플리케이션에 대기 시간이 추가될 수 있습니다. 이러한 언어별 인터페이스에 대한 코드 및 종속성을 관리하면 특히 호스팅, 배포 및 관리에 상당한 복잡성을 더할 수 있습니다.
솔루션
주 애플리케이션과 응집력 있는 작업 집합을 공동 배치하지만 자체 프로세스 또는 컨테이너 내에 배치하여 언어 간 플랫폼 서비스에 대한 동질적인 인터페이스를 제공합니다.
사이드카 서비스가 반드시 애플리케이션의 일부는 아니지만 연결됩니다. 부모 애플리케이션이 어디를 가든 이동합니다. 사이드카는 기본 애플리케이션과 함께 배포되는 프로세스 또는 서비스를 지원합니다. 오토바이의 경우 사이드카는 하나의 오토바이에 연결되고 각 오토바이는 자체 사이드카를 가질 수 있습니다. 마찬가지로 사이드카 서비스는 부모 애플리케이션의 운명을 공유합니다. 애플리케이션의 각 인스턴스에 대해 사이드카의 인스턴스가 배포되고 그 옆에 호스트됩니다.
사이드카 패턴을 사용하는 이점은 다음과 같습니다.
사이드카는 런타임 환경 및 프로그래밍 언어 측면에서 기본 애플리케이션과 독립적이므로 언어당 하나의 사이드카를 개발할 필요가 없습니다.
사이드카는 기본 애플리케이션과 동일한 리소스에 액세스할 수 있습니다. 예를 들어 사이드카는 사이드카 및 기본 애플리케이션 둘 다에서 사용하는 시스템 리소스를 모니터링할 수 있습니다.
기본 애플리케이션에 대한 사이드카의 근접도로 인해 둘 간의 통신 시 대기 시간이 길지 않습니다.
확장성 메커니즘을 제공하지 않는 애플리케이션의 경우에도 사이드카를 사용하여 기본 애플리케이션과 동일한 호스트 또는 하위 컨테이너에서 자체 프로세스로 연결하여 기능을 확장할 수 있습니다.
사이드카 패턴은 컨테이너와 함께 사용되는 경우가 많으며 사이드카 컨테이너 또는 사이드킥 컨테이너라고도 합니다.
문제 및 고려 사항
- 서비스, 프로세스 또는 컨테이너를 배포하는 데 사용할 배포 및 패키징 형식을 고려합니다. 특히 컨테이너는 사이드카 패턴에 매우 적합합니다.
- 사이드카 서비스를 디자인할 때는 프로세스 간 통신 메커니즘을 신중하게 결정합니다. 성능 요구 사항이 비실용적이지 않는 한 언어 또는 프레임워크에 구애받지 않는 기술을 사용하려고 합니다.
- 사이드카에 기능을 설정하기 전에 별도 서비스 또는 전형적인 디먼 중 어느 것으로 더 잘 작동할지 고려합니다.
- 또한 기능을 라이브러리로 구현할 수 있는지 또는 기존 확장 메커니즘을 사용할 수 있는지도 고려합니다. 언어별 라이브러리는 더 심층적인 통합 수준과 네트워크 오버헤드가 적을 수 있습니다.
이 패턴을 사용해야 하는 경우
다음 경우에 이 패턴을 사용합니다.
- 기본 애플리케이션은 다른 유형의 언어 및 프레임워크 집합을 사용합니다. 사이드카 서비스에 있는 구성 요소는 다른 프레임워크를 사용하여 다른 언어로 작성된 애플리케이션에서 사용할 수 있습니다.
- 구성 요소는 원격 팀 또는 다른 조직에서 소유합니다.
- 구성 요소 또는 기능은 애플리케이션과 동일한 호스트에 공동 배치되어야 합니다.
- 기본 애플리케이션의 전체 수명 주기를 공유하지만 독립적으로 업데이트할 수 있는 서비스가 필요합니다.
- 특정 리소스 또는 구성 요소에 대한 리소스 제한을 세밀하게 제어해야 합니다. 예를 들어 특정 구성 요소가 사용하는 메모리의 양을 제한할 수 있습니다. 구성 요소를 사이드카로 배포하고 기본 애플리케이션과 독립적으로 메모리 사용량을 관리할 수 있습니다.
이 패턴은 적합하지 않을 수 있습니다.
- 프로세스 간 통신을 최적화해야 할 경우. 부모 애플리케이션과 사이드카 서비스 간의 통신에는 몇 가지 오버헤드, 특히 호출의 대기 시간이 포함됩니다. 이것은 수다스러운 인터페이스에 대한 허용 절상이 아닐 수 있습니다.
- 각 인스턴스에 대한 사이드카 서비스를 배포하는 데 드는 리소스 비용이 격리의 장점이 아닌 소규모 애플리케이션의 경우
- 서비스가 기본 애플리케이션과 다르게 또는 독립적으로 확장해야 하는 경우 그렇다면 기능을 별도의 서비스로 배포하는 것이 더 나을 수 있습니다.
워크로드 디자인
설계자는 테스트용 자동차 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:
| 핵심 요소 | 이 패턴이 핵심 목표를 지원하는 방법 |
|---|---|
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 이러한 작업을 캡슐화하고 out-of-process를 배포하면 중요한 프로세스의 노출 영역을 작업을 수행하는 데 필요한 코드로만 줄일 수 있습니다. 사이드카를 사용하여 해당 기능으로 고유하게 설계되지 않은 애플리케이션 구성 요소에 교차 절단 보안 컨트롤을 추가할 수도 있습니다. - SE:04 구분 - SE:07 암호화 |
| 운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. | 이 패턴은 애플리케이션이 직접 구현 종속성을 수행하지 않고도 애플리케이션의 관찰성을 향상시킬 수 있는 도구 통합의 유연성을 구현하는 방법을 제공합니다. 이를 통해 사이드카 기능이 독립적으로 발전하고 애플리케이션의 수명 주기와 독립적으로 기본 얻을 수 있습니다. - OE:04 도구 및 프로세스 - OE:07 모니터링 시스템 |
| 성능 효율성은 크기 조정, 데이터, 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족하는 데 도움이 됩니다. | 교차 절단 작업을 기본 프로세스의 여러 인스턴스에서 확장할 수 있는 단일 프로세스로 이동할 수 있으므로 애플리케이션의 각 인스턴스에 대해 중복 기능을 배포할 필요가 줄어듭니다. - PE:07 코드 및 인프라 |
디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.
예시
사이드카 패턴은 많은 시나리오에 적용할 수 있습니다. 몇 가지 일반적인 예는 다음과 같습니다.
- 인프라 API. 인프라 개발 팀은 인프라에 액세스하기 위해 언어별 클라이언트 라이브러리 대신 각 애플리케이션과 함께 배포되는 서비스를 만듭니다. 서비스는 사이드카로 로드되며 로깅, 환경 데이터, 구성 저장소, 검색, 상태 검사 및 Watchdog 서비스를 비롯한 인프라 서비스에 대한 공통 계층을 제공합니다. 또한 사이드카는 상위 애플리케이션의 호스트 환경 및 프로세스(또는 컨테이너)를 모니터링하고 중앙 집중식 서비스에 정보를 기록합니다.
- NGINX/HAProxy를 관리합니다. 환경 상태를 모니터링하는 사이드카 서비스를 사용하여 NGINX를 배포한 다음, NGINX 구성 파일을 업데이트하고 상태 변경이 필요한 경우 프로세스를 재활용합니다.
- 대사 사이드카. 특사 서비스를 사이드카로 배포합니다. 애플리케이션은 요청 로깅, 라우팅, 회로 중단 및 기타 연결 관련 기능을 처리하는 앰배서더를 통해 호출합니다.
- 프록시를 오프로드합니다. 서비스에 대한 정적 파일 콘텐츠 제공을 처리하려면 node.js 서비스 인스턴스 앞에 NGINX 프록시를 배치합니다.