L4/L7 그리고 프록시와 로드밸런서가 어떤 역할을 하는지 알아봤다.
그래서 이게 내가 개발하는 서비스에서 어떻게 이용되고 있었던 걸까?
개념은 새로 생긴 게 아니라 "역할이 분리/계층화"된 것이다.
프록시, 로드밸런서로 관점에서 보는 Web Server와 WAS
전통적인 웹 아키텍처에서 '웹서버(Web Server)'의 기능이라고 하면 보통 클라이언트 요청을 가장 앞에서 받아 '정적 자원'의 서빙과 동적 자원의 필요시 WAS로 요청을 넘기는 역할을 한다고 알고 있다. 근데 이 백엔드(WAS/앱)로 요청을 넘긴다는 건 사실 Reverse Proxy의 기능과 뒤에 있는 여러 백엔드 인스턴스로의 분산까지 수행함을 의미하고 있다. 즉, Nginx/Apache 같은 웹서버들은 정적 자원 제공만 하는 것은 아니고, 일반적으로 '정적 서빙/프록시/로드밸런싱'를 모두 하고 있었던 것이었다.
- 정적 리소스 서빙: HTML/CSS/JS, 이미지 등 파일을 그대로 응답
- Reverse Proxy(프록시): 클라이언트 요청을 받아 백엔드(WAS/앱) 로 전달
- 로드밸런싱: 여러 백엔드 인스턴스 중 하나로 분산
그리고 웹서버와 함께 비교되어 나오는 개념인 WAS(Tomcat 등)도 사실 HTTP를 받고 정적 파일을 내려주는 이런 업무들을 단독으로 충분히 할 수 있다. 하지만 서비스 규모가 커지고 운영 요구가 복잡해지면서, 여러 업무를 모두 책임지는 방식은 결국 한계에 부딪혔다. 마치 객체지향 프로그래밍에서 모듈이 커짐에 따라 '단일 책임의 원칙'을 지키면서 확장하듯이, 성능 자체라기보다 운영/보안/정책/확장 때문에 웹서버가 기존에 하던 일을 하나하나 구분해서 전용 담당자를 두게 만든 것이 필요해진 것이다. 그래서 정적 서빙은 CDN/오브젝트 스토리지가 처리하고 기타 역할들도 로드밸런서, 쿠버네티스(Kubernetes), Gateway 등의 구성요소로 분리되어 운영되는 형태가 흔해졌다.
Kubernetes ? Gateway ? 확장된 여러 개념들
핵심은 "기존에 누가 하던 일을, 왜, 누가 가져갔는가"이다.
일단 게이트웨이(Gateway)가 어디에 배치되고 무엇을 하는가를 이해하기 위해선 Kubernetes(k8s)에 대해 조금 이해할 필요가 있다. k8s는 여러 개의 서버(노드)를 하나의 클러스터로 묶어서, 그 위에 컨테이너 애플리케이션(Pod)을 자동으로 배포·확장(Scaling)·복구 해주는 운영/관리 기술 또는 소프트웨어이다.
k8s의 구성하는 대표적인 용어/개념을 정리해 봤다.
| 개념 | 한 줄 정의 | 핵심 역할 | 기억 포인트 |
| Cluster | K8s가 관리하는 전체 운영 환경(노드들의 묶음). 풀네임은 Kubernetes Cluster. | 애플리케이션이 "한 서버"가 아니라 여러 노드/파드에 분산되어 돌아가는 운영 단위. 클러스터가 다르면, 기본적으로 Node/Pod는 공유되지 않는다. |
k8s가 관리하는 범위 |
| Ingress | 외부 HTTP(S) 라우팅 규칙(리소스)이 적힌 노트 | Host/Path 기반으로 "어느 Service로 보낼지" 선언 | Ingress = 규칙 |
| Ingress Controller | 외부 HTTP(S)를 어떤 Service로 보낼지 정하는 L7 관문 | 실제로 외부 요청을 받고 Ingress 규칙대로 Service로 프록시(라우팅). 실제 트래픽을 받는 건 Controller지만 실무에선 보통 통째로 "Ingress"라고 부름 | Controller가 실제로 받는다 |
| Node | Pod가 올라가는 실제 서버(VM/물리) | Pod는 항상 어떤 Node 위에서 실행됨. | Node = Pod의 집 |
| Pod | 컨테이너가 실행되는 배포 최소 단위 | 앱이 실제로 실행되는 곳. 중요한 특징은 Pod IP는 바뀔 수 있음(휘발성) |
Pod = 앱 실행된 형태 |
| Service | Pod들을 묶는 클러스터 내부 가상 주소(가상 IP/DNS) | 외부/내부에서 Pod에 직접 붙지 않고 Service로 접근. 트래픽을 Pod들로 분산 | 바뀌는 Pod들의 논리 주소를 Service를 통해 접근 |
다시 정의하면 K8s는 "클러스터"라는 운영 환경 위에서 리소스를 관리하는 시스템이다.
추가적으로 '클러스터에서 실제로 실행되는 인스턴스'를 '워크로드(Workload)'라고 말하는데, 그 워크로드는 결국 Pod 형태로 실행되기에 문맥에 따라 '실행 중인 Pod들' 혹은 '그 Pod들을 운영하는 단위' 정도로 이해하면 될 것 같다. 또 Node는 클러스터 내에서 실제로 일을(워크로드를) 수행하는 Node이기도 하므로 Worker Node(워커 노드)라고도 부른다. 실무에서 '워크로드가 돈다'고 하면 Pod들이 실행 중인 상태를 말한다고 이해하면 되겠다.
Gateway 역할 그리고 어디에 위치하는가?
Gateway는 Ingress Controller와 함께 비교된다. 위에서 Ingress Controller는 L7 Reverse Proxy 계열로써 Host/Path/Header 등을 보고 트래픽을 어느 Service로 보낼지 결정한다고 했다. 즉, Ingress(Controller)는 출발점이 "클러스터 진입"인 "L7 라우팅"을 수행하는 것이다. 이때 시스템과 여러 요구가 커지면서 클러스터 진입이라는 '라우팅 규칙'만큼 클라이언트 요청을 통제하거나 어떤 정책(인증/인가/로깅 등)을 일관되게 적용하고자 하는 니즈가 생긴 것이다. 그래서 Gateway라는 개념으로 역할이 분화됐다.
다른 개념들과 마찬가지로 Gateway라는 새로운 네트워크 계층이 생겨난 것이 아니다. Gateway는 본질적으로 Ingress Controller와 마찬가지로 실제로 트래픽을 받아서 라우팅하는 L7 Reverse Proxy/Load Balancer이다. 다만 Gateway가 Proxy/Ingress와 다른 점은 라우팅 자체보다 "정책"을 중심 기능으로 운영한다는 점에서 다르다. 그니까 Ingress도 정책을 다룰 수 있는데, 정책을 운영 가능한 방식으로 하기 위해 업무 담당자를 나눈 것일 뿐이다.
1. Ingress만으로 충분한 구조
Client → External LB → Ingress Controller → Service → Pod
클러스터 진입 라우팅 중심, 인증/정책은 애플리케이션(또는 플러그인)으로 처리
2. Gateway + Ingress를 함께 쓰는 구조
Client → WAF → External LB → API Gateway → Ingress Controller → Service → Pod
전사 정책/관리/관측 등은 Gateway, 클러스터 내부 라우팅은 Ingress
3. Ingress Controller가 Gateway 역할까지 흡수한 구조
Client → External LB → Ingress Controller(플러그인/정책 포함) → Service → Pod
정책까지 Ingress에 몰아넣어 단순하지만, 관리 범위는 클러스터 내부.
'Infra & Cloud' 카테고리의 다른 글
| 프록시(Proxy)와 로드밸런서(Load Balancer), L4/L7 한 번에 비교 정리 (0) | 2026.01.15 |
|---|---|
| Springboot를 Docker Image로 생성 및 실행(Dockerfile) (0) | 2025.05.11 |
| Docker Volume 개념 및 활용 예시 (0) | 2025.04.28 |
| Docker 명령어 사용 및 예시(nginx 설치&실행) (0) | 2025.04.25 |
| Docker Desktop 설치 및 확인 (0) | 2025.04.17 |