“Istio”로 시작하는 서비스 메시의 여정:1
서비스 메시란 무엇인가?
Istio공식 문서에서는 서비스 메시를 다음과 같이 정의하고 있습니다.
“서비스 메시는 애플리케이션의 코드 수정 없이 보안, 관찰 가능성(Observability), 트래픽 관리를 제공하는 인프라 계층이다.”
즉, 서비스 간 통신을 보다 안전하고 효율적으로 관리할 수 있도록 돕는 네트워크 프록시 역할을 합니다. 이스티오는 제로 트러스트 보안, 트래픽 관리, 장애 복구, 부하 분산, A/B 테스트 등의 기능을 지원하며, 멀티 클러스터, 하이브리드 클라우드, 온프레미스 환경에서도 단일 네트워크로 통합 운영할 수 있습니다.
Sidecar프록시는 마이크로서비스와 나란히 옆에 위치하며 다른 프록시로 요청을 라우팅합니다. 이러한 Sidecar들이 모여 메시 네트워크를 형성한 인프라 계층입니다.
다음 그림에서 Istio 아키텍쳐와 구성 요소에 대해서 알아보겠습니다.
Istio의 핵심 구성 요소와 역할
이스티오는 크게 데이터 플레인(Data Plane) 과 컨트롤 플레인(Control Plane) 으로 나뉩니다.
데이터 플레인: Envoy 프록시가 사이드카(Sidecar) 형태로 배포되어 서비스 간 네트워크 인바운드/아웃바운드 트래픽을 중재하고 제어하며, 상세한 텔레메트리 데이터를 수집합니다.
컨트롤 플레인: Envoy 프록시를 관리하고 트래픽 라우팅을 설정하는 역할을 합니다.
다음은 이스티오의 핵심 구성 요소와 역할을 살펴보겠습니다.
Envoy (엔보이)
Envoy는 경량화된 L7 전용 Proxy로, 서비스 간 네트워크 트래픽을 중재하는 데이터 플레인 역할을 합니다. 사이드카 방식으로 각 서비스에 배포되며 동적 서비스 디스커버리, 로드 밸런싱, 회로 차단(Circuit Breaker), A/B 테스트 및 카나리 배포, 트래픽 오류 주입(Fault Injection) 등의 기능을 별도의 코드 변경 없이 서비스 간 트래픽을 정밀하게 제어할 수 있으며, 보안 정책을 적용하고 네트워크 복원력을 강화할 수 있습니다.Istiod (이스티오 컨트롤 플레인)
Istiod는 서비스 디스커버리, 설정 관리, 인증서를 관리하는 컨트롤 플레인 역할을 합니다. Envoy 프록시 설정 및 정책 전파하며 Istiod는 단순한 트래픽 라우팅뿐만 아니라 보안과 거버넌스 기능을 통합하여 서비스 간 통신을 더욱 안전하고 효율적으로 만들어 줍니다.
Kiali와 Jaeger UI 소개
그렇다면 이러한 트래픽 관리와 보안 정책이 효과적으로 수행되고 있다는 것을 어떻게 확인할 수 있을까요? 클라우드 네이티브 환경에서의 관찰 가능성은 시스템의 성능 모니터링과 문제 해결에 필수적인 역할을 합니다. Istio는 자체적인 강력한 관찰 가능성 기능을 제공하며, 이는 서비스가 원활하게 작동하며 문제를 신속하게 식별하고 해결할 수 있도록 합니다. 이러한 맥락에서, Istio와 긴밀하게 통합되어 사용되는 두 가지 주요 도구가 바로 Kiali와 Jaeger UI입니다.
Kiali는 Istio서비스 메시의 시각화와 관리 도구로, 애플리케이션의 서비스 네트워크를 다이어그램 형태로 볼 수 있어 상태 파악이 용이합니다. 이는 복잡한 서비스구성을 직관적으로 이해하는 데 도움을 주며, 문제 발생 시 빠른 대처를 가능하게 합니다.
시각적 네트워크 토폴로지 제공
실시간 메트릭 및 상태 정보 제공
동적 트래픽 라우팅
Jaeger UI는 오픈소스 분산 추적 시스템으로, Istio와 통합하여 서비스 호출 시퀀스를 추적할 수 있습니다. 이를 통해 성능 병목 현상 및 지연 시간을 조사하고 최적화할 수 있습니다.
End To End 분산 추적
성능 최적화 및 디버깅 도구
Kiali와 Jaeger UI의 특징과 기능을 살펴보았듯, 이러한 도구들은 서비스 성능을 모니터링하고 잠재적인 문제를 신속히 파악하는 데 중요한 역할을 합니다.
헤더를 확산시켜야 하는 이유
이러한 관찰 가능성과 추적 능력을 최대한 활용하려면, 클라이언트로부터의 요청이 마이크로서비스 아키텍처 전반에 걸쳐 일관되게 추적될 수 있어야 하며, 이는 각 요청에 포함된 헤더 정보가 정확히 전달되는 것을 필요로 합니다.
헤더 확산(Header Propagation)은 이러한 맥락에서 필수적인 요소로 작용합니다. 요청 헤더에는 추적 ID, 사용자 인증 정보 등 중요한 메타데이터가 포함되며, 이러한 정보가 서비스 호출 사이에서 누락 없이 전달됨으로써, 전체 시스템의 성능을 정확히 추적할 수 있습니다.
그렇다면 헤더를 확산시켜야 하는 구체적인 이유와 그로 인해 기대할 수 있는 이점은 무엇일까요?
Istio 공식 문서를 참고해보면 Istio 사이드카는 관련 애플리케이션 인스턴스에 대해 인바운드/아웃바운드 요청 모두를 처리하지만, 아웃바운드 요청이 어떤 인바운드 요청에서 발생했는지를 연관지을 수 있는 명시적인 방법이 없습니다. 이러한 연관성을 달성하기 위해서는 애플리케이션이 인바운드 요청에서 아웃바운드 요청으로 관련 정보를 (예: 헤더) 전파해야만 합니다. 헤더 확산은 클라이언트 라이브러리를 통해 수행되거나 수동으로 수행할 수 있다고 나옵니다.
마치며
오늘은 서비스 메시와 Istio의 기본 개념부터 Kiali와 Jaeger UI의 역할, 그리고 헤더 확산이 중요한 이유까지 살펴보았습니다. 이러한 기초적인 이해를 바탕으로, 다음 글에서는 실제로 Istio를 설치하는 단계에서부터 헤더 확산을 구현하고 카나리 배포 전략을 적용하는 방법까지 다뤄볼 예정입니다. 여기에는 버추얼 서비스와 데스티네이션 룰을 활용한 실전 예제가 포함될 예정입니다. 앞으로의 내용도 많은 기대 부탁드리며, 유익한 정보가 되었기를 바랍니다. 감사합니다.
