결정 브리프(초안) — egress(L4)×GSLB 검증: 세션 단절은 기우였고, 그래도 STRICT를 쓰는 이유

1. 우리 환경

flowchart LR
    APP["client app<br/>HTTPS를 직접 맺음"] --> SC["sidecar<br/>암호화된 바이트만 통과"]
    SC --> GW["egress gateway<br/>SNI만 보고 통과 - L4"]
    GW --> VA["VIP-A"]
    GW -.-> VB["VIP-B"]
    DNS["GSLB DNS<br/>리전 VIP 로드밸런싱<br/>+ 장애/점검 시 절체"] -.->|"IP 목록 갱신"| GW

앱이 TLS를 직접 맺으므로 sidecar와 egress gateway는 HTTP 요청/응답을 볼 수 없고 암호화된 바이트를 나르기만 한다(L4). 이 사실이 이 문서 전체를 지배한다 — Envoy가 HTTP 요청 단위로 개입하는 기능(요청 재시도 등)은 이 경로에 없다.

ServiceEntry.resolution은 “Envoy가 이 도메인의 IP 목록을 어떻게 관리하는가"를 정한다:

2. 걱정 1 — “GSLB가 IP를 바꾸면 기존 세션이 끊긴다?” → 기우로 확인

걱정의 논리는 이랬다: “STRICT는 DNS가 갱신되면 IP 목록을 즉시 교체한다니까, 그 순간 그 IP로 통신 중이던 연결도 끊길 것이다.” 두 방향에서 검증했다.

공식 문서 — Envoy service discovery의 STRICT_DNS 원문은 “will drain traffic from any existing connection pools"다. drain은 “지금 하는 일은 끝내게 두고 새 일만 안 준다"는 뜻이지, 끊는다(close)가 아니다. “IP가 바뀌면 기존 연결을 즉시 정리"는 오히려 일부러 켜야 하는 별도 옵션으로 존재한다 (close_connections_on_host_set_change, 기본 false). 기본이 즉시 정리라면 이 옵션이 있을 이유가 없다.

실측 — 40초짜리 응답을 받는 도중에 A레코드를 바꾸고 Envoy 카운터를 4개 시점에서 찍었다:

sequenceDiagram
    participant C as client (curl)
    participant E as Envoy (L4)
    participant A as server A (기존 IP)
    participant D as GSLB DNS
    C->>E: HTTPS 요청 (40초짜리 응답)
    E->>A: TCP 연결, 스트리밍 시작
    Note over D: +5초 - A레코드를 B로 변경
    D-->>E: 백그라운드 갱신 - IP 목록은 B로
    Note over E,A: 기존 연결은 그대로 둠
    A-->>C: 스트리밍 계속
    A-->>C: +40초 - 409,610바이트 전량 수신, HTTP 200

IP 목록이 B로 바뀐 뒤에도 기존 연결은 살아서 스트리밍을 계속했고, 연결이 닫힌 것은 요청을 마친 클라이언트가 닫은 시점이다. STRICT/LOGICAL 양쪽, 그리고 sidecar가 TLS를 대신 맺는 L7 경로까지 4가지 조합 전부에서 진행 중 요청은 완주했다(원표는 Q&A 문서의 실측 부록). 결론: “세션 끊김” 걱정으로 resolution을 고를 필요가 없다 — 어느 쪽도 안 끊는다.

3. 그럼 왜 STRICT인가 — 세션이 아니라 “장애 때 작동하는 장치” 때문

세션에 차이가 없다면 무엇으로 고르는가. 먼저 오해 하나를 제거하자:

로드밸런싱 동작은 두 설정이 사실상 같다. Envoy는 어느 쪽이든 DNS를 백그라운드 주기 (TTL, 수 초~수십 초)로만 갱신하므로, 한 주기 안의 새 연결은 전부 같은 응답 결과로 간다. GSLB의 “질의당 분산"은 양쪽 모두 이 주기 단위로 뭉개진다 — LOGICAL을 골라도 더 고운 분산을 얻지 못한다. (egress gateway 인스턴스가 여러 개면 각자 다른 시점에 갱신하므로 전체 분포는 평균화된다.) (메커니즘 추론 — 갱신 주기 동작은 공식 문서 기반, 분산 양자화 자체의 실측은 없음)

같은 동작이라면, 남는 차이 3가지가 결정한다:

STRICT의 유일한 비용(DNS가 바뀔 때마다 목록이 바뀌면서 놀고 있는 연결이 정리되는 것)은 L4인 우리 환경에서는 발생하지 않는다 — 기존 연결을 아예 안 건드리기 때문(2절 실측). 즉 잃는 것 없이 장애 대응 장치와 미래 호환성을 얻는 선택이다.

