[EKS/Istio] 서비스 메시와 Istio를 활용한 버전 기반 라우팅 실습

서비스 메시란? - 서비스 메시 설명 - AWS

istio/samples/bookinfo/platform/kube/bookinfo.yaml at master · istio/istio

---

얼마 전 참여했던 Dev Meetup에서 가장 흥미롭게 들었던 부분은 Service Mesh 중 Istio 였다. "애플리케이션 코드 수정 없이 네트워크를 제어한다"는 개념은 매우 매력적인 주제였다. Meetup에서 간단히 이론을 듣는 것에 그치지 않고, 직접 AWS EKS 환경 위에 Istio를 올리고 istio에서 제공하는 bookinfo를 바탕으로 3개의 서비스 버전을 제어하며 가졌던 의문과 해답들을 정리해본다.

1. 서비스 메시(Service Mesh)란?

서비스 메시는 마이크로서비스 아키텍처(MSA)에서 각 서비스 간의 통신을 관리하기 위한 전용 소프트웨어 계층으로, 애플리케이션의 비즈니스 로직과 분리되어 네트워크 통신을 제어하며, 가시성, 보안, 안정성을 제공한다.

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2018/11/28/appmesh-proxy-1024x341.png

주요 기능 및 이점

• 서비스 검색: 메시 내 서비스들을 동적으로 추적하여 서비스 위치에 관계없이 서로를 찾고 통신할 수 있게 한다.
• 로드 밸런싱: 요청을 여러 인스턴스에 지능적으로 분산하여 리소스 활용도를 최적화한다.
• 트래픽 관리: 카나리 배포, 요청 미러링 등을 통해 안전한 배포와 테스트를 지원한다.
• 보안: 상호 TLS 암호화를 통해 데이터 기밀성을 보장하고, 서비스 간 인증 및 권한 부여를 처리한다.
• 모니터링 및 관찰성: 지연 시간, 오류율 등의 지표 수집과 분산 추적을 통해 시스템 상태를 상세히 파악한다.

작동 원리

• 데이터 영역: 각 서비스 옆에 사이드카 형태로 배치된 프록시들로 구성된다. 실제 서비스 간 모든 트래픽을 가로채고 전달하는 역할
• 제어 영역: 관리자가 정책과 구성을 정의하는 중앙 관리 계층으로 정의된 설정을 데이터 영역의 프록시들에 배포하여 동작을 제어한다.

도입 시 고려사항

• 데이터 플레인 리소스 (사이드카 오버헤드)
  • 메모리 및 CPU 소모: 서비스 메시는 각 마이크로서비스마다 사이드카 프록시를 하나씩 배치하는데 이 때문에 서비스가 많을 경우 전체 클러스터에서 무시할 수 없는 수준의 인프라 비용이 추가된다.
  • 네트워크 지연: 트래픽이 반드시 프록시를 거쳐야 하므로, 홉이 늘어남에 따라 미세한 네트워크 지연이 발생한다.
• 컨트롤 플레인 부하
  • 설정 배포 부하: 마이크로서비스의 개수가 수천 개로 늘어나면, 컨트롤 플레인이 모든 사이드카 프록시에 실시간으로 설정을 전파하는 과정에서 부하가 급증한다.
  • 관리 복잡도: 컨트롤 플레인 자체가 고가용성을 유지해야 하므로, 이를 관리하기 위한 운영 인력과 모니터링 비용이 추가로 발생한다.

2. EKS 클러스터 구축

먼저 AWS에서 실제로 전체 인프라를 조종할 물리 서버(EC2)를 생성하고, eksctl을 활용해 t3.medium 인스턴스 2개 규모의 클러스터를 생성했다. 인프라 재현성을 위해 모든 과정은 Bash 스크립트로 자동화했다.

# eksctl을 활용한 클러스터 생성
eksctl create cluster \
  --name istio-lab \
  --region ap-northeast-2 \
  --nodegroup-name istio-nodes \
  --node-type t3.medium \
  --nodes 2 \
  --managed

• 질문: 노드는 2개인데, 어떻게 서비스 버전은 3개가 돌아가는가?
  • 통찰: 노드는 하위 계층에서 CPU와 메모리를 제공하는 물리적 자원 풀이며, 서비스 버전은 그 위에서 구동되는 논리적 객체이다. 따라서 노드의 개수는 서비스의 가짓수가 아닌, 시스템의 장애 내성을 결정하는 통제 변수로 이해해야 한다.

3. Istio 설치와 사이드카 패턴 확인

EKS 구축 후 Istio를 설치하고 네임스페이스(default)에 자동 주입 설정을 마친 뒤, Bookinfo 샘플 앱을 배포했다.

# default 네임스페이스에 배포되는 모든 Pod에 Istio 프록시가 자동으로 붙도록 라벨 설정
kubectl label namespace default istio-injection=enabled

# Istio 샘플 디렉토리에 있는 bookinfo.yaml 배포
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

• 질문: Bookinfo 앱 배포 후 kubectl get pods에서 보이는 2/2 는 무엇을 의미하는가?
  • 통찰: 하나의 Pod 안에 비즈니스 앱 컨테이너와 Istio 프록시 컨테이너가 하나로 묶여 있기 때문에 2/2로 표시된다. 해당 Pod 내부에 있는 프록시가 앱의 입출구 역할을 대신해주기 때문에 통제권이 인프라 계층으로 넘어오게 된다.

4. Bookinfo 앱을 통한 트래픽 제어 확인

배포 후 웹 페이지를 새로고침할 때마다 별점 모양(없음/검은별/빨간별)이 순차적으로 바뀌는 것을 확인했다.

• 질문: 새로고침할 때마다 바뀌는 이유는?
  • 통찰: 새로고침마다 화면이 바뀌는 것은 라벨로 묶인 여러 파드들 사이를 Istio가 라운드 로빈 방식으로 연결해주기 때문이다. 즉, 서비스의 외적인 변화는 하단의 메타데이터 관리와 트래픽 분배 정책에 의해 결정된다.

5. 후기

Meetup에서의 호기심으로 시작한 실습은 EC2-Pod-Container로 이어지는 수직적 구조와, 이를 관통하는 Istio의 통제 방식을 직접 경험하는 시간이었다. 이제 깔끔하게 정리된 내용 위에, 다음 번에는 카나리 배포를 통한 세밀한 트래픽 전환과 프로메테우스/그라파나 기반의 정밀 모니터링을 실습하고 결과를 공유할 예정이다.