ISTIO (r1)

데이터 플레인은 서비스 메시 내에서 실제 네트워크 트래픽을 처리하는 구성 요소이다. Istio의 데이터 플레인은 Envoy 프록시를 확장한 사이드카 프록시로 구현된다. 이 프록시는 마이크로서비스의 각 인스턴스(예: Kubernetes 파드) 옆에 배치되어 모든 인바운드 및 아웃바운드 트래픽을 가로채고 제어한다.

Envoy 프록시는 L4 및 L7 트래픽을 처리하며, 컨트롤 플레인으로부터 전달받은 구성에 따라 다양한 기능을 수행한다. 주요 역할은 다음과 같다.

이러한 사이드카 패턴 덕분에 애플리케이션 코드는 네트워크 관련 복잡성(예: 서비스 발견, 재시도 로직, 암호화)을 직접 처리하지 않고도 서비스 메시의 혜택을 누릴 수 있다. 모든 트래픽이 프록시를 통과하므로, 중앙 집중식 컨트롤 플레인은 네트워크 동작을 일관되게 관리하고 모니터링할 수 있다.

컨트롤 플레인은 서비스 메시의 두뇌 역할을 하며, 데이터 플레인에 구성 정보를 전달하고 정책을 집행하는 역할을 한다. 초기 아이스티오의 컨트롤 플레인은 파일럿, 믹서, 시타델의 세 가지 주요 구성 요소로 이루어졌으나, 이후 아키텍처가 단순화되면서 기능이 통합 및 재편되었다. 현재는 주로 아이스티오디(Istiod)라는 단일 바이너리로 배포되며, 내부적으로 파일럿, 시타델, 갤리의 핵심 기능을 통합하여 관리한다.

컨트롤 플레인의 주요 구성 요소와 그 역할은 다음과 같다.

이러한 구성 요소들은 협력하여 동작한다. 예를 들어, 갤리가 사용자의 게이트웨이 설정을 검증한 후 파일럿에 전달하면, 파일럿은 해당 규칙을 해석하여 모든 관련 엔보이 프록시에 배포한다. 동시에 시타델은 해당 서비스들 간의 통신에 필요한 TLS 인증서를 자동으로 생성하고 제공한다. 이러한 분리된 아키텍처는 유연성을 제공했지만, 운영 복잡성을 초래하여 이후 아이스티오디로의 통합을 촉진하는 요인이 되었다.

트래픽 관리는 서비스 메시에서 마이크로서비스 간의 통신 흐름을 세밀하게 제어하는 ISTIO의 핵심 기능이다. 이 기능은 주로 VirtualService와 DestinationRule이라는 두 가지 주요 커스텀 리소스 정의를 통해 구현된다. VirtualService는 들어오는 트래픽이 메시 내 서비스에 어떻게 라우팅될지를 정의하며, DestinationRule은 트래픽이 라우팅된 후 해당 서비스의 인스턴스(예: 특정 버전의 파드)에 대한 정책을 구성한다.

라우팅 규칙은 매우 유연하게 설정할 수 있다. 예를 들어, HTTP 요청 헤더의 값, URI 경로, 소스 네임스페이스 등을 기준으로 트래픽을 특정 서비스 버전(예: v1, v2)으로 분기할 수 있다. 이를 통해 카나리 배포나 A/B 테스트를 안전하게 수행할 수 있다. 가상 서비스는 단일 호스트 이름에 대한 모든 트래픽 규칙을 중앙에서 관리하는 단일화된 인터페이스를 제공한다.

트래픽 관리 기능은 라우팅 외에도 로드 밸런싱 정책, 연결 풀 설정, 장애 복구를 위한 재시도 및 타임아웃 정책을 포함한다. 아래 표는 주요 트래픽 관리 객체와 그 역할을 요약한다.

이러한 구성 요소들을 조합하면, 운영자는 트래픽의 일정 비율을 새 버전으로 점진적으로 전환하거나, 특정 조건에서 트래픽을 완전히 차단하며, 장애가 발생한 서비스 인스턴스로의 요청을 자동으로 재시도하거나 회로 차단하는 등의 고급 패턴을 구현할 수 있다. 모든 트래픽 제어는 애플리케이션 코드를 변경하지 않고 선언적으로 설정하며, Envoy 프록시 사이드카를 통해 실시간으로 적용된다.

