Service Mesh, Istio란?

 

Istio를 이해하기 전에 먼저 서비스 메시에 대한 정의를 알고 가면 좋을 것 같습니다. 서비스 메시(Service Mesh)란 서비스가 애플리케이션 수명 주기 전반에 걸쳐 데이터와 일관성을 공유하며 서로 통신할 수 있도록 지원하는 사전 구성된 애플리케이션 서비스입니다.

즉, 애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층으로, 이 계층은 컨테이너화된 마이크로서비스로 구성됩니다.

 

현대에는 애플리케이션이 확장되고 수 천, 수 만 개의 마이크로서비스로 구성된 아키텍처가 나오기 시작하면서 서비스의 성능을 모니터링하기가 점점 어려워지고 있습니다. 이에 서비스 메시는 서비스 간 연결을 관리하기 위해 모니터링, 로깅, 추적, 트래픽 제어와 같은 새로운 기능을 제공합니다. 이러한 기능은 각 서비스의 코드와 독립적이므로 네트워크 경계를 넘어 여러 서비스 관리 시스템에서 작동이 가능합니다.

 

애플리케이션을 구축하는 수 많은 마이크로서비스간의 통신의 속도와 탄력성에 따라 성능이 좌우됩니다. 더 많은 워크로드와 서비스가 배포됨에 따라 개발자들은 모든 요소가 연동하여 작동하는 방식에 대한 이해에 대한 어려움을 겪습니다. 또한, 관리자는 어떤 서비스가 서로 통신하고 어떤 작업을 수행하는지 확인하고 제어하고 싶습니다. 아키텍처 내에서 서비스의 동작, 정책 및 상호 작용에 대한 세밀한 제어 및 거버넌스 기능을 제공하기 위해 서비스 메쉬가 필요하고 사용되고 있습니다.

 

 

 

위와 같이 구현된 마이크로 서비스 아키텍처를 적용한 시스템의 내부 통신이 Mesh 네트워크 형태를 띄는 것에 빗대어 Service Mesh로 명명되었습니다. 서비스 메시는 다시 말해 서비스 간 통신을 추상화하여 안전하고, 빠르고, 신뢰할 수 있게 만드는 전용 Infrastructure Layer입니다. 추상화를 통해 복잡한 내부 네트워크를 제어하고, 추적하고, 내부 네트워크 관련 로직을 추가함으로써 안정성, 신뢰성, 탄력성, 표준화, 가시성, 보안성 등을 확보합니다.

 

서비스 메시는 URL Path, Host Header, API Version 또는 기타 응용 프로그램 수준 규칙을 기반으로하는 Layer 7(Application Layer) 계층입니다. 서비스 메시의 구현체인 Proxy를 통해 다양한 Routing Rules, Circuit Breaker등 공통 기능을 설정할 수 있습니다. 이는 서비스 간 통신에 연관된 기능 뿐만 아니라 서비스의 배포 전략에도 도움을 줍니다.

 

 

서비스 메시 아키텍처의 구현은 위에서 언급한 것처럼 보통 마이크로서비스 앞단에 경량화 프록시를 사이드카 패턴(https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar)으로 배치하여, 서비스 간 통신을 제어하는 방법으로 구현됩니다. 서비스 간 통신 시에는 사이드카로 배치된 경량화 프록시를 통해 동작하며, 해당 프록시에 Routing Rules, Retry, Timeout등을 설정하고 로직을 작성하여 공통 기능을 기본 애플리케이션에서 분리할 수 있습니다.

서비스 메시의 기능으로는 다음과 같습니다.

