Istio/Linkerd 트래픽 문제 완벽 디버깅 가이드: 헬스 체크 실패부터 라우팅 오류까지

마이크로서비스 아키텍처(MSA)를 구축하는 과정에서 Service Mesh는 마치 만능 해결책처럼 보입니다. 관측성(Observability)을 극대화하고, 서비스 간 통신에 대한 보안 정책을 중앙에서 관리할 수 있게 해주죠. Istio나 Linkerd 같은 툴을 도입하면 트래픽 흐름을 눈으로 직접 확인할 수 있게 되어 개발자 입장에서는 꿈만 같습니다.

하지만, 현실은 녹록지 않습니다. "작동하던 서비스가 갑자기 다운된다", "특정 버전으로 트래픽을 보내려는데 엉뚱한 곳으로 간다"와 같은 운영상의 난제에 부딪히기 쉽습니다. 이 복잡성이야말로 Service Mesh가 주는 가장 큰 '트래픽 함정'이기도 합니다.

이 글은 단순히 이론적인 설명을 넘어, 실제 운영 환경에서 마주치는 헬스 체크 실패, 잘못된 라우팅, 디스커버리 지연 등의 복잡한 트래픽 문제를 YAML 수정과 명령어 조합을 통해 어떻게 실질적으로 해결할 수 있는지에 초점을 맞춘 가이드입니다.

Service Mesh, 트래픽을 가로채는 마법의 원리 이해하기

Service Mesh가 어떻게 트래픽을 제어하는지 이해하는 것이 디버깅의 첫걸음입니다. Istio나 Linkerd는 기본적으로 Sidecar 패턴을 사용합니다.

쉽게 비유하자면, 여러분의 마이크로서비스(A 서비스)가 친구(B 서비스)에게 편지(HTTP Request)를 보낼 때, 이 편지함 입구와 출구에 의무적으로 '보안 검문소(Sidecar Proxy, 보통 Envoy)'가 설치되는 것과 같습니다.

1. 트래픽 가로채기 (Interception): 애플리케이션이 B 서비스로 요청을 보내면, 실제 네트워크 인터페이스를 통하지 않고 먼저 이 Sidecar 프록시를 거치게 됩니다.
2. 정책 적용: 이 프록시는 요청을 가로채서, "이 요청은 인증이 필요한가?", "특정 헤더가 붙었는가?", "헬스 체크를 통과했는가?" 등의 복잡한 정책 검사를 수행합니다.

이 과정이 강력한 만큼, 이 검문소(프록시)의 설정 하나가 전체 서비스의 생명줄이 됩니다. 만약 헬스 체크 로직이 잘못되거나, 라우팅 규칙이 모호하면, 이 검문소 자체가 병목 지점이 되거나 오작동을 일으키는 것이죠.

🚨 헬스 체크 실패와 잘못된 라우팅, DestinationRule로 정밀 제어하기

가장 흔하게 부딪히는 문제는 '헬스 체크 실패'입니다. 기본적으로 Service Mesh는 서비스가 정상인지 확인하기 위해 헬스 체크를 수행합니다. 하지만 이 기본 로직이 애플리케이션의 실제 비즈니스 로직과 다를 때 문제가 발생합니다.

문제 상황 예시: 우리는 v2 버전의 서비스만 트래픽을 받아야 하는데, Sidecar가 기본으로 설정된 헬스 체크 포트(예: 8080/health)가 일시적으로 응답하지 않아, 전체 v2 서비스가 '다운'으로 간주되어 트래픽이 완전히 차단되는 상황입니다.

해결책: DestinationRule을 이용한 정책 오버라이드 이럴 때는 DestinationRule을 사용하여, Sidecar가 기본으로 사용하는 헬스 체크 정책을 우리가 원하는 대로 명시적으로 덮어씌워야 합니다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service-dr
spec:
  host: my-service
  rules:
  - subset: v2 # 특정 버전(Subset)에만 적용
    trafficPolicy:
      healthCircuitBreaker:
        maxConnections: 10
        # 헬스 체크를 기본 포트가 아닌, 비즈니스 로직 포트로 지정하거나
        # 아예 헬스 체크를 건너뛰도록 설정할 수 있습니다.
        failFast: true 

💡 실무 팁: 만약 헬스 체크 자체가 트래픽에 영향을 주지 않도록 하고 싶다면, DestinationRule에서 헬스 체크 관련 설정을 최소화하거나, 애플리케이션 레벨의 헬스 체크 엔드포인트(예: /ready)를 명시적으로 지정하는 것이 좋습니다.

🚀 서비스 디스커버리 지연 및 카나리 배포, VirtualService 심화 활용

서비스가 늘어나고 버전이 분기되면서, "A 서비스가 B 서비스의 특정 API(/api/v2/users)로만 트래픽을 보내야 하는데, 모든 트래픽이 기본 경로로 간다"와 같은 라우팅 오류가 발생합니다.

문제 상황 예시: A 서비스가 B 서비스를 호출할 때, VirtualService가 명확하지 않으면 모든 트래픽이 기본 경로로 쏠리거나, 의도치 않은 경로로 라우팅되어 A/B 테스트가 불가능해집니다.

