Scale Out 패턴 - 서버 수의 동적 증감

ㅁ  풀어야 할 문제

웹 서비스의 과도한 트래픽 요청을 처리하기 위해 높은 사양의 서버를 통해 처리 능력을 높이는 방법을 Scale Up이라 함, 하지만 일반적으로 높은 사양의 서버는 사양이 올라감에 따라 처리 단가가 올라가며 서버 사양에 제한이 있어 무제한으로 높은 사양으로 만들 수 없음

 

ㅁ  해결/패턴

같은 사양의 서버를 여러 대 배치하고 높은 트래픽 요청을 처리하는 방법을 Scale Out이라고 함

여러 대의 가상 서버를 가동하고 로드 밸런서를 이용해 각 가상 서버에 부하를 분산

시스템에 따라서 매주 또는 매일 시간 단위로 트래픽이 급격하게 증감, 따라서 클라우드에서는 그렇게 변동이 심한 트래픽 양에 맞춰 처리를 담당하는 가상 서버의 수를 동적으로 구현하는 것이 쉽다.

 

ㅁ  구현

로드 밸런서 서비스 [ELB], 모니터링 툴[CloudWatch], 그리고 자동으로 스케일 아웃하는 [Auto Scaling] 이렇게 세 가지 서비스를 같이 사용하면 부하에 따라 자동으로 스케일 아웃하는 시스템을 쉽게 구축 가능

-       ELB 아래에 (웹/AP 서버로) EC2를 여러 대 배치

-       EC2를 새롭게 가동할 때 사용하는 AMI를 생성

-       EC2 수를 증감시키는 Trigger가 되는 조건을 정의. 

n  EC2의 평균 CPU 사용량, 네트워크 사용량, 세션 수, EBS의 지연 시간 등이 사용

-       그 측정 방법을 CloudWatch를 이용해 감시하고, 일정 조건을 만족하면 알람을 보내도록 설정

-       알람을 받았을 때 Auto Scaling이 EC2 수를 증감하게 설정

-       위 설정을 완료하면 상태에 맞춰 서버 수의 증감 가능

n  예) CPU 사용량 70% 이상인 상태가 5분 이상 지속될 경우 미리 준비한 AMI를 사용해 EC2 인스턴스 두 대를 가동

 

ㅁ  장점

-       트래픽 양의 증가에 따라 자동으로 EC2 인스턴스를 늘릴 수 있어 서비스의 연속성 확보

-       트래픽 양이 많지 않을 때는 EC2 인스턴스를 줄일 수 있어 비용 절감 가능

-       트래픽 양의 증감에 맞춰 자동으로 EC2 인스턴스를 증감시킬 수 있어 운영을 쉽게 할 수 있음.

-       ELB 아래에 필요한 수의 EC2 인스턴스를 배치할 수 있어 스케일 업과 비교하면 처리 능력의 한계는 매운 높음

 

ㅁ  주의점

-       수분 사이 트래픽이 몇 배가 되는 급격한 트래픽 변동은 대응하기 어려움, 따라서 미리 예비 EC2 인스턴스를 준비하여 부하에 견딜 수 있게 해두고, 나중에 불필요한 EC2 인스턴스를 삭제

-       HTTP 세션 관리나 SSL 처리 등을 ELB로 할 것인지 아니면 웹/AP 서버에서 처리할 것인 것 고려

-       ELB에는 사양에 따라 분산량을 변경하는 구조를 제공하지 않으므로 아래의 EC2 인스턴스 타입은 통일해야 함

-       웹/AP 서버 계층의 스케일 아웃에 비해 DB 서버 계층의 스케일 아웃은 일반적으로 어려움

-       안정성을 높이기 위해 여러 곳의 가용존에 분산하여 스케일 아웃 하는 것이 좋음

 

ㅁ 기타 

-       스케일 아웃 될 때 파일 공유는 Clone Server 패턴, NFS Sharing 패턴, NFS Replica 패턴을 참조

-       세션 관리에 대해서는 State Sharing 패턴을 참조

Scheduled Scale Out 패턴을 참조