Istio 서비스 메쉬, 똑똑한 Envoy 프록시의 귀는 대체 몇 개일까? 🧐

마이크로서비스 아키텍처(MSA)의 복잡한 통신을 관리하기 위해 Istio를 사용하고 계신가요? 그렇다면 모든 트래픽을 처리하는 핵심 일꾼, Envoy 프록시에 대해 들어보셨을 겁니다. 모든 서비스 컨테이너 옆에 바싹 붙어 다니는 이 똑똑한 사이드카(Sidecar)는 어떻게 모든 종류의 트래픽을 마법처럼 처리하는 걸까요?

 

혹시 "하나의 프록시니까, 당연히 하나의 통로(포트)로 모든 걸 듣고 처리하겠지?" 라고 생각하셨나요? 🤔

오늘은 이 흔한 오해를 바로잡고, Envoy 프록시가 얼마나 정교하고 효율적으로 통신을 관리하는지 그 비밀을 파헤쳐 보겠습니다.

---

하나의 프록시, 하나의 리스너? 🤔 오해와 진실

결론부터 말씀드리면, Envoy 프록시는 절대로 단 하나의 '귀(Listener)'만 가지고 있지 않습니다. 오히려 여러 개의 리스너를 갖는 것이 일반적이며, 이것이 바로 Istio가 강력한 기능을 제공할 수 있는 핵심 비결 중 하나입니다.

마치 한 명의 경비원이 여러 개의 문(Gate)을 동시에 감시하며 각기 다른 목적의 방문객을 처리하는 것과 같습니다. 🚪

• 문 A: 직원 전용 (내부 서비스 간 통신)
• 문 B: 외부 방문객 전용 (외부에서 들어오는 통신)
• 문 C: 화물 전용 (특별한 목적의 통신)

Envoy의 리스너도 이와 비슷합니다. 각 리스너는 특정 IP 주소와 포트 조합에 바인딩되어, 정해진 목적의 트래픽을 전문적으로 처리할 준비를 하고 있죠.

왜 여러 개의 리스너가 필요할까? 🚦

Envoy가 여러 개의 리스너를 사용하는 이유는 명확합니다. 바로 트래픽의 '종류'와 '방향'에 따라 각기 다른 정책과 규칙을 적용하기 위해서입니다.

1. 인바운드 트래픽 (Inbound Traffic) 📥

다른 서비스에서 내 서비스로 들어오는 모든 트래픽을 의미합니다.

• 역할: Envoy는 내 애플리케이션 컨테이너로 들어오는 요청을 가로챕니다.
• 리스너: 이 트래픽을 처리하기 위한 전용 리스너가 존재합니다. 예를 들어, 서비스가 8080 포트를 사용한다면, Envoy는 이 포트로 오는 트래픽을 감지하고 mTLS 암호화 해제, 인가 정책(Authorization Policy) 적용, 각종 메트릭 수집과 같은 작업을 수행한 후, 안전하게 애플리케이션으로 전달합니다.

2. 아웃바운드 트래픽 (Outbound Traffic) 📤

내 서비스가 다른 서비스를 호출할 때 발생하는 트래픽입니다.

• 역할: 애플리케이션이 외부로 보내는 모든 요청을 가로챕니다.
• 리스너: Istio는 여기서 아주 영리한 방법을 사용합니다. 바로 **'가상 리스너(Virtual Listener)'**입니다. 0.0.0.0:15001 포트에서 동작하는 이 특별한 리스너는 모든 아웃바운드 트래픽을 일단 전부 받아들입니다. 그리고 나서 요청의 목적지(Host, Port)를 확인하고, Istio 제어 플레인(Control Plane)에서 받아온 서비스 디스커버리 정보를 바탕으로 가장 적절한 클러스터(대상 서비스)로 트래픽을 라우팅합니다. 이 과정에서 mTLS 암호화, 재시도(Retry), 서킷 브레이커(Circuit Breaker)와 같은 규칙들이 적용됩니다.

3. 기타 특수 목적 리스너 📈