ISTIO는 서비스 간 통신의 보안을 강화하기 위해 상호 TLS(mTLS)를 기본적으로 제공합니다. 이는 서비스 메시 내의 모든 트래픽이 자동으로 암호화되고 인증되도록 합니다. mTLS는 양방향 인증을 수행하여 통신하는 양측 모두가 신원을 확인하므로, 스푸핑 공격과 중간자 공격을 방지합니다. Citadel 컴포넌트는 인증서의 발급, 순환, 폐기를 관리하는 역할을 담당합니다.

인가 정책은 특정 서비스, 메서드, 사용자에 대해 '누가 무엇을 할 수 있는지'를 세밀하게 제어합니다. AuthorizationPolicy 리소스를 사용하여 네임스페이스, 워크로드, 포트 수준에서 접근 규칙을 정의할 수 있습니다. 예를 들어, '프론트엔드 서비스만 결제 서비스의 POST 메서드를 호출할 수 있다'와 같은 규칙을 설정할 수 있습니다. 정책은 기본적으로 거부 모드로 작동하여, 명시적으로 허용되지 않은 모든 요청은 차단됩니다.

보안 설정은 아래와 같은 리소스를 통해 구성할 수 있습니다.

이러한 메커니즘을 통해, 개발자는 애플리케이션 코드를 변경하지 않고도 선언적 방식으로 서비스 메시 전체에 걸친 강력한 보안 정책을 적용할 수 있습니다. 이를 통해 제로 트러스트 네트워크 보안 모델을 구현하는 데 기여합니다.

Istio는 서비스 메시의 핵심 기능 중 하나인 가시성을 종합적으로 제공합니다. 이는 애플리케이션 코드를 수정하지 않고도 서비스 간 통신에 대한 상세한 메트릭, 분산 추적, 액세스 로그를 자동으로 수집하고 시각화할 수 있게 합니다. 이러한 데이터는 마이크로서비스 아키텍처의 복잡한 트래픽 흐름을 이해하고, 성능 병목 현상을 식별하며, 문제를 신속하게 진단하는 데 필수적입니다.

가시성은 주로 데이터 플레인을 구성하는 Envoy 프록시에 의해 구현됩니다. 모든 파드에 사이드카로 주입된 Envoy 프록시는 서비스 간 모든 입출력 트래픽을 가로채고, 다음과 같은 원격 분석 데이터를 생성합니다.

* 메트릭: 요청 볼륨, 응답 지연 시간, 오류율 등 서비스 성능에 관한 지표입니다.

* 분산 추적: 단일 요청이 여러 서비스를 거치는 전체 경로와 각 구간의 소요 시간을 기록합니다.

* 액세스 로그: 각 개별 요청에 대한 상세 정보(예: 소스, 대상, 응답 코드)를 기록합니다.

수집된 데이터는 Istio의 통합 또는 외부 모니터링 도구로 전송되어 분석됩니다. 주요 통합은 다음과 같습니다.

이러한 도구들을 조합함으로써 운영자는 서비스 의존성 지도를 확인하고, p95 지연 시간 또는 서비스 수준 목표 위반을 모니터링하며, 특정 실패 요청의 정확한 호출 체인을 추적할 수 있습니다. 이는 시스템의 건강 상태를 지속적으로 파악하고 신속한 장애 대응을 가능하게 하는 Istio의 핵심 가치입니다.

Istio는 다양한 방법으로 설치 및 구성할 수 있다. 주요 설치 방법으로는 Istio Operator와 Helm 차트를 통한 설치가 있다. 두 방법 모두 Kubernetes 클러스터에 Istio의 컨트롤 플레인 컴포넌트와 사이드카 프록시 인젝터를 배포하는 것을 목표로 하지만, 관리 방식과 세부 구성에서 차이를 보인다.

Istio Operator는 Istio 설치와 생명주기 관리를 위한 선언적 방법을 제공한다. 사용자는 IstioOperator라는 사용자 정의 리소스를 통해 원하는 구성 상태를 정의한다. 예를 들어, 어떤 프로필을 사용할지, 컴포넌트별 설정값, 또는 기능 활성화 여부를 명시한다. Istio Operator 컨트롤러는 이 리소스를 감시하며, 실제 클러스터 상태가 선언된 상태와 일치하도록 필요한 변경 사항을 조정한다. 이 방식은 설치뿐만 아니라 업그레이드, 구성 변경, 컴포넌트 스케일링 등을 통합적으로 관리할 수 있게 해준다. 기본적으로 istioctl install 명령어는 내부적으로 Operator를 사용한다.