참고 — LOGICAL이 맞는 자리는 따로 있다: 판별 질문은 “응답에서 IP가 빠졌을 때 그 빠짐에 의미가 있는가"다. 사내 GSLB는 VIP 몇 개짜리 작은 고정 풀이고 빠짐 = 의도(장애·점검·절체)라서 그 의미를 목록에 반영하는 STRICT가 맞다. 반면 수백 IP 풀에서 매번 일부만 잘라 보여주는 대형 SaaS/CDN은 빠짐에 아무 의미가 없어서(빠진 IP도 멀쩡) 목록을 안 만드는 LOGICAL이 맞다 — “질의마다 응답이 다르다"는 사실 자체는 기준이 아니다.

4. 절체가 일어나면 실제로 벌어지는 일

절체의 이유에 따라 완전히 다른 두 상황이 된다.

계획 절체 (점검 배수 — 옛 VIP가 살아있는 상태) → 무손실 가능

t=0      GSLB가 A레코드를 VIP-A -> VIP-B로 변경
t+TTL    Envoy IP 목록 = [B]
         - 진행 중이던 요청      : 그대로 완료                    (실측)
         - 새 연결              : B로                            (실측)
         - 앱이 keepalive로 쥔
           기존 연결            : 계속 A로                       (추론, 미실측)
           ... 앱 커넥션 수명이 다해 새로 맺을 때 B로

무손실이다. 단 “옛 VIP가 조용해지는 시간"은 Istio가 아니라 앱의 커넥션 수명이 결정한다 — L4에서는 요청이 끝나도 Envoy가 연결을 회수하지 않으므로. 절체 runbook에 필요한 것:

1. flip 후 옛 VIP를 앱 커넥션 최대 수명만큼 살려둘 것 (바로 내리면 아래 장애 절체가 됨)
2. 앱 커넥션 풀의 max lifetime 상한 합의 (절체 완료 목표 시간보다 짧게)
3. 배수 완료 판단은 DNS가 아니라 옛 VIP의 연결 수 모니터링으로

장애 절체 (VIP 사망 → GSLB가 감지 후 변경) → 유손실 구간이 구조적으로 존재

t=0      VIP-A 사망
         - A 위의 연결/진행 중 요청 : 실패가 앱까지 전달 (서버가 죽은 것이므로 당연)
t=0~W    새 연결이 아직 목록에 있는 A를 집으면 : 연결 실패가 앱까지 전달
         W = min( GSLB 감지 + TTL + Envoy 갱신 ,  outlier 격리 ~수 초 )
t>W      목록 = [B], 정상

주의: 2절의 “세션 안 끊김"은 IP 변경 때문에는 안 끊긴다는 뜻이다. 서버가 죽으면 그 위의 요청은 당연히 죽고, L4에서는 Envoy가 이 실패를 앱 대신 흡수하지 못한다(실측: 완화 없이 요청 44%가 실패로 앱 도달). 유손실 구간 W를 줄이는 3중 완화가 실측으로 검증돼 있다:

• outlier detection — 연속 연결 실패 3회면 그 VIP를 목록에서 일시 제외 (실패율 1/250로)
• 짧은 connect timeout (1초) — 죽은 IP를 만나도 빨리 실패하고 넘어가게
• 앱의 연결 실패 한정 재시도 1~2회 — 격리되기 전의 첫 실패들을 흡수. 연결 실패는 요청이 서버에 닿기 전의 실패라 중복 실행 걱정 없이 재시도해도 안전

5. outlier detection이 하는 일과 안 하는 일

사내 공유 때 반드시 나올 질문: “outlier가 되면 뭐가 되는데? 실패하면 DNS 질의를 다시 하나?”

아니다 — DNS와 outlier는 서로를 호출하지 않는 별개의 장치다. 둘 다 같은 IP 목록을 만지되 역할이 다르다:

outlier가 하는 일: 어떤 VIP로의 연결 실패가 연속 3회 쌓이면, 그 VIP를 목록에서 지우는 게 아니라 “일시 제외” 표시를 한다(우리 설정 기준 30초, 반복되면 제외 시간이 늘어난다). 그동안 새 연결은 목록에 남은 다른 VIP로만 간다. 제외 시간이 지나면 다시 후보에 넣어 살아났는지 자연스럽게 확인된다.

outlier가 안 하는 일 세 가지:

