[Infra] 서비스 메시(Service Mesh)의 등장과 쿠버네티스(Kubernetes)의 SidecarContainers

이번에는 서비스 메시(Service Mesh)가 무엇인지 알아보고, 서비스 메시가 갖는 문제와 이를 해결하기 위한 쿠버네티스(Kubernetes)의 SidecarContainers에 대해 알아보도록 하겠습니다.

 

 

 

1. 서비스 메시(Service Mesh)의 등장

---

[ MSA와 함께 부각되는 인프라 문제들 ]

기존의 모놀로식(Monolithic)에서 마이크로서비스 아키텍처(MicroService Architecture)로 전환하면서 많은 변화가 생겼다. 특히 기존에는 겪지 않았던 인프라와 관련된 문제(특히 네트워크)들이 더욱 중요해졌다.

• Client-side load balancing: 호출 가능한 엔드포인트 목록을 클라이언트에게 주고, 직접 결정하도록 함
• Service discovery: 정상 상태인 서비스들을 주기적으로 찾아 갱신하는 메커니즘
• Circuit breaking: 문제가 있는 서비스로의 부하를 줄여주는 기술
• Bulkheading: 클라이언트의 리소스 사용량을 임계값으로 제한하는 기술
• Timeouts: 서비스 호출 시에 시간 제한을 적용함
• Retries: 실패한 요청을 재시도함
• Retry budgets: 재시도에 제약 조건을 적용합니다. 즉, 주어진 기간 동안 재시도 횟수를 제한합니다
• Deadlines: 응답이 유효한 컨텍스트를 제공하고, 기간이 지나면 요청 처리를 무시함

 

 

[ 라이브러리를 활용한 해결 방법 ]

각 회사들은 라이브러리 형태로 이러한 문제들을 해결하였고, 대표적으로 넷플릭스는 마이크로서비스로 전환하면서 구현했던 NetflixOSS(hystrix, zuul, eureka, ribbon 등)을 오픈소스로 공개했다. 스프링 클라우드는 이를 내재화하여 spring-cloud-netflix 프로젝트로 재구성했는데, 이를 통해 많은 사용자들이 편리하게 처리할 수 있게 되었다. 하지만 그럼에도 불구하고 다음과 같은 한계가 있었다.

• 특정 환경(JVM)에 종속적이게 됨
• 특정 도구에 대한 제약을 받게 됨(라이브러리의 구현을 따라야만 함)
• 비용이 많이 들고 숙련이 필요함

 

 

[ 서비스 메시의 등장 ]

MSA를 위한 공통 관심사는 특정 비즈니스나 개발 언어 및 프레임워크에 종속적이지 않고, 모든 시스템이 거의 동일하게 필요로 한다. 또한 이를 언어 별로 구현하는 것은 상당한 시간 낭비이다. 그래서 공통 관심사를 애플리케이션으로부터 분리하고 인프라로 넣자는 관점이 생겼고, 이렇게 탄생한 것이 바로 Service mesh(서비스 메쉬)이다. Service mesh는 애플리케이션 앞에 프록시를 두어 공통 문제를 해결할 뿐만 아니라 트래픽을 제어하여 분산시키는 등 다양한 문제를 해결한다.

• Service resilience
  • retries
  • timeout
  • circuit breaker
• Observability signals
  • request spike
  • latency
  • failure
  • throughput
• Traffic control capabilities
  • service discovery
  • zone-aware load balacing
  • health checking
  • rate limit
  • quotas
  • organizational policies
• Security
  • TLS

 

 

 

서비스 메시를 조금 깊게 들여다보면 Data plane과 Control plane이 존재함을 확인할 수 있다. Data plane은 애플리케이션의 모든 트래픽이 처리되고 관찰되는 곳으로, 트래픽 설정과 보호 및 제어를 담당한다. 그리고 Data plane은 Control plane에 의해 구성된다. Control plane는 서비스 메시의 두뇌에 해당하며 운영자가 네트워크 동작을 조작할 수 있도록 API를 노출시킨다. 이 둘은 함께 결합되어 중요한 기능을 담당한다.

 

 

