쿠버네티스 위 웹 서비스의 요청 경로와 구성 요소

서버 컴포넌트·스트리밍 SSR로 프론트엔드 코드가 서버에서 도는 비중이 커지면서, 요청이 어떤 구성 요소를 지나 앱에 닿고 그 트래픽을 어디서 보는지 아는 것이 성능 작업의 출발점이 됐다.

요청 경로 한눈에

flowchart TB
  browser["브라우저"] --> lb["External Load Balancer<br/>클라우드가 만든 공인 IP"]
  lb --> ing["Ingress / Gateway<br/>클러스터 입구. TLS 종료, 호스트·경로 라우팅<br/>(Istio Ingress Gateway, Kubernetes Gateway API 구현체)"]
  ing --> apigw["API Gateway (선택)<br/>인증, 레이트 리밋, L7 라우팅 (Kong 등)"]
  apigw --> svc["Service<br/>같은 앱의 여러 파드로 로드 밸런싱"]
  svc --> px
  subgraph pod["Pod"]
    px["프록시 (사이드카 또는 노드 프록시)<br/>트래픽 관측·보안·재시도"] --> app["앱 컨테이너 (예: Next.js 서버)"]
  end

응답은 같은 길을 거슬러 나간다.

관측:

flowchart LR
  m["각 프록시의 지표"] -->|"scrape"| prom["Prometheus"]
  prom -->|"query"| graf["Grafana 대시보드"]

구성 요소

구성 요소	한 줄 정의	익숙한 비유
Terraform / OpenTofu	클라우드 자원(클러스터, 레지스트리, 권한)을 코드로 선언하면 그 상태를 만들어 주는 IaC 도구	인프라의 `package.json` + 설치 명령
Kubernetes	컨테이너의 배포·확장·재시작·롤백을 선언적으로 관리하는 오케스트레이터	컨테이너용 운영체제
Helm	쿠버네티스 리소스 묶음을 템플릿과 값(values)으로 나눠 버전 관리하는 패키지 관리자	쿠버네티스의 npm
서비스 메시 (Istio, Linkerd)	앱 코드를 고치지 않고 관측, 트래픽 관리, 서비스 간 mTLS를 붙이는 인프라 계층	모든 요청에 끼우는 미들웨어
API 게이트웨이 (Kong 등)	여러 백엔드 앞에서 인증과 경로 기반 라우팅을 맡는 관문	리버스 프록시 + 인증 미들웨어
Prometheus	대상에서 지표를 주기적으로 긁어(scrape) 시계열로 저장하는 모니터링 시스템	지표 DB
Grafana	지표·로그·트레이스를 질의해 대시보드와 알림을 만드는 시각화 도구	지표 DB의 프론트엔드

이 생태계의 많은 프로젝트(Kubernetes, Helm, Istio, Prometheus, OpenTelemetry)는 리눅스 재단 산하 CNCF(Cloud Native Computing Foundation)에서 관리한다. Terraform은 HashiCorp 제품이고, 2023년 라이선스가 비오픈소스(BSL)로 바뀐 뒤 커뮤니티 포크인 OpenTofu가 리눅스 재단에서 이어지고 있다.

Kubernetes 리소스와 Helm

컨테이너 하나를 서비스하려 해도 리소스가 여러 개 필요하다.

리소스	역할
Pod	컨테이너가 실제로 도는 가장 작은 단위
Deployment	파드를 몇 개, 어떤 이미지로 띄울지 선언. 롤링 업데이트와 롤백
Service	파드 집합 앞의 고정 주소와 로드 밸런싱
HorizontalPodAutoscaler	부하에 따라 파드 수를 조절
Namespace, ServiceAccount	격리 단위와 권한

리소스마다 이미지 태그, 이름, 네임스페이스가 반복된다. Helm 차트는 이를 템플릿 + values.yaml로 나눈다. 새 이미지를 배포할 때는 values의 태그만 바꾸고 helm upgrade하면 차트의 새 리비전이 생기고, 문제가 생기면 이전 리비전으로 되돌린다.

서비스 메시: 사이드카와 앰비언트

서비스 메시는 앱으로 들어오고 나가는 모든 트래픽을 프록시에 통과시켜, 앱을 고치지 않고 지연 시간, 응답 코드, 요청 수를 수집하고 보안·재시도 정책을 적용한다.

방식	구조	특징
사이드카	파드마다 앱 컨테이너 옆에 프록시(Envoy) 컨테이너를 주입. 네임스페이스에 `istio-injection=enabled` 라벨을 붙이면 새 파드에 자동 주입된다	기능이 풍부하지만 파드마다 메모리·지연 비용이 든다
앰비언트	노드마다 공용 L4 프록시(ztunnel)를 두고, L7 기능이 필요한 곳에만 waypoint 프록시를 둔다	사이드카 비용이 없고 파드 재시작 없이 붙인다. Istio 1.24(2024.11)에서 정식 지원

Istio는 Prometheus용 지표 노출을 기본으로 켜 두기 때문에, Prometheus를 설치하면 별도 설정 없이 프록시 지표가 수집된다.

클러스터 입구: Ingress에서 Gateway API로

클러스터 밖 트래픽을 받는 리소스는 Ingress에서 Gateway API로 옮겨 가고 있다. Ingress는 호스트·경로 라우팅만 표현해 그 밖의 기능은 구현체 전용 어노테이션에 기댔고, Gateway API는 역할별 리소스(GatewayClass, Gateway, HTTPRoute)와 가중치 분배·헤더 매칭을 명세에 담았다. 두 API의 차이, 컨트롤러 목록, 커뮤니티 Ingress NGINX의 유지보수 종료는 쿠버네티스 네트워킹에 있다.

관측: 무엇을 보면 되나

지표	보는 곳	프론트엔드에서의 의미
요청 수(RPS)	게이트웨이, 앱 프록시	서버 컴포넌트·SSR 변경이 서버 호출을 늘렸는가
지연 시간 p50·p95·p99	구간별 프록시	느린 구간이 게이트웨이인지 앱인지
응답 코드 비율	게이트웨이	배포 직후 5xx 증가
파드 수, CPU·메모리	Kubernetes, HPA	렌더링 부하로 오토스케일이 일어나는가

지표 외에 로그와 분산 트레이스까지 한 표준으로 모으려면 OpenTelemetry로 계측하고, Grafana에서 지표(Prometheus)·로그(Loki)·트레이스(Tempo)를 함께 본다.

직접 구성해 볼 때는 Terraform으로 관리형 클러스터 생성 → Helm으로 서비스 메시·앱 차트 설치 → 게이트웨이 라우트로 노출 → Prometheus·Grafana로 확인하는 순서가 자연스럽고, 클러스터는 비용이 크므로 쓰고 나면 destroy한다.

정리

요청은 로드 밸런서 → 게이트웨이 → (API 게이트웨이) → 서비스 → 파드의 프록시 → 앱 순으로 흐르고, 프록시마다 지표가 쌓인다.
Terraform은 클라우드 자원을, Kubernetes는 컨테이너를, Helm은 리소스 묶음을, 서비스 메시는 서비스 간 트래픽을 맡는다.
클러스터 입구는 Ingress에서 Gateway API로, 서비스 메시는 사이드카에서 앰비언트 방식으로 옮겨 가고 있다.
서버에서 도는 프론트엔드 코드가 늘수록, 요청 경로와 지표를 직접 읽을 줄 아는 것이 성능 작업의 출발점이다.

버그 제보