Istio 트래픽 관리 완벽 가이드

Istio의 트래픽 관리 기능을 마스터하는 완벽 가이드입니다. VirtualService와 DestinationRule을 활용한 라우팅부터 트래픽 분할, 헤더 기반 라우팅까지 실무에 필요한 모든 내용을 다룹니다.

1. VirtualService 개념

2-3문장으로 상황 설정 어느 날 김개발 씨는 마이크로서비스 환경에서 특정 버전의 서비스로만 트래픽을 보내야 하는 요구사항을 받았습니다. 기존 쿠버네티스 서비스만으로는 이런 세밀한 제어가 불가능했죠.

선배 박시니어 씨가 다가와 말했습니다. "Istio의 VirtualService를 사용해보세요."

핵심 개념을 3-4문장으로 VirtualService는 Istio에서 트래픽 라우팅 규칙을 정의하는 핵심 리소스입니다. 마치 교통 경찰이 차량의 목적지에 따라 어느 길로 갈지 안내하는 것처럼, 들어오는 요청을 어떤 서비스 버전으로 보낼지 결정합니다.

쿠버네티스의 기본 서비스보다 훨씬 더 정교한 라우팅 제어가 가능합니다. HTTP 헤더, URI 경로, 메서드 등 다양한 조건으로 트래픽을 제어할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-vs
spec:
  hosts:
  - reviews.default.svc.cluster.local
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v2
  - route:
    - destination:
        host: reviews.default.svc.cluster.local
        subset: v1

이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 마이크로서비스 아키텍처로 전환하면서 서비스 메시 도구인 Istio를 도입하기로 했습니다.

오늘 김개발 씨가 받은 첫 번째 과제는 특정 사용자에게만 새 버전의 리뷰 서비스를 보여주는 것이었습니다. "이걸 어떻게 구현하지?" 김개발 씨는 고민에 빠졌습니다.

쿠버네티스의 기본 서비스로는 단순히 파드들 사이에 부하를 분산할 수만 있었기 때문입니다. 사용자별로 다른 버전을 보여주려면 애플리케이션 코드를 수정해야 할 것 같았습니다.

바로 그때 선배 박시니어 씨가 다가왔습니다. "VirtualService를 사용하면 코드 수정 없이 가능해요." 그렇다면 VirtualService란 정확히 무엇일까요?

쉽게 비유하자면, VirtualService는 마치 호텔 컨시어지와 같습니다. 손님(요청)이 들어오면 컨시어지는 손님의 신분, 목적, 요구사항을 확인하고 적절한 층의 적절한 방(서비스 버전)으로 안내합니다.

일반 손님은 스탠다드 룸으로, VIP 손님은 스위트룸으로 안내하는 것처럼 말이죠. 이처럼 VirtualService도 들어오는 트래픽의 특성을 파악하고 적절한 목적지로 라우팅하는 역할을 담당합니다.

VirtualService가 없던 시절에는 어땠을까요? 개발자들은 애플리케이션 코드 내부에서 직접 라우팅 로직을 구현해야 했습니다.

"이 사용자는 베타 테스터니까 v2로 보내고, 일반 사용자는 v1로 보내고..." 이런 로직이 모든 서비스에 중복으로 들어가게 되었죠. 코드가 복잡해지고, 라우팅 규칙을 변경하려면 매번 재배포해야 했습니다.

더 큰 문제는 네트워크 레벨의 문제를 애플리케이션 레벨에서 처리하다 보니 관심사가 섞이고 유지보수가 어려워진다는 점이었습니다. 바로 이런 문제를 해결하기 위해 VirtualService가 등장했습니다.

VirtualService를 사용하면 애플리케이션 코드 수정 없이 트래픽 라우팅을 제어할 수 있습니다. 또한 배포 없이 설정 파일만 변경하면 즉시 라우팅 규칙이 적용됩니다.

무엇보다 네트워크 관심사를 인프라 레벨에서 처리하므로 코드가 깔끔해진다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 hosts 필드를 보면 이 VirtualService가 어떤 서비스에 대한 트래픽을 제어할지 정의합니다. 여기서는 reviews 서비스가 대상입니다.

http 섹션에서는 HTTP 트래픽에 대한 라우팅 규칙을 정의합니다. 첫 번째 match 조건은 "end-user 헤더가 jason인 요청"을 의미하며, 이런 요청은 v2 서브셋으로 라우팅됩니다.

두 번째 route는 매치 조건이 없으므로 나머지 모든 트래픽이 v1 서브셋으로 라우팅됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 서비스를 개발한다고 가정해봅시다. 새로운 결제 시스템을 도입하는데 바로 전체 사용자에게 적용하기는 위험합니다.

VirtualService를 활용하면 내부 직원들에게만 먼저 새 버전을 노출하고, 문제가 없으면 점진적으로 확대할 수 있습니다. 넷플릭스, 우버 같은 많은 기업에서 이런 패턴을 적극적으로 사용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 VirtualService만 정의하고 DestinationRule을 정의하지 않는 것입니다.

VirtualService에서 "v1", "v2" 같은 서브셋을 참조하려면 반드시 DestinationRule에서 이 서브셋들을 정의해야 합니다. 그렇지 않으면 트래픽이 라우팅되지 않는 문제가 발생합니다.

따라서 VirtualService와 DestinationRule은 항상 쌍으로 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 애플리케이션 코드를 건드리지 않고도 라우팅을 제어할 수 있군요!" VirtualService를 제대로 이해하면 카나리 배포, A/B 테스팅, 블루-그린 배포 같은 고급 배포 전략을 손쉽게 구현할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 실전 팁 2-3개

VirtualService와 DestinationRule은 항상 쌍으로 정의해야 합니다.
match 조건은 위에서 아래로 순차적으로 평가되므로 더 구체적인 조건을 위에 배치하세요.
hosts 필드에는 정규화된 도메인 이름(FQDN)을 사용하는 것이 안전합니다.

2. 라우팅 규칙 정의

2-3문장으로 상황 설정 김개발 씨는 VirtualService를 성공적으로 적용한 후, 이번에는 더 복잡한 요구사항을 받았습니다. "/api/v1" 경로로 오는 요청은 구 버전으로, "/api/v2" 경로는 신 버전으로 라우팅해야 한다는 것이었죠.

박시니어 씨가 말했습니다. "라우팅 규칙을 더 정교하게 정의할 수 있어요."

핵심 개념을 3-4문장으로 라우팅 규칙은 VirtualService에서 트래픽을 어떻게 분배할지 결정하는 세부 조건입니다. URI 경로, HTTP 메서드, 헤더, 쿼리 파라미터 등 다양한 기준으로 매칭할 수 있습니다.

마치 우체국에서 우편물을 주소, 크기, 중요도에 따라 분류하는 것처럼 세밀한 제어가 가능합니다. 여러 조건을 조합하여 매우 복잡한 라우팅 시나리오도 구현할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: productpage-vs
spec:
  hosts:
  - productpage
  http:
  - match:
    - uri:
        prefix: "/api/v2"
    - method:
        exact: "POST"
    route:
    - destination:
        host: productpage
        subset: v2
  - match:
    - uri:
        prefix: "/api/v1"
    route:
    - destination:
        host: productpage
        subset: v1

이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 회사는 API 버전 관리 정책을 도입하기로 했습니다. 기존 고객들은 계속 v1 API를 사용하고, 신규 고객들은 개선된 v2 API를 사용하도록 분리하는 것이었습니다.

문제는 두 버전의 API가 같은 서비스 이름을 사용한다는 점이었습니다. "경로 기반으로 라우팅할 수 있을까요?" 김개발 씨가 물었습니다.

박시니어 씨가 웃으며 대답했습니다. "당연하죠.

Istio의 라우팅 규칙은 생각보다 훨씬 강력해요." 그렇다면 라우팅 규칙을 어떻게 정의할까요? 쉽게 비유하자면, 라우팅 규칙은 마치 공항의 탑승객 분류 시스템과 같습니다.

비즈니스 클래스 승객, 이코노미 승객, 마일리지 등급, 목적지 등 여러 기준으로 승객을 분류해서 각각 다른 게이트로 안내하죠. 라우팅 규칙도 이처럼 요청의 여러 속성을 검사해서 적절한 서비스 버전으로 안내합니다.

라우팅 규칙이 없던 시절에는 어땠을까요? 개발자들은 각 서비스마다 별도의 쿠버네티스 서비스를 만들고, 서로 다른 이름을 부여해야 했습니다.

productpage-v1, productpage-v2 같은 식으로 말이죠. 클라이언트 코드에서는 어떤 버전을 호출할지 직접 결정해야 했고, 이는 코드 전반에 버전 관리 로직이 흩어지는 결과를 낳았습니다.

API 버전을 추가하거나 변경할 때마다 모든 클라이언트 코드를 수정해야 했습니다. 바로 이런 문제를 해결하기 위해 정교한 라우팅 규칙이 필요했습니다.

라우팅 규칙을 사용하면 같은 서비스 이름으로 여러 버전을 관리할 수 있습니다. 또한 클라이언트는 버전을 신경 쓰지 않고 단순히 요청만 보내면 됩니다.

무엇보다 라우팅 정책을 중앙에서 관리하므로 일관성 있는 트래픽 제어가 가능하다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

첫 번째 match 블록을 보면 두 가지 조건이 있습니다. URI가 "/api/v2"로 시작하고, HTTP 메서드가 POST인 요청입니다.