서비스 메쉬를 적용함으로써 특정 프로그래밍 언어나 프레임워크에 의존하지 않고 공통 관심사를 처리할 수 있으며, 수 많은 마이크로서비스를 운영하는 조직 전체의 개발 생산성을 극대화할 수 있었다. 하지만 서비스 메쉬의 궁극적인 장점은 인프라 사항들을 애플리케이션으로부터 분리시킬 수 있다는 점이다. 가장 먼저 Docker가 애플리케이션이 구동되는 머신과 무관하게 애플리케이션을 패키징하는 방식을 제안했고, 그 다음으로 쿠버네티스를 통해 자동으로 서비스를 생성하고 확장할 수 있게 되었다. 그리고 마지막으로 서비스 메쉬를 통해 인프라를 애플리케이션으로부터 분리시킬 수 있게 된 것이다.

서비스 메쉬 도구로 Istio 외에도 여러 가지가 있었지만, 최근에는 Istio를 많이 사용하고 있다. 서비스 트래픽 흐름을 웹 UI로 확인할 수 있도록 도와주는 모니터링 도구들도 존재하는데, 대표적으로 Kiali가 있다.

 

 

 

 

2. Sidecar 방식과 Sidecarless 방식, SidecarContainers의 등장

---

[ 기존의 사이드카 패턴(Sidecar Pattern) 방식 ]

서비스 메쉬(Istio)를 적용할 때 일반적으로 사이드카 패턴(어플리케이션 컨테이너와 독립적으로 동작하는 별도의 컨테이너를 붙이는 패턴)을 사용한다. 그러면 애플리케이션 컨테이너에 프록시(Envoy)가 붙는 구조로 만들어진다. 아래의 그림에서 source1은 사이드카 패턴으로 만들어진 구조이다.

 

 

 

[ Sidecar 방식의 문제와 Sidecarless 방식의 등장 ]

하지만 사이드카 방식은 CPU나 메모리와 같은 리소스를 추가로 사용한다는 문제가 있다. 또한 둘의 생명주기를 맞춰주지 않으면 예상치 못한 문제가 발생하기도 한다. 예를 들어 애플리케이션 컨테이너에서 OOM이 발생하여 죽어도, 사이드카 컨테이너가 죽지 않으면 팟이 내려가지 않는 것이다. 또한 Job 형태의 팟이라면 Job 실행이 끝난 뒤에도 프록시가 살아있기 때문에 팟이 내려가지 않을 수 있다.

주로 사용되는 Istio도 사이드카 패턴을 사용했는데, 이러한 문제를 해결하고자 사이드카가 없는 sidecareless 방식을 고안하기 시작했다. Istio의 경우 ambient mode를 제공하는데, 이를 적용하면 프록시가 사이드카 패턴으로 파드에 붙는 것이 아니라 ztunnel(제로 트러스트 터널)이라는 데몬을 통해서 서비스 메쉬를 구성할 수 있다. ambient mode는 애플리케이션 뿐만 아니라 CI/CD 설정도 바꿀 필요가 없다는 장점이 있다.

 

 

 

[ 쿠버네티스(Kubernetes) SidecarContainers의 등장 ]

하지만 이러한 방식만으로는 제대로 된 해결을 하기 어려웠다고 한다. 그래서 쿠버네티스(Kuberenetes)에서 이 문제를 직접 해결하기로 결정하였고 1.28 버전부터 SidecarContainers라는 기능이 추가되었다. 이 기능을 사용하면 Istio 프록시가 initContainers로 실행되기 때문에 항상 먼저 실행되고 컨테이너가 죽으면 자동으로 사이드카 컨테이너도 내려가게 된다.

 

 

 

 

참고 자료

• Istio in action
• https://www.infoq.com/articles/istio-ambient-mesh/
• https://yozm.wishket.com/magazine/detail/1998/
• https://careerly.co.kr/profiles/410926?from=comment&fromArea=
• https://istio.io/latest/blog/2023/native-sidecars/