AWS EKS 앞에 어떤 load balancer를 붙여야 할까?

 

 

일단 AWS EKS 를 사용하면 주로 alb 를 사용하거나 ingress nginx 를 사용하여 nlb를 eks에 잘 안붙여 보아 어떻게 동작하는지 알아보도록하겠습니다.

안붙이는 이유는 path 라우팅이 안되기 때문인데 잘사용 안하기 때문에 nlb를 붙이면 어떻게 될지 알아봅시다.

 

NLB의 EKS 동작

 

NLB의 기본 작동 방식 (정상적인 경우)

NLB가 EKS와 연동될 때, 다음과 같은 순서로 작동합니다.

1. 사용자는 app: my-api와 같은 레이블(label)을 가진 파드 그룹을 지정하여 쿠버네티스 서비스(Service)를 생성합니다.
2. 이 서비스의 타입을 LoadBalancer로 지정하면, AWS Load Balancer Controller가 NLB를 생성합니다.
3. NLB는 서비스가 지정한 레이블(app: my-api)을 가진 모든 파드들의 IP 주소를 자신의 타겟 그룹(Target Group)에 등록합니다.
4. 외부에서 NLB로 트래픽이 들어오면, NLB는 타겟 그룹에 등록된 여러 파드들에게 트래픽을 골고루 분산합니다.

즉, NLB의 역할은 특정 파드 하나를 '지목'하는 것이 아니라, 특정 그룹 전체를 대상으로 트래픽을 '분배'하는 것입니다.

 

2. 특정 파드로 보내는 방법 (권장되지 않는 경우)

이론적으로 특정 파드 하나에만 트래픽을 보내려면 다음과 같은 편법을 사용할 수 있습니다.

1. 수많은 파드 중 오직 하나의 파드에만 pod-id: unique-123과 같은 고유한 레이블을 붙입니다.
2. 쿠버네티스 서비스를 생성할 때, 셀렉터(selector)로 바로 이 고유한 레이블(pod-id: unique-123)을 지정합니다.
3. 이렇게 생성된 서비스와 연동된 NLB의 타겟 그룹에는 오직 그 파드 하나의 IP만 등록됩니다.

하지만 이 방식은 다음과 같은 심각한 문제점을 가집니다.

• 단일 장애점 (SPOF): 만약 그 특정 파드 하나가 장애로 재시작되거나 삭제되면, 서비스는 즉시 중단됩니다.
• 확장성 부재: 트래픽이 증가해도 파드를 추가하여 대응할 수 없습니다.
• 쿠버네티스 철학 위배: 장애가 나면 자동으로 복구하고(Self-healing), 유연하게 확장하는(Scalability) 쿠버네티스의 핵심 가치를 완전히 무시하는 방식입니다.

 

 

 

API gateway + NLB, ALB + EKS 조합

그렇다면 앞에 path 라우팅하는 서비스가 있다면 어떤 조합을 하는게 좋을까?

 

API Gateway와 NLB 조합을 사용하여, API Gateway의 특정 경로(.../users)로 들어온 요청을 EKS의 특정 서비스(user-service)로 라우팅할 수 있습니다.

하지만 이 방식은 일반적으로 추천되지 않는데, 비효율적이고 비용이 많이 들기 때문입니다.

---

API Gateway + NLB 조합의 작동 방식

이 조합으로 경로별 라우팅을 구현하려면 라우팅하려는 EKS 서비스마다 별도의 NLB가 하나씩 필요합니다.

1. EKS 클러스터 안에 user-service를 만들고 타입을 LoadBalancer로 지정합니다. → NLB-A가 생성됩니다.
2. EKS 클러스터 안에 order-service를 만들고 타입을 LoadBalancer로 지정합니다. → NLB-B가 생성됩니다.
3. API Gateway에서 /users 경로에 대한 통합(Integration)을 설정할 때, NLB-A를 가리키는 VPC Link를 연결합니다.
4. API Gateway에서 /orders 경로에 대한 통합을 설정할 때, NLB-B를 가리키는 VPC Link를 연결합니다.

흐름도:

                                 ┌─ (VPC Link) → NLB-A → user-service → (user-pods)
Client → API Gateway (/users) ─┤
             (/orders) ─┤
                                 └─ (VPC Link) → NLB-B → order-service → (order-pods)

 이 방식의 문제점 (비용과 비효율성)

