내 Istio가 점점 느려지는 충격적인 이유 (feat. Sidecar 리소스)

혹시 여러분의 서비스 메시는 안녕하신가요? 🤔 마이크로서비스(MSA) 아키텍처가 복잡해지고 서비스의 수가 늘어날수록 Istio가 점점 무거워지고 느려지는 경험, 다들 한 번쯤은 있으실 겁니다. 사이드카 프록시의 메모리 사용량은 하늘 높은 줄 모르고 치솟고, 설정이 전파되는 시간도 점점 길어지죠.

 

"서버 사양을 늘려야 하나?" 고민하셨다면, 잠시만요! ✋ 어쩌면 아주 간단한 설정 하나를 놓치고 있었을지도 모릅니다. 오늘은 많은 분들이 간과하지만, Istio 성능 최적화의 핵심 열쇠인 Sidecar 리소스에 대해 깊이 파헤쳐 보겠습니다.

---

🌍 기본 설정의 함정: "모든 것을 알려줄게!"

Istio를 설치하고 서비스를 메시에 편입시키면, 기본적으로 각 워크로드에 주입된 사이드카 프록시(Envoy)는 아주 친절하고 부지런하게 일합니다. 너무 부지런한 나머지, 메시에 존재하는 모든 서비스에 대한 라우팅 정보, 엔드포인트 등 모든 설정을 컨트롤 플레인(Istiod)으로부터 수신하죠.

 

이게 왜 문제일까요? 🤯

 

서비스가 10개일 때는 괜찮을 수 있습니다. 하지만 100개, 500개로 늘어난다고 상상해 보세요. A 서비스가 오직 B 서비스와만 통신하면 되는데도, 전혀 상관없는 C, D, E...Z 서비스의 정보까지 모두 꾸역꾸역 받아 메모리에 쌓아두는 셈입니다.

마치 서울의 특정 동네에서만 배달하는 라이더에게 대한민국 전체 지도와 주소록을 통째로 쥐여주는 것과 같습니다. 🗺️

• 메모리 & CPU 폭증: 불필요한 설정 정보가 사이드카의 리소스 사용량을 급격히 증가시킵니다.
• 느린 설정 전파: 설정의 크기가 커지니, 작은 변경 사항 하나가 전체 메시의 모든 프록시에 전파되는 데 오랜 시간이 걸립니다.
• 성능 저하: 결국 서비스 메시 전반의 성능 저하로 이어집니다.

---

🦸‍♂️ 구원 등판! Sidecar 리소스

이러한 비효율을 해결하기 위해 Sidecar 리소스가 존재합니다. Sidecar 리소스는 각 사이드카 프록시가 "알아야 할 것만 알도록" 설정의 범위를 현명하게 제한해 주는 역할을 합니다.

 

즉, "모든 것을 알려줄게!" 모드에서 "네게 꼭 필요한 정보만 알려줄게!" 모드로 전환하는 스위치인 셈이죠. 💡

Sidecar 리소스의 핵심은 egress 필드입니다. 이 필드를 통해 해당 워크로드가 외부로 통신(outbound)해야 하는 대상을 명시적으로 지정할 수 있습니다.

🛠️ 직접 확인해볼까요?

예를 들어, bookinfo 예제의 reviews 서비스는 오직 ratings 서비스와만 통신한다고 가정해 봅시다.

 

1. Sidecar 리소스 적용 전

아무런 Sidecar 리소스가 없다면, reviews 파드의 사이드카는 메시 내의 모든 서비스(productpage, details 등)에 대한 설정을 받습니다. 아래 명령어로 확인해 볼 수 있습니다. (결과 라인 수는 환경에 따라 다릅니다.)

# reviews 파드의 이름을 확인
REVIEWS_POD=$(kubectl get pod -l app=reviews -n bookinfo -o jsonpath='{.items[0].metadata.name}')

# reviews 파드의 사이드카가 알고 있는 클러스터(서비스) 목록 확인
istioctl proxy-config clusters $REVIEWS_POD -n bookinfo | wc -l

# Raw Data (예시)
# 아마 꽤 큰 숫자가 나올 겁니다. 예를 들어...
52

 

2. Sidecar 리소스 적용하기

