Istio Service Mesh: East-West Traffic

이번 포스트에서는 Kubernetes 기반 MSA(Microservices Architecture) 환경에서 Istio Service Mesh가 관리하는 East-West Traffic에 대해 전반적으로 설명합니다. North-South 트래픽(외부 → 클러스터 내부)과 달리 East-West 트래픽은 클러스터 내부 서비스 간 통신을 의미하며, 마이크로서비스 아키텍처에서 가장 빈번하게 발생하는 트래픽 유형입니다.

Istio는 이러한 내부 통신을 투명하게 관제·제어·보호하는 강력한 Service Mesh로, 사이드카 패턴(Envoy Proxy)을 통해 트래픽을 가로채고 정책을 적용합니다.

목차

1. East-West Traffic이란?
1-1. North-South vs East-West
2. Kubernetes MSA에서 East-West Traffic의 특징
3. Istio가 East-West Traffic을 어떻게 관리하나?
4. 실제 예시 구성 개요
5. 결론 및 운영 팁

1. East-West Traffic이란?

East-West Traffic은 클러스터 내부의 Pod(서비스) 간 통신을 의미합니다. 마이크로서비스 환경에서 하나의 사용자 요청을 처리하기 위해 여러 서비스가 연쇄적으로 호출되는 경우가 많아, 이 내부 통신량이 전체 트래픽의 대부분을 차지합니다.

예를 들어, 프론트엔드 서비스가 상품 서비스 API를 호출하고, 상품 서비스가 재고 서비스·결제 서비스를 다시 호출하는 구조가 전형적인 East-West 트래픽 패턴입니다.

1-1. North-South vs East-West

2. Kubernetes MSA에서 East-West Traffic의 특징

• 빈번한 서비스 간 호출: 하나의 사용자 요청이 여러 마이크로서비스를 거치며 호출 체인이 길어짐
• 동적 네트워크: Pod IP가 자주 변경되므로 서비스 디스커버리가 필수
• 보안 요구사항 증가: 내부 통신이라도 데이터 유출 방지를 위해 mTLS 필요
• 관찰성 요구: 호출 체인 추적(Tracing), 메트릭 수집, 로깅이 복잡
• 장애 전파 위험: 한 서비스의 지연/장애가 전체 체인에 영향

이러한 특징 때문에 순수 Kubernetes만으로는 East-West 트래픽을 효과적으로 관리하기 어렵고, 서비스 메시(Istio, Linkerd 등)의 도입이 필수적입니다.

3. Istio가 East-West Traffic을 어떻게 관리하나?

Istio는 사이드카 프록시(Envoy)를 모든 Pod에 주입하여 내부 트래픽을 가로채고 제어합니다. 주요 기능은 다음과 같습니다:

• mTLS(Mutual TLS): 모든 내부 통신 자동 암호화 및 상호 인증
• 트래픽 관리: VirtualService, DestinationRule로 라우팅, 로드밸런싱, Fault Injection, Retry, Timeout 설정
• 관찰성: Kiali 대시보드, Prometheus 메트릭, Jaeger 분산 추적, Access Log
• 보안 정책: AuthorizationPolicy로 RBAC 기반 접근 제어
• 투명성: 애플리케이션 코드 수정 없이 정책 적용 가능

특히 East-West 트래픽은 사이드카를 통해 모두 Envoy Proxy를 거치므로, 지연 분석, 장애 지점 파악, 보안 감사 등이 훨씬 용이해집니다.

4. 실제 예시 구성 개요

아래에서는 Istio 환경에서 East-West 트래픽을 관찰하는 예제를 다룹니다.
(※ 이 포스트 내에서는 NGINX Gateway Fabric과 Istio 배포에 대한 내용은 다루지 않습니다.)