인바운드, 아웃바운드 외에도 Envoy는 다양한 목적을 위해 추가적인 리스너를 가집니다.

• 관리 및 모니터링: Prometheus가 메트릭을 수집해갈 수 있도록 /stats/prometheus 엔드포인트를 노출하는 리스너 (예: 15090 포트)
• 상태 확인(Health Check): Istio가 Envoy 프록시 자체의 상태를 확인할 수 있도록 하는 리스너

실제 Envoy 설정 들여다보기: "백문이 불여일견" 💻

말로만 설명하면 감이 잘 안 오시죠? istioctl 명령어를 통해 실제 Pod에 주입된 Envoy 프록시의 리스너 구성을 직접 확인해 보겠습니다.

아래는 productpage라는 이름의 Pod에 설정된 Envoy 리스너 목록의 일부를 간략화한 예시입니다.

# istioctl proxy-config listeners productpage-v1-xxxxxxxxxx-xxxxx -n default

ADDRESS             PORT      TYPE        MATCH                                    DESTINATION
0.0.0.0             15001     TCP         ALL                                      Route: 15001
0.0.0.0             15006     TCP         ALL                                      Route: 15006
0.0.0.0             15090     HTTP        ALL                                      Route: 15090
...
#  모든 아웃바운드 트래픽을 처리하는 가상 리스너
127.0.0.1           15001     HTTP        ALL                                      PassthroughCluster
...
# productpage 서비스(9080 포트)로 들어오는 인바운드 트래픽 리스너
10.4.1.23           9080      HTTP        ALL                                      Route: inbound|9080||
...
# reviews 서비스로 보내는 아웃바운드 트래픽을 위한 가상 인바운드 리스너
0.0.0.0             9080      HTTP        Transferred from 0.0.0.0:15001           Cluster: outbound|9080||reviews.default.svc.cluster.local

코드 해설:

• 0.0.0.0:15001: 바로 위에서 설명한 아웃바운드 가상 리스너입니다. 모든 나가는 트래픽이 이 리스너를 통해 가로채집니다.
• 10.4.1.23:9080: productpage 서비스의 Pod IP와 서비스 포트(9080)에 바인딩된 인바운드 리스너입니다. 외부에서 productpage를 호출하면 이 리스너가 트래픽을 수신합니다.
• 0.0.0.0:15090: Prometheus 메트릭 수집을 위한 리스너입니다. http://<POD_IP>:15090/stats/prometheus로 접근하면 Envoy의 다양한 통계 정보를 확인할 수 있습니다.
• 0.0.0.0:9080: Transferred from 0.0.0.0:15001 라는 설명이 보이시나요? 이는 reviews 서비스(마찬가지로 9080 포트 사용)로 나가는 트래픽이 15001 가상 리스너에 잡힌 후, 실제 목적지인 reviews 서비스로 라우팅되기 위해 내부적으로 사용되는 리스너 체인 중 일부입니다.

---

결론: 다재다능한 트래픽 지휘자, Envoy 🚀

이제 Envoy 프록시가 단 하나의 귀가 아닌, 여러 개의 전문화된 귀를 가진 정교한 트래픽 지휘자라는 사실을 이해하셨을 겁니다.

• 인바운드 리스너는 우리 집을 지키는 든든한 문지기처럼 들어오는 트래픽을 검사하고 보호합니다.
• 아웃바운드 가상 리스너는 모든 외부 요청을 일단 받아 똑똑하게 길을 찾아주는 만능 안내원 역할을 합니다.
• 그 외 특수 목적 리스너들은 프록시의 건강과 성과를 꾸준히 보고합니다.

이러한 다중 리스너 아키텍처 덕분에 Istio는 서비스 간의 통신을 투명하게 가로채고, mTLS, 트래픽 제어, 풍부한 관측 가능성(Observability)과 같은 강력한 기능들을 코드 수정 없이 제공할 수 있는 것입니다.

다음에 Istio 환경에서 네트워크 문제를 디버깅하거나 트래픽 흐름을 분석할 때, Envoy가 여러 개의 귀를 열고 열심히 일하고 있다는 사실을 기억해 주세요!