• Service Discovery: 자동화된 서비스 검색을 제공하여 서비스 앤드포인트 관리의 운영 부하를 줄입니다. 서비스 레지스트리를 사용하여 메시 내 모든 서비스를 동적으로 검색하고 추적하며, 서비스 위치나 기반 인프라에 관계없이 서로 원활하게 찾고 통신 가능합니다.
• Load Balancing: 다양한 알고리즘을 사용하여 요청을 여러 서비스 인스턴스에 분산 가능하며, 이를 통해 리소스의 활용도를 높이고 고가용성 및 확장성을 보장합니다. 성능 최적화 및 네트워크 통신 병목 현상을 방지할 수 있습니다. (HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 자동 부하 분산)
• Dynamic Request Routing: 플랫폼이 커지고 서비스 개수가 많아짐에 따라 정교한 라우팅 기능이 필요 -> A/B테스트, 카나리 배포 등 특정 서비스 대상으로 라우팅이 가능한 기능 제공 
• Circuit Breaking: 장애 전파를 방지하고 시스템의 안정성을 유지하기 위한 패턴으로, 서비스 간 통신에서 특정 문제가 발생했을 때 이를 감지하고, 추가 요청을 제한하거나 차단하여 문제의 확산을 방지하는 역할을 제공합니다.
• Retry and Timeout: 네트워크 안정성을 높이고 가용성을 보장하기 위한 기능으로 재시도를 통해 일시적인 문제를 해결하고, 타임 아웃을 통해 무한 대기 상태를 방지하고 리소스를 효율적으로 활용하도록 돕습니다.
• TLS(Transport Layer Security): 서비스가 커짐에 따라 공격 대상 범위도 커지게 되므로, 모든 요청은 인증, 승인, 암호화가 필요한데 플랫폼 수준에서 보안 통신을 관리하여 서비스 복잡도를 줄일 수 있습니다.
• Distributed Tracing: 서비스 개수가 늘어남에 따라 마이크로서비스 환경에서 요청 흐름을 시각화 하고 분석하는 것이 어려운데, 서비스 간 요청이 어떻게 이동하고 처리되는지를 추적하여 문제를 진단하거나 성능 병목 현상을 분석할 수 있게 해주는 기능입니다.
• metrics 수집: 서비스 간, 서비스 메쉬의 모든 트래픽을 실시간으로 수집하고 분석하여 모니터링할 수 있도록 돕습니다.

 

 

모든 기술에는 장점만 있을 수는 없을 것 같습니다. 장점을 먼저 알아보면,

• 장점으로는 네트워크 공통 기능을 애플리케이션에서 분리하여 순수 로직에 집중할 수 있습니다.
• 또한, 이러한 기능이 외부에 구현되어 있다보니 재 사용이 가능하다는 장점도 있을 수 있습니다. (미들웨어와 앱 종속성 제거)
• 마이크로서비스의 런타임 복잡성에 대한 이슈 해결 가능
• 가벼운 Proxy 연계를 통해 인프라 복잡성 감소
• 분산된 기능의 관리를 중앙 집중화 가능

단점도 정리해보겠습니다.

• 사이드카 패턴 구현을 위한 리소스가 추가되어 인스턴스가 최소 2배 증가
• 서비스 간 통신에 네트워크 레이어가 추가되어 이로 인한 지연 발생 가능
• Proxy에 대한 디버깅 및 관리 이슈 증가
• 신기술로 러닝 커브 및 구현체 릴리즈 될 때까지 시간이 필요하다는 단점이 있습니다.

 

 

 

이제 서비스 메시는 어떤 방식으로 동작하는지에 대해 알아보도록 하겠습니다. 서비스 메시는 크게 데이터 플레인, 컨트롤 플레인 두 개의 컴포넌트로 구성되는데, 데이터 플레인은 애플리케이션 사이에 있는 프록시 네트워크로 구성되고, 컨트롤 플레인은 프록시에게 수행할 작업을 알려주고 메시를 작동하는 사람을 위한 인터페이스를 제공합니다.

 

데이터 플레인은 서비스 메시의 데이터 처리 구성 요소로, 사이드카가 요청을 가로채고 요청을 별도 네트워크 연결로 캡슐화합니다. 그리고 소스 프록시와 대상 프록시 간에 안전하고 암호화된 채널을 설정한 후, 통신합니다. 이를 통해 안전하고 신속한 통신이 가능합니다.