위 흐름도에서 볼 수 있듯이, 새로운 EKS 서비스가 추가될 때마다 새로운 NLB를 생성하고 VPC Link를 연결해야 합니다. NLB는 시간당 요금과 데이터 처리 요금이 부과되므로, 서비스가 10개라면 10개의 NLB 비용이 발생합니다.

이는 NLB가 Layer 4(TCP) 로드밸런서라서 /users, /orders와 같은 경로(Path)를 인지하고 라우팅할 수 없기 때문입니다. NLB는 단순히 지정된 곳으로 트래픽을 전달만 할 뿐입니다. 따라서 API Gateway단에서 서로 다른 NLB로 보내는 방식으로 라우팅을 구현해야만 합니다.

---

  더 효율적이고 일반적인 방법: ALB 사용

이것이 바로 이전 답변에서 ALB가 더 유리하다고 설명한 이유입니다.

ALB는 Layer 7(HTTP) 로드밸런서이므로 하나의 ALB만으로 경로 기반 라우팅을 모두 처리할 수 있습니다.

1. EKS 클러스터에 단 하나의 ALB를 Ingress를 통해 생성합니다.
2. Ingress 규칙에 아래와 같이 정의합니다.
   • /users 경로는 user-service로 전달
   • /orders 경로는 order-service로 전달
3. API Gateway에서는 이 단일 ALB를 가리키는 VPC Link 하나만 연결하면 됩니다.

흐름도:

                                             ┌─ (경로 분석) → user-service → (user-pods)
Client → API Gateway → (VPC Link) → 단일 ALB ┤
                                             └─ (경로 분석) → order-service → (order-pods)

  요약

• API Gateway + NLB 조합: 가능하지만, 서비스마다 NLB를 생성해야 해서 비효율적이고 비용이 많이 듭니다.
• API Gateway + ALB 조합: 하나의 ALB로 수많은 서비스에 대한 경로 기반 라우팅을 처리할 수 있어 매우 효율적이고 비용을 절감할 수 있습니다. 이것이 MSA 환경의 표준 아키텍처입니다.

 

 

그렇다면 내부 라우팅을 위해 nlb 뒤에 ingress controller nginx 를 붙여 보자

 

NLB + Ingress controller(Nginx) + EKS

NLB + NGINX 조합의 작동 방식

이 구조에서 각 컴포넌트의 역할은 다음과 같습니다.

1. NLB (Network Load Balancer):
   • 단 하나의 고정된 진입점(Entrypoint) 역할을 합니다.
   • Layer 4에서 작동하여 외부 트래픽을 매우 빠르고 효율적으로 EKS 클러스터 내부의 NGINX Ingress Controller 파드로 전달합니다. NLB 자체는 경로 분기를 하지 않습니다.
2. NGINX Ingress Controller:
   • EKS 클러스터 내부에서 실행되는 파드(Pod) 형태의 애플리케이션입니다.
   • 실질적인 Layer 7 라우팅을 담당합니다.
   • 사용자가 작성한 Ingress 규칙(예: /users → user-service)을 읽어들여 내부의 NGINX 설정을 동적으로 변경합니다.
   • NLB로부터 전달받은 트래픽의 경로를 보고 적절한 내부 서비스로 요청을 분배합니다.

흐름도:

Client → API Gateway → (VPC Link) → 단일 NLB → NGINX Ingress Pod → (경로 분석) ┬→ user-service
                                                                         └→ order-service

이 방식은 단 하나의 NLB와 그 뒤에 위치한 NGINX Controller가 라우팅을 전담하므로, 서비스를 추가할 때마다 NLB를 추가할 필요가 전혀 없습니다.

 

 

ALB Ingress controller vs NLB + Nginx Ingress controller 

 

일반적으로 ALB의 L7 기능을 자체 service로 구성한 ingress로 처리하면 더저렴하지않을까?

 

 1. 비용: 보이는 것과 다른 총소유비용(TCO)

단순히 로드밸런서 시간당 요금만 비교하면 NLB가 ALB보다 저렴한 것이 맞습니다.