이런 요청은 v2 서브셋으로 라우팅됩니다. 두 번째 match 블록은 URI가 "/api/v1"로 시작하는 요청을 v1 서브셋으로 라우팅합니다.

prefix 매칭을 사용했으므로 "/api/v1/products", "/api/v1/users" 같은 하위 경로도 모두 매칭됩니다. match 조건에는 여러 가지 매칭 방법이 있습니다.

exact는 정확히 일치하는 경우, prefix는 접두사가 일치하는 경우, regex는 정규표현식으로 매칭하는 경우입니다. 상황에 맞게 적절한 방법을 선택해야 합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 모바일 앱과 웹 클라이언트가 같은 API를 사용하는 서비스가 있다고 가정해봅시다.

웹은 이미 v2 API를 사용 중인데, 모바일 앱은 아직 v1을 사용합니다. User-Agent 헤더를 기반으로 라우팅 규칙을 정의하면, 모바일 요청은 v1으로, 웹 요청은 v2로 자동으로 분기할 수 있습니다.

앱 업데이트 없이도 점진적으로 마이그레이션이 가능하죠. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 match 조건의 순서를 고려하지 않는 것입니다. Istio는 위에서 아래로 순차적으로 조건을 평가하고, 첫 번째로 매칭되는 규칙을 적용합니다.

만약 더 일반적인 조건을 위에 두면 구체적인 조건이 절대 실행되지 않습니다. 따라서 가장 구체적인 조건을 위에, 일반적인 조건을 아래에 배치해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 라우팅 규칙을 적용한 김개발 씨는 테스트를 진행했습니다.

"/api/v1/products"로 요청하니 v1이 응답했고, "/api/v2/products"로 요청하니 v2가 응답했습니다. "완벽하네요!" 라우팅 규칙을 제대로 이해하면 복잡한 트래픽 관리 시나리오도 코드 수정 없이 해결할 수 있습니다.

여러분도 다양한 match 조건을 조합해서 실험해 보세요.

실전 팁

💡 실전 팁 2-3개

match 조건은 구체적인 것부터 일반적인 순서로 배치하세요.
prefix 매칭은 하위 경로도 모두 포함하므로 주의가 필요합니다.
복잡한 조건은 regex보다 여러 개의 간단한 조건으로 나누는 것이 가독성에 좋습니다.

3. DestinationRule 설정

2-3문장으로 상황 설정 김개발 씨는 VirtualService에서 "subset: v1", "subset: v2"를 사용했지만, 아직 이 서브셋이 무엇을 의미하는지 정의하지 않았습니다. 트래픽을 테스트하려는데 에러가 발생했죠.

박시니어 씨가 말했습니다. "DestinationRule을 정의해야 해요."

핵심 개념을 3-4문장으로 DestinationRule은 트래픽이 목적지에 도착한 후 어떻게 처리될지 정의하는 리소스입니다. 서브셋을 정의하고, 로드 밸런싱 정책을 설정하며, 연결 풀 관리 등을 담당합니다.

마치 호텔에서 객실 등급을 정의하고 각 등급별 서비스 정책을 수립하는 것과 같습니다. VirtualService가 "어디로 보낼지" 결정한다면, DestinationRule은 "도착 후 어떻게 처리할지"를 결정합니다.

다음 코드를 살펴봅시다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: LEAST_REQUEST

이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨는 VirtualService를 완벽하게 작성했다고 생각했습니다. 하지만 막상 실행해보니 이상한 에러가 발생했습니다.

"host has no subset v1"이라는 메시지가 나타났죠. 코드를 여러 번 확인했지만 문제를 찾을 수 없었습니다.

박시니어 씨가 화면을 보더니 바로 원인을 파악했습니다. "아, DestinationRule을 안 만드셨군요.

VirtualService만으로는 부족해요." 그렇다면 DestinationRule은 정확히 무엇일까요? 쉽게 비유하자면, DestinationRule은 마치 레스토랑의 좌석 배치 정책과 같습니다.

VirtualService가 손님을 레스토랑으로 안내했다면, DestinationRule은 "흡연석/금연석", "창가/복도" 같은 좌석 구역을 정의하고, 각 구역마다 서비스 방식을 결정합니다. 어떤 구역은 빠른 회전율을 위해 테이블을 많이 배치하고, 어떤 구역은 VIP를 위해 널찍하게 배치하는 것처럼 말이죠.

DestinationRule이 없던 시절에는 어떻게 했을까요? 쿠버네티스의 기본 서비스는 모든 파드를 동일하게 취급했습니다.

라벨로 파드를 선택할 수는 있었지만, 같은 서비스 내에서 서로 다른 버전을 구분할 방법이 없었습니다. v1 파드와 v2 파드를 분리하려면 아예 별도의 서비스를 만들어야 했죠.

그러다 보니 서비스 개수가 기하급수적으로 늘어나고, 관리가 복잡해졌습니다. 바로 이런 문제를 해결하기 위해 DestinationRule이 등장했습니다.

DestinationRule을 사용하면 하나의 서비스 내에서 여러 서브셋을 논리적으로 분리할 수 있습니다. 또한 각 서브셋마다 다른 트래픽 정책을 적용할 수 있습니다.

무엇보다 로드 밸런싱, 연결 풀, 아웃라이어 감지 같은 고급 기능을 세밀하게 제어할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 host 필드는 이 DestinationRule이 적용될 서비스를 지정합니다. 전역 trafficPolicy는 모든 서브셋에 기본적으로 적용되는 정책입니다.

여기서는 라운드 로빈 방식의 로드 밸런싱을 사용합니다. subsets 섹션에서 v1과 v2 서브셋을 정의합니다.

각 서브셋은 labels로 어떤 파드를 선택할지 결정합니다. v1 서브셋은 최대 100개의 TCP 연결만 허용하고, v2 서브셋은 최소 요청 개수 기준으로 로드 밸런싱합니다.

서브셋별로 다른 정책을 적용할 수 있다는 점이 매우 강력합니다. 예를 들어 구 버전은 보수적으로 연결 수를 제한하고, 신 버전은 공격적으로 성능을 최적화할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 AI 추천 서비스를 운영한다고 가정해봅시다.

GPU 서버에서 실행되는 v2는 성능이 좋지만 비용이 높고, CPU 서버의 v1은 저렴하지만 느립니다. DestinationRule에서 v2는 LEAST_REQUEST 정책으로 부하를 고르게 분산하고, v1은 단순 라운드 로빈을 사용할 수 있습니다.

또한 v2의 연결 풀을 크게 설정해서 GPU 리소스를 최대한 활용할 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 서브셋의 labels와 실제 파드의 labels가 일치하지 않는 것입니다. DestinationRule에서 "version: v1"을 선택하도록 했는데, 실제 파드에는 "app: reviews" 라벨만 있다면 서브셋이 아무 파드도 선택하지 못합니다.

따라서 파드의 라벨을 먼저 확인하고, 정확히 일치하는 라벨 선택자를 작성해야 합니다. 또 다른 실수는 전역 정책과 서브셋 정책의 우선순위를 이해하지 못하는 것입니다.

서브셋에 정의된 정책이 전역 정책을 오버라이드합니다. 만약 의도치 않게 서브셋 정책이 전역 정책을 덮어쓴다면 예상과 다른 동작이 발생할 수 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. DestinationRule을 추가한 김개발 씨는 다시 테스트를 진행했습니다.

이번에는 에러 없이 정상적으로 동작했습니다. "이제 VirtualService와 DestinationRule이 어떻게 함께 작동하는지 알겠어요!" DestinationRule을 제대로 이해하면 서비스 메시의 진정한 힘을 활용할 수 있습니다.

여러분도 다양한 트래픽 정책을 실험해 보세요.

실전 팁

💡 실전 팁 2-3개

VirtualService와 DestinationRule은 항상 쌍으로 정의해야 합니다.
서브셋의 라벨 선택자는 실제 파드의 라벨과 정확히 일치해야 합니다.
서브셋 정책이 전역 정책을 오버라이드한다는 점을 기억하세요.

4. 트래픽 분할

2-3문장으로 상황 설정 김개발 씨는 이번에 카나리 배포를 구현해야 했습니다. 새 버전을 전체 사용자에게 바로 배포하는 것은 위험하니, 10%의 트래픽만 새 버전으로 보내고 싶었죠.

박시니어 씨가 말했습니다. "트래픽 분할 기능을 사용하면 됩니다."

핵심 개념을 3-4문장으로 트래픽 분할은 들어오는 트래픽을 여러 버전에 비율대로 나누어 분배하는 기능입니다. 마치 강물을 여러 수로로 나누어 각각 원하는 비율로 흐르게 하는 것과 같습니다.

카나리 배포, A/B 테스팅 같은 고급 배포 전략의 핵심입니다. 비율은 자유롭게 조정할 수 있으며, 문제가 발생하면 즉시 100% 롤백도 가능합니다.

다음 코드를 살펴봅시다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-canary
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 팀은 새로운 추천 알고리즘을 개발했습니다. 시뮬레이션에서는 완벽했지만, 실제 운영 환경에서 어떻게 동작할지는 알 수 없었습니다.

전체 사용자에게 한 번에 배포했다가 문제가 생기면 대참사가 될 것입니다. "일단 소수의 사용자에게만 적용해볼 수 없을까요?" 김개발 씨가 물었습니다.

