당신의 Istio 트래픽 라우팅이 실패하는 진짜 이유? AND와 OR 논리 완전 정복 🚀

안녕하세요! MSA(Microservice Architecture) 환경에서 서비스 메시, 특히 Istio를 다루다 보면 트래픽을 원하는 대로 제어하는 것이 얼마나 중요한지 깨닫게 됩니다. "이 요청은 A 서비스로, 저 요청은 B 서비스로 보내줘!" 와 같은 규칙을 설정할 때, 우리는 VirtualService를 사용하죠.

 

그런데 이상하게 트래픽이 내가 의도한 대로 흐르지 않을 때가 있습니다. 🤔 분명 규칙을 잘 설정한 것 같은데 말이죠. 많은 경우, 그 원인은 Istio가 트래픽 매칭 규칙을 해석하는 논리(Logic)를 정확히 이해하지 못했기 때문일 수 있습니다.

 

혹시 Istio의 매칭 규칙이 여러 조건 중 하나만 만족하면 되는 OR 조건만 지원한다고 생각하셨나요? 만약 그렇다면, 이 글이 여러분의 디버깅 시간을 획기적으로 줄여줄 열쇠가 될 겁니다! 🔑

❌ 흔한 오해: "Istio는 OR 조건만 사용한다?"

결론부터 말하면, 아닙니다! Istio는 매우 유연하게 AND와 OR 논리를 모두 사용하여 강력하고 세밀한 트래픽 제어를 가능하게 합니다. 이 두 가지 논리가 어떻게 작동하는지 모른다면, 복잡한 라우팅 규칙을 만들 때 예상치 못한 결과를 마주하게 될 확률이 높습니다.

---

🔗 AND 논리: 모든 조건을 만족시켜라! (하나의 match 블록)

가장 먼저 알아볼 것은 AND 논리입니다. Istio에서 http 라우팅 규칙 내에 단 하나의 match 블록을 정의하고, 그 안에 여러 필드(예: uri, method, headers)를 함께 명시하면, 이 필드들은 AND 조건으로 묶입니다.

즉, 들어온 요청이 match 블록 안의 모든 조건을 동시에 만족해야만 해당 라우팅 규칙이 적용됩니다.

 

예시 시나리오: /api/v1/products 경로로 들어오는 GET 요청이면서, 헤더에 user-group이 beta-testers인 요청만 product-v2 서비스로 보내고 싶다고 가정해봅시다.

 

이 경우, 다음과 같이 VirtualService를 작성할 수 있습니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: product-reviews
spec:
  hosts:
    - product.example.com
  http:
  - match:
    - uri:
        prefix: "/api/v1/products" # 조건 1
      method:
        exact: "GET" # 조건 2
      headers:
        user-group:
          exact: "beta-testers" # 조건 3
    route:
    - destination:
        host: product-v2
        subset: v2

 

위 YAML 파일에서 match 블록 안의 세 가지 조건은 AND로 연결됩니다.

1. 요청 URI가 /api/v1/products로 시작 하고(AND)
2. HTTP 메소드가 정확히 GET 이며(AND)
3. user-group 헤더 값이 beta-testers인 경우

이 세 가지를 모두 충족하는 요청만이 product-v2 서비스로 라우팅됩니다. 하나라도 만족하지 않으면 이 규칙은 무시됩니다.

---

🔀 OR 논리: 하나라도 만족하면 OK! (여러 개의 match 블록)

그렇다면 OR 논리는 언제 사용할까요? 바로 여러 개의 match 블록을 리스트(배열) 형태로 나열할 때입니다. YAML에서 - 기호로 새로운 아이템을 시작하는 것을 생각하시면 됩니다.

 

http 규칙 아래에 여러 match 블록을 정의하면, Istio는 들어온 요청이 이 블록들 중 단 하나라도 만족하는지를 검사합니다. 하나라도 만족하면 해당 라우팅 규칙이 즉시 적용됩니다.

 

예시 시나리오: /mobile-api 경로로 들어오는 요청 또는(OR) 헤더에 device가 mobile인 요청을 모두 mobile-gateway 서비스로 보내고 싶다고 가정해봅시다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway
spec:
  hosts:
    - api.example.com
  http:
  - match:
    - uri: # 첫 번째 match 블록 (조건 A)
        prefix: "/mobile-api"
    - headers: # 두 번째 match 블록 (조건 B)
        device:
          exact: "mobile"
    route:
    - destination:
        host: mobile-gateway
        subset: v1

 

이 설정에서는 두 개의 match 블록이 리스트로 존재합니다.

1. 요청 URI가 /mobile-api로 시작하는 경우
2. 또는(OR) device 헤더 값이 mobile인 경우

이 두 가지 케이스 중 하나에만 해당되어도 요청은 mobile-gateway로 라우팅됩니다.

---

💡 전체 맥락 보기: AND와 OR의 조합으로 전문가 되기

이제 진짜 강력한 점이 드러납니다. Istio는 이 두 가지 논리를 조합하여 매우 정교한 트래픽 제어를 할 수 있습니다.

(조건 A AND 조건 B) OR (조건 C AND 조건 D) 와 같은 복잡한 논리도 쉽게 구현할 수 있습니다.

예시 시나리오 (고급):

• 케이스 1: 내부 직원(internal-user: true 헤더)이 /admin 페이지에 POST 요청을 보내는 경우
• 또는(OR)
• 케이스 2: 베타 테스터(user-group: beta 헤더)가 /new-feature 페이지에 접근하는 경우

이 두 가지 경우 모두를 admin-panel-v2 서비스로 보내고 싶다면 어떻게 해야 할까요? 바로 이렇게 조합하면 됩니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: admin-access-control
spec:
  hosts:
    - admin.example.com
  http:
  - match:
    - headers: # 첫 번째 match 블록 (케이스 1)
        internal-user:
          exact: "true"
      uri:
        prefix: "/admin"
      method:
        exact: "POST"
    - headers: # 두 번째 match 블록 (케이스 2)
        user-group:
          exact: "beta"
      uri:
        prefix: "/new-feature"
    route:
    - destination:
        host: admin-panel-v2
        subset: v2

 

이 VirtualService는 다음과 같이 동작합니다.

• 첫 번째 match 블록: 헤더, URI, 메소드 조건이 AND로 묶여 케이스 1을 처리합니다.
• 두 번째 match 블록: 헤더와 URI 조건이 AND로 묶여 케이스 2를 처리합니다.
• 두 match 블록의 관계: 이 두 블록은 OR 관계로 연결되어, 들어온 요청이 케이스 1 또는 케이스 2에 해당하면 admin-panel-v2로 라우팅됩니다.

✅ 결론

이제 Istio의 트래픽 매칭 규칙이 어떻게 동작하는지 명확해졌을 겁니다.

• AND 🔗: 하나의 match 블록 안에서 여러 조건을 사용할 때. "모든 조건을 만족해야 해!"
• OR 🔀: 여러 match 블록을 리스트로 나열할 때. "여러 조건 중 하나만 만족해도 돼!"

이 간단하지만 강력한 원리를 이해하는 것이야말로, Istio를 활용한 정교하고 안정적인 트래픽 관리의 첫걸음입니다. 더 이상 예상치 못한 라우팅 오류로 시간을 낭비하지 마시고, AND와 OR 논리를 자유자재로 활용하여 서비스 메시를 완벽하게 제어해보세요!