반면, Helm은 Kubernetes용 패키지 매니저로, Istio를 구성 가능한 템플릿 차트로 제공한다. 사용자는 values.yaml 파일을 통해 설치 옵션을 재정의하고, helm install 명령어로 배포한다. 이 방법은 Helm 생태계에 익숙한 사용자에게 친숙하며, 릴리스 버전 관리와 템플릿 재사용의 이점이 있다. Istio는 공식적으로 Helm 3를 지원하며, 각 주요 컴포넌트(예: istio-base, istiod, istio-ingressgateway)에 대해 별도의 차트를 제공하여 모듈식 설치를 가능하게 한다.

최근 Istio 프로젝트는 Istio Operator를 기본이자 권장 설치 방법으로 표방한다. 이는 설치 경험을 단순화하고, 업그레이드 및 구성 드리프트 관리에 일관성을 제공하기 위함이다. 그러나 Helm은 여전히 유효한 대안이며, 특히 조직 내에 표준화된 Helm 기반 배포 프로세스가 이미 구축되어 있는 경우 선호된다.

Istio는 서비스 메시의 동작을 정의하기 위해 쿠버네티스 커스텀 리소스 정의를 사용한다. 이 리소스들은 선언적 방식으로 트래픽 라우팅, 로드 밸런싱, 보안 정책 등을 구성하는 데 사용된다. 가장 핵심적인 리소스로는 VirtualService와 DestinationRule이 있으며, 이들은 함께 작동하여 서비스 간 통신의 세부 사항을 제어한다.

VirtualService는 하나 이상의 서비스에 대한 요청이 Istio 서비스 메시 내에서 어떻게 라우팅되는지를 정의한다. 이 리소스는 특정 호스트(서비스)로 향하는 트래픽에 대한 라우팅 규칙을 설정한다. 주요 기능은 다음과 같다.

* 요청 라우팅: HTTP 요청의 경로, 헤더, 권한 등을 기반으로 트래픽을 서비스의 특정 버전(서브셋)으로 전송한다. 이를 통해 카나리 배포나 A/B 테스트를 구현할 수 있다.

* 폴트 인젝션: 의도적으로 지연이나 오류를 트래픽에 주입하여 서비스의 복원력을 테스트한다.

* 트래픽 분할: 가중치를 지정하여 트래픽을 여러 서비스 버전 간에 나눈다.

예를 들어, reviews 서비스로의 트래픽을 v1, v2, v3 버전으로 5:3:2의 비율로 분배하는 규칙을 VirtualService로 정의할 수 있다.

DestinationRule은 VirtualService의 라우팅 규칙이 적용된 후, 트래픽이 실제 목적지 서비스에 도달했을 때 적용되는 정책을 정의한다. 이는 대상 서비스에 대한 운영 정책을 구성하는 역할을 한다. 주요 구성 요소는 다음과 같다.

* 서브셋: 하나의 서비스를 version이나 environment와 같은 레이블에 따라 논리적 그룹으로 나눈다. VirtualService의 라우팅 규칙은 이러한 서브셋을 대상으로 한다.

* 로드 밸런싱 정책: 연결 풀 설정, 로드 밸런싱 알고리즘(예: 라운드 로빈, 최소 연결) 등을 지정한다.

* 연결 보안: 대상 서비스와의 통신에 상호 TLS를 사용할지 여부를 설정한다.

다음은 두 리소스의 관계와 주요 설정 항목을 요약한 표이다.

실제 구성에서는 일반적으로 먼저 DestinationRule을 통해 서비스의 서브셋을 정의한 후, VirtualService에서 해당 서브셋을 참조하여 라우팅 규칙을 작성한다. 이 두 리소스는 게이트웨이와 함께 사용되어 외부 트래픽의 수신부터 내부 서비스 간 세부 라우팅 및 정책 적용까지 종단간 흐름을 관리한다.

카나리 배포는 새로운 소프트웨어 버전을 위험을 최소화하면서 점진적으로 롤아웃하기 위한 전략이다. 이 이름은 과거 광부들이 유독 가스를 탐지하기 위해 카나리아를 이용한 데서 유래했다. 서비스 메시 환경에서 Istio는 애플리케이션 코드 변경 없이 네트워크 수준에서 세밀한 트래픽 라우팅 규칙을 적용하여 카나리 배포를 구현한다.

배포는 일반적으로 두 단계로 진행된다. 먼저 새 버전(카나리 버전)의 서비스를 기존 버전(스테이블 버전)과 함께 배포한다. 이후 Istio의 VirtualService와 DestinationRule 리소스를 구성하여 사용자 트래픽의 일부만 새 버전으로 전달한다. 트래픽 분할은 다양한 기준으로 가능하다.