해결책: VirtualService를 이용한 정밀 라우팅 및 가중치 제어 VirtualService는 "어떤 조건(Host, Path)에서, 어떤 트래픽을, 어디로 보낼지"를 정의하는 핵심 리소스입니다. 특히 가중치(Weight)를 이용한 카나리 배포는 필수입니다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service-vs
spec:
  hosts:
  - my-service
  http:
  - match:
    - uri:
        prefix: /api/users # 오직 /api/users 경로에만 적용
    route:
    - destination:
        host: my-service
        subset: v1 # 90% 트래픽은 안정 버전으로
        weight: 90
    - destination:
        host: my-service
        subset: v2 # 10% 트래픽은 신규 버전으로 (카나리)
        weight: 10

이 코드를 적용하면, my-service로 들어오는 /api/users 요청 중 90%는 v1로, 10%는 v2로만 정확히 분할되어 전송됩니다. 이처럼 VirtualService는 단순한 라우팅을 넘어, **통제된 위험 노출(Controlled Risk Exposure)**을 가능하게 합니다.

🛠️ 디버깅 시나리오별 핵심 명령어 체크리스트

YAML 설정이 아무리 완벽해도, 실제 환경에서는 예상치 못한 문제가 발생합니다. 이럴 때 필요한 것이 체계적인 디버깅 순서입니다.

GitOps 관점의 조언: 이 모든 설정 변경(DR, VS)은 절대 수동으로 kubectl apply 해서는 안 됩니다. 모든 인프라 설정은 Git Repository에 코드로 관리되어야 합니다. GitOps 워크플로우를 통해 변경 이력을 추적하고, 문제가 발생했을 때 이전의 안정적인 커밋으로 롤백하는 것이 서비스 Mesh 운영의 기본 원칙입니다.

✍️ 시니어 엔지니어의 실무 경험 공유

제가 가장 많이 경험하는 실수는, 개발팀이 "서비스가 다운됐다"고 보고할 때, 실제로는 Sidecar 프록시가 먼저 503 에러를 반환하고 있다는 사실을 놓치는 경우입니다. 이 경우, 애플리케이션 코드를 수정하기 전에, 먼저 istioctl proxy-status를 돌려 프록시가 어떤 백엔드에 연결을 시도하고 있는지, 그리고 그 연결 시도 자체가 실패했는지(예: 포트 바인딩 실패)를 확인하는 습관을 들이는 것이 디버깅 시간을 획기적으로 줄여줍니다.

결론: Service Mesh 운영의 핵심은 '관측성'과 '점진적 적용'

Service Mesh는 강력한 도구이지만, 그 강력함만큼 복잡성을 내포하고 있습니다. 이 도구를 마스터한다는 것은 단순히 YAML 문법을 외우는 것이 아니라, **'트래픽이 어디를 거쳐서, 어떤 정책을 거쳐서, 최종 목적지에 도달하는지'**의 흐름을 완벽하게 이해하는 것을 의미합니다.

최종 디버깅 체크리스트:

1. 흐름 파악: 요청이 애플리케이션 $\rightarrow$ Sidecar $\rightarrow$ DestinationRule $\rightarrow$ VirtualService $\rightarrow$ 실제 Pod 순서로 흐르는지 시각화합니다.
2. 정책 검증: DestinationRule로 헬스 체크 및 서브셋 정책을 명시적으로 정의했는지 확인합니다.
3. 라우팅 검증: VirtualService에서 match 조건과 weight를 통해 원하는 트래픽 분배가 정확한지 검증합니다.
4. 관측성 확보: Prometheus/Grafana를 통해 에러율, 레이턴시 지표를 지속적으로 모니터링하며, 이상 징후 발생 시 로그를 즉시 확인합니다.

Service Mesh는 최종 목표가 아닙니다. 안정적이고 예측 가능한 MSA를 구축하기 위한 **'관리 계층(Control Plane)'**일 뿐입니다. 이 점을 기억하며, 항상 작은 범위부터 점진적으로(Canary 방식으로) 적용하고 검증하는 것이 성공적인 운영의 열쇠입니다.

자주 묻는 질문 (FAQ)

Q. Istio를 사용하면 모든 트래픽에 대해 인증(mTLS)이 강제되나요? A. 기본적으로 Istio는 강력한 보안을 위해 mTLS를 권장하며, 기본 설정 시 강제될 수 있습니다. 만약 특정 트래픽에 대해서만 인증을 건너뛰고 싶다면, DestinationRule에서 trafficPolicy를 조정하여 mTLS 적용 범위를 세밀하게 제어해야 합니다.

Q. Linkerd와 Istio 중 어떤 것을 선택해야 할까요? A. 선택은 팀의 숙련도와 요구사항에 따라 다릅니다. Linkerd는 매우 가볍고 설정이 간결하여 빠른 도입에 유리하며, Istio는 기능의 깊이(Policy, 고급 트래픽 제어)가 매우 뛰어나 복잡한 엔터프라이즈 환경에 적합합니다. 초기 도입 시에는 간단한 기능부터 시작하여 점진적으로 확장하는 것이 좋습니다.