• NGINX Gateway Fabric을 통해 North-South 트래픽으로 외부 클라이언트가 nginx-example-1 Pod(프론트엔드 역할)에 접근
• 프론트엔드 페이지에 있는 버튼 클릭 시, nginx-example-1 내부의 NGINX 설정(proxy_pass)을 통해 nginx-example-2 Pod로 East-West 트래픽 발생
• /api/product 경로 호출을 통해 백엔드 데이터 로드
• Istio 사이드카(Envoy)가 이 내부 트래픽을 가로채 메트릭 수집, 추적 정보 생성

이 포스트에서 사용될 테스트용 리소스입니다:

root@master:~# kubectl get pods,svc,gateway,httproute -n ngf-shin
NAME                                        READY   STATUS    RESTARTS   AGE
pod/ho-ngf-gateway-nginx-7df88cdf5d-dkzl8   2/2     Running   0          23h
pod/nginx-example-1-7754bbbfb9-7rglq        2/2     Running   0          4h54m
pod/nginx-example-2-ff6946d8-fj8rf          2/2     Running   0          4h54m

NAME                           TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
service/ho-ngf-gateway-nginx   LoadBalancer   10.105.42.126    192.168.40.20   80:31187/TCP   7d4h
service/nginx-example-1        ClusterIP      10.96.23.74      <none>          80/TCP         4h54m
service/nginx-example-2        ClusterIP      10.106.233.209   <none>          8081/TCP       4h54m

NAME                                               CLASS   ADDRESS         PROGRAMMED   AGE
gateway.gateway.networking.k8s.io/ho-ngf-gateway   nginx   192.168.40.20   True         7d4h

NAME                                                   HOSTNAMES                   AGE
httproute.gateway.networking.k8s.io/ho-ngf-httproute   ["ho-ngf.devopsshin.com"]   7d4h

각 파드에는 Istio Sidecar가 포함되어 있습니다.

아래와 같이 Client의 요청을 받는 nginx-example-1의 Pod에서 /api/product로 요청이 발생했을 때 다음과 같이 처리됩니다.

NGINX 구성과 같이 nginx-example-1 파드에서 /api/product 요청이 발생하면 nginx-example-2 svc로 요청을 넘겨 East-West Traffic을 발생시킵니다.

nginx-example-1에서 발생한 /api/product 요청을 받는 nginx-example-2 서비스의 응답은 다음과 같습니다.

이 예제를 통해 Istio가 어떻게 내부 서비스 간 통신을 투명하게 보호하고 관찰 가능한지 직접 확인할 수 있습니다.

GUI 상으로 접근했을 때 nginx-example-1이 보여주는 화면은 다음과 같습니다.

Get Request nginx-example-2 버튼을 클릭하면 nginx-example-2 파드 내에 있는 json을 불러오게 됩니다.

nginx-example-1 pod <-> nginx-example-2 pod가 서로 트래픽을 주고 받아 East-West Traffic이 흐르게 되며, 이 Istio-proxy container log에서 확인할 수 있습니다.

왼쪽이 nginx-example-1의 istio-proxy container 로그이고, 오른쪽이 nginx-example-2의 istio-proxy로그입니다.

East-West Traffic을 log로 각각 확인하여 병목 구간 또는 트래픽의 흐름 분석을 명확하게 할 수 있습니다

또한 Kiali와 같은 모니터링 툴로 trace 해보면 다음과 같습니다.

5. 결론 및 운영 팁

• East-West 트래픽은 MSA의 핵심이며, Istio 없이 관리하면 보안·관찰성·안정성 확보가 어렵습니다.
• Istio 도입 시 사이드카 자동 주입, mTLS 기본 활성화로 보안 수준을 크게 높일 수 있습니다.
• 운영 시 Kiali로 토폴로지 시각화, Jaeger로 호출 체인 추적을 반드시 활용하세요.
• 초기에는 strict mTLS 대신 permissive 모드로 시작해 점진적으로 강화하는 것을 추천합니다.

Istio Service Mesh를 통해 East-West 트래픽을 효과적으로 관리하면, 복잡한 마이크로서비스 환경에서도 안정성과 보안성을 유지할 수 있습니다.

NGINX Gateway Fabric 또는 Istio에 관심이 있으시다면, NGINX STORE에 연락하여 논의하십시오.