6 min to read
AWS #4 / TIL
수평 확장
Auto Scaling
미리 정해 놓은 규칙에 따라 워크로드(작업량)를 자동으로 확대/축소 할 수 있는 기술. 클라우드가 제공하는 탄력성에 의해 만들어지고 사용자의 요구 수준을 반영할 수 있는 기술이다.
Auto Scaling을 이용하면 처리 요구량이 급등하는 시기(피크 워크로드)에 맞춰 새 리소스를 자동으로 추가, 설정하고 처리 요구량이 줄어들면 해당 리소스를 감소시키기 때문에, 과잉 *프로비전을 할 필요성이 사라진다.
-
동적 스케일링
Auto Scaling의 가장 큰 장점은 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있다는 점이다. 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업 할 수 있다. -
로드 밸런싱
Auto Scaling은 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리할 수 있다. Auto Scalig은 리소스를 동적으로 스케일 업/다운하는데, 로드 밸런서와 함께 사용하면 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있고, 다수의 AZ에 분포된 EC2 인스턴스에 대한 워크로드도 자동으로 분배하도록 설정할 수 있다. -
타켓 트래킹
사용자는 특정 타겟에 대해서만 Auto Scaling 할 수 있으며, 사용자가 설정한 타켓에 맞춰 EC2 인스턴스의 수를 조정한다. -
헬스 체크와 서버 플릿 관리
Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있다. 헬스 체크를 하는 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체한다.
Auto Scaling은 적정 수준의 *서버 플릿 용량을 유지하는 데에 도움을 준다. 한 대 또는 그 이상의 서버가 다운 되면, Auto Scaling은 6대의 서버 인스턴스 처리 용량을 유지하기 위해 부족한 부분만큼의 서버를 추가로 실행시키는 방식으로 서버 플릿을 유지한다.
EC2 Auto Scaling 활용
시작 템플릿
Auto Scaling으로 인스턴스를 확장/축소하려면 어떤 서버를 사용할지 결정해야 한다. 시작 템플릿을 통해 AMI 상세 정보, 인스턴스 가입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있다.
Auto Scaling 그룹 생성
Auto Scaling 그룹은 스케일업/다운 규칙의 모음으로 EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있다. 따라서 Auto Scaling 그룹을 생성하기 위해 스케일링 정책 및 유형에 대해 잘 숙지하고 있어야 한다.
| 유형 | 설명 |
|---|---|
| 인스턴스 레벨 유지 | 기본 스케일링 계획이라고도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있다. 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정하면 된다. |
| 수동 스케일링 | 기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있다. 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가, 삭제 해야 한다. (추천하지 않는 방식) |
| 예측 스케일링 | 트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도 트래픽이 증가하는지 패턴을 파악하고 있다면 일정 별 스케일링을 사용하는 것이 좋다. (낮 : 트래픽 최고치, 스케일 업. 밤 : 트래픽 거의 없음, 스케일 다운) |
| 동적 스케일링 | 수요 변화에 대응하여 용량을 조정하는 방법. CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정한다. (CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속되면 Auto Scaling이 작동되어 새 서버를 추가하는 방식) |
EC2 Auto Scaling 동적 스케일링 정책 유형
- 타겟 트랙킹 스케일링 : 미리 정의된 성능 지표를 이용하거나, 커스텀 성능지표(custom metric)을 사용하여 타겟 값으로 설정할 수 있다.
- 단순 스케일링 : 단 하나의 스케일링 설정에 따라 그룹의 현재 용량을 늘리거나 줄인다. 새 인스턴스를 시작 혹은 정지 시키기 위한 대기 시간도 정의할 수 있으며 이를 쿨다운 기간이라고 부른다.
- 단계 스케일링 : 단순 스케일링은 특정 이벤트에 대해 매번 같은 액션을 한다면, 단계 스케일링은 좀 더 세분화 해서 단계를 나누어 규칙을 추가할 수 있다.
인스턴스 삭제 정책
스케일다운 정책이 적용되면, EC2 인스턴스가 삭제되며, 서버를 셧다운 하는 것은 리소스 관리 측면에서도 꼭 필요한 일이다. 스케인 다운 정책에서는 명확하게 몇 개의 인스턴스를 삭제할 것인지 정의할 수 있으며, 어떤 인스턴스를 먼저 셧다운 할 것 인지 환경 설정을 통해 결정할 수 있다.
- 사용자의 서버 플릿에서 가장 오랫동안 실행된 서버를 삭제한다. 가장 오랫동안 실행된 서버일수록 패치 수준이 낮고 메모리 누수 등의 문제가 누적해 있을 가능성이 크기 때문에 이를 삭제함으로써 최신의 성능 기준을 유지할 수 있다는 장점이 있다.
- 시간 단위 과금이 임박한 서버를 삭제한다. 이 서버를 삭제하면 Auto Scaling의 특유 장점을 최대한 살려, 과금 부담을 줄일 수 있다.
Elastic Load Balancing (ELB)
로드 밸런싱 (부하 분산)
로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자 별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산한다. 이러한 작동을 로드 밸런싱이라고 하고, AWS에서 제공하는 이러한 방식의 서비스가 ELB이다.
ELB는 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산한다. 등록된 대상의 상태를 모니터링하며 상태가 양호한 대상으로만 트래픽을 라우팅 한다.
- ELB는 트래픽을 다수의 EC2 인스턴스, 컨테이너, AZ로 분산 시킬 수 있기 때문에 가용성 아키텍처를 구현하는데 도움을 준다.
- 관리자는 인스턴스 추가, 삭제를 위한 어떤 수작업도 할 필요도, 수동으로 뭔가를 할 여지도 없기 때문에 ELB의 최대 장점은 자동적 확장성이다.
- 통합 인증관리, SSL 복호화, 포트 포워딩 등 다수의 보안 기능을 제공한다.
- ELB는 트래픽 증가를 처리할 수 있도록 설계되어 초당 수백만 개의 요청을 로드 밸런싱할 수 있고, 변동이 심한 트래픽 패턴도 처리할 수 있다.
작동 방식
- 로드 밸런서는 클라이언트에 대한 단일 접점으로, 클라이언트에서 오는 트래픽을 허용하고, 하나 이상의 가용 영역에서 등록된 대상(EC2 인스턴스)으로 요청을 라우팅한다.
- 로드 밸런서는 등록된 타켓의 상태를 모니터링하고 정상 타겟으로만 트래픽이 라우팅 되도록 한다.
- 로드 밸런서가 비정상 타켓을 감지하면, 해당 타겟으로 트래픽 라우팅을 중단하고, 타켓이 정상으로 감지되면 트래픽을 해당 타켓으로 다시 라우팅 한다.
- 리스너는 구성한 프로토콜 및 포트를 사용해 클라이언트의 연결 요청을 확인하고, 리스너에 대해 정의한 규칙에 따라 로드 밸런서가 등록된 타겟으로 요청을 라우팅하는 방법이 결정된다.
- 각 규칙은 우선 순위, 하나 이상의 작업, 하나 이상의 조건으로 구성되며, 규칙에 대한 조건이 충족되면 작업이 수행된다.
- 각 리스너에 대한 기본 규칙을 정의해야 하며, 필요에 따라 추가 규칙을 정의할 수 있다.
- 각 타겟 그룹은 지정한 프로토콜과 포트 번호를 사용하여 EC2 인스턴스 같은 하나 이상의 등록된 타겟으로 요청을 라우팅하는데, 여러 대상 그룹에 타겟을 등록할 수 있고, 타겟 그룹 기준으로 상태 확인을 구성할 수 있다.
- 로드 밸런서의 리스너 규칙에서 지정한 타겟 그룹에 등록된 모든 타겟에서 헬스 체크를 수행한다.
ELB 유형
Application Load Balancer
OSI 모델의 레이어 7에 해당하며, HTTP와 HTTPS를 지원한다. ALB에서는 헤더 수정이 가능하고, ALP 호스트 기반 라우팅을 통해 HTTP 헤더의 Host 필드에 따라 클라이언트 요청을 라우팅할 수 있고, 경로 기반 라우팅을 통해 HTTP 헤더의 URL 경로에 따라 클라이언트 요청을 라우팅할 수 있다.
Network Load Balancer (TCP 로드 밸런서)
OSI 모델의 레이어 4에서 작동하며, 로드 밸런서가 연결 요청을 받으면 기본 규칙의 타겟 그룹에서 대상을 선택한다. 리스너 구성에 지정된 포트에서 선택한 타겟에 대한 TCP 연결을 열려고 시도한다.
-
TCP 트래픽 : 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트, TCP 시퀀스 번호에 따라 흐름 해시 알고리즘을 사용해 타겟을 선택한다. 클라이언트로부터 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 타겟에 라우팅될 수 있다. 각 TCP 연결은 연결 수명 동안 하나의 타겟에 라우팅된다.
-
UDP 트래픽 : 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트에 따라 흐름 해시 알고리즘을 사용해 타겟을 선택한다. UDP 흐름은 소스와 목적지가 동일하기 때문에 수명이 다할 때까지 일관되게 단일 타겟으로 라우트 된다. 서로 다른 UDP 흐름에는 서로 다른 IP 주소와 포트가 있으므로 다른 타겟에 라우팅될 수 있다.
AZ가 고가용성을 구현하기 위한 기본 구조이기 때문에 Auto Scaling과 ELB를 활용해 애플리케이션을 구현할 때는 가능한 다중 AZ를 기반으로 할 것을 권장한다. ELB가 트래픽을 AZ간에 균등하게 배분할 수 있으므로, AWS 생태계를 기반으로 서비스를 구현할 때 다중 AZ 구조의 활용은 당연하다.