박시니어 씨가 웃으며 대답했습니다. "그게 바로 카나리 배포죠.

Istio로 아주 쉽게 구현할 수 있어요." 그렇다면 트래픽 분할은 어떻게 작동할까요? 쉽게 비유하자면, 트래픽 분할은 마치 샘플링 조사와 같습니다.

신제품을 출시하기 전에 전체 시장에 바로 내놓지 않고, 먼저 일부 지역에서 테스트 마케팅을 하는 것이죠. 반응이 좋으면 점차 확대하고, 문제가 있으면 즉시 철수합니다.

트래픽 분할도 이처럼 위험을 최소화하면서 새로운 변경사항을 안전하게 검증할 수 있게 해줍니다. 트래픽 분할이 없던 시절에는 어땠을까요?

개발자들은 블루-그린 배포를 주로 사용했습니다. 완전히 새로운 환경을 구축하고, 한 번에 모든 트래픽을 전환하는 방식이었죠.

문제는 새 버전에 버그가 있으면 전체 서비스가 장애를 겪는다는 점이었습니다. 또한 인프라 비용도 두 배로 들었습니다.

점진적으로 배포할 방법이 없었기 때문에 항상 큰 위험을 감수해야 했습니다. 바로 이런 문제를 해결하기 위해 트래픽 분할이 필요했습니다.

트래픽 분할을 사용하면 위험을 최소화하면서 새 버전을 검증할 수 있습니다. 또한 추가 인프라 없이 기존 환경에서 비율만 조정하면 됩니다.

무엇보다 실시간으로 모니터링하면서 비율을 동적으로 조정할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

첫 번째 match 블록은 특별한 경우입니다. "x-canary: true" 헤더가 있는 요청은 무조건 v2로 라우팅됩니다.

이는 내부 테스터나 개발자가 강제로 새 버전을 테스트할 수 있게 하는 장치입니다. weight: 100은 이 조건에 매칭되면 100% v2로 간다는 의미입니다.

두 번째 블록이 핵심입니다. 일반 트래픽의 90%는 v1으로, 10%는 v2로 분할됩니다.

weight 값의 합은 100이어야 합니다. 이 비율은 언제든 변경할 수 있습니다.

처음에는 v2에 5%만 보내다가, 안정적이면 점차 20%, 50%, 100%로 늘려갈 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 결제 시스템을 개선하는 프로젝트가 있다고 가정해봅시다. 새 결제 로직은 더 빠르고 안전하지만, 실제 환경에서 검증되지 않았습니다.

먼저 1%의 트래픽만 새 버전으로 보내고, 에러율과 응답 시간을 모니터링합니다. 문제가 없으면 5%, 10%, 25%로 점진적으로 확대합니다.

만약 에러가 증가하면 즉시 0%로 되돌립니다. 이런 방식으로 페이팔, 아마존 같은 기업들이 안전하게 배포합니다.

트래픽 분할은 A/B 테스팅에도 활용됩니다. UI 디자인 두 가지를 테스트한다면, 50:50으로 트래픽을 분할하고 어느 쪽의 전환율이 높은지 측정할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 weight 값의 합이 100이 아니게 설정하는 것입니다.

Istio는 자동으로 정규화하기는 하지만, 명시적으로 100이 되도록 하는 것이 가독성에 좋습니다. 또한 너무 작은 비율(1% 미만)로 시작하면 통계적으로 유의미한 데이터를 얻기 어렵습니다.

최소 5-10%는 되어야 의미 있는 모니터링이 가능합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

트래픽 분할을 적용한 김개발 씨는 먼저 10%로 시작했습니다. 일주일간 모니터링한 결과 에러율이 오히려 낮아졌습니다.

자신감을 얻은 팀은 비율을 50%로 늘렸고, 최종적으로 100% 전환에 성공했습니다. "안전하게 배포할 수 있어서 정말 좋네요!" 트래픽 분할을 제대로 이해하면 두려움 없이 새로운 기능을 배포할 수 있습니다.

여러분도 점진적 배포 전략을 실제로 적용해 보세요.

실전 팁

💡 실전 팁 2-3개

weight 값의 합은 항상 100이 되도록 설정하세요.
카나리 배포는 5-10%부터 시작하고 점진적으로 확대하세요.
내부 테스터용 강제 라우팅 규칙을 별도로 추가하면 편리합니다.

5. 헤더 기반 라우팅

2-3문장으로 상황 설정 김개발 씨는 이번에 모바일 앱과 웹 클라이언트가 서로 다른 API 버전을 사용하도록 구현해야 했습니다. User-Agent 헤더를 확인해서 분기하면 될 것 같았는데, 애플리케이션 코드를 수정하고 싶지 않았죠.

박시니어 씨가 말했습니다. "헤더 기반 라우팅을 사용하세요."

핵심 개념을 3-4문장으로 헤더 기반 라우팅은 HTTP 헤더의 값을 기준으로 트래픽을 라우팅하는 기술입니다. User-Agent, Authorization, 커스텀 헤더 등 어떤 헤더든 조건으로 사용할 수 있습니다.

마치 클럽 입구에서 회원증을 확인하고 VIP는 특별실로, 일반 회원은 메인홀로 안내하는 것과 같습니다. 클라이언트 타입, 사용자 권한, 지역 등 다양한 기준으로 라우팅을 제어할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-header-routing
spec:
  hosts:
  - api.example.com
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Mobile.*"
    route:
    - destination:
        host: api-service
        subset: mobile-optimized
  - match:
    - headers:
        x-user-type:
          exact: "premium"
    route:
    - destination:
        host: api-service
        subset: premium-tier
  - route:
    - destination:
        host: api-service
        subset: standard

이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 회사는 모바일 앱을 새로 출시했습니다. 문제는 모바일 환경에서는 데이터를 최소화해야 하므로 응답 구조가 웹과 달라야 한다는 점이었습니다.

두 개의 완전히 다른 API를 만들까 고민했지만, 중복 코드가 너무 많아질 것 같았습니다. "클라이언트 타입에 따라 다른 서비스 버전으로 라우팅할 수 있을까요?" 김개발 씨가 물었습니다.

박시니어 씨가 고개를 끄덕였습니다. "당연하죠.

헤더를 보고 판단하면 됩니다." 그렇다면 헤더 기반 라우팅은 어떻게 작동할까요? 쉽게 비유하자면, 헤더 기반 라우팅은 마치 공항의 탑승 게이트 안내와 같습니다.

항공권(헤더)을 확인해서 비즈니스 승객은 라운지로, 이코노미 승객은 대기실로, 환승 승객은 환승 구역으로 안내합니다. 각 승객 유형마다 다른 서비스와 경로를 제공하는 것이죠.

HTTP 헤더도 이처럼 요청자의 신원, 특성, 선호도를 담고 있어서 이를 기반으로 최적의 경로를 찾아줄 수 있습니다. 헤더 기반 라우팅이 없던 시절에는 어땠을까요?

애플리케이션 코드 내부에서 헤더를 파싱하고 조건문으로 분기를 처리해야 했습니다. "if user-agent contains Mobile then ...

else ..." 같은 로직이 컨트롤러마다 반복되었죠. 새로운 클라이언트 타입이 추가되면 모든 엔드포인트를 수정해야 했습니다.

더 큰 문제는 라우팅 로직이 비즈니스 로직과 섞여서 코드가 복잡해진다는 점이었습니다. 바로 이런 문제를 해결하기 위해 헤더 기반 라우팅이 필요했습니다.

헤더 기반 라우팅을 사용하면 애플리케이션 코드 수정 없이 인프라 레벨에서 라우팅을 제어할 수 있습니다. 또한 새로운 클라이언트 타입 추가가 매우 간단합니다.

무엇보다 관심사의 분리가 명확해져서 코드 품질이 향상된다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

첫 번째 match 블록은 User-Agent 헤더를 정규표현식으로 검사합니다. "Mobile"이라는 단어가 포함되어 있으면 mobile-optimized 서브셋으로 라우팅됩니다.

regex 매칭을 사용하면 복잡한 패턴도 처리할 수 있습니다. 두 번째 match 블록은 커스텀 헤더인 "x-user-type"을 확인합니다.

프리미엄 사용자는 더 강력한 서버로 라우팅되어 빠른 응답을 받을 수 있습니다. exact 매칭은 정확히 일치하는 경우에만 적용됩니다.

마지막 블록은 기본 라우팅입니다. 어떤 조건도 만족하지 않으면 standard 서브셋으로 라우팅됩니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 SaaS 서비스를 운영하는데 프리티어, 스탠다드, 엔터프라이즈 세 가지 플랜이 있다고 가정해봅시다.

API 게이트웨이에서 사용자의 플랜 정보를 조회해서 커스텀 헤더 "x-plan"을 추가합니다. Istio는 이 헤더를 보고 엔터프라이즈 사용자는 전용 고성능 서버로, 프리티어는 공유 서버로 라우팅합니다.

이렇게 하면 공정한 리소스 분배와 QoS 보장이 가능합니다. 또 다른 사례는 지역 기반 라우팅입니다.

CloudFront 같은 CDN은 "CloudFront-Viewer-Country" 헤더를 추가합니다. 한국 사용자는 서울 리전의 서버로, 미국 사용자는 버지니아 리전의 서버로 라우팅하여 지연 시간을 최소화할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 헤더 이름의 대소문자를 잘못 쓰는 것입니다.