프록시는 보통 엔보이(Envoy)서비스를 이용하여 구성되고 포워드 프록시 및 리버스 프록시 역할을 모두 수행하여 인/아웃 바운드 호출을 모두 처리합니다. 

 

컨트롤 플레인은 서비스 검색(Discovery), TLS인증서 발급, 메트릭 집계 등을 토함하여 데이터 플레인이 작동하는데 필요한 컴포넌트들을 제공합니다. 또한 사용자가 전체적으로 데이터 플레인의 동작을 수정하고 검사할 수 있도록 API를 제공합니다. 관리자가 직접 컨트롤 플레인을 사용하여 메시 내 서비스를 정의하고 구성할 수 있으며, 서비스 엔드포인트, 라우팅 규칙, 부하 분산 정책 및 보안 설정과 같은 파라미터를 지정할 수 있습니다. 이러한 설정을 바탕으로 프록시는 요청을 처리할 방법을 결정하며, 이러한 구성 변경 사항을 서비스 재 시작 또는 중단 없이 실시간으로 적용할 수 있습니다.

 

그렇다면 이제 Istio에 대해 이야기 해 볼 수 있을 것 같습니다 :) Istio는 주로 Kubernetes와 함께 작동하도록 설계된 오픈 소스 서비스 메시 프로젝트로, Istio의 컨트롤 플레인 구성 요소는 자체적으로 쿠버네티스 워크로드로 실행됩니다. 

데이터 플레인의 프록시는 Envoy를 사용하고, 서비스 메시의 모든 서비스에 대한 모든 인/아웃 바운드 트래픽을 관장합니다. (Envoy에서 제공하는 통신과 관련된 기능(카나리 배포, 트래픽 제어, 요청 제한)등을 사용하는데 애플리케이션 단 수정 없이 Istio 사용만으로 가능)

컨트롤 플레인의 istiod는 트래픽 라우팅 규칙을 Envoy구성으로 변환하고 사이드카에 전파합니다. 그 외 서비스 디스커버리, 서비스 간 mTLS통신을 위한 인증기관(CA)역할도 담당합니다.

 

 

 

 

위에서 알아본 것처럼 서비스 메시, Istio를 사용하면 다양한 이점이 있을 것 같습니다. 하지만 서비스 메시가 정말 필요한가에 대한 질문에 대한 고민을 해 볼 필요가 있을 것 같습니다.

서비스 메시 프록시는 경량화 되어 있지만, 마냥 가볍지만은 않습니다. 인프라와 관련된 리소스를 소비하고 모든 요청이 프록시를 거쳐야 하므로 네트워크 지연을 유발합니다. 기존 컨테이너 간 통신에는 커넥션 풀이 1개만 존재하지만, 사이드카를 통하게 되면서 3개로 늘어납니다.

 

또한, Ingress와 어노테이션 호환성 문제도 있을 것이고, mTLS통신의 단점도 존재합니다. 모든 연결이 프록시를 통하게 되므로 클러스터에서 트래픽을 암호화하는데 상당한 성능 저하를 경험할 수 있습니다. 그리고 불가피하게 애플리케이션의 코드 수정이 필요할 수 있습니다. HTTP헤더에 따라 대상 서비스를 다르게 라우팅하는 기능이 있을 때, 이스티오 오브젝트의 헤더 식별 규칙에 맞춰 변경이 필요합니다. 추가로, 트레이싱 헤더를 반영하기 위해 telemetry라이브러리를 사용하면, 서비스를 추적하기 위해 trace-id를 생성하고 span-id라고 불리는 서비스 헤더를 통해 전파됩니다. 이러한 모든 기능에 대한 이해를 바탕으로 운영하는 서비스에 적용 여부를 판단해보면 좋을 것 같습니다.

긴 글 읽어주셔서 감사합니다 😊