이제 reviews 워크로드를 위한 Sidecar 리소스를 정의해 봅시다. 이 설정은 reviews 앱이 같은 네임스페이스(bookinfo)에 있는 ratings 서비스와 istio-system 네임스페이스의 필수 컴포넌트하고만 통신하도록 제한합니다.

# Code
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: reviews-sidecar
  namespace: bookinfo
spec:
  # 'app: reviews' 레이블을 가진 파드에 이 설정을 적용합니다.
  workloadSelector:
    labels:
      app: reviews
  egress:
    # 아웃바운드 트래픽 대상을 명시합니다.
    - hosts:
        # 1. 현재 네임스페이스("./")의 서비스만 허용
        - "./ratings.bookinfo.svc.cluster.local"
        # 2. Istiod 등 컨트롤 플레인 통신을 위한 필수 설정
        - "istio-system/*"

 

위 YAML 파일을 kubectl apply -f 명령어로 적용합니다.

 

3. Sidecar 리소스 적용 후

다시 한번 프록시 설정을 확인해 봅시다.

# 잠시 후 설정을 다시 확인
istioctl proxy-config clusters $REVIEWS_POD -n bookinfo | wc -l

# Raw Data (예시)
# 이전보다 훨씬 작은 숫자가 나옵니다. 예를 들어...
15

 

결과가 보이시나요? 🚀 reviews 사이드카가 관리해야 할 설정의 양이 극적으로 줄었습니다. 이는 곧바로 리소스 사용량 감소와 성능 향상으로 이어집니다.

---

🧐 흔한 오해와 잘못된 접근법

Sidecar 리소스를 이해할 때 흔히 하는 오해들이 있습니다. 잘못된 방법은 오히려 문제를 악화시킬 수 있으니 꼭 짚고 넘어가야 합니다.

• "그냥 메모리/CPU 할당량을 늘리면 안 되나요?" (❌)
  • 이것은 근본적인 원인을 해결하는 것이 아니라, 문제를 돈으로 덮는 미봉책에 불과합니다. 🚚 배달 경로가 비효율적인데, 더 큰 트럭을 사는 것과 같죠. 사이드카의 리소스 할당은 파드 정의(Deployment)의 resources 필드에서 하는 것이 맞지만, 이는 설정 범위를 최적화한 후에 필요한 만큼 할당하는 것이 올바른 순서입니다.
• "사이드카 주입을 끄면 되지 않나요?" (❌)
  • 네임스페이스 레이블이나 파드 어노테이션(sidecar.istio.io/inject: "false")으로 주입을 제어하는 것은 해당 워크로드를 아예 서비스 메시에서 제외하는 것입니다. 이건 "최적화"가 아니라 "포기"에 가깝습니다. 우리는 메시의 장점을 누리면서 성능을 개선하고 싶은 것이지, 메시를 떠나고 싶은 게 아닙니다.
• "설정 업데이트 빈도를 조절하는 기능인가요?" (❌)
  • Sidecar 리소스는 업데이트 빈도를 제어하지 않습니다. 수신하는 설정의 범위와 크기를 제한할 뿐입니다.

---

✨ 전체적인 관점에서

개별 Sidecar 리소스를 적용하는 것도 중요하지만, 전체적인 맥락에서 접근하는 것이 좋습니다.

1. 네임스페이스 격리: 먼저, 각 네임스페이스가 꼭 필요한 다른 네임스페이스의 서비스만 볼 수 있도록 네임스페이스 단위의 Sidecar 리소스를 기본으로 설정하세요. (./*, istio-system/* 및 필요한 다른 네임스페이스 namespace-b/* 등)
2. 워크로드 특화: 그 후, reviews 서비스처럼 특별히 통신 범위가 더 좁은 워크로드가 있다면, workloadSelector를 사용해 더 세분화된 Sidecar 리소스를 추가로 적용하는 전략이 효과적입니다.

이러한 접근법은 서비스 메시를 더욱 견고하고, 예측 가능하며, 무엇보다도 빠르게 만들어 줍니다. 여러분의 Istio가 왠지 모르게 느려졌다면, 지금 바로 Sidecar 리소스를 점검해 보세요!