Istio ServiceEntry 자동생성으로 외부 트래픽 가시화하기 (SRE 밋업 4회)

주요 구간

• 01:30 Istio의 서비스 레지스트리
• 04:00 문제 정의
• 06:00 L4와 L7, SNI, TLS origination
• 13:00 주요 도메인 ServiceEntry 수동 생성
• 15:00 CoreDNS 로그를 메트릭으로
• 17:30 CronJob 구현과 한계

외부 호출에서 보이지 않던 것

당근은 AI 서비스가 늘며 외부 호출이 급증했지만, 서비스별 OpenAI 사용량이나 지연이 외부 호출 때문인지는 확인할 수 없었습니다. 메시 내부 트래픽은 사이드카의 L7 메트릭(istio_requests_total 등)으로 자세히 보였습니다. Istio가 제어하는 범위는 서비스 레지스트리에 등록된 대상뿐입니다. OpenAI나 Google API 같은 외부 도메인은 그냥 통과(PassThrough)해 메트릭이 남지 않았습니다.

L4 관측을 선택하고 ServiceEntry 생성을 자동화

L7까지 보려면 앱이 평문 HTTP로 요청하고 DestinationRule을 설정해 Istio가 TLS를 대신 처리해야 합니다. 당근은 언어와 SDK가 다양하고 코드 변경 때마다 SRE가 Istio 리소스를 관리해야 하는 부담을 고려해, 코드 수정 없이 L4(TCP 연결 단위)만 확보하기로 했습니다. 외부 호스트를 ServiceEntry로 등록하면 Istio가 대상을 인식합니다. HTTPS는 암호화되어 사이드카가 읽을 수 있는 정보가 TLS 핸드셰이크의 SNI뿐이므로, 관측 범위는 L4까지입니다.

Google API, AWS, OpenAI, Pinecone 네 도메인을 수동으로 등록해 TCP 메트릭을 확인한 뒤, 모든 외부 호출을 다루도록 생성을 자동화했습니다. 호출 도메인을 찾을 자료로는 CoreDNS 로그를 골랐습니다. 모든 Pod가 외부 통신 전에 DNS를 질의하기 때문입니다.

CoreDNS 로그는 형식을 간소화한 뒤 Alloy로 Loki에 보내고, recording rule로 메트릭화해 Thanos에 저장합니다. PromQL에서 소스 IP를 네임스페이스·Pod와 조인하면 네임스페이스별 외부 도메인 목록을 얻습니다. 이 목록을 읽는 Go CronJob은 사이드카가 주입된 네임스페이스를 찾고 메시 내부 주소를 제외한 뒤, 기존 ServiceEntry를 확인해 생성하거나 갱신하도록 구현했습니다.

실시간 처리가 필요하지 않았던 이유는 목적이 제어보다 가시성 확보에 있었기 때문입니다. 새 도메인이 자주 생기지 않았고, istiod와 Thanos의 부하도 줄여야 했습니다.

확보한 가시성

당근은 아웃바운드 HTTPS 트래픽을 서비스별 TCP 메트릭과 response flag로 확인할 수 있게 되었습니다. TCP connection close 메트릭으로는 외부 연결이 끊길 때 알림을 만들 수 있습니다. 발표에 제시된 정량 수치는 거의 없습니다.

관측 한계와 적용 시 주의점

SNI가 있는 트래픽만 볼 수 있습니다. Redis나 MySQL처럼 SNI가 없는 프로토콜은 도메인을 구분할 수 없어, 요청량이 가장 많은 데이터베이스 계열 트래픽은 아직 가시화하지 못했습니다. CoreDNS 로그에는 포트와 프로토콜 정보도 없습니다.

적용 과정에서는 네임스페이스 수백 개와 호스트 수천 개를 한꺼번에 처리할 때 istiod에 생기는 부담을 줄이려고 나눠서 순차 적용했습니다. 다음 과제로 제시한 내용은 비용 추적, 외부 API 급증 대응, DB를 포함한 모든 외부 트래픽의 가시화입니다.

2026년 3월 장애와의 관계는 옵저버빌리티 발표 요약에서 다룹니다. 그 발표는 ServiceEntry 자동 관리 로직의 방어 로직 오류를 장애 원인으로 들었습니다. 이 영상의 CronJob과 같은 컴포넌트인지는 영상에서 확인되지 않습니다.

이 사이트의 관련 문서: Istio