Sidecar 패턴 이란 ?

Sidecar 패턴은 마이크로서비스 아키텍처에서 보조 기능을 담당하는 프로세스를 주 애플리케이션과 분리하여 독립적인 프로세스로 실행하는 방법입니다. 이 패턴은 주로 애플리케이션의 주요 기능과 관계없이 추가적인 기능을 제공하는 데 활용됩니다. Sidecar는 '옆에 붙어 다니는 차'라는 뜻으로, 주 프로세스와 함께 배포되지만 별도의 컨테이너나 프로세스로 동작합니다. 주로 Kubernetes 환경에서 자주 사용되며, 이 패턴을 통해 애플리케이션의 확장성과 관리성을 높일 수 있습니다.

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

 

1. Sidecar 패턴의 발전

Sidecar 패턴은 마이크로서비스 아키텍처가 확산되면서 점차 사용되기 시작했습니다. 특히 2010년대 중반부터 마이크로서비스가 널리 도입되면서, 독립적이면서도 서로 연관된 여러 기능을 효율적으로 관리하고 배포할 필요성이 커졌습니다.

 

이 패턴은 정확히 누가 처음 제안했는지에 대한 공식적인 기록은 없지만, 주로 Netflix와 Google 같은 기술 선도 기업들이 초기에 이를 도입하고 발전시켰습니다. Netflix는 다양한 보조 서비스를 독립적인 프로세스로 분리해 마이크로서비스와 연계하여 실행하는 방식으로 패턴을 적용했고, Google은 자사의 오픈소스 오케스트레이션 플랫폼인 Kubernetes에서 Sidecar 패턴을 적극적으로 활용할 수 있는 환경을 만들면서 이 패턴의 확산에 기여했습니다.

 

특히 2016년 Envoy라는 오픈소스 프록시가 등장하면서 Sidecar 패턴이 본격적으로 주목받기 시작했습니다. Envoy는 Lyft에서 개발한 프로젝트로, 애플리케이션과 독립된 프록시로서 네트워크 통신을 관리하는 Sidecar 역할을 수행했습니다. 이후 Envoy는 Istio와 같은 서비스 메쉬의 핵심 구성 요소로 채택되며, Sidecar 패턴이 서비스 메쉬 아키텍처의 주요 패턴으로 자리 잡는 데 중요한 역할을 했습니다.

 

따라서 Sidecar 패턴은 2010년대 중반부터 대규모 서비스를 운영하는 기업들이 서비스 메쉬 아키텍처와 마이크로서비스의 복잡성을 해결하기 위해 적극적으로 사용하기 시작했다고 볼 수 있습니다.

 

2. Sidecar 패턴의 구조와 특징

• 독립성: Sidecar는 주 애플리케이션과 별도의 프로세스로 실행되므로 개별적으로 배포하고 관리할 수 있습니다.
• 연결: 주 애플리케이션과 Sidecar는 로컬 네트워크를 통해 통신하며, 이를 통해 트래픽 제어, 로깅, 모니터링 등을 수행할 수 있습니다.
• 추가 기능 제공: 인증, 로깅, 트래픽 라우팅, 모니터링, 캐싱, 프로세스 간 통신 등 보조적인 기능을 제공하여 주 애플리케이션의 기능을 보완합니다.

 

3. Sidecar 패턴의 주요 사용 사례

 

1)  서비스 메쉬: Envoy, Istio 등과 같은 서비스 메쉬 솔루션은 Sidecar 패턴을 활용해 네트워크 트래픽 관리, 보안, 로깅 등의 기능을 제공합니다.

• 프로젝트 환경 적용 사례) 보안을 위해 사이드카로 NGINX reverse proxy 등을 붙여서 HTTPS 통신을 할 수 있습니다.

2) 로깅 및 모니터링: Sidecar 컨테이너에서 주 애플리케이션의 로그를 수집하고 전송하거나, 애플리케이션 성능을 모니터링할 수 있습니다.

• 프로젝트 환경 적용 사례) 컨테이너 외부로 로그를 모으기 위해 logstash, fluentd 등을 붙일 수 있습니다. (centralized logging)

3) 데이터 동기화: 주 애플리케이션과 외부 시스템 간의 데이터를 주기적으로 동기화하거나 캐싱할 때 Sidecar 패턴이 사용될 수 있습니다.

• 프로젝트 환경 적용 사례) 성능을 위해 사이드카로 NGINX content cache 등을 붙일 수 있습니다.

4)    API 프록시: 주 애플리케이션이 직접 API에 접근하지 않고 Sidecar를 통해 접근함으로써, 보안과 트래픽 제어 기능을 강화할 수 있습니다.

 

4. Sidecar 패턴의 장점

• 유연한 배포 : 주 애플리케이션과 독립적으로 업데이트할 수 있으므로 유지 보수가 용이합니다.
• 확장성 : 보조 기능을 Sidecar로 분리하여 주 애플리케이션을 간결하게 유지하고, 필요할 때 새로운 기능을 추가할 수 있습니다.
• 재사용성 : 다양한 마이크로서비스에서 동일한 Sidecar를 재사용할 수 있어 일관성 있고 효율적인 관리를 지원합니다.
• 사이드카 장애 시 어플리케이션이 영향을 받지 않습니다. (isolation)
• 사이드카 적용/변경/제거 등의 경우에 어플리케이션은 수정이 필요 없습니다.
• 어플리케이션과 사이드카를 다른 언어로 만들 수 있습니다.

5. Sidecar 패턴의 단점

• 복잡성 증가 : 애플리케이션과 Sidecar 간의 통신 및 관리가 필요해 시스템의 복잡도가 증가할 수 있습니다.
• 리소스 사용량 : 독립된 프로세스로 동작하기 때문에 추가적인 메모리와 CPU 리소스를 사용합니다.

6. 결론

Sidecar 패턴은 특히 마이크로서비스 아키텍처에서 개별 서비스를 간결하게 유지하면서도 확장 가능하고 관리 가능한 시스템을 구현할 때 유용한 패턴입니다.