ALB를 이용해 EKS 단일 장애점 개선하기 (이론)

AWS Load Balancer Controller

개요

최근 EKS로 인프라를 마이그레이션하면서, 수많은 챌린지를 진행하고 있습니다. 초기에는 EKS 구축에만 많은 리소스를 사용하고 있었지만, 현재는 어느정도 쿠버네티스가 익숙해졌고 EKS를 이용하여 다수의 어플리케이션이 배포된 상태입니다.

 

이렇게 EKS를 이용해 여러 서비스들이 배포된 상황이긴 하지만, 매번 설계한 아키텍처에서 마음에 들지 않는 부분이나 개선되었으면 좋을 부분들이 점점 눈에 띄고 있는 상태입니다.

 

이번 게시글에서는 사용에 직접적인 문제는 없지만, 개선되어야할 부분 중 하나인 Niginx Ingress Controller의 단일 장애점(SPOF, Single Point Of Failure)에 대한 개선기를 작성해보고자 합니다.

 

먼저 알아보기

Ingress

1️⃣ Ingress

인그레스(Ingress)는 쿠버네티스 클러스터 외부에서 내부로 접근하는 요청을 관리하는 리소스이다.

 

인그레스(Ingress)는 클러스터 내의 여러 서비스(Service)에 대한 외부 트래픽을 효율적으로 라우팅 해주는 역할을 담당합니다. 주로 Application에게 안정적인 트래픽 전달을 수행하며, URL 기반의 라우팅과 쿠버네티스 내부에서 Service Name 기반의 가상 호스팅을 가능하게 합니다.

 

2️⃣ Ingress Controller

인그레스 컨트롤러(Ingress Controller)는 인그레스 리소스에 정의된 Rule에 따라 외부 트래픽을 지정된 서비스로 라우팅하는 역할을 담당하는 리버스 프록시(Reverse Proxy) 서버이다.

 

인그레스(Ingress)는 쿠버네티스 클러스터 외부에서 내부로 트래픽을 전달하기 위한 Rule을 담당하게 됩니다. 이렇게 정의된 Rule에 따라 실제로 라우팅을 수행하기 위해서는 인그레스 컨트롤러(Ingress Controller)가 필요하게 됩니다.

 

인그레스 컨트롤러(Ingress Controller)는 쿠버네티스 클러스터의 Gateway 역할을 담당하며, 외부 트래픽을 지정된 내부 Service에게 전달하게됩니다.

 

3️⃣ Nginx Ingress Controller

Nginx Ingress Controller는 쿠버네티스가 기본적으로 제공해주는 Ingress Controller 중 하나이며, Nginx 웹 서버를 기반으로 한 Open Source Ingress Controller이다.

 

Nginx Ingress Controller는 쿠버네티스의 Nginx Pod로써 구성되며, 모든 외부 트래픽은 Nginx Pod를 거쳐 정의된 Ingress Rule에 따라 지정된 Service에 라우팅됩니다.

 

여기서, 모든 트래픽 라우팅을 Nginx Pod가 담당하게 되므로 기존에 인프라를 담당하였던 개발자라면 Nginx에 대한 지식만 가지고 있더라도 추가적인 리소스 없이 인프라 환경을 구축할 수 있게 되는 장점을 가지고 있습니다.

 

현재 문제점

단일 장애점(SPOF, Single Point Of Failure)

현재 EKS 환경의 모든 인바운드 트래픽은 Nginx Ingress Controller를 거치게됩니다. 이는 Nginx를 사용했던 개발자라면 익숙하겠지만, 사실은 중대한 위험을 내포하고 있는 구성입니다.

 

만약, Nginx가 다운되는 순간, 클러스터 내의 모든 어플리케이션을 도메인을 통해 접근할 수 없는 문제가 발생하게 됩니다. 이는 Nginx가 클러스터 내의 모든 어플리케이션의 트래픽을 관리하므로 Nginx 하나가 모든 클러스터의 장애를 발생시키는 단일 장애점(SPOF, Single Point Of Failure)이 되는 것입니다.

 

필요하지 않은 트래픽 모니터링

초기에는 Nginx Ingress Controller의 트래픽 모니터링은 가장 중요한 부분이었습니다. 하지만 시간이 지나면서 ELK, Datadog과 같은 외부의 3rd Party 모니터링 도구를 도입하게 되었습니다. 이러한 도구들을 통해 Nginx에서 제공하던 기능보다 더욱 향상된 트래픽 분석과 로그 관리가 가능하게 되어 Nginx의 필요성이 더욱 줄어들게 되었습니다.

 

위와 같은 문제점으로 인해, Nginx Ingress Controller의 필요성이 점차 줄어들게 되었고, 이를 해결하기위한 다른 방안이 필요하게 되었습니다.

 

AWS Load Balancer Controller

AWS Load Balancer Controller는 쿠버네티스 클러스터에서 AWS ALB(Application Load Balancer)를 통해 인바운드 트래픽을 관리한다.

 

AWS Load Balancer Controller를 이용한다면, 쿠버네티스의 Service에서 LoadBalancer 타입을 사용하는 것과 유사하게 AWS Load Balancer를 구성할 수 있습니다. 다만, Service의 LoadBalancer 타입과 다르게, AWS Load Balancer Controller는 ALB 또는 NLB(Network Load Balancer)를 사용하여 Ingress Rule에 따라 다수의 서비스로 트래픽을 라우팅하는 더 복잡한 구성이 가능하게 됩니다.

 

Nginx Ingress Controller가 일반적으로 단일 NLB로 트래픽을 Nginx Pod로 라우팅하는 반면, AWS Load Balancer Controller는 ALB 또는 NLB의 Listener를 구성하여, Ingress Rule을 바탕으로 트래픽을 적절한 Service로 라우팅하게 됩니다.

 

모든 인바운드 트래픽에 대한 의존성을 AWS Load Balancer로 이전함으로써, 기존 Nginx 기반 아키텍처에서 발생할 수 있는 단일 장애점 문제를 제거할 수 있게 됩니다. 또한, ALB의 자동화된 스케일링 기능과 함께 ACM(AWS Certificate Manager)를 통한 SSL/TLS 관리 및 AWS WAF(Firewall)를 통한 세밀한 트래픽 필터링을 제공할 수 있게 됩니다.

 

결론

AWS Load Balancer Controlelr를 통해 Nginx 기반의 Ingress Controller가 가지고 있던 단일 장애점을 제거할 수 있었고, ALB 및 NLB를 통해 운영 효율성과 안정성을 향상시킬 수 있었습니다.

 

이번 게시글에서는 현재 문제점과 해결 방법에 대한 이론만 설명하였지만, 다음 게시글에서는 Terraform을 이용하여 VPC, EKS, AWS Load Balancer Controller Helm을 통해 ALB가 생성되는 것과 Ingress Rule에 따라 ALB Listener Rule이 지정된 Target Group을 Routing 하도록 구성할 예정입니다.