요즘 개발자를 위한 시스템 설계 수업 - 4장 분산 시스템의 기본 요소: DNS, 로드밸런서, 애플리케이션 게이트웨이 - 3

4.4 애플리케이션 게이트웨이

• 현대 클라우드 환경에 맞추어서 더 고도화된 프록시 기능 제공
• 여러 API를 통합으로 묶어야 하는 MSA 환경에서 장점
• 내부 백엔드 서비스들이 비즈니스 로직에만 집중할 수 있도록 횡단의 관심사 담당(보안, 캐싱 등)

4.1.1 애플리케이션 게이트웨이의 기능과 역할

• 고급 요청 라우팅
  MSA 환경에서 각 서비스에 맞게 라우팅
• 보안
  반드시 거치는 단일지점이라 최적 장소
• 가속와 오프로딩
  캐싱, TCP 연결, TLS 오프로딩 등 대신 처리하여 백엔드 부담을 덜어줌
• 모니터링 기능
• 적응성
  요청과 응답을 조정할 수 있음, 예를 들어 클라이언트의 HTTP REST 요청을 내부의 gRPC나 AMQP 메시지로 변환하여 전달
• 트래픽 제어
  Rate Limiting을 걸어 제어하기도 함

L7과 차이점

구분	L7 Load Balancer	Application / API Gateway
주요 목적	트래픽의 고속 분산 및 인프라 가용성 확보	API 관리, 보안 통제, MSA 공통 로직 중앙화
패킷 개입 수준	HTTP 헤더, URI 파싱 후 즉시 포워딩	페이로드(Body) 검사, 토큰 파싱, 데이터 변환
주요 기능	SSL 오프로딩, Round-Robin, Session Sticky	JWT 인증, Rate Limiting, IP 화이트리스트, API 빌링
성능 (Latency)	매우 빠름 (연산 오버헤드 최소화)	상대적으로 느림 (각종 필터 체인 연산 발생)
대표 솔루션	AWS ALB, Nginx, HAProxy, Envoy (기본)	AWS API Gateway, Kong, Spring Cloud Gateway

 

4.6 클라우드 네이티브 애플리케이션 게이트웨이 서비스 개요

각 기업마다 자사 환경에 적합한 솔루션 제공

 

• AWS
  게이트웨이는 API 생성, 배포, 관리, 보안 담당
  ALB는 트래픽 라우팅 담당
• Azure
  L7 로드 밸런싱 기능 제공
  보안 담당
• Cloud Armor
  보안 담당, 캐싱
• 쿠버네티스 환경
  Istio, Kong, Ambassador 같은 인그레이스 컨트롤러가 API 게이트웨이 역할

인그레이스 컨트롤러

쿠버네티스 네트워크 환경에서 트레픽을 라우팅하는 네트워크 프록시 엔진(L7 로드 밸런서)

 

비교 항목	NodePort / LoadBalancer 서비스	Ingress + Ingress Controller
비용 구조 (Cloud)	서비스마다 개별 Public IP / LB 생성 (고비용)	클러스터당 1~2개의 LB만 생성 후 내부에서 분기 (저비용)
라우팅 능력	L4 중심 (IP/Port 기반), 단순 포워딩	L7 중심 (URL, 헤더, 도메인 기반), SSL 오프로딩
인프라 결합도	클라우드 벤더(AWS, GCP) 종속성 높음	클러스터 내부에서 동작하므로 벤더 중립성 확보 가능
장애 시 파급력(Blast Radius)	해당 단일 서비스만 영향받음	Controller 장애 시 전체 서비스 라우팅 마비 (SPOF)

• 가장 많이 사용하는 Nginx Ingress Controller는 Ingress 규칙이나 Pod IP(Endpoint)가 변경될 때마다 프로세스 리로드(Reload)를 유발하기 때문에 자주 배포하는 환경에서는 주의가 필요함
• 쿠버네티스 진영에서 차세대 표준 Gateway API를 공식화 해서 앞으로 'Ingress Controller' 용어 대신 점진적으로 'Gateway Implementation' 명칭으로 대체

인그레이스 컨트롤러가 있어야 하는 이유

• 쿠버네티스 자체에는 외부 트래픽을 받을 수 있는 '진짜 로드밸런서'가 없음
• 그래서 개발자가 쿠버네티스에 외부 서비스 연결 요청을 하면 쿠버네티스는 클라우드 제공자에게 API로 클라우드 로드밸런서 장비 생성 명령을 함
• 이때 인그레이스 컨트롤러가 없으면 진짜 마이크로 서비스 만큼의 로드 밸런서가 생성
• 인그레이스 컨트롤러가 있으면 1개 로드 밸런서가 생성

 

4.7 온프레미스 옵션

대표적 플랫폼

• Kong
• Tyk
• NGINX
• HAProxy

플랫폼	기반 언어 / 코어	런타임 의존성 (상태 저장소)	아키텍처 특성	최고 강점
HAProxy	C	없음 (Stateless)	순수 L4/L7 로드 밸런서	압도적인 처리량, 최저 지연 시간, 극강의 안정성
NGINX	C	없음 (Stateless)	리버스 프록시 / 웹 서버	범용성, 풍부한 문서, 가벼운 리소스 사용량
Kong	Nginx + LuaJIT	Postgres / DB-less 지원	분산 API 게이트웨이	거대한 플러그인 생태계, 무중단 동적 설정(Hot-reload)
Tyk	Go	Redis (필수)	Full API Management	대시보드/포털 내장, 단일 바이너리로 배포 용이

• 동적으로 성적하는 유연함은 필연적으로 성능 저하로 다가온다.
• 저장소 의존은 그 시스템이 죽으면 같이 죽게 된다.