Service Mesh & Ingress Dynamics

1. Overview

서비스 메시와 인그레스 동학(Service Mesh & Ingress Dynamics)은 마이크로서비스가 100개로 쪼개지며 발생한 끔찍한 네트워크 지옥(추적 불가, 보안 붕괴, 통신 에러)을 비즈니스 로직(코드)에서 떼어내어, 인프라 계층으로 완전히 밀어버리는 현대 클라우드 네이티브의 궁극적 네트워크 방어망을 해부합니다.

학습자는 클러스터 밖에서 들어오는 무자비한 트래픽을 단일 진입점에서 통제하고 URL 경로(/api, /web)에 따라 우아하게 쪼개주는 **L7 인그레스(Ingress Controller)**의 라우팅 역학을 뜯어봅니다. 나아가 K8s 내부에서 서비스끼리 통신할 때 개발자가 일일이 서킷 브레이커와 인증 코드를 짜넣어야 하는 고통을 해결하기 위해, 애플리케이션 컨테이너 옆에 기생하는 프록시(Sidecar)를 붙여 네트워크 통제권을 탈취하는 **서비스 메시(Service Mesh, Istio)**의 사이드카 패턴(Sidecar Pattern)을 장악합니다. 마지막으로, 트래픽을 $1\%$만 흘려보내는 카나리(Canary) 배포와 모든 통신을 암호화하는 mTLS를 통해 마이크로서비스 네트워크를 지배하는 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Ingress Controller (L7 Edge): 외부 트래픽 수신, Host/Path 기반 라우팅, SSL/TLS Termination.
• Sidecar Pattern (사이드카 패턴): 애플리케이션 코드를 건드리지 않고 네트워크 기능(프록시)을 주입.
• Service Mesh (Istio / Linkerd): Control Plane(규칙 배포)과 Data Plane(Envoy 프록시 모음).
• Traffic Management: Canary Deployment(카나리 배포), Traffic Shadowing(미러링), mTLS (상호 인증).

Out-of-Scope

• API Gateway (Edge Logic): 비즈니스 레벨의 Rate Limiting, GraphQL 통합, JWT 토큰 검증 $\rightarrow$ 07-06-05 API Gateways 영역으로 위임 (Service Mesh는 '인프라/네트워크' 레벨의 통제에 집중).
• Service Mesh 도구 설치 명령어: Istio istioctl 설치 과정 $\rightarrow$ DevOps 매뉴얼 영역.

Boundaries

• Ingress vs Service Mesh: 인그레스(Ingress)는 "클러스터 외부에서 내부로 들어오는 문(North-South Traffic)"을 통제하는 경비원입니다. 서비스 메시(Service Mesh)는 "클러스터 내부에서 A 서비스와 B 서비스가 대화하는 흐름(East-West Traffic)"을 도청하고 제어하는 내부 통신망입니다. 인그레스로 내부 서비스 간 통신을 제어하려 하거나, 서비스 메시를 엣지 게이트웨이 없이 외부 노출용으로만 쓰는 것은 각 기술의 아키텍처적 역할을 오해한 치명적 결함임을 명확히 경계 짓습니다.

3. Counterexample

• 비즈니스 로직에 침투한 네트워크 코드: 100개의 마이크로서비스 팀이 있습니다. 통신 실패를 막기 위해 모든 팀이 각자의 언어(Java, Python, Go)로 Retry(재시도), Timeout(타임아웃), Circuit Breaker 라이브러리를 소스 코드 안에 덕지덕지 발라 넣었습니다. 나중에 전사 타임아웃 룰을 1초에서 3초로 바꾸려 하자 100개 팀이 코드를 다 고치고 재배포해야 하는 지옥이 열립니다. 네트워크 통신 로직을 비즈니스 로직(코드)에서 떼어내어 사이드카 프록시(Service Mesh)로 내리지 못한 분산 시스템의 기술 부채입니다.
• NodePort의 난립과 L4 라우팅의 한계: 클러스터 내부에 50개의 웹 서비스가 있습니다. 외부 노출을 위해 50개의 K8s Service(NodePort)를 뚫어, 유저가 IP:30001, IP:30002 포트 번호를 외우고 들어오게 만들었습니다. 보안팀은 50개의 포트가 열린 것을 보고 경악합니다. 단 1개의 포트(443)만 열어두고(Ingress), L7 계층에서 도메인 주소(Host)나 경로(Path)를 읽어 50개의 서비스로 우아하게 라우팅하는 Ingress Controller를 쓰지 않은 미개한 네트워킹입니다.