배포 관리자는 새 버전으로 유입된 트래픽의 성능 지표(지연 시간, 오류율 등)와 로그를 모니터링한다. Prometheus와 Grafana를 통한 메트릭 시각화, Jaeger를 이용한 분산 트레이싱이 이 과정을 지원한다. 문제가 발견되지 않으면 새 버전으로의 트래픽 비율을 단계적으로 증가시켜 결국 모든 트래픽을 전환한다. 반면, 문제가 발생하면 트래픽을 즉시 이전 스테이블 버전으로 완전히 되돌릴 수 있다. 이 접근 방식은 롤백 시간을 최소화하고 장애 영향을 제한한다.

서킷 브레이커는 마이크로서비스 아키텍처에서 장애가 연쇄적으로 전파되는 것을 방지하기 위한 패턴입니다. Istio는 데이터 플레인의 Envoy 프록시를 통해 이 패턴을 투명하게 구현하여, 서비스 간 호출에서 실패나 지연이 특정 임계값을 초과할 경우 해당 연결을 일시적으로 차단합니다. 이는 장애가 발생한 서비스에 대한 추가적인 요청 부하를 줄이고, 시스템 전체의 자원 소모를 방지하는 데 목적이 있습니다.

Istio에서 서킷 브레이커는 주로 DestinationRule 리소스를 통해 구성됩니다. 이 리소스에서는 연결 풀 설정과 이상 감지 설정을 정의하여 서비스의 건강 상태를 모니터링하고 제어합니다. 주요 구성 항목은 다음과 같습니다.

예를 들어, consecutive5xxErrors를 5로 설정하면 목적지 서비스로부터 연속 5회의 서버 오류 응답이 발생했을 때, 해당 호스트는 지정된 시간 동안 아웃바운드 연결 풀에서 제거됩니다. 이 기간 동안 Envoy 프록시는 새로운 요청을 장애 서비스로 라우팅하지 않고 즉시 실패 처리합니다.

이 메커니즘은 시스템의 회복 탄력성을 높입니다. 장애 서비스는 요청 부하에서 벗어나 회복할 시간을 갖게 되고, 호출자는 빠르게 실패하여 대체 로직을 실행하거나 사용자에게 적절한 에러 메시지를 반환할 수 있습니다. 서킷 브레이커 상태는 주기적으로 확인되며, 서비스가 정상으로 돌아오면 자동으로 연결이 재개됩니다. 이를 통해 애플리케이션 코드를 수정하지 않고도 네트워크 수준에서 견고한 장애 조치를 구현할 수 있습니다.

폴트 인젝션은 서비스 메시에서 의도적으로 오류를 발생시켜 시스템의 복원력을 테스트하고 검증하는 기법이다. 이는 카나리 배포나 서킷 브레이커와 같은 복원력 패턴이 실제로 제대로 작동하는지 확인하기 위한 목적으로 사용된다. 운영 중인 시스템에 실제 사용자 트래픽에 영향을 주지 않고 안전하게 테스트를 수행할 수 있게 해준다.

Istio는 VirtualService 리소스를 통해 다양한 형태의 폴트를 주입할 수 있다. 주로 사용되는 폴트 유형은 다음과 같다.

예를 들어, reviews 서비스의 v2 버전에 대해 1000ms의 지연을 10%의 요청에 추가하거나, 10%의 요청에 대해 HTTP 500 오류를 반환하도록 구성할 수 있다. 이렇게 하면 애플리케이션의 타임아웃 설정이나 재시도 정책, 서킷 브레이커의 트리거 조건이 예상대로 동작하는지 관찰할 수 있다.

폴트 인젝션은 카오스 엔지니어링의 핵심 실천법 중 하나로, 시스템의 약점을 사전에 발견하고 개선하는 데 기여한다. 이를 통해 개발팀과 운영팀은 장애 발생 시의 시스템 동작을 미리 경험하고, 복구 절차를 검증하며, 궁극적으로 더 견고한 마이크로서비스 아키텍처를 구축할 수 있다.

ISTIO는 기본적으로 쿠버네티스 환경에서 실행되도록 설계되었으며, 두 기술은 긴밀하게 통합되어 서비스 메시를 구현합니다. ISTIO의 모든 구성 요소와 사용자 정의 리소스는 쿠버네티스의 API 서버를 통해 관리됩니다. ISTIO는 쿠버네티스 클러스터 내의 파드에 사이드카 형태로 Envoy 프록시를 주입하여 네트워크 트래픽을 가로채고 제어합니다.