HTTP 헤더는 대소문자를 구분하지 않지만, Istio 설정에서는 소문자로 정규화되어 비교됩니다. "User-Agent"와 "user-agent"는 같은 헤더이지만, 설정에서는 "user-agent"로 작성해야 안전합니다.

또 다른 실수는 클라이언트가 헤더를 제대로 보내지 않는 경우를 고려하지 않는 것입니다. 항상 기본 라우팅 규칙을 마지막에 추가해서 예외 상황을 처리해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 헤더 기반 라우팅을 적용한 김개발 씨는 모바일 앱에서 API를 호출해봤습니다.

모바일에 최적화된 간결한 응답이 돌아왔습니다. 웹에서 호출하니 상세한 정보가 포함된 응답이 왔습니다.

"코드 수정 없이 클라이언트별로 다른 처리가 가능하네요!" 헤더 기반 라우팅을 제대로 이해하면 매우 유연한 멀티 테넌시 시스템을 구축할 수 있습니다. 여러분도 다양한 헤더를 활용해서 실험해 보세요.

실전 팁

💡 실전 팁 2-3개

헤더 이름은 소문자로 작성하는 것이 안전합니다.
항상 기본 라우팅 규칙을 마지막에 추가하세요.
커스텀 헤더는 "x-" 접두사를 사용하는 것이 관례입니다.

6. 타임아웃과 재시도

2-3문장으로 상황 설정 김개발 씨의 서비스는 종종 외부 API 호출 때문에 느려졌습니다. 외부 API가 응답하지 않으면 30초 동안 기다렸다가 타임아웃되는데, 사용자 경험이 너무 나빴죠.

박시니어 씨가 말했습니다. "타임아웃과 재시도 정책을 설정해보세요."

핵심 개념을 3-4문장으로 타임아웃은 요청이 일정 시간 내에 응답하지 않으면 실패 처리하는 기능입니다. 재시도는 실패한 요청을 자동으로 다시 시도하는 기능입니다.

마치 전화를 걸었는데 받지 않으면 일정 시간 후 끊고, 몇 번 더 걸어보는 것과 같습니다. 이 두 기능을 적절히 조합하면 일시적인 네트워크 장애를 극복하고 안정적인 서비스를 제공할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: payment-service-vs
spec:
  hosts:
  - payment-service
  http:
  - route:
    - destination:
        host: payment-service
    timeout: 3s
    retries:
      attempts: 3
      perTryTimeout: 1s
      retryOn: 5xx,reset,connect-failure,refused-stream
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-service-dr
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s

이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 결제 서비스는 외부 PG사 API를 호출합니다. 대부분의 경우 1초 이내에 응답이 오지만, 가끔 PG사 서버 상태가 불안정하면 10초 이상 걸리거나 아예 응답이 없었습니다.

사용자는 결제 버튼을 누르고 한참을 기다려야 했고, 결국 "죽었나?" 싶어서 새로고침을 누릅니다. 이는 중복 결제로 이어지기도 했습니다.

"요청이 너무 오래 걸리면 빨리 포기하고, 실패하면 자동으로 재시도할 수 없을까요?" 김개발 씨가 물었습니다. 박시니어 씨가 웃으며 대답했습니다.

"그게 바로 타임아웃과 재시도 정책입니다." 그렇다면 타임아웃과 재시도는 어떻게 작동할까요? 쉽게 비유하자면, 타임아웃과 재시도는 마치 택배 배송 정책과 같습니다.

배송 기사가 집에 갔는데 아무도 없으면 무한정 기다리지 않습니다. 10분만 기다리고(타임아웃), 부재중 메모를 남기고 돌아갑니다.

그리고 당일 저녁에 다시 방문을 시도하고(재시도), 그래도 안 되면 택배 센터로 반송합니다. 이처럼 적절한 포기 시점과 재시도 전략을 세우는 것이 중요합니다.

타임아웃과 재시도가 없던 시절에는 어땠을까요? 애플리케이션 코드에서 직접 타임아웃을 설정하고, try-catch 블록으로 재시도 로직을 구현해야 했습니다.

문제는 이런 로직이 모든 외부 API 호출 부분에 중복되어 나타났다는 점입니다. 개발자마다 타임아웃 시간을 다르게 설정하고, 재시도 횟수도 제각각이었습니다.

일관성 없는 에러 처리는 디버깅을 어렵게 만들었습니다. 바로 이런 문제를 해결하기 위해 인프라 레벨의 타임아웃과 재시도가 필요했습니다.

타임아웃과 재시도를 Istio에서 관리하면 애플리케이션 코드가 깔끔해집니다. 또한 모든 서비스에 일관된 정책을 적용할 수 있습니다.

무엇보다 코드 수정 없이 설정만 변경하면 즉시 적용된다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

VirtualService의 timeout 필드는 전체 요청의 최대 허용 시간입니다. 여기서는 3초로 설정했습니다.

3초 안에 응답이 오지 않으면 즉시 실패합니다. retries 섹션이 핵심입니다.

attempts: 3은 최대 3번까지 재시도한다는 의미입니다. 원래 요청을 포함하면 총 4번의 시도가 일어납니다.

perTryTimeout: 1s는 각 시도마다 1초씩만 기다린다는 뜻입니다. 전체 타임아웃 3초 안에 세 번의 1초 재시도가 일어날 수 있습니다.

retryOn 필드는 어떤 경우에 재시도할지 정의합니다. "5xx"는 서버 에러, "reset"은 연결 리셋, "connect-failure"는 연결 실패, "refused-stream"은 스트림 거부 등입니다.

4xx 클라이언트 에러는 재시도해도 소용없으므로 포함하지 않습니다. DestinationRule의 outlierDetection은 문제 있는 인스턴스를 자동으로 제외하는 기능입니다.

30초 동안 5번 연속 에러가 발생하면 해당 파드를 30초간 로드 밸런싱 풀에서 제외합니다. 이를 "서킷 브레이커" 패턴이라고 합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 추천 서비스를 개발하는데, 외부 ML 모델 API를 호출한다고 가정해봅시다.

ML 모델은 가끔 과부하 상태가 됩니다. 타임아웃을 2초로 설정하고, 재시도를 3번으로 설정합니다.

첫 번째 시도가 실패하면 다른 파드로 자동 재시도합니다. 여러 파드 중 하나라도 정상이면 성공할 가능성이 높아집니다.

Outlier detection으로 문제 있는 파드는 자동으로 격리되어 전체 성공률이 향상됩니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 재시도를 무조건 많이 설정하는 것입니다. 재시도가 많으면 일시적 장애를 극복할 가능성은 높아지지만, 시스템에 부하를 가중시킵니다.

만약 모든 클라이언트가 실패할 때마다 3번씩 재시도하면 서버는 3배의 트래픽을 받게 됩니다. 장애 상황에서는 오히려 재시도가 시스템을 더 악화시킬 수 있습니다.

또 다른 실수는 멱등하지 않은 작업에 재시도를 적용하는 것입니다. 결제 API처럼 여러 번 호출하면 중복 처리되는 작업은 재시도하면 안 됩니다.

이런 경우 애플리케이션 레벨에서 멱등성 키를 사용하거나, GET 요청만 재시도하도록 제한해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

타임아웃과 재시도 정책을 적용한 김개발 씨는 모니터링 대시보드를 확인했습니다. 평균 응답 시간이 크게 줄어들었고, 일시적인 네트워크 블립으로 인한 에러가 대부분 재시도로 해결되었습니다.

"사용자는 장애를 느끼지도 못했겠네요!" 타임아웃과 재시도를 제대로 이해하면 훨씬 더 탄력적이고 안정적인 시스템을 구축할 수 있습니다. 여러분도 실제 서비스에 적용해서 효과를 체험해 보세요.

실전 팁

💡 실전 팁 2-3개

재시도는 2-3번 정도가 적당하며, 너무 많으면 시스템에 부담을 줍니다.
멱등하지 않은 작업(POST, 결제 등)에는 재시도를 신중하게 적용하세요.
outlierDetection으로 문제 있는 인스턴스를 자동으로 격리하면 전체 안정성이 향상됩니다.

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Istio#VirtualService#DestinationRule#TrafficManagement#ServiceMesh#Kubernetes

Istio 트래픽 관리 완벽 가이드