4. Prerequisites

• 쿠버네티스 네트워킹 (Basic): K8s Service (ClusterIP) 개념. (07-06-03 Kubernetes)
• L4 vs L7 라우팅 (Basic): HTTP 헤더와 URL을 읽어내는 애플리케이션 계층 지식. (03-03 Advanced Networking)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 클러스터의 단일 관문, Ingress Controller (L7 Edge)

• Why to Learn: K8s 내부의 서비스 수백 개를 외부로 노출할 때 포트를 수백 개 여는(NodePort) 미친 짓을 막고, 단 하나의 우아한 L7 라우터(문지기)를 세우기 위함입니다.
• What to Learn:
  • Concepts: Ingress vs NodePort/LoadBalancer, Ingress Controller (NGINX), L7 Routing (Host-based, Path-based), SSL/TLS Termination.
  • Skills: 도메인(Host)과 경로(Path)에 따라 트래픽을 서로 다른 K8s Service로 분배하는 Ingress YAML 작성.
• How to Learn:
  • 1단계: L4의 멍청함 (NodePort): L4 로드밸런서는 패킷의 IP와 포트만 봅니다. 유저가 들어오면 무식하게 Service A, Service B 포트로 연결만 해줍니다. 포트 번호가 3만 번대로 더러워지는 한계를 해부합니다.
  • 2단계: L7의 똑똑함 (Ingress): Ingress는 패킷의 내용(HTTP Header)을 뜯어봅니다. 유저가 443 포트로 들어왔더라도, example.com/api로 왔으면 Backend API Service로, example.com/blog로 왔으면 Frontend Web Service로 찢어주는 똑똑한 문지기 역할을 뜯어봅니다. 추가로 무거운 SSL 복호화(HTTPS)를 여기서 한 번에 처리(Termination)하여 내부 서비스의 CPU를 아껴줍니다.
• Implement: L7 라우터 시뮬레이션(CLI). [REQUEST] GET http://app.com/api/v1/users. Ingress 객체(라우터 스크립트)가 이 텍스트를 파싱하여, Host가 app.com이고 Path가 /api로 시작하므로 [ROUTING TO -> api-service:8080]을 콘솔에 출력. 만약 일치하는 룰이 없으면 404 Default Backend로 빠지는 로직 렌더링.

Recommended

Core Topic 02: 찰거머리 프록시, 사이드카 패턴 (The Sidecar Pattern)

• Why to Learn: MSA 환경에서 필요한 네트워크 로직(재시도, 타임아웃, 로깅)을 비즈니스 코드에 덕지덕지 짜 넣는 참사를 막고, 오직 인프라 레벨에서 프록시(Proxy)를 덧씌워 해결하기 위함입니다.
• What to Learn:
  • Concepts: Sidecar Pattern (사이드카 패턴), Proxy (Envoy), Separation of Concerns (관심사 분리), Transparent Interception (투명한 가로채기).
  • Skills: 애플리케이션 컨테이너와 동일한 Pod 안에 프록시 컨테이너를 함께 띄우고(공유 네트워크), 모든 트래픽을 프록시가 가로채도록 iptables 라우팅 설정.