1. DNS 재질의를 유발하지 않는다. DNS 갱신은 자기 주기로만 돈다. outlier는 그 주기 사이의 공백(“GSLB는 아직 모르는 죽은 VIP”)을 메우는 장치다.
2. 이미 실패한 요청을 살려내지 못한다. 격리는 다음 연결부터의 예방이다. 첫 1~3건의 실패는 앱에 도달한다 — 그걸 흡수하는 것이 앱 재시도의 몫이다.
3. 목록에 대안이 없으면 우회시킬 곳도 없다. GSLB가 A레코드를 하나만 반환하는 순간의 목록은 VIP 1개다 — 그게 죽어 있으면 outlier로도 갈 곳이 없고, 복구는 DNS 갱신(TTL)을 기다려야 한다. outlier의 효과는 목록에 살아있는 대안이 있을 때 성립한다 — 우리 실측 (51.7%→0.21%)도 목록에 정상 endpoint가 함께 있던 조건이다. GSLB가 복수 A레코드를 반환하게 할 수 있다면 이 장치의 가치가 온전해진다 (STRICT만 복수 A를 수용한다는 3절과 연결되는 지점).

6. 전체 설정 예시

권장 세트 (우리 환경: 앱 HTTPS + L4 passthrough)

# 외부 도메인 등록 — resolution: DNS(STRICT)
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: partner-api
spec:
  hosts: ["api.partner.example"]        # GSLB가 리전 VIP를 로드밸런싱하는 외부 도메인
  location: MESH_EXTERNAL
  resolution: DNS                        # STRICT_DNS: DNS 응답 = IP 목록
  ports:
    - number: 443
      name: tls
      protocol: TLS                      # 앱이 직접 TLS를 맺음 → Envoy는 통과만(L4)
---
# 죽은 VIP 자동 격리 — 실측에서 실패율 51.7% → 0.21%를 만든 설정
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: partner-api-outlier
spec:
  host: api.partner.example
  trafficPolicy:
    connectionPool:
      tcp:
        connectTimeout: 1s               # 죽은 IP의 연결 실패를 1초 안에 판정
    outlierDetection:
      splitExternalLocalOriginErrors: true
      consecutiveLocalOriginFailures: 3  # 연결 실패(연속 3회)면
      interval: 5s                       # 5초마다 판정해서
      baseEjectionTime: 30s              # 그 VIP를 30초간 목록에서 일시 제외
      maxEjectionPercent: 50             # 단 목록의 절반까지만 (전멸 방지)
      minHealthPercent: 0

앱 팀에 요청할 두 가지: ① 연결 실패(connect timeout/reset) 한정 재시도 12회 + connect timeout 13초, ② 커넥션 풀 max lifetime을 절체 완료 목표 시간 이하로.

안티 예시 두 가지

# (1) GSLB 도메인에 LOGICAL — 쓰지 않는다
spec:
  resolution: DNS_ROUND_ROBIN   # outlier 무력 + 복수 A레코드에서 설정 거부 + 관측 어긋남

# (2) L7 경로(원격 TLS를 sidecar가 대신 맺는 팀)에서 기본 재시도 끄기 — 쓰지 않는다
http:
  - retries:
      attempts: 0   # Istio가 기본 탑재한 "연결 실패 시 다른 IP로 재시도"가 꺼진다

(L7 경로 팀 참고: Istio는 VS에 retries를 안 쓰면 “연결 실패 → 다른 IP로 최대 2회 재시도"를 자동 적용한다 — 같은 실측에서 L7이 86/86 무손실이었던 이유. 또 DR에서 포트별 portLevelSettings를 쓰면 outlier도 반드시 그 안에 넣어야 적용된다.)

7. 운영 시 주의

• 연결 정리 상태를 endpoint 목록으로 판단하지 말 것. 목록에서 제거된 VIP에 아직 살아있는 연결은 istioctl proxy-config endpoints에 보이지 않는다(cluster 합계 upstream_cx_active 카운터로만 보임). 실측으로 확인된 관측 사각지대.
• 미실측 범위: ① 계획 절체에서 “앱이 쥔 keepalive 연결이 옛 VIP에 남는다"는 메커니즘 추론 (실측은 40초 단일 요청 생존까지), ② 수 분급 초장기 스트림의 drain 동작, ③ HTTP/2 경로. 해당 워크로드 적용 전 추가 확인 필요.

8. 근거 자료 (읽는 순서)

1. Q&A — GSLB가 IP를 바꾸면 내 요청은 어떻게 되나 — 쉬운 입구 + 실측 부록(모든 원본 수치)
2. SE resolution × TLS passthrough — in-flight 요청의 운명 — 4조합 정밀 비교 + 공식 문서 대조
3. DNS/GSLB resolution 재현 랩 — 직접 재현 가능한 절차·킷
4. ServiceEntry resolution 이론 runbook — 필드 정본 (초기 권장이 뒤집힌 교정 이력 포함)
5. 공식 문서: Envoy — Service discovery · cluster.proto — CommonLbConfig
6. 원시 리포트·manifest·재현 스크립트: files.homelab89.com/istio-egress/dns-resolution/