ISTIO의 설치와 운영은 쿠버네티스의 선언적 모델에 의존합니다. 사용자는 VirtualService, DestinationRule, Gateway와 같은 커스텀 리소스 정의를 배포하여 트래픽 라우팅, 로드 밸런싱, 보안 정책을 정의합니다. ISTIO의 컨트롤 플레인은 이러한 리소스의 변경 사항을 감지하고, 이를 데이터 플레인인 Envoy 프록시에 실시간으로 전파하여 구성합니다. 또한, ISTIO는 쿠버네티스의 서비스 디스커버리 메커니즘을 활용하여 클러스터 내 서비스 엔드포인트를 자동으로 인식합니다.

다음 표는 ISTIO와 쿠버네티스의 주요 통합 지점을 보여줍니다.

이러한 깊은 통합 덕분에 개발자와 운영자는 익숙한 쿠버네티스 인터페이스를 그대로 사용하면서도, ISTIO가 제공하는 세분화된 트래픽 제어, 강화된 보안, 상세한 관측 가능성을 서비스에 추가할 수 있습니다. ISTIO는 쿠버네티스 생태계의 핵심적인 네트워킹 계층으로 자리 잡았습니다.

Istio는 애플리케이션의 메트릭을 자동으로 수집하고, 이 데이터를 프로메테우스(Prometheus)에 노출시킨다. Istio의 데이터 플레인인 Envoy 프록시는 모든 서비스 간 통신에 대한 풍부한 메트릭(예: 요청량, 지연 시간, 오류율)을 생성하며, 컨트롤 플레인 구성 요소들도 자체 메트릭을 제공한다. Istio는 프로메테우스가 이러한 메트릭을 스크랩할 수 있도록 서비스 디스커버리와 자동 구성을 지원한다[3].

수집된 메트릭은 그라파나(Grafana) 대시보드를 통해 시각화된다. Istio는 사전 구성된 그라파나 대시보드를 제공하여 서비스 메시의 상태를 실시간으로 모니터링할 수 있게 한다. 주요 대시보드에는 메시 개요, 서비스별 성능, 워크로드별 성능 등이 포함되어 있다. 이를 통해 운영자는 트래픽 흐름, 서비스 의존성, 성능 병목 현상을 직관적으로 파악할 수 있다.

이 통합은 서비스 메시(Service Mesh)의 핵심 가치 중 하나인 가시성(Observability)을 실현하는 기반이 된다. 사용자는 추가 코드 변경 없이 애플리케이션 수준과 인프라 수준의 통합 모니터링을 확보할 수 있다. 또한, 프로메테우스에서 수집한 데이터를 기반으로 사용자 정의 경고 규칙을 설정하여 문제를 조기에 감지할 수 있다.

Jaeger는 CNCF(Cloud Native Computing Foundation)의 졸업 프로젝트로서, 분산 시스템의 성능 문제를 해결하기 위한 분산 추적 시스템이다. Istio는 서비스 메시 내의 마이크로서비스 간 통신에 대한 세밀한 트레이스를 생성하며, 이를 수집, 저장, 분석 및 시각화하기 위한 백엔드로 Jaeger와의 통합을 공식적으로 지원한다.

Istio는 Envoy 프록시가 생성한 스팬(Span) 데이터를 Jaeger 수집기에 자동으로 전송한다. 사용자는 애플리케이션 코드를 수정할 필요 없이, Istio의 사이드카 인젝션 기능만으로 서비스 간의 모든 호출에 대한 분산 트레이스를 얻을 수 있다. 트레이스 데이터는 Jaeger의 사용자 인터페이스를 통해 시각적으로 조회할 수 있으며, 각 요청이 통과한 서비스, 각 단계의 지연 시간, 오류 발생 여부 등을 확인하여 병목 지점을 식별하는 데 유용하다.

Istio에서 Jaeger를 설정하는 주요 방법은 다음과 같다.

이 통합을 통해 운영자는 복잡한 마이크로서비스 아키텍처에서 발생하는 요청의 전체 경로를 하나의 트랜잭션 뷰로 확인할 수 있다. 이는 지연 시간 문제의 근본 원인 분석, 서비스 종속성 매핑, 그리고 성능 최적화를 위한 핵심적인 가시성 도구 역할을 한다.