# Istio 트래픽 관리 완벽 가이드 Istio의 트래픽 관리 기능을 마스터하는 완벽 가이드입니다. VirtualService와 DestinationRule을 활용한 라우팅부터 트래픽 분할, 헤더 기반 라우팅까지 실무에 필요한 모든 내용을 다룹니다. --- ## 목차 1. [VirtualService 개념](#virtualservice-개념) 2. [라우팅 규칙 정의](#라우팅-규칙-정의) 3. [DestinationRule 설정](#destinationrule-설정) 4. [트래픽 분할](#트래픽-분할) 5. [헤더 기반 라우팅](#헤더-기반-라우팅) 6. [타임아웃과 재시도](#타임아웃과-재시도) --- ## 1. VirtualService 개념 2-3문장으로 상황 설정 어느 날 김개발 씨는 마이크로서비스 환경에서 특정 버전의 서비스로만 트래픽을 보내야 하는 요구사항을 받았습니다. 기존 쿠버네티스 서비스만으로는 이런 세밀한 제어가 불가능했죠. 선배 박시니어 씨가 다가와 말했습니다. "Istio의 VirtualService를 사용해보세요." 핵심 개념을 3-4문장으로 **VirtualService**는 Istio에서 트래픽 라우팅 규칙을 정의하는 핵심 리소스입니다. 마치 교통 경찰이 차량의 목적지에 따라 어느 길로 갈지 안내하는 것처럼, 들어오는 요청을 어떤 서비스 버전으로 보낼지 결정합니다. 쿠버네티스의 기본 서비스보다 훨씬 더 정교한 라우팅 제어가 가능합니다. HTTP 헤더, URI 경로, 메서드 등 다양한 조건으로 트래픽을 제어할 수 있습니다. 다음 코드를 살펴봅시다. ```yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: reviews-vs spec: hosts: - reviews.default.svc.cluster.local http: - match: - headers: end-user: exact: jason route: - destination: host: reviews.default.svc.cluster.local subset: v2 - route: - destination: host: reviews.default.svc.cluster.local subset: v1 ``` 이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 마이크로서비스 아키텍처로 전환하면서 서비스 메시 도구인 Istio를 도입하기로 했습니다. 오늘 김개발 씨가 받은 첫 번째 과제는 특정 사용자에게만 새 버전의 리뷰 서비스를 보여주는 것이었습니다. "이걸 어떻게 구현하지?" 김개발 씨는 고민에 빠졌습니다. 쿠버네티스의 기본 서비스로는 단순히 파드들 사이에 부하를 분산할 수만 있었기 때문입니다. 사용자별로 다른 버전을 보여주려면 애플리케이션 코드를 수정해야 할 것 같았습니다. 바로 그때 선배 박시니어 씨가 다가왔습니다. "VirtualService를 사용하면 코드 수정 없이 가능해요." 그렇다면 **VirtualService**란 정확히 무엇일까요? 쉽게 비유하자면, VirtualService는 마치 호텔 컨시어지와 같습니다. 손님(요청)이 들어오면 컨시어지는 손님의 신분, 목적, 요구사항을 확인하고 적절한 층의 적절한 방(서비스 버전)으로 안내합니다. 일반 손님은 스탠다드 룸으로, VIP 손님은 스위트룸으로 안내하는 것처럼 말이죠. 이처럼 VirtualService도 들어오는 트래픽의 특성을 파악하고 적절한 목적지로 라우팅하는 역할을 담당합니다. VirtualService가 없던 시절에는 어땠을까요? 개발자들은 애플리케이션 코드 내부에서 직접 라우팅 로직을 구현해야 했습니다. "이 사용자는 베타 테스터니까 v2로 보내고, 일반 사용자는 v1로 보내고..." 이런 로직이 모든 서비스에 중복으로 들어가게 되었죠. 코드가 복잡해지고, 라우팅 규칙을 변경하려면 매번 재배포해야 했습니다. 더 큰 문제는 네트워크 레벨의 문제를 애플리케이션 레벨에서 처리하다 보니 관심사가 섞이고 유지보수가 어려워진다는 점이었습니다. 바로 이런 문제를 해결하기 위해 **VirtualService**가 등장했습니다. VirtualService를 사용하면 애플리케이션 코드 수정 없이 트래픽 라우팅을 제어할 수 있습니다. 또한 배포 없이 설정 파일만 변경하면 즉시 라우팅 규칙이 적용됩니다. 무엇보다 네트워크 관심사를 인프라 레벨에서 처리하므로 코드가 깔끔해진다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **hosts** 필드를 보면 이 VirtualService가 어떤 서비스에 대한 트래픽을 제어할지 정의합니다. 여기서는 reviews 서비스가 대상입니다. **http** 섹션에서는 HTTP 트래픽에 대한 라우팅 규칙을 정의합니다. 첫 번째 **match** 조건은 "end-user 헤더가 jason인 요청"을 의미하며, 이런 요청은 v2 서브셋으로 라우팅됩니다. 두 번째 **route**는 매치 조건이 없으므로 나머지 모든 트래픽이 v1 서브셋으로 라우팅됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 서비스를 개발한다고 가정해봅시다. 새로운 결제 시스템을 도입하는데 바로 전체 사용자에게 적용하기는 위험합니다. VirtualService를 활용하면 내부 직원들에게만 먼저 새 버전을 노출하고, 문제가 없으면 점진적으로 확대할 수 있습니다. 넷플릭스, 우버 같은 많은 기업에서 이런 패턴을 적극적으로 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 VirtualService만 정의하고 **DestinationRule**을 정의하지 않는 것입니다. VirtualService에서 "v1", "v2" 같은 서브셋을 참조하려면 반드시 DestinationRule에서 이 서브셋들을 정의해야 합니다. 그렇지 않으면 트래픽이 라우팅되지 않는 문제가 발생합니다. 따라서 VirtualService와 DestinationRule은 항상 쌍으로 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 애플리케이션 코드를 건드리지 않고도 라우팅을 제어할 수 있군요!" VirtualService를 제대로 이해하면 카나리 배포, A/B 테스팅, 블루-그린 배포 같은 고급 배포 전략을 손쉽게 구현할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 실전 팁 2-3개 - VirtualService와 DestinationRule은 항상 쌍으로 정의해야 합니다. - match 조건은 위에서 아래로 순차적으로 평가되므로 더 구체적인 조건을 위에 배치하세요. - hosts 필드에는 정규화된 도메인 이름(FQDN)을 사용하는 것이 안전합니다. --- ## 2. 라우팅 규칙 정의 2-3문장으로 상황 설정 김개발 씨는 VirtualService를 성공적으로 적용한 후, 이번에는 더 복잡한 요구사항을 받았습니다. "/api/v1" 경로로 오는 요청은 구 버전으로, "/api/v2" 경로는 신 버전으로 라우팅해야 한다는 것이었죠. 박시니어 씨가 말했습니다. "라우팅 규칙을 더 정교하게 정의할 수 있어요." 핵심 개념을 3-4문장으로 **라우팅 규칙**은 VirtualService에서 트래픽을 어떻게 분배할지 결정하는 세부 조건입니다. URI 경로, HTTP 메서드, 헤더, 쿼리 파라미터 등 다양한 기준으로 매칭할 수 있습니다. 마치 우체국에서 우편물을 주소, 크기, 중요도에 따라 분류하는 것처럼 세밀한 제어가 가능합니다. 여러 조건을 조합하여 매우 복잡한 라우팅 시나리오도 구현할 수 있습니다. 다음 코드를 살펴봅시다. ```yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: productpage-vs spec: hosts: - productpage http: - match: - uri: prefix: "/api/v2" - method: exact: "POST" route: - destination: host: productpage subset: v2 - match: - uri: prefix: "/api/v1" route: - destination: host: productpage subset: v1 ``` 이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 회사는 API 버전 관리 정책을 도입하기로 했습니다. 기존 고객들은 계속 v1 API를 사용하고, 신규 고객들은 개선된 v2 API를 사용하도록 분리하는 것이었습니다. 문제는 두 버전의 API가 같은 서비스 이름을 사용한다는 점이었습니다. "경로 기반으로 라우팅할 수 있을까요?" 김개발 씨가 물었습니다. 박시니어 씨가 웃으며 대답했습니다. "당연하죠. Istio의 라우팅 규칙은 생각보다 훨씬 강력해요." 그렇다면 **라우팅 규칙**을 어떻게 정의할까요? 쉽게 비유하자면, 라우팅 규칙은 마치 공항의 탑승객 분류 시스템과 같습니다. 비즈니스 클래스 승객, 이코노미 승객, 마일리지 등급, 목적지 등 여러 기준으로 승객을 분류해서 각각 다른 게이트로 안내하죠. 라우팅 규칙도 이처럼 요청의 여러 속성을 검사해서 적절한 서비스 버전으로 안내합니다. 라우팅 규칙이 없던 시절에는 어땠을까요? 개발자들은 각 서비스마다 별도의 쿠버네티스 서비스를 만들고, 서로 다른 이름을 부여해야 했습니다. productpage-v1, productpage-v2 같은 식으로 말이죠. 클라이언트 코드에서는 어떤 버전을 호출할지 직접 결정해야 했고, 이는 코드 전반에 버전 관리 로직이 흩어지는 결과를 낳았습니다. API 버전을 추가하거나 변경할 때마다 모든 클라이언트 코드를 수정해야 했습니다. 바로 이런 문제를 해결하기 위해 **정교한 라우팅 규칙**이 필요했습니다. 라우팅 규칙을 사용하면 같은 서비스 이름으로 여러 버전을 관리할 수 있습니다. 또한 클라이언트는 버전을 신경 쓰지 않고 단순히 요청만 보내면 됩니다. 무엇보다 라우팅 정책을 중앙에서 관리하므로 일관성 있는 트래픽 제어가 가능하다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 첫 번째 **match** 블록을 보면 두 가지 조건이 있습니다. URI가 "/api/v2"로 시작하고, HTTP 메서드가 POST인 요청입니다. 이런 요청은 v2 서브셋으로 라우팅됩니다. 두 번째 match 블록은 URI가 "/api/v1"로 시작하는 요청을 v1 서브셋으로 라우팅합니다. **prefix** 매칭을 사용했으므로 "/api/v1/products", "/api/v1/users" 같은 하위 경로도 모두 매칭됩니다. match 조건에는 여러 가지 매칭 방법이 있습니다. **exact**는 정확히 일치하는 경우, **prefix**는 접두사가 일치하는 경우, **regex**는 정규표현식으로 매칭하는 경우입니다. 상황에 맞게 적절한 방법을 선택해야 합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 모바일 앱과 웹 클라이언트가 같은 API를 사용하는 서비스가 있다고 가정해봅시다. 웹은 이미 v2 API를 사용 중인데, 모바일 앱은 아직 v1을 사용합니다. User-Agent 헤더를 기반으로 라우팅 규칙을 정의하면, 모바일 요청은 v1으로, 웹 요청은 v2로 자동으로 분기할 수 있습니다. 앱 업데이트 없이도 점진적으로 마이그레이션이 가능하죠. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 match 조건의 순서를 고려하지 않는 것입니다. Istio는 위에서 아래로 순차적으로 조건을 평가하고, 첫 번째로 매칭되는 규칙을 적용합니다. 만약 더 일반적인 조건을 위에 두면 구체적인 조건이 절대 실행되지 않습니다. 따라서 가장 구체적인 조건을 위에, 일반적인 조건을 아래에 배치해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 라우팅 규칙을 적용한 김개발 씨는 테스트를 진행했습니다. "/api/v1/products"로 요청하니 v1이 응답했고, "/api/v2/products"로 요청하니 v2가 응답했습니다. "완벽하네요!" 라우팅 규칙을 제대로 이해하면 복잡한 트래픽 관리 시나리오도 코드 수정 없이 해결할 수 있습니다. 여러분도 다양한 match 조건을 조합해서 실험해 보세요. **실전 팁** 💡 실전 팁 2-3개 - match 조건은 구체적인 것부터 일반적인 순서로 배치하세요. - prefix 매칭은 하위 경로도 모두 포함하므로 주의가 필요합니다. - 복잡한 조건은 regex보다 여러 개의 간단한 조건으로 나누는 것이 가독성에 좋습니다. --- ## 3. DestinationRule 설정 2-3문장으로 상황 설정 김개발 씨는 VirtualService에서 "subset: v1", "subset: v2"를 사용했지만, 아직 이 서브셋이 무엇을 의미하는지 정의하지 않았습니다. 트래픽을 테스트하려는데 에러가 발생했죠. 박시니어 씨가 말했습니다. "DestinationRule을 정의해야 해요." 핵심 개념을 3-4문장으로 **DestinationRule**은 트래픽이 목적지에 도착한 후 어떻게 처리될지 정의하는 리소스입니다. 서브셋을 정의하고, 로드 밸런싱 정책을 설정하며, 연결 풀 관리 등을 담당합니다. 마치 호텔에서 객실 등급을 정의하고 각 등급별 서비스 정책을 수립하는 것과 같습니다. VirtualService가 "어디로 보낼지" 결정한다면, DestinationRule은 "도착 후 어떻게 처리할지"를 결정합니다. 다음 코드를 살펴봅시다. ```yaml apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews-dr spec: host: reviews.default.svc.cluster.local trafficPolicy: loadBalancer: simple: ROUND_ROBIN subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 100 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: LEAST_REQUEST ``` 이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨는 VirtualService를 완벽하게 작성했다고 생각했습니다. 하지만 막상 실행해보니 이상한 에러가 발생했습니다. "host has no subset v1"이라는 메시지가 나타났죠. 코드를 여러 번 확인했지만 문제를 찾을 수 없었습니다. 박시니어 씨가 화면을 보더니 바로 원인을 파악했습니다. "아, DestinationRule을 안 만드셨군요. VirtualService만으로는 부족해요." 그렇다면 **DestinationRule**은 정확히 무엇일까요? 쉽게 비유하자면, DestinationRule은 마치 레스토랑의 좌석 배치 정책과 같습니다. VirtualService가 손님을 레스토랑으로 안내했다면, DestinationRule은 "흡연석/금연석", "창가/복도" 같은 좌석 구역을 정의하고, 각 구역마다 서비스 방식을 결정합니다. 어떤 구역은 빠른 회전율을 위해 테이블을 많이 배치하고, 어떤 구역은 VIP를 위해 널찍하게 배치하는 것처럼 말이죠. DestinationRule이 없던 시절에는 어떻게 했을까요? 쿠버네티스의 기본 서비스는 모든 파드를 동일하게 취급했습니다. 라벨로 파드를 선택할 수는 있었지만, 같은 서비스 내에서 서로 다른 버전을 구분할 방법이 없었습니다. v1 파드와 v2 파드를 분리하려면 아예 별도의 서비스를 만들어야 했죠. 그러다 보니 서비스 개수가 기하급수적으로 늘어나고, 관리가 복잡해졌습니다. 바로 이런 문제를 해결하기 위해 **DestinationRule**이 등장했습니다. DestinationRule을 사용하면 하나의 서비스 내에서 여러 서브셋을 논리적으로 분리할 수 있습니다. 또한 각 서브셋마다 다른 트래픽 정책을 적용할 수 있습니다. 무엇보다 로드 밸런싱, 연결 풀, 아웃라이어 감지 같은 고급 기능을 세밀하게 제어할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 **host** 필드는 이 DestinationRule이 적용될 서비스를 지정합니다. 전역 **trafficPolicy**는 모든 서브셋에 기본적으로 적용되는 정책입니다. 여기서는 라운드 로빈 방식의 로드 밸런싱을 사용합니다. **subsets** 섹션에서 v1과 v2 서브셋을 정의합니다. 각 서브셋은 **labels**로 어떤 파드를 선택할지 결정합니다. v1 서브셋은 최대 100개의 TCP 연결만 허용하고, v2 서브셋은 최소 요청 개수 기준으로 로드 밸런싱합니다. 서브셋별로 다른 정책을 적용할 수 있다는 점이 매우 강력합니다. 예를 들어 구 버전은 보수적으로 연결 수를 제한하고, 신 버전은 공격적으로 성능을 최적화할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 AI 추천 서비스를 운영한다고 가정해봅시다. GPU 서버에서 실행되는 v2는 성능이 좋지만 비용이 높고, CPU 서버의 v1은 저렴하지만 느립니다. DestinationRule에서 v2는 LEAST_REQUEST 정책으로 부하를 고르게 분산하고, v1은 단순 라운드 로빈을 사용할 수 있습니다. 또한 v2의 연결 풀을 크게 설정해서 GPU 리소스를 최대한 활용할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 서브셋의 labels와 실제 파드의 labels가 일치하지 않는 것입니다. DestinationRule에서 "version: v1"을 선택하도록 했는데, 실제 파드에는 "app: reviews" 라벨만 있다면 서브셋이 아무 파드도 선택하지 못합니다. 따라서 파드의 라벨을 먼저 확인하고, 정확히 일치하는 라벨 선택자를 작성해야 합니다. 또 다른 실수는 전역 정책과 서브셋 정책의 우선순위를 이해하지 못하는 것입니다. 서브셋에 정의된 정책이 전역 정책을 오버라이드합니다. 만약 의도치 않게 서브셋 정책이 전역 정책을 덮어쓴다면 예상과 다른 동작이 발생할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. DestinationRule을 추가한 김개발 씨는 다시 테스트를 진행했습니다. 이번에는 에러 없이 정상적으로 동작했습니다. "이제 VirtualService와 DestinationRule이 어떻게 함께 작동하는지 알겠어요!" DestinationRule을 제대로 이해하면 서비스 메시의 진정한 힘을 활용할 수 있습니다. 여러분도 다양한 트래픽 정책을 실험해 보세요. **실전 팁** 💡 실전 팁 2-3개 - VirtualService와 DestinationRule은 항상 쌍으로 정의해야 합니다. - 서브셋의 라벨 선택자는 실제 파드의 라벨과 정확히 일치해야 합니다. - 서브셋 정책이 전역 정책을 오버라이드한다는 점을 기억하세요. --- ## 4. 트래픽 분할 2-3문장으로 상황 설정 김개발 씨는 이번에 카나리 배포를 구현해야 했습니다. 새 버전을 전체 사용자에게 바로 배포하는 것은 위험하니, 10%의 트래픽만 새 버전으로 보내고 싶었죠. 박시니어 씨가 말했습니다. "트래픽 분할 기능을 사용하면 됩니다." 핵심 개념을 3-4문장으로 **트래픽 분할**은 들어오는 트래픽을 여러 버전에 비율대로 나누어 분배하는 기능입니다. 마치 강물을 여러 수로로 나누어 각각 원하는 비율로 흐르게 하는 것과 같습니다. 카나리 배포, A/B 테스팅 같은 고급 배포 전략의 핵심입니다. 비율은 자유롭게 조정할 수 있으며, 문제가 발생하면 즉시 100% 롤백도 가능합니다. 다음 코드를 살펴봅시다. ```yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: reviews-canary spec: hosts: - reviews http: - match: - headers: x-canary: exact: "true" route: - destination: host: reviews subset: v2 weight: 100 - route: - destination: host: reviews subset: v1 weight: 90 - destination: host: reviews subset: v2 weight: 10 ``` 이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 팀은 새로운 추천 알고리즘을 개발했습니다. 시뮬레이션에서는 완벽했지만, 실제 운영 환경에서 어떻게 동작할지는 알 수 없었습니다. 전체 사용자에게 한 번에 배포했다가 문제가 생기면 대참사가 될 것입니다. "일단 소수의 사용자에게만 적용해볼 수 없을까요?" 김개발 씨가 물었습니다. 박시니어 씨가 웃으며 대답했습니다. "그게 바로 카나리 배포죠. Istio로 아주 쉽게 구현할 수 있어요." 그렇다면 **트래픽 분할**은 어떻게 작동할까요? 쉽게 비유하자면, 트래픽 분할은 마치 샘플링 조사와 같습니다. 신제품을 출시하기 전에 전체 시장에 바로 내놓지 않고, 먼저 일부 지역에서 테스트 마케팅을 하는 것이죠. 반응이 좋으면 점차 확대하고, 문제가 있으면 즉시 철수합니다. 트래픽 분할도 이처럼 위험을 최소화하면서 새로운 변경사항을 안전하게 검증할 수 있게 해줍니다. 트래픽 분할이 없던 시절에는 어땠을까요? 개발자들은 블루-그린 배포를 주로 사용했습니다. 완전히 새로운 환경을 구축하고, 한 번에 모든 트래픽을 전환하는 방식이었죠. 문제는 새 버전에 버그가 있으면 전체 서비스가 장애를 겪는다는 점이었습니다. 또한 인프라 비용도 두 배로 들었습니다. 점진적으로 배포할 방법이 없었기 때문에 항상 큰 위험을 감수해야 했습니다. 바로 이런 문제를 해결하기 위해 **트래픽 분할**이 필요했습니다. 트래픽 분할을 사용하면 위험을 최소화하면서 새 버전을 검증할 수 있습니다. 또한 추가 인프라 없이 기존 환경에서 비율만 조정하면 됩니다. 무엇보다 실시간으로 모니터링하면서 비율을 동적으로 조정할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 첫 번째 **match** 블록은 특별한 경우입니다. "x-canary: true" 헤더가 있는 요청은 무조건 v2로 라우팅됩니다. 이는 내부 테스터나 개발자가 강제로 새 버전을 테스트할 수 있게 하는 장치입니다. **weight: 100**은 이 조건에 매칭되면 100% v2로 간다는 의미입니다. 두 번째 블록이 핵심입니다. 일반 트래픽의 90%는 v1으로, 10%는 v2로 분할됩니다. **weight** 값의 합은 100이어야 합니다. 이 비율은 언제든 변경할 수 있습니다. 처음에는 v2에 5%만 보내다가, 안정적이면 점차 20%, 50%, 100%로 늘려갈 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 결제 시스템을 개선하는 프로젝트가 있다고 가정해봅시다. 새 결제 로직은 더 빠르고 안전하지만, 실제 환경에서 검증되지 않았습니다. 먼저 1%의 트래픽만 새 버전으로 보내고, 에러율과 응답 시간을 모니터링합니다. 문제가 없으면 5%, 10%, 25%로 점진적으로 확대합니다. 만약 에러가 증가하면 즉시 0%로 되돌립니다. 이런 방식으로 페이팔, 아마존 같은 기업들이 안전하게 배포합니다. 트래픽 분할은 A/B 테스팅에도 활용됩니다. UI 디자인 두 가지를 테스트한다면, 50:50으로 트래픽을 분할하고 어느 쪽의 전환율이 높은지 측정할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 weight 값의 합이 100이 아니게 설정하는 것입니다. Istio는 자동으로 정규화하기는 하지만, 명시적으로 100이 되도록 하는 것이 가독성에 좋습니다. 또한 너무 작은 비율(1% 미만)로 시작하면 통계적으로 유의미한 데이터를 얻기 어렵습니다. 최소 5-10%는 되어야 의미 있는 모니터링이 가능합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 트래픽 분할을 적용한 김개발 씨는 먼저 10%로 시작했습니다. 일주일간 모니터링한 결과 에러율이 오히려 낮아졌습니다. 자신감을 얻은 팀은 비율을 50%로 늘렸고, 최종적으로 100% 전환에 성공했습니다. "안전하게 배포할 수 있어서 정말 좋네요!" 트래픽 분할을 제대로 이해하면 두려움 없이 새로운 기능을 배포할 수 있습니다. 여러분도 점진적 배포 전략을 실제로 적용해 보세요. **실전 팁** 💡 실전 팁 2-3개 - weight 값의 합은 항상 100이 되도록 설정하세요. - 카나리 배포는 5-10%부터 시작하고 점진적으로 확대하세요. - 내부 테스터용 강제 라우팅 규칙을 별도로 추가하면 편리합니다. --- ## 5. 헤더 기반 라우팅 2-3문장으로 상황 설정 김개발 씨는 이번에 모바일 앱과 웹 클라이언트가 서로 다른 API 버전을 사용하도록 구현해야 했습니다. User-Agent 헤더를 확인해서 분기하면 될 것 같았는데, 애플리케이션 코드를 수정하고 싶지 않았죠. 박시니어 씨가 말했습니다. "헤더 기반 라우팅을 사용하세요." 핵심 개념을 3-4문장으로 **헤더 기반 라우팅**은 HTTP 헤더의 값을 기준으로 트래픽을 라우팅하는 기술입니다. User-Agent, Authorization, 커스텀 헤더 등 어떤 헤더든 조건으로 사용할 수 있습니다. 마치 클럽 입구에서 회원증을 확인하고 VIP는 특별실로, 일반 회원은 메인홀로 안내하는 것과 같습니다. 클라이언트 타입, 사용자 권한, 지역 등 다양한 기준으로 라우팅을 제어할 수 있습니다. 다음 코드를 살펴봅시다. ```yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: api-header-routing spec: hosts: - api.example.com http: - match: - headers: user-agent: regex: ".*Mobile.*" route: - destination: host: api-service subset: mobile-optimized - match: - headers: x-user-type: exact: "premium" route: - destination: host: api-service subset: premium-tier - route: - destination: host: api-service subset: standard ``` 이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 회사는 모바일 앱을 새로 출시했습니다. 문제는 모바일 환경에서는 데이터를 최소화해야 하므로 응답 구조가 웹과 달라야 한다는 점이었습니다. 두 개의 완전히 다른 API를 만들까 고민했지만, 중복 코드가 너무 많아질 것 같았습니다. "클라이언트 타입에 따라 다른 서비스 버전으로 라우팅할 수 있을까요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 끄덕였습니다. "당연하죠. 헤더를 보고 판단하면 됩니다." 그렇다면 **헤더 기반 라우팅**은 어떻게 작동할까요? 쉽게 비유하자면, 헤더 기반 라우팅은 마치 공항의 탑승 게이트 안내와 같습니다. 항공권(헤더)을 확인해서 비즈니스 승객은 라운지로, 이코노미 승객은 대기실로, 환승 승객은 환승 구역으로 안내합니다. 각 승객 유형마다 다른 서비스와 경로를 제공하는 것이죠. HTTP 헤더도 이처럼 요청자의 신원, 특성, 선호도를 담고 있어서 이를 기반으로 최적의 경로를 찾아줄 수 있습니다. 헤더 기반 라우팅이 없던 시절에는 어땠을까요? 애플리케이션 코드 내부에서 헤더를 파싱하고 조건문으로 분기를 처리해야 했습니다. "if user-agent contains Mobile then ... else ..." 같은 로직이 컨트롤러마다 반복되었죠. 새로운 클라이언트 타입이 추가되면 모든 엔드포인트를 수정해야 했습니다. 더 큰 문제는 라우팅 로직이 비즈니스 로직과 섞여서 코드가 복잡해진다는 점이었습니다. 바로 이런 문제를 해결하기 위해 **헤더 기반 라우팅**이 필요했습니다. 헤더 기반 라우팅을 사용하면 애플리케이션 코드 수정 없이 인프라 레벨에서 라우팅을 제어할 수 있습니다. 또한 새로운 클라이언트 타입 추가가 매우 간단합니다. 무엇보다 관심사의 분리가 명확해져서 코드 품질이 향상된다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 첫 번째 **match** 블록은 User-Agent 헤더를 정규표현식으로 검사합니다. "Mobile"이라는 단어가 포함되어 있으면 mobile-optimized 서브셋으로 라우팅됩니다. **regex** 매칭을 사용하면 복잡한 패턴도 처리할 수 있습니다. 두 번째 match 블록은 커스텀 헤더인 "x-user-type"을 확인합니다. 프리미엄 사용자는 더 강력한 서버로 라우팅되어 빠른 응답을 받을 수 있습니다. **exact** 매칭은 정확히 일치하는 경우에만 적용됩니다. 마지막 블록은 기본 라우팅입니다. 어떤 조건도 만족하지 않으면 standard 서브셋으로 라우팅됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 SaaS 서비스를 운영하는데 프리티어, 스탠다드, 엔터프라이즈 세 가지 플랜이 있다고 가정해봅시다. API 게이트웨이에서 사용자의 플랜 정보를 조회해서 커스텀 헤더 "x-plan"을 추가합니다. Istio는 이 헤더를 보고 엔터프라이즈 사용자는 전용 고성능 서버로, 프리티어는 공유 서버로 라우팅합니다. 이렇게 하면 공정한 리소스 분배와 QoS 보장이 가능합니다. 또 다른 사례는 지역 기반 라우팅입니다. CloudFront 같은 CDN은 "CloudFront-Viewer-Country" 헤더를 추가합니다. 한국 사용자는 서울 리전의 서버로, 미국 사용자는 버지니아 리전의 서버로 라우팅하여 지연 시간을 최소화할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 헤더 이름의 대소문자를 잘못 쓰는 것입니다. HTTP 헤더는 대소문자를 구분하지 않지만, Istio 설정에서는 소문자로 정규화되어 비교됩니다. "User-Agent"와 "user-agent"는 같은 헤더이지만, 설정에서는 "user-agent"로 작성해야 안전합니다. 또 다른 실수는 클라이언트가 헤더를 제대로 보내지 않는 경우를 고려하지 않는 것입니다. 항상 기본 라우팅 규칙을 마지막에 추가해서 예외 상황을 처리해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 헤더 기반 라우팅을 적용한 김개발 씨는 모바일 앱에서 API를 호출해봤습니다. 모바일에 최적화된 간결한 응답이 돌아왔습니다. 웹에서 호출하니 상세한 정보가 포함된 응답이 왔습니다. "코드 수정 없이 클라이언트별로 다른 처리가 가능하네요!" 헤더 기반 라우팅을 제대로 이해하면 매우 유연한 멀티 테넌시 시스템을 구축할 수 있습니다. 여러분도 다양한 헤더를 활용해서 실험해 보세요. **실전 팁** 💡 실전 팁 2-3개 - 헤더 이름은 소문자로 작성하는 것이 안전합니다. - 항상 기본 라우팅 규칙을 마지막에 추가하세요. - 커스텀 헤더는 "x-" 접두사를 사용하는 것이 관례입니다. --- ## 6. 타임아웃과 재시도 2-3문장으로 상황 설정 김개발 씨의 서비스는 종종 외부 API 호출 때문에 느려졌습니다. 외부 API가 응답하지 않으면 30초 동안 기다렸다가 타임아웃되는데, 사용자 경험이 너무 나빴죠. 박시니어 씨가 말했습니다. "타임아웃과 재시도 정책을 설정해보세요." 핵심 개념을 3-4문장으로 **타임아웃**은 요청이 일정 시간 내에 응답하지 않으면 실패 처리하는 기능입니다. **재시도**는 실패한 요청을 자동으로 다시 시도하는 기능입니다. 마치 전화를 걸었는데 받지 않으면 일정 시간 후 끊고, 몇 번 더 걸어보는 것과 같습니다. 이 두 기능을 적절히 조합하면 일시적인 네트워크 장애를 극복하고 안정적인 서비스를 제공할 수 있습니다. 다음 코드를 살펴봅시다. ```yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: payment-service-vs spec: hosts: - payment-service http: - route: - destination: host: payment-service timeout: 3s retries: attempts: 3 perTryTimeout: 1s retryOn: 5xx,reset,connect-failure,refused-stream --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: payment-service-dr spec: host: payment-service trafficPolicy: outlierDetection: consecutiveErrors: 5 interval: 30s baseEjectionTime: 30s ``` 이북처럼 술술 읽히는 설명 - 10-15문단, 소설처럼 자연스럽게 흘러가도록 김개발 씨의 결제 서비스는 외부 PG사 API를 호출합니다. 대부분의 경우 1초 이내에 응답이 오지만, 가끔 PG사 서버 상태가 불안정하면 10초 이상 걸리거나 아예 응답이 없었습니다. 사용자는 결제 버튼을 누르고 한참을 기다려야 했고, 결국 "죽었나?" 싶어서 새로고침을 누릅니다. 이는 중복 결제로 이어지기도 했습니다. "요청이 너무 오래 걸리면 빨리 포기하고, 실패하면 자동으로 재시도할 수 없을까요?" 김개발 씨가 물었습니다. 박시니어 씨가 웃으며 대답했습니다. "그게 바로 타임아웃과 재시도 정책입니다." 그렇다면 **타임아웃과 재시도**는 어떻게 작동할까요? 쉽게 비유하자면, 타임아웃과 재시도는 마치 택배 배송 정책과 같습니다. 배송 기사가 집에 갔는데 아무도 없으면 무한정 기다리지 않습니다. 10분만 기다리고(타임아웃), 부재중 메모를 남기고 돌아갑니다. 그리고 당일 저녁에 다시 방문을 시도하고(재시도), 그래도 안 되면 택배 센터로 반송합니다. 이처럼 적절한 포기 시점과 재시도 전략을 세우는 것이 중요합니다. 타임아웃과 재시도가 없던 시절에는 어땠을까요? 애플리케이션 코드에서 직접 타임아웃을 설정하고, try-catch 블록으로 재시도 로직을 구현해야 했습니다. 문제는 이런 로직이 모든 외부 API 호출 부분에 중복되어 나타났다는 점입니다. 개발자마다 타임아웃 시간을 다르게 설정하고, 재시도 횟수도 제각각이었습니다. 일관성 없는 에러 처리는 디버깅을 어렵게 만들었습니다. 바로 이런 문제를 해결하기 위해 **인프라 레벨의 타임아웃과 재시도**가 필요했습니다. 타임아웃과 재시도를 Istio에서 관리하면 애플리케이션 코드가 깔끔해집니다. 또한 모든 서비스에 일관된 정책을 적용할 수 있습니다. 무엇보다 코드 수정 없이 설정만 변경하면 즉시 적용된다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. VirtualService의 **timeout** 필드는 전체 요청의 최대 허용 시간입니다. 여기서는 3초로 설정했습니다. 3초 안에 응답이 오지 않으면 즉시 실패합니다. **retries** 섹션이 핵심입니다. **attempts: 3**은 최대 3번까지 재시도한다는 의미입니다. 원래 요청을 포함하면 총 4번의 시도가 일어납니다. **perTryTimeout: 1s**는 각 시도마다 1초씩만 기다린다는 뜻입니다. 전체 타임아웃 3초 안에 세 번의 1초 재시도가 일어날 수 있습니다. **retryOn** 필드는 어떤 경우에 재시도할지 정의합니다. "5xx"는 서버 에러, "reset"은 연결 리셋, "connect-failure"는 연결 실패, "refused-stream"은 스트림 거부 등입니다. 4xx 클라이언트 에러는 재시도해도 소용없으므로 포함하지 않습니다. DestinationRule의 **outlierDetection**은 문제 있는 인스턴스를 자동으로 제외하는 기능입니다. 30초 동안 5번 연속 에러가 발생하면 해당 파드를 30초간 로드 밸런싱 풀에서 제외합니다. 이를 "서킷 브레이커" 패턴이라고 합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 추천 서비스를 개발하는데, 외부 ML 모델 API를 호출한다고 가정해봅시다. ML 모델은 가끔 과부하 상태가 됩니다. 타임아웃을 2초로 설정하고, 재시도를 3번으로 설정합니다. 첫 번째 시도가 실패하면 다른 파드로 자동 재시도합니다. 여러 파드 중 하나라도 정상이면 성공할 가능성이 높아집니다. Outlier detection으로 문제 있는 파드는 자동으로 격리되어 전체 성공률이 향상됩니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 재시도를 무조건 많이 설정하는 것입니다. 재시도가 많으면 일시적 장애를 극복할 가능성은 높아지지만, 시스템에 부하를 가중시킵니다. 만약 모든 클라이언트가 실패할 때마다 3번씩 재시도하면 서버는 3배의 트래픽을 받게 됩니다. 장애 상황에서는 오히려 재시도가 시스템을 더 악화시킬 수 있습니다. 또 다른 실수는 멱등하지 않은 작업에 재시도를 적용하는 것입니다. 결제 API처럼 여러 번 호출하면 중복 처리되는 작업은 재시도하면 안 됩니다. 이런 경우 애플리케이션 레벨에서 멱등성 키를 사용하거나, GET 요청만 재시도하도록 제한해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 타임아웃과 재시도 정책을 적용한 김개발 씨는 모니터링 대시보드를 확인했습니다. 평균 응답 시간이 크게 줄어들었고, 일시적인 네트워크 블립으로 인한 에러가 대부분 재시도로 해결되었습니다. "사용자는 장애를 느끼지도 못했겠네요!" 타임아웃과 재시도를 제대로 이해하면 훨씬 더 탄력적이고 안정적인 시스템을 구축할 수 있습니다. 여러분도 실제 서비스에 적용해서 효과를 체험해 보세요. **실전 팁** 💡 실전 팁 2-3개 - 재시도는 2-3번 정도가 적당하며, 너무 많으면 시스템에 부담을 줍니다. - 멱등하지 않은 작업(POST, 결제 등)에는 재시도를 신중하게 적용하세요. - outlierDetection으로 문제 있는 인스턴스를 자동으로 격리하면 전체 안정성이 향상됩니다. --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Kubernetes

언어: YAML

태그: Istio, VirtualService, DestinationRule, TrafficManagement, ServiceMesh, Kubernetes

작성자: AI Generated

CodeDeck

Istio 트래픽 관리 완벽 가이드

목차

1. VirtualService 개념

2. 라우팅 규칙 정의

3. DestinationRule 설정

4. 트래픽 분할

5. 헤더 기반 라우팅

6. 타임아웃과 재시도

댓글 (0)

함께 보면 좋은 카드 뉴스

Istio 보안 완벽 가이드

Istio 설치와 구성 완벽 가이드

서비스 메시 완벽 가이드

Helm 마이크로서비스 패키징 완벽 가이드

Helm 차트 기초 완벽 가이드