• How to Learn:
  • 1단계: 개발자의 고통: 앱 개발자가 비즈니스 로직(결제)을 짜기도 바쁜데, "상대 서버가 죽으면 3번 재시도하는 코드 넣어라, 응답 지연 1초 넘으면 잘라라(Timeout)" 등 네트워크 방어 코드를 짜느라 야근하는 비효율을 해부합니다.
  • 2단계: 오토바이와 사이드카: K8s Pod 안에 결제 앱(오토바이) 옆에 작은 프록시 컨테이너(사이드카)를 몰래 끼워 넣습니다. 결제 앱이 바깥으로 API를 쏠 때, 커널(iptables)이 이 트래픽을 납치해서 사이드카(Envoy)로 보냅니다. 사이드카가 알아서 3번 재시도하고, 타임아웃 걸고, 실패하면 에러를 예쁘게 포장해서 돌려줍니다. 결제 앱은 자기가 사이드카와 통신하는 줄도 모르는 완벽한 관심사 분리를 뜯어봅니다.
• Implement: 트래픽 가로채기(Interception) 데모 스크립트. App은 무조건 http://target으로 GET 요청을 날림. 옆에 띄워둔 Sidecar(Python Proxy)가 이 포트(80)를 선점하여 트래픽을 대신 받음. Sidecar가 3번의 Retry 로직과 타임아웃(Timeout 1s)을 수행한 뒤, 진짜 타겟 시스템으로 쏘고 그 결과를 App에 돌려주는 래핑(Wrapping) 콘솔 렌더링.

Practical

Core Topic 03: 거미줄을 지배하는 뇌, 서비스 메시 (Service Mesh Architecture)

• Why to Learn: 사이드카 1개는 훌륭하지만, 마이크로서비스가 1,000개가 되면 사이드카 1,000개의 설정(Routing Rule)을 사람이 일일이 바꿀 수 없는 한계를 중앙 통제로 박살 내기 위함입니다.
• What to Learn:
  • Concepts: Service Mesh, Data Plane (Envoy Proxies), Control Plane (Istiod), East-West Traffic (내부 통신), Telemetry (원격 측정).
  • Skills: Istio Control Plane을 통해 수백 개의 Data Plane(사이드카)에 글로벌 타임아웃/라우팅 룰을 한 방에 배포(Inject)하기.
• How to Learn:
  • 1단계: 데이터 플레인 (근육): 클러스터 내부의 모든 트래픽(East-West)은 서비스 A의 사이드카에서 서비스 B의 사이드카로 곧바로 꽂힙니다. 이 거미줄 같은 프록시들의 연결망을 '서비스 메시'의 데이터 플레인이라고 부릅니다.
  • 2단계: 컨트롤 플레인 (뇌): "전사 모든 API 호출 타임아웃을 1초에서 2초로 바꿔." 이 명령을 사이드카 1,000개에 일일이 치는 대신, 중앙의 컨트롤 플레인(Istio)에 YAML을 딱 1번만 던집니다. Istio가 1,000개의 사이드카 설정 파일을 실시간으로 동시에 갈아 끼워 버리는 압도적인 인프라 지배력을 뜯어봅니다.
• Implement: Control Plane의 설정 전파(Propagation) 시뮬레이터. Proxy_A, Proxy_B, Proxy_C 인스턴스 실행 중 (모두 Timeout=1s 설정). ControlPlane 중앙 서버에 update_rule(Timeout=3s) 커맨드를 날리면, 3개의 Proxy가 비동기로 새 룰을 수신([ACK])하고 런타임 재시작 없이 메모리 상의 타임아웃 설정을 갈아 끼우는 분산 제어 터미널 애니메이션.

Advanced

Core Topic 04: 카나리 배포와 제로 트러스트 (Canary & Zero-Trust mTLS)

• Why to Learn: 서비스 메시가 장악한 네트워크 통제권을 활용하여, 코드를 배포할 때 유저의 $1\%$만 새 버전으로 흘려보내는 안전한 배포와 아무도 믿지 않는 강력한 보안망을 뚫어내기 위함입니다.
• What to Learn:
  • Concepts: Canary Deployment (카나리 배포), Traffic Shadowing (트래픽 미러링), mTLS (Mutual TLS), Zero-Trust Network.
  • Skills: Istio VirtualService를 활용한 가중치 기반(Weight 95<5>) 트래픽 라우팅 및 클러스터 내부 mTLS 강제 적용.
