서비스 메시(Service Mesh) 도입의 그림자: Istio 사이드카 프록시의 네트워크 지연 오버헤드와 대응 전략

사내 100개가 넘는 쿠버네티스 마이크로서비스들의 결합도를 낮추기 위해 수조 원 단위의 트랜잭션 망에 과감히 Istio 서비스 메시(Service Mesh)를 덧씌운 적이 있습니다. 네트워크 프록시를 애플리케이션 외부로 분리하는 이 아름다운 아키텍처는 논리적으로 완벽했지만, 물리적으로는 악몽을 선사했습니다. 기존 A 서비스가 B 서비스를 직접 찌르던 1-Hop 통신이 사이드카(Sidecar) 모드에서는 A → Envoy (A의 꼬리) → Envoy (B의 꼬리) → B로 이어지는 3-Hop으로 극단적 파편화를 겪게 됩니다. 단순히 홉 수가 늘어난 것이 문제가 아니라, 유저 모드의 iptables 트래픽 리다이렉션으로 인해 커널 스택을 타는 오버헤드가 눈에 띄게 격화되었습니다. p99 응답 지연 시간(Tail Latency)이 순식간에 20ms 이상 튀면서 민감한 트레이딩 API의 타임아웃 레이트가 치솟았습니다. 네트워크 계층의 암호화(mTLS)와 다이내믹 라우팅이라는 혜택의 대가로 시스템의 물리적 속도를 처참하게 지불해야 했던 것입니다. 이를 극복하기 위해 컨트롤 플레인(Control Plane)의 설정 최적화에 착수했습니다. Envoy 프록시가 들고 있는 '전체 클러스터 엔드포인트 테이블' 크기를 Sidecar 리소스를 통해 무식한 전체 맵핑에서 해당 서비스가 실제로 호출하는 관련 목적지들로만 축소(Pruning)시켜 메타데이터 파싱 스루풋을 확보했습니다. 궁극적으로는 eBPF 기술을 결합하여 컨테이너 네임스페이스 간의 iptables 커널 릴레이를 바이패스하는 연구를 진행하게 되었고, 마이크로서비스 추상화의 이면에는 가시화되지 않은 거대한 인프라 세금(Tax)이 강제로 부과됨을 처절하게 실감했습니다.