하지만 NLB + NGINX 모델은 숨겨진 비용이 있습니다. 바로 NGINX Ingress Controller를 실행하기 위한 EKS 워커 노드의 컴퓨팅 자원(CPU, Memory) 비용입니다. 트래픽이 많은 대규모 서비스라면 NGINX 파드의 자원 사용량도 무시할 수 없으며, 이를 위해 더 크거나 더 많은 워커 노드가 필요하게 됩니다.

반면 ALB는 로드밸런싱의 모든 부하를 AWS가 관리하는 별도의 인프라에서 처리합니다. 따라서 EKS 클러스터는 오직 애플리케이션 로직에만 자원을 집중할 수 있습니다.

• NLB + NGINX: (NLB 요금) + (NGINX 파드를 위한 EC2 노드 자원 비용)
• ALB: (ALB 요금)
• 결론: 트래픽 규모와 NGINX의 부하에 따라 총비용은 역전될 수 있습니다.

 2. 속도: 추가적인 경로(Hop)의 존재

NLB가 Layer 4에서 작동하여 ALB보다 지연 시간이 낮은 것은 사실입니다.

하지만 NLB + NGINX 아키텍처는 트래픽이 최종 목적지 파드에 도달하기까지 추가적인 경로(Hop)를 거칩니다.

• NLB + NGINX: Client → NLB → NGINX 파드 → 최종 서비스 파드
• ALB: Client → ALB → 최종 서비스 파드

NLB의 낮은 지연 시간이라는 이점이 NGINX 파드를 거치는 추가적인 네트워크 홉과 L7 처리 시간 때문에 상쇄될 수 있습니다. 결과적으로 두 방식의 전체적인 응답 속도는 비슷하거나 상황에 따라 ALB가 더 빠를 수도 있습니다. 'NLB가 있으니 무조건 빠르다'고 단정하기는 어렵습니다.

## 3. 비용과 속도보다 중요할 수 있는 것들

실제 운영 환경에서는 비용과 속도 외에 다음 두 가지가 더 중요하게 작용하는 경우가 많습니다.

관리 및 운영 부담

• ALB: AWS가 완전히 관리하는 서비스입니다. 사용자는 Ingress 규칙만 정의하면 보안 패치, 스케일링, 가용성 등을 AWS가 알아서 처리해 줍니다. 운영이 매우 편리합니다.
• NLB + NGINX: NGINX 자체는 사용자가 직접 관리해야 합니다. NGINX 버전을 올리거나, 보안 취약점(CVE)이 발견되었을 때 직접 패치하고, 성능을 튜닝하는 모든 책임이 사용자에게 있습니다. 운영 부담이 상대적으로 큽니다.

기능 및 AWS 생태계 통합 

• ALB: AWS WAF(웹 방화벽)를 클릭 몇 번으로 쉽게 연동할 수 있다는 것이 가장 큰 장점입니다. 또한 Cognito(인증), IAM 등 다른 AWS 서비스와의 통합이 매우 자연스럽습니다.
• NLB + NGINX: NLB에는 WAF를 직접 붙일 수 없어 복잡한 우회 경로(예: CloudFront 사용)를 만들어야 합니다. 대신 NGINX의 모든 기능을 활용한 매우 세밀하고 유연한 라우팅 규칙 설정이 가능합니다.

---

#최종 요약: 무엇을 선택할 것인가?

고려사항	ALB Ingress	NLB + NGINX Ingress
관리 편의성	매우 높음 (AWS 완전 관리형)	상대적 부담 (사용자가 NGINX 관리)
AWS 통합	최상 (WAF, Cognito 등 간편 연동)	제한적 (WAF 등 연동 복잡)
유연성	AWS가 제공하는 기능으로 한정	최상 (NGINX의 모든 기능 사용 가능)
총 비용	관리형 서비스 비용	NLB + EC2 노드 비용 (규모에 따라 다름)
속도	추가 홉 없음	추가 홉 발생 (전체 속도는 비슷할 수 있음)

 

요약

 

• ALB를 추천하는 경우: 운영 편의성이 가장 중요하고, AWS WAF와 같은 다른 AWS 서비스를 쉽고 빠르게 통합하고 싶을 때
• NLB + NGINX를 추천하는 경우: NGINX의 특정 고급 기능이 반드시 필요하거나, 멀티클라우드 등 특정 플랫폼에 종속되지 않는 유연성이 더 중요할 때