makgol's note – 기초·요청 경로

서비스 메시와 Istio 기초

Sat, 01 Aug 2026 00:00:00 +0900

01 · 서비스 메시와 Istio 기초 — 왜 EKS에 메시를 얹나

서비스 메시 = 데이터 플레인(파드마다 붙는 Envoy 사이드카) + 컨트롤 플레인(istiod). 이 분리가 챕터 전체의 뼈대입니다.
사이드카는 iptables로 트래픽을 가로채 앱 코드를 그대로 둔 채 mTLS·라우팅·재시도·관측성을 더합니다.
메시는 공짜가 아닙니다 — 프록시 오버헤드·컨트롤 플레인 부하·설정 복잡도·디버깅 난이도라는 네 비용을 집니다.
Ambient 모드(사이드카리스, ztunnel+waypoint)는 이 비용을 줄이려는 후속 설계지만, 이 챕터는 사이드카 모드 운영을 전제로 합니다.

02~05는 메시를 운영하며 겪은 사건의 기록입니다. 그 기록이 읽히려면 메시가 무엇으로 이뤄져 있고 그 대가가 무엇인지를 먼저 잡아야 합니다. 이 문서는 서비스 메시의 두 축(데이터 플레인·컨트롤 플레인), 메시가 해주는 것, 그 비용을 다룹니다.

요청 경로 해부

Sat, 01 Aug 2026 00:00:00 +0900

11 · 요청 경로 해부 — 요청 하나가 지나는 길과, 그 길을 만드는 배선

istiod는 요청 경로 위에 없습니다. 파드 안의 istio-agent가 부트스트랩·인증서·xDS를 모두 중계하고 Envoy는 istiod에 직접 연결하지 않습니다.
남북 경로에서 클라우드 LB는 L4로만 넘깁니다. 요청이 처음 L7이 되는 곳은 게이트웨이 Envoy이고 거기서 TLS가 끝나고 VirtualService 라우트가 걸립니다.
동서 경로는 iptables가 아웃바운드를 :15001, 인바운드를 :15006으로 꺾습니다. 프로토콜을 판별하지 못하면 평문 TCP로 취급되어 L7 기능이 통째로 사라집니다.
L7 파싱 지점이 곧 메트릭·재시도·라우팅이 생기는 지점입니다. 게이트웨이를 경유하는 메시 내부 호출이면 한 요청에 그런 곳이 세 곳 생깁니다.
게이트웨이와 사이드카는 같은 부품입니다 — 같은 Envoy, 같은 istio-agent, 같은 포트 규약.

01은 메시가 두 평면으로 갈린다는 것을, 02는 istiod가 왜 CPU를 먹는지를, 03은 게이트웨이를 왜 노드로 격리하는지를 다뤘습니다. 셋 다 맞는 얘기지만 따로 읽으면 **“그래서 요청 하나가 실제로 어디를 지나는가”**가 남지 않습니다. 이 문서는 그 조각들을 클라이언트에서 앱까지의 경로라는 하나의 축 위에 다시 배치합니다. 각 조각의 깊은 설명은 해당 문서로 넘기고 여기서는 경로와 접점만 봅니다.

Envoy가 제공하는 것

Sat, 01 Aug 2026 00:00:00 +0900

12 · Envoy가 제공하는 것 — Istio를 걷어내고 프록시 하나만 본다

Envoy는 앱에 링크되는 라이브러리가 아니라 앱 옆에서 따로 도는 프로세스입니다. 그래서 언어를 가리지 않습니다. 공식 홈페이지의 자기 정의가 “universal data plane"입니다.
코어는 L3/L4 프록시 + 꽂아 넣는 필터 체인이고 HTTP는 그 위에 놓인 L7 필터 레이어입니다. 모델은 listener → 필터 체인 → route → cluster → endpoint 하나로 끝납니다.
재시도·서킷 브레이킹·아웃라이어 감지·헬스체크·로드밸런싱은 전부 Envoy에 이미 있는 기능입니다. Istio CRD는 그 스위치를 밖으로 꺼낸 창구입니다.
관측성 세 축도 Envoy가 생산합니다. 특히 트레이싱에서 Envoy는 헤더만 넘기는 게 아니라 스팬을 직접 만들어 수집기로 보냅니다.
xDS는 Envoy 프로젝트가 정의한 API이고 istiod는 그 관리 서버 구현 중 하나입니다.