• How to Learn:
  • 1단계: 신들의 라우팅 (Canary): 구 버전(V1)과 신 버전(V2)을 동시에 띄워둡니다. Kubernetes Service만 쓰면 무식하게 50<50으로> 트래픽이 갈립니다. 서비스 메시(Istio)를 쓰면 "전체 트래픽의 $99\%$는 V1으로, 딱 $1\%$만 V2로 보내라"라고 L7 가중치 라우팅을 할 수 있습니다. V2에서 에러가 튀면 즉시 $0\%$로 잠가버리는(Rollback) 완벽한 안전 배포를 해부합니다.
  • 2단계: 제로 트러스트(mTLS): "해커가 이미 방화벽을 뚫고 K8s 클러스터 내부에 들어왔다"고 가정합니다(Zero Trust). 해커가 스니핑(Sniffing)을 떠도 데이터를 못 보게, 서비스 A와 B가 통신할 때 내부망임에도 불구하고 무조건 양방향 TLS(mTLS) 암호화를 강제합니다. 이 복잡한 인증서 발급과 갱신을 개발자 모르게 사이드카(Istio)가 알아서 처리해 주는 기적을 뜯어봅니다.
• Implement: Canary 트래픽 라우터 & Shadowing 데모. 들어오는 100개의 HTTP 요청. 라우터가 난수를 발생시켜 95개는 V1_Server로, 5개는 V2_Server로 보냄(Canary). 추가로, V1으로 가는 트래픽의 '복사본'을 생성하여 백그라운드의 V3_Test_Server에 쏘고 결과는 유저에게 안 알려주는(Shadowing/Mirroring - 운영 트래픽으로 안전한 테스트) 로직 콘솔 시뮬레이션.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Microservices and Network Routing
• [P5] SFIA - Enterprise IT Architecture (ARCH) - Cloud Native Network Architecture

Secondary

• [Istio in Action] Christian Posta - Service Mesh Architecture and Sidecar Proxies
• [Kubernetes Patterns] Bilgin Ibryam - Sidecar Pattern and Ingress

Industry

• [Istio Official Documentation] - Traffic Management, Security, and Observability
• [NGINX Blog] - What Is an Ingress Controller?

9. Final Checklist

Primary

• 50개의 마이크로서비스를 외부에 노출하기 위해 50개의 포트를 뚫는(NodePort/L4) 무식함을 버리고, 단 1개의 443 포트로 들어온 트래픽을 URL Path 기반으로 찢어주는 Ingress Controller(L7)의 아키텍처적 우위를 설명할 수 있는가?
• 애플리케이션 개발자가 소스 코드 내에 Retry나 Timeout 로직을 하드코딩했을 때 발생하는 기술 부채를 지적하고, 이를 사이드카(Sidecar) 패턴으로 완벽히 분리(Decoupling)해 내는 원리를 증명할 수 있는가?

Secondary

• 서비스 메시(Service Mesh) 환경에서 실제로 데이터를 나르는 수많은 프록시들(Data Plane)과, 이들에게 라우팅 룰(YAML)을 실시간으로 꽂아 넣는 뇌(Control Plane) 간의 통제 역학을 해부할 수 있는가?
• 무중단 배포 시 K8s Deployment의 단순한 롤링 업데이트가 아닌, Istio VirtualService를 활용하여 트래픽의 정확히 $5\%$만 V2로 흘리고 이상 없으면 $100\%$로 전환하는 카나리 배포(Canary Deployment)의 세밀한 L7 라우팅을 설계할 수 있는가?

Industry

• 프로덕션 트래픽(유저 데이터)을 V1으로 정상 처리하면서 동시에 그 트래픽의 '복사본'을 V2(테스트 서버)로 보내어 버그를 숨어서 테스트하는 트래픽 미러링(Traffic Shadowing) 기법의 비즈니스적 가치를 평가할 수 있는가?
• "내부망(K8s 클러스터 내부)은 안전하다"는 낡은 철학을 부수고, 서비스 간 통신(East-West)에 mTLS(Mutual TLS)를 강제하여 제로 트러스트(Zero Trust) 네트워크를 구축할 때, 인증서 관리 부담을 사이드카가 어떻게 제거해 주는지 논증할 수 있는가?