마이크로서비스 아키텍처(MSA)가 확산되면서 서비스 간 통신의 복잡성이 기하급수적으로 증가했습니다. 기존의 모놀리식 환경에서는 함수 호출로 해결되던 것이 네트워크 통신으로 바뀌면서 레이턴시, 보안, 트래픽 제어, 가시성 확보 등의 문제가 발생했습니다. 저희 팀 또한 50개 이상의 마이크로서비스를 운영하면서 "어떤 서비스가 에러를 뱉고 있는지", "특정 버전으로 트래픽을 어떻게 안전하게 흘려보낼지"에 대한 고민이 깊어졌습니다. 이러한 문제를 해결하기 위해 Istio 서비스 메시를 도입하기로 결정했습니다.
본 글에서는 Kubernetes 클러스터에 Istio를 설치하고, 사이드카를 주입하여 트래픽을 제어하는 전체 과정을 상세히 다룹니다. 특히 Canary 배포를 위한 가중치 기반 라우팅과 Kiali를 이용한 시각화 부분을 중점적으로 설명합니다.
실습 환경은 다음과 같습니다.
Istio는 컨트롤 플레인(Istiod)과 데이터 플레인(Envoy Proxy)으로 구성됩니다. 저희는 프로덕션 환경을 고려하여 Demo 프로필을 사용하여 설치를 진행했습니다.
가장 먼저 Istio 설치 도구인 istioctl을 다운로드합니다.
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.20.0
export PATH=$PWD/bin:$PATH설치가 완료되었다면 버전을 확인하여 정상적으로 다운로드되었는지 검증합니다.
istioctl version
demo 프로필은 학습 및 테스트 목적에 적합한 설정(높은 추적 레벨, 접근 로그 활성화 등)을 포함하고 있습니다.
istioctl install --set profile=demo -y
설치 명령어를 실행하면 istio-system 네임스페이스에 istiod, istio-ingressgateway, istio-egressgateway 파드가 생성됩니다.
Istio의 핵심은 각 애플리케이션 파드에 Envoy 프록시를 사이드카 형태로 끼워 넣는 것입니다. 이를 자동으로 수행하기 위해 네임스페이스에 레이블을 추가합니다.
kubectl label namespace default istio-injection=enabled
이제 default 네임스페이스에 배포되는 모든 파드는 자동으로 istio-proxy 컨테이너를 포함하게 됩니다.
Istio에서 제공하는 bookinfo 예제 애플리케이션을 배포하여 테스트를 진행합니다.
이 앱은 Productpage, Details, Reviews(v1, v2, v3), Ratings 서비스로 구성되어 있습니다.
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
배포 후 kubectl get pods를 확인해보면 각 파드의 컨테이너 수가 2/2로 표시되는 것을 볼 수 있습니다. (앱 컨테이너 + 사이드카 컨테이너)
외부 트래픽을 클러스터 내부로 인입시키기 위해 Gateway 리소스를 정의합니다.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
그리고 VirtualService를 통해 들어온 트래픽을 productpage 서비스로 라우팅합니다.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo
spec:
hosts:
- "*"
gateways:
- bookinfo-gateway
http:
- match:
- uri:
exact: /productpage
- uri:
prefix: /static
- uri:
exact: /login
- uri:
exact: /logout
- uri:
prefix: /api/v1/products
route:
- destination:
host: productpage
port:
number: 9080이 설정을 적용하면 Ingress Gateway IP를 통해 브라우저에서 Bookinfo 앱에 접근할 수 있습니다.
Reviews 서비스의 v1(별점 없음)과 v2(검은 별점) 버전에 대해 트래픽을 90:10 비율로 나누어보겠습니다. 먼저 DestinationRule을 정의하여 버전을 구분합니다.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2그 다음 VirtualService를 수정하여 가중치를 설정합니다.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10이제 브라우저를 새로고침 해보면 대부분 v1이 보이고 간헐적으로 v2가 보이는 것을 확인할 수 있습니다.
서비스 간의 연결 관계와 트래픽 흐름을 시각적으로 파악하기 위해 Kiali를 설치합니다.
kubectl apply -f samples/addons
kubectl rollout status deployment/kiali -n istio-system포트 포워딩을 통해 로컬에서 Kiali에 접속합니다.
istioctl dashboard kiali'Graph' 메뉴로 들어가면 각 마이크로서비스(Productpage, Reviews, Ratings 등)가 어떻게 연결되어 있는지 그래프 형태로 보여줍니다. 특히 앞서 설정한 90:10 트래픽 분할이 실제로 이루어지고 있는지, 특정 구간에서 에러(5xx)가 발생하고 있는지 실시간으로 확인할 수 있습니다. 저희는 이 기능을 통해 Reviews v3 배포 시 발생한 지연 문제를 즉각적으로 파악하고 롤백할 수 있었습니다.
Istio 도입을 통해 다음과 같은 성과를 얻었습니다.
하지만 사이드카 패턴으로 인한 리소스 오버헤드(각 파드마다 약 100MB 메모리 추가 소모)는 고려해야 할 사항입니다. 향후에는 Istio Ambient Mesh를 도입하여 사이드카 없는 구조로 성능 최적화를 진행할 예정입니다. MSA 환경에서 서비스 메시는 선택이 아닌 필수에 가깝다는 것을 이번 프로젝트를 통해 절실히 깨달았습니다.