LoadBalancer 타입의 한계와 Ingress 도입 전략 (비용/구조 최적화)

정성헌·2026년 3월 27일

1. 문제 제기: LoadBalancer 남발의 맹점

쿠버네티스 환경에서 외부 트래픽을 내부로 인입시킬 때, 서비스(Service)의 타입을 습관적으로 LoadBalancer로 설정하는 경우가 많다. 단일 서비스를 띄울 때는 직관적이고 편리하지만, 서비스 개수가 늘어날수록 이 방식은 아키텍처의 부채가 된다.

1.1. L4 계층의 한계

LoadBalancer 타입은 L4(전송 계층)에서 동작한다. IP와 Port 번호만 확인하고 트래픽을 맹목적으로 전달할 뿐, HTTP/HTTPS 프로토콜의 특성(도메인, URL 경로 등)을 이해하지 못한다.

1.2. 1:1 프로비저닝 구조

가장 큰 문제는 클라우드 벤더(AWS, GCP 등)와의 연동 방식이다.
쿠버네티스에 LoadBalancer 타입의 서비스를 생성하면, 클라우드 환경에서는 실제 로드밸런서(예: AWS NLB) 장비가 1:1로 생성된다.

2. 팩트 체크: 왜 Ingress로 전환해야 하는가?

기능적으로 동작한다고 해서 올바른 설계가 아니다. Ingress 도입은 선택이 아닌 필수이며, 그 논리적 근거는 다음과 같다.

2.1. 비용의 선형적 증가 (가장 치명적 결함)

LoadBalancer (10개 서비스): 10개의 클라우드 로드밸런서가 생성된다. (클라우드 제공자 기준 1개당 월 최소 $15~$20 유지비 발생. 트래픽 유무와 상관없이 월 $200 고정 지출)
Ingress 도입 시: 단 1개의 클라우드 로드밸런서(Ingress Controller)만 생성한다. 수십 개의 서비스 트래픽을 1개의 LB가 받아서 내부로 분기하므로, 인프라 비용이 1/10 수준으로 압축된다.

2.2. 보안 및 인증서(SSL/TLS) 관리의 파편화

HTTPS 통신을 구축할 때의 차이는 더욱 극명하다.

LoadBalancer 구조에서는 10개의 서비스에 각각 SSL 인증서를 세팅하고 갱신해야 하는 '관리 지옥'이 열린다.
Ingress는 L7 계층에서 동작하므로, 단일 진입점에서 SSL 인증을 해제(SSL Termination)한다. 뒷단의 서비스들은 복잡한 암복호화 로직 없이 비즈니스 로직에만 집중할 수 있다.

3. 실무 아키텍처: Ingress 라우팅 로직

인그레스는 시스템의 '정문 경비실'이다. 외부의 모든 요청은 정문(Ingress Controller)을 통과하며, 여기서 방문자의 목적지(URL Path, Host)를 분석해 클러스터 내부의 각 서비스(ClusterIP)로 안내한다.

3.1. 트래픽 흐름 비교

Legacy: 사용자 $\rightarrow$ 클라우드 LB 10개 $\rightarrow$ Node $\rightarrow$ Pod 10개
Ingress: 사용자 $\rightarrow$ 단일 클라우드 LB (ALB) $\rightarrow$ Ingress Controller $\rightarrow$ Service (ClusterIP) $\rightarrow$ Pod

3.2. 실무 YAML 설정 예시

단 하나의 도메인(example.com)으로 관리자 페이지, API, 프론트엔드를 분기하는 라우팅 규칙이다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-routing-ingress
spec:
  rules:
  # 1. 서브 도메인 기반 라우팅
  - host: admin.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: admin-svc # 외부 노출 없이 ClusterIP로 설정됨
            port:
              number: 80
              
  # 2. URI 경로(Path) 기반 라우팅
  - host: example.com
    http:
      paths:
      # /api 요청은 api-svc로 포워딩
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 8080
      # 그 외 모든 요청은 frontend-svc로 포워딩
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-svc
            port:
              number: 80