[AWS] Availability and Scalability

 

 

 

AWS에서는 ELB(Elastic Load Balancer)를 사용해 트래픽을 여러 대상에 효율적으로 분신시켜 애플리케이션의 Availability와 Scalability를 높인다. 

 

리버스 프록시처럼 클라이언트의 요청을 로드밸런서가 받아 여러 백엔드 리소스에게 넘겨주는 역할을 수행한다.

이 때 트래픽 분산 알고리즘과 Health Check가 적용되고, 트래픽 증감에 따라 ELB는 자동으로 확장되거나 축소된다.

 

클라이언트에게 백엔드 리소스의 IP 정보를 숨길 수 있어 보안을 강화할 수 있고, 복잡한 설정을 AWS가 자동으로 관리해줘서 개발자는 비즈니스 로직 개발에 집중할 수 있다. 

 

실제로 EC2에 엔진엑스같은 웹서버를 설정해 직접 로드밸런서를 구성할 수도 있지만, ELB가 제공하는 Auto Scailing, 다중 Availability Zone 지원 등 다양한 편의 기능을 직접 설계해야 하니 웬만하면 ELB를 가져다 사용한다.

 

 

Application Load Balancer

OSI Layer 7계층인 애플리케이션 계층에서 HTTP 및 WebSocket 요청을 처리하는 로드밸런서로 트래픽의 세부 조건에 따라 요청을 라우팅 할 수 있다. 

 

Listener에 로드밸런서가 요청을 수신하는 조건을 정의하고 (프로토콜, 포트)

Listener Rule에 Listener가 수신한 요청을 어떻게 평가하고 처리할 지 정의하며 (URL, Hostname, 쿼리스트링)

Target Group에 Listener Rule이 라우팅한 요청을 실제로 처리할 백엔드 리소스를 정의한다. (EC2)

 

클라이언트가 HTTP 요청을 ALB로 보내고, ALB는 앞서 설정한 조건을 확인하고 Target Group으로 요청을 전달한다.

 

네트워크 수준(L4) 에서 접근을 제어할 때는 Security Group을 사용하고, 애플리케이션 계층(L7) 에서 트래픽 라우팅 로직을 정의할 때는 Listener Group을 Rule을 사용한다. 

 

Networ Load Balancer

OSI Layer 4계층에서 TCP, UDP, TLS 기반 트래픽을 처리한다.
High Performance, Low Latency, 고정 IP가 필요한 애플리케이션에 적합하다.

 

전송 계층 프로토콜을 기반으로 트래픽을 처리해 초당 수백만의 요청을 처리할 수 있고, 4계층에서 작동해 응답 시간도 빠르다.

NLB는 각 Availability Zone에 고정 IP를 제공해 클라이언트가 항상 동일한 IP로 해당 NLB에 접근할 수 있다. (ALB는 동적IP)

 

URL, Hostname 기반 라우팅으로 MSA나 서버리스 아키텍처를 구축할 때는 ALB를 사용하고 

클라이언트가 고정 IP로 로드밸런서에 접근하거나 속도가 많이 중요한 환경에서는 NLB를 사용하자. 

 

Gateway Load Balancer

OSI Layer 3계층에서 방화벽, 패킷 검사 등을 통합하고 확장할 수 있도록 설계되어있다.

IP 패킷 수준에서 트래픽을 처리하고 상위 프로토콜을 분석하지 않는다.

 

 

 

트래픽을 보안 Appliance에 전달할 때 GENEVE encapsulation 방식을 사용한다. 

 

 

ELB를 사용할 때 Sticky Session을 사용하면 클라이언트의 요청을 항상 동일한 백엔드 리소스로 라우팅 할 수 있다.
클라이언트가 처음 로드밸런서에 요청을 보낼 때, 로드밸런서는 요청을 처리할 백엔드 리소스를 선택하고 선택한 내용을 쿠키에 담아 클라이언트의 응답에 포함시킨다. 

 

로드밸런서가 백엔드 리소스와 연결할 때 쿠키를 사용하는데, 서버 장애 시 세션 데이터 손실 가능성이 있으니 Redis 등 외부 저장소를 저장하는 경우도 있다.

 

 

 

 

로드밸런서는 설계상 여러 Availability Zone에 걸쳐 트래픽을 분산할 수 있도록 설계되어있고, 각 영역 간 연결을 관리한다.
Cross-Zone 로드밸런싱 옵션을 활성화 한 경우 모든 영역에 대해 골고루 요청을 분배하고, 해당 옵션을 적용하지 않은 경우 각 영역별로 요청을 분배한다. 

 

 

 

 

클라우드를 대여해서 사용할 때 사용자의 트래픽에 따라 인스턴스를 추가하거나 제거하는 기능을 구현할 때는 AWS가 제공하는 Auto Scaling Group을 사용한다.

 

여러 Auto Scaling 정책을 통해 리소스 사용을 최적화하고, 관리하는 EC2 인스턴스들의 상태를 지속적으로 감시해 비정상 인스턴스를 자동으로 교체해준다.

 

Launch Template에 ASG 내부에서 관리될 EC2 인스턴스의 AMI, 유형, 보안 그룹, 요금제 등을 정의하고 해당 템플릿을 기반으로 최소 / 최대 / 요구 인스턴스 수를 설정한다. 

 

트래픽이 많아지거나 적어지면 정의해 둔 인스턴스 수 안에서 EC2 인스턴스가 추가되거나 중단되는 수직적 확장 구조로 트래픽을 분산시킨다. 

ASG는 수평적 확장만을 지원하니 제대로 활용하기 위해서는 ELB를 꼭 함께 사용해 줘야 하고, 수직적 확장 구조는 보통 분산 처리가 불가능한 단일 노드 환경에서 자주 사용된다. 

 

Target Tracking - API 호출량, 네트워크 트래픽,CPU 사용량 등 특정 지표를 유지하도록 스케일링하는 전략이다.

Scheduled Scaling Policy - 특정 시간대나 주기적 스케쥴에 따라 인스턴스를 조정하는 전략이다. 

Predictive Scaling Policy - 기계 학습 모델으로 과거 트래픽 데이터를 기반으로 부하를 예측하고 스케일링한다. 

 

CloudWatch와 ASG를 함께 사용해 스케일링 정책을 구현할 수 있다.

 

 

온프레미스 서버에 Tomcat을 배포할 때는 Tomcat을 실행할 때 설정한 메모리 내에서 RAM을 사용할 수 있어, Heap Space공간을 모두 사용하고 GC로도 메모리 사용량이 커버되지 않을 경우 Out of memory한다.

 

이 때 배포 서버에 원격으로 붙어서 Tomcat 메모리를 올리거나 다른 서버에서 실행되는 다른 프로그램을 종료해 RAM을 확보해 줘야 하는데..

 

AWS의 Auto Scaling, Health Check 기능을 사용하면 이런 오류를 예방할 수 있다.