지금까지 이 챕터에서 Envoy는 늘 Istio의 부품이었습니다. 01에서는 파드에 붙는 사이드카였습니다. 02에서는 xDS를 받아가는 대상이었고 08에서는 EnvoyFilter가 패치하는 설정 덩어리였습니다. 이 문서는 그 방향을 뒤집습니다 — Istio를 걷어낸 Envoy 자체의 기능 카탈로그, 즉 조립되기 전의 부품이 원래 무엇을 할 수 있는가입니다. 조립 이야기는 13으로 넘깁니다.

Istio의 Envoy 조립

Sat, 01 Aug 2026 00:00:00 +0900

13 · Istio의 Envoy 조립 — proxyv2 이미지부터 CRD 번역까지

proxyv2에는 바이너리가 둘 들어 있고(Envoy · pilot-agent), 그 Envoy조차 upstream 그대로가 아닙니다 — istio/proxy가 확장을 함께 컴파일해 만든 빌드입니다.
istio_requests_total과 source_*/destination_* 라벨은 프록시 안에 컴파일된 확장이 만듭니다. 컨트롤 플레인은 관여하지 않습니다. Mixer가 사라졌다는 말의 실질이 여기 있습니다.
CRD는 xDS 리소스로 번역됩니다 — VirtualService→route, DestinationRule→cluster, Gateway→listener. 번역 결과는 추측하지 말고 istioctl proxy-config로 봅니다.
Istio 빌드는 Envoy의 특정 커밋에 pin됩니다. 사이드카 업그레이드가 곧 Envoy 업그레이드입니다. 그 버전은 릴리스 노트가 아니라 파드에 물어봐야 압니다.
이미지에 박힌 내장 확장과 CRD로 추가하는 사용자 확장(08)은 바꾸는 방법이 다릅니다. 전자는 이미지 교체로만, 후자는 설정으로.

“Istio는 Envoy를 쓴다"는 문장은 어디에나 있지만 ‘쓴다’가 무엇인지는 잘 안 적혀 있습니다. 12가 Envoy 자체의 능력을 훑었다면, 이 문서는 그 위에 Istio가 무엇을 더했는지를 봅니다. 층이 둘입니다. 아래층은 컴파일 시점 — Istio는 upstream Envoy 바이너리를 받아 쓰지 않고 자기 확장을 넣어 다시 빌드합니다. 위층은 런타임 — istiod가 CRD를 Envoy 설정으로 번역해 xDS로 내려보냅니다.

왜 서비스 메시인가

Sat, 01 Aug 2026 00:00:00 +0900

14 · 왜 서비스 메시인가 — 대안 스펙트럼과 손익 분석

고를 것은 기능이 아니라 배치입니다 — 재시도·타임아웃·mTLS·관측이라는 공통 관심사를 앱 안에 둘 것인가, 앱 밖 프록시에 둘 것인가, 그 프록시를 파드마다 둘 것인가 노드마다 둘 것인가.
후보는 넷(라이브러리 · 게이트웨이만 · 사이드카 메시 · ambient)이고 넷을 구분하는 축도 넷입니다: 커버 범위 · 언어 의존 · 업그레이드 결합 · 운영 비용.
메시가 이기는 조건은 서비스 수 × 언어 수가 크고 정책을 일괄로 바꿔야 할 때입니다. 우리 챕터에서 그 증거는 [06]·[07]·[05]에 실물로 남아 있습니다.
청구서에는 공식 수치가 있습니다 — 벤치마크 조건에서 사이드카 하나가 약 0.20 vCPU · 60 MB, 그리고 데이터 경로에 프록시가 붙는 만큼의 지연.
메시는 재시도·서킷브레이커까지 대신해주지만 폴백은 앱 몫입니다. 이 경계는 공식 문서가 직접 명시합니다.

이 문서의 자리를 먼저 짚습니다. 01 메시 기초가 답한 질문은 메시가 무엇으로 이뤄져 있고 그 대가가 무엇인지였습니다 — 두 개의 플레인, iptables 가로채기, 네 가지 비용. 그건 메커니즘입니다. 이 문서는 그 앞에 오는 질문을 다룹니다: 같은 문제를 푸는 다른 방법과 비교했을 때 메시가 이기는 조건은 무엇이고 지는 조건은 무엇인가. 01과 겹치는 서술은 링크로 넘기고 여기서는 판단에 필요한 것만 봅니다.