[ALB] 왜 ALB는 고정 IP의 할당이 불가능할까?

Contents

개요

AWS를 사용하면 이런 의문점이 든다. 왜 NLB는 고정 IP 할당이 가능한데 ALB는 고정 IP 할당이 불가능할까?

그 이유에 대해서 간략하게 소개한다.

 

ALB의 작동방식

왜 ALB에 고정 IP를 할당하지 못하는지에 대해서 알기 위해서는 ALB가 어떻게 작동하는지 알 필요가 있다.

우리가 AWS에서 ALB를 생성하게 되면 해당 서브넷에 EC2가 생성된다. 하지만 그 EC2는 AWS가 관리하고 있기 때문에 우리는 인식할 수 없다.

이렇게 ALB의 로드밸런싱은 내부적으로 EC2에서 작동하는 것이다.

• 볼 수 없는 EC2에 바인딩된 ENI는 우리가 확인할 수 있다. ENI 메뉴에서 확인할 수 있다.

💡 아마 ALB의 로드밸런싱은 EC2 서버에 LoadBalaning을 담당하는 소프트웨어를 설치 후 소프트웨어 단에서 처리하는 게 아닐까 짐작해 본다.

 

ALB의 Autoscaling 방식

바로 위에서 ALB는 우리가 볼 수 없는 EC2로 동작한다고 했다.

ALB에 부하가 많이 발생할 경우 내부적으로 ALB EC2에는 다음의 변화를 거친다.

 

Scale Out

1. 하나의 AZ에 배포되어 있는 ALB EC2에 Scale Up이 발생한다.

2. 다른 AZ에 배포되어 있는 ALB EC2에 Scale Up이 발생한다.

💡 더 이상의 Scale Up이 될 수 없을 때까지 1번과 2번 과정을 반복하게 된다.

3. 이후부터는 최종 Scale Up 된 ALB EC2의 Scale Out이 발생한다.

💡 Scale Out에는 약 5분 정도 소요된다.

 

Scale In

Scale In의 작동 방식은 간단하다. Scale Out의 역순으로 수행되는데 Scale Out에 비해 수백 배 정도 더 느리게 Scale In이 발생한다.

 

트래픽이 많이 발생할 것 같으면?

특정 시간대에 이벤트를 진행한다고 생각해 보자. 일반적인 경우라면 그 시간대에만 서버를 더 늘리면 간단하게 해결할 수 있겠지만 ALB는 내부적으로 EC2로 동작하기 때문에 사용자가 서버를 더 늘릴 수는 없다.

 

그러면 사용자가 조치할 수 있는 방법은 없을까?

물론 있다. 단, 절차는 다소 까다로운데 미리 AWS에 Scale Out을 요청하면 AWS에서 서버를 늘려주는 방식이다.

이를 ELB Pre-warming이라고 한다.

💡 단, ELB Pre-Warming 신청은 AWS Support plan에 가입되어 있어야 신청할 수 있다.

아래의 ELB Pre-Warming 신청 양식에 따라 내용 작성하고 AWS Support Center에 Case를 올려주면 된다.

1. ELB DNS Name
: ELB 명

2. Event start date/time
: 이벤트 시작 시간

3. Event end date/time
: 이벤트 종료 시간

4. Pre-Warm 필요 Instance 수

5. (정기적인 이벤트가 예상되는 경우) Event 주기
: ex. Weekly 매주 목요일 20:20 ~ 20:40 (KST/UTC 표기)

6. (정기적인 이벤트가 예상되는 경우) Event 총 기간
: 몇개월 동안 이벤트가 진행되는지 (시즌 기간)

7. Expected percent of traffic going through the ELB that will be using SSL termination.
: SSL 사용 비욜 (%)

8. An approximate percentage increase in traffic, or expected requests/sec that will go through the load balancer.
: 예측되는 트래픽, 요구되는 Request per second 성능 수치 (ex. 1,500 request/sec)

9. Average amount of data passing through the ELB per request/response pair (In Bytes)
: 요청 + 응답 데이터 사이즈

※ 200KBytes와 같은 크기는 요청과 응답 데이터 사이즈로는 너무 크고 통상적이지 않습니다.
보통은 20KBytes 이내 입니다.

10. Number of Availability Zones enabled
: Target Group에 속해 있는 AZ들 (ex. ap-northeast-2a, ap-northeast-2c)

※ 주의: Pre-Warming 요청 시, 등록되어 있는 모든 AZ에 target instance가 존재해야 합니다.

11. Is the back-end currently scaled to the level it will be during the event?
: AutoScaling 등이 적용되어 있는가? (보통 AutoScaling 이라고 작성하시면 됩니다.)

12. A description of the traffic pattern you are expecting
: 트래픽 패턴이 어떤지? (Spiky 라고 작성하시면 됩니다.)

13. A brief description of your use case.
: 사용 사례 설명 (New game launch 혹은 Game event 등)

14. Are the back-end instances using persistent connections (Keep-alive)?
: Target instance가 keep alive를 사용하는가?

- 출처 : https://support.bespinglobal.com/ko/support/solutions/articles/73000544756--aws-elb-pre-warming-%EC%8B%A0%EC%B2%AD-%EA%B0%80%EC%9D%B4%EB%93%9C

 

마치며

ALB는 위에서 설명했듯이 내부적으로 EC2를 생성 후 동작하고 생성된 EC2의 IP는 수시로 변동이 되기 때문에 고정 IP를 할당할 수 없는 것이다. (간단하게 말하자면 Hyper Plane 동작하기 때문인데 Hyper Plane에 대한 내용은 추후 다시 포스팅할 예정이다.)

언젠가는 AWS에서 ALB에 고정 IP를 할당할 수 있게 해주지 않을까?

 

 

Reference

• https://support.bespinglobal.com/ko/support/solutions/articles/73000544756--aws-elb-pre-warming-%EC%8B%A0%EC%B2%AD-%EA%B0%80%EC%9D%B4%EB%93%9C