1. AWS Load Balancer Controller 설치 ( Introduction )

구현하려고 하는 것

우선 우리 X2bee 초기 개발의 develop 환경의 구성을 아래 왼쪽과 같이 Nginx와 CLB(classic load balancer)로 구성하였다.

 

이것을 위 오른쪽처럼 Nginx의 단계를 없애고 CLB대신 ALB로 교체하려고 한다.

 

왜 구현하려고 하는가?

ALB가 최고의, 궁극의 Load Balancer인가? 그건 아니다.

 

Nginx(유료인 Nginx Plus도)는 OSI Layer 4와 Layer 7 둘 다 설정이 가능하다.

CLB는 OSI Layer 4 와 Layer 7에서 동작한다. 

ALB는 OSI Layer 7에서만 동작한다. 

NLB(Network Load Balancer)는 OSI Layer 4에서만 동작한다.

그러면 CLB와 Nginx가 짱 아닌가? 그것도 아니다. 각각의 장단점이있다. (그래서 가격이 CLB, ALB, NLB 셋 다 비슷하다.)

 

CLB는 2009년에 출시되었다. 기능이 아주 한정적이다.

ALB와 NLB는 2016년에 출시되었다. 

ALB는 CLB가 구현하지 못한 Layer 7의 기능을 많이 추가했다.

NLB는 셋 중에 속도가 가장 빠르다.

 

결국 각각의 장단점이 있으므로 자신이 원하는 운영 환경에 맞게 쓰면 된다.

 

내가 ALB를 설치하려는 실질적인 이유는

1. 위에 Nginx + CLB는 접속자의 증가로 트래픽이 늘어나면서 

항상 bottleneck이 되는데, 어디서 bottleneck이 발생했는지는 정확히 알기 쉽지 않다.

그래서 points of failure를 줄이기 위해 두 단계를 한 단계로 줄이고 성능이 훨씬 우수한 ALB로 교체하는 의미도 있다.

(귀게 걸면 귀걸이, 코에 걸면 코걸이인 멘트지만 사실 Nginx와 CLB의 장점을 잘 조합해서 configure하면 장점도 있을 것이다.)

2. 그리고 t3.small 타입의 EC2 instance에 설치된 Nginx와, CLB의 조합보다, →  ALB는 트래픽 증가에 대한 auto scaling 기능이 우수하다.

3. 실존주의 철학의 장 폴 샤르트르의 (-_-;) 관점에서 이야기를 하자면,

  Route53는 태초에 DNS resolution을 위해 만들어진 서비스다. 

  Nginx는 태생이 Reverse Proxy server다.

  ALB는 애초에 오직 L7 layer Load Balancer 기능만을 위해 만들어졌다.

 

그리고 X2bee가 택한 MSA구조의 Kubernetes 배포 형태에서는 ALB의 장점이 여러가지가 있다.

 

ALB의 장점

여러가지가 있지만 다 나열하기는 힘들고

우선 가장 두드러진 장점은 아무래도 Layer 7의 이점을 다 살린 Load Balancer란 것이다.

즉, 다른 말로 하자면 content-based routing이 가능하다는 것이다.

     

    

content-based routing은 routing방식 여러 가지를 아우르는 가장 상위 개념의 용어다. 그러니까 path-based routing, host-based routing, request header에 따른 routing, query parameter에 의한 routing 등을 다 포함하는 포괄적인 용어다.

우선 path-based routing의 개념을 살펴보자면

example.com/app1 과 example.com/app2 가 서로 다른 리소스를 가리키게 할 수 있다.

 

ALB 설치 방법

AWS EKS에서 CLB를 설치하는 것은 간단하다.

svc(Service)에다가 'LoadBalancer'라고 딱 한 줄만 수정하면 뾰로롱~하고 생긴다.

그렇다면, 맨 위의 그림을 구현하기 위해서는

간단하게 코드 딱 한 줄로 구현했던 CLB대신에

코드 딱 한 줄로 ALB를 같은 걸 대체해주면 짜잔~하고 생기지 않을까?

아니다... ㅠㅠ

아주 복잡하다.

 

우선 가장 중요한 것이 CLB구현할 때는 필요도 없었던 AWS Load Balancer Controller 이라고 불리는 Ingress Controller를 EKS에 설치해야한다. 이것은 ALB를 configure할 때 쓰인다. 이 Controller는 Kubernetes Ingress 리소스와 조합하여, 다른 service와 pod의 routing traffic rule을 정의하는데 사용된다.  추상화가 한 단계 더 추가되는 것이다. (extra layer of abstraction이란 '분리'와 '간접적 접근'이 한 단계 더 추가되서 '운영'과 '유연성'을 발전시킨다는 뜻이다. 복잡해지는 걸 좋게 말해서 그렇다고 한다.)

 

개념을 대충 그리자면 다음과 같다. (ALB를 위 대신에 왼쪽에 그렸다. 그냥)

 

AWS Load Balancer Controller 설치

Controller 설치에 대해서는 다음 그림 하나만 이해하면 된다. (위의 개념 그림을 더 자세히 그렸다.)

(아래 그림 하나 그리는데 족히 1시간은 걸린듯... 휴...)

다음 글부터는 다음 그림을 계속 반복해서 올리면서 설치 절차를 쓸 예정이다.