[Kubernetes] sidecar pattern (사이드카 패턴)

사이드카 개념

사이드카 패턴은 기본 어플리케이션 컨테이너와 독립적으로 동작하는 별도의 컨테이너를 붙이는 패턴이다. 위의 사진에 나온 오토바이에 연결된 사이드카를 붙이든 떼어내든 상관없이 오토바이에 영향을 주지 않는다. 이와 같이 기본 애플리케이션 컨테이너의 변경이나 수정 없이 독립적으로 동작하는 컨테이너를 붙였다 뗐다 할 수 있다.
패턴에서 사이드카는 기본 애플리케이션에 연결되고 애플리케이션에 대한 지원 기능을 제공한다. 또한 기본 애플리케이션 생명 주기와 동일해서 기본 애플리케이션과 함께 만들어지고 종료된다.

https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar

사이드카 패턴을 이용하지 않았을 때

통합되어 있는 경우


위에 보이는 사진 설명에서 logging, proxy 기능들을 하나의 애플리케이션에서 모두 들어있다해보자.

이는 애플리케이션과 동일한 프로세스에서 실행되어 공유 리소스를 효과적으로 사용할 수 있다. 하지만 이는 사이드카 패턴처럼 독립적으로 격리되지 않아서 이 구성 요소 중 하나가 중단되면 전체 애플리케이션에 영향을 줄 수 있다. 또한 일반적으로 기본 애플리케이션과 동일한 언어를 사용해 구현해야 한다.
→ 구성 요소 및 애플리케이션이 서로 긴밀하게 상호 종속된다.
 

서비스로 분해할 경우


애플리케이션을 서비스로 분해할 경우 각 서비스를 다른 언어와 기술을 사용하여 빌드할 수 있다. 이렇게 하면 유연성은 높아지지만, 기본 애플리케이션과 공유되는 리소스 및 기본 플랫폼에 접근할 때 언어별 라이브러리가 필요하게 된다. 또한 이러한 기능은 별도로 서비스로 배포하게 될 때, 애플리케이션에 대기 시간이 추가될 수 있다.

위의 문제점들을 사이드카 패턴을 이용해 해결할 수 있다.
사이드카 서비스는 애플리케이션의 일부일 필요는 없지만 애플리케이션에 연결되어 있다. 기본 애플리케이션의 이동 위치로 어디든 이동한다. 사이드카는 기본 애플리케이션을 사용하여 배포되는 프로세스 또는 서비스를 지원합니다. 사이드카 서비스는 해당 기본 애플리케이션과 함께 운용된다. 애플리케이션의 각 인스턴스에 대해 사이드카의 인스턴스가 배포되고 그 옆에 호스트된다.
사이드카 패턴 사용의 장점

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

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

이 패턴을 사용하면 좋은 경우

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

 

참고

 

Sidecar pattern - Azure Architecture Center