다중 ALB 와 단일 ALB에 대하여

다중 ALB와 단일 ALB에 대해 간략하게 작성한 글 입니다.
2023.01.23

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요 클래스메소드의 수재입니다 이번에 담당한 안건에서 여러 서비스에 대해 다중 ALB로 운용할지 단일 ALB로 운용할지 고민한 일이 있어서 메모를 겸해 블로그를 작성합니다.

결론부터

여러 개의 ALB가 필요한 상황에서 대부분은 단일 ALB로 대응이 가능했습니다.
단 관리의 용이성이나 단일 ALB의 상한으로는 커버할 수 없는 요건이 있는 경우에는 역시 여러개의 ALB를 운용하는 것이 좋을 것 같습니다.

고민한 요건들

AWS WAF

ALB에는 AWS WAF를 연결하여 접속하는 트래픽을 조절할 수 있습니다.

작성한 WAF의 규칙 그룹(rule group)은 여러 대상에 연결할 수 있습니다.
WAF의 비용 조건은 연결한 대상의 수와는 관계없기 때문에 여러 대상에 연결한다고 해서 추가 비용이 발생하지는 않습니다.

자주 있는 케이스는 아니지만 적용하는 Rule이 서비스 별로 다르다면 여러 개의 Web ACL을 준비할 필요가 있고, 서비스 별로 준비된 ALB에 해당 ACL을 연결해야 합니다.1 단, 이러한 경우에는 당연히 여러 ACL을 사용하기 때문에 더 많은 비용이 발생합니다.

정리하자면 서비스 별로 다른 ACL을 적용할 필요가 있다면 다중 ALB와 다중 WAF Web ACL을 사용하고, 하나로도 대응할 수 있다면 단일 ALB와 단일 Web ACL로 대응할 수 있습니다.

고정 IP

ALB에 고정 IP가 필요한 경우 NLB 혹은 Global Accelerator(이하 GA) 를 연결하면 ALB에 고정 IP를 부여할 수 있습니다.
예전에는 NLB의 타겟으로 ALB의 IP를 지속적으로 등록해주는 람다 등이 필요했지만 지금은 타겟으로 ALB를 등록해주기만 하면 됩니다.
GA도 ALB를 생성할 때 같이 생성해주거나 나중에 ALB와 연결할 수도 있습니다.

단일 ALB에 위의 서비스들을 이용해서 IP를 부여하는 것은 어렵지 않습니다.
하지만 다중 ALB의 환경에서 고정 IP를 부여한다면 ALB 수 만큼 NLB나 GA를 생성할 필요가 있습니다.
정확히는 하나의 NLB나 GA로 여러 ALB를 관리하는 방법도 가능은 하지만 제대로 된 운용이라고는 생각되지 않습니다.2

NLB를 연결한다면 TCP나 UDP 연결은 다른 타겟으로 바로 향하게 하는 식의 운용이 가능하며 GA를 연결한다면 리전에 따른 엣지 로케이션의 이용이 가능하며 DDoS 공격에 대해서도 어느정도 보완이 가능해집니다.
두 서비스의 비용은 차이가 있기 때문에 비용에 대한 검토 후 도입을 결정하는 것이 좋습니다.

정리하자면 ALB의 수 만큼 고정 IP를 부여하기 위한 비용이 발생합니다. 상황에 맞추어 NLB나 GA 중 적절한 방법을 선택하면 되겠습니다.

인증서

여러 서비스를 운용하다보면 여러 증명서가 필요한 경우가 있습니다.
다중 ALB라면 각 ALB마다 필요한 인증서를 등록해서 대응이 가능합니다.
그리고 단일 ALB라도 다중 인증서를 처리할 수 있으므로3 인증서의 수는 문제가 되지 않습니다.
물론 간혹 발생하는 경우지만 단일 ALB로 다중 인증서를 처리하는 경우 클라이언트가 SNI를 처리할 수 있는 브라우저를 이용해야합니다.

비용

ALB의 비용은 ALB 자체의 이용 요금과 LCU 단위 당 요금이 있습니다.
총 LCU는 몇 개의 ALB를 사용라도 같다는 가정 하에 비용을 생각해자면, 다중 ALB를 이용함으로써 발생하는 추가 비용은 추가 ALB의 이용 요금만이 발생합니다. 단, LCU를 계산하는 기준이 있기 때문에 다중 ALB를 사용하는 경우 총 LCU가 단일 ALB와 비교해서 적거나 많아질 수 있기 때문에 단순히 (ALB 이용 요금 X 개수)로 산정한 비용과는 조금 차이가 있을 수 있습니다.

기능적인 측면

단일 ALB로 여러 서비스를 운용하게 된다면 리스너 규칙이나 타겟 그룹이 다중 ALB보다 더 많이 설정되어 있게 됩니다.
그리고 리스너 규칙을 설정하기 위해서는 우선순위도 결정하게 됩니다.
그럼 가장 낮은 우선순위의 리스너 규칙은 느리게 처리되지는 않습니다.
정확하게는 우선순위에 따른 대기 시간은 발생하지만 그 차이가 밀리초 단위4이기 때문에 서비스의 운용에서는 고려하지 않아도 될 사항이라고 생각합니다.
만약 그러한 특징도 고려해야한다면 리스너 규칙을 여러 ALB에 나누어 설정하여 대기 시간을 줄이는 것이 좋습니다.

그 외

관리적인 측면으로 본다면 서비스 별로 담당하는 ALB를 확실히 구분하는게 운영적으로도 좋습니다.
리스너 규칙에는 별도의 설명문 등을 추가할 수 없기 때문에 만약 단일 ALB에 모든 설정을 적용한 경우 삭제나 설정 실수 등이 발생 할 수 있습니다.

또한 단일 ALB의 경우에는 모니터링 등을 위해 CloudWatch나 Config 의 정보를 확인할 때도 하나의 ALB에 모두 연관되기 때문에 이러한 측면에 요구 사항이 있다면 다중 ALB를 이용하는 것이 좋은 경우도 있습니다.

마무리

제가 담당했던 안건에서는 6개의 ALB와 단일 ALB 중 어느 쪽을 채택할 것인지 고민했었습니다.
결국 비용적인 부분, 다른 여러 상황을 고려해서 우선 단일 ALB를 이용하다가 상한치를 넘는 경우 추가 ALB를 사용하는 식으로 진행하게 되었습니다.
비슷한 내용으로 고민하시는 분들에게 이 글이 도움이 되었으면 합니다.

긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 언제나 환영합니다. must01940 지메일로 연락 주시면 감사합니다!


본 블로그 게시글을 보시고 문의 사항이 있으신 분들은
클래스메소드코리아 (info@classmethod.kr)로 연락 주시면 빠른 시일 내 담당자가 회신 드릴 수 있도록 하겠습니다 !


  1. 서비스 레이어에서 조절할 수 있다면 단일 ACL로 처리할 수 있는 케이스도 있습니다. 
  2. NLB는 리스너의 포트 번호를 다르게 해서 여러 ALB에 연결하거나 GA는 여러 ALB를 다른 가중치로 등록하는 등의 편법으로 어떻게든 해결이 가능하겠지만 좋은 방법이라고는 생각되지 않습니다. 
  3. 공식 문서 
  4. 출처:What's the latency of the ALB Listener priority evaluation