Auto Scaling과 고가용성은 "서비스가 절대 멈추지 않도록 만드는" 기술입니다.
식당을 운영한다고 상상해보세요. 점심 시간에 손님이 몰리면 직원을 더 투입하고, 저녁에 한가해지면 줄입니다(Auto Scaling). 여러 테이블에 손님을 골고루 배치합니다(Load Balancing). 주방이 하나 고장 나도 다른 주방에서 계속 요리합니다(Multi-AZ). 이게 바로 AWS의 고가용성 설계입니다.
Auto Scaling Group(ASG) — 서버 수를 자동으로 조절
ASG는 EC2 인스턴스의 수를 자동으로 늘리거나 줄이는 서비스입니다.
Launch Template — 인스턴스 생성 레시피
인스턴스를 만들 때 사용하는 설정 모음입니다. 요리 레시피처럼, 어떤 재료(AMI, 인스턴스 유형)를, 어떻게 준비하고(보안 그룹, 키 페어), 시작 시 무엇을 실행하는지(User Data 스크립트)를 정의합니다.
Launch Configuration이라는 이전 방식도 있지만, 현재는 Launch Template 사용을 권장합니다. Launch Template은 버전 관리가 되고, 스팟 인스턴스 설정도 지원하는 등 기능이 더 많습니다.
용량 설정 — 최소, 최대, 목표
| 설정 | 의미 | 예시 | |------|------|------| | Minimum | 절대 이 수 아래로 줄지 않음 | 최소 2대 (항상 유지) | | Desired | 현재 유지하려는 목표 수 | 현재 5대를 유지하고 싶음 | | Maximum | 절대 이 수 이상으로 늘지 않음 | 아무리 바빠도 20대 이하 |
Minimum을 0으로 설정하면 트래픽이 없을 때 모든 인스턴스를 종료해 비용을 절약할 수 있습니다. 하지만 Production 환경에서는 위험하므로 최소 2대 이상 유지하는 것이 일반적입니다.
스케일링 정책 — 언제 서버를 늘리고 줄일까
Target Tracking (목표 추적 스케일링)
가장 간단하고 가장 많이 권장되는 방식입니다. "CPU 사용률을 50%로 유지해줘"처럼 목표값을 정해주면 ASG가 알아서 인스턴스를 늘리거나 줄입니다. 에어컨의 온도 설정처럼, "25도로 유지"라고 하면 에어컨이 알아서 켜지고 꺼집니다.
Step Scaling (단계적 스케일링)
경보의 심각도에 따라 다른 행동을 합니다. 예를 들면 이렇습니다. CPU가 60~70%이면 인스턴스 1개 추가 CPU가 70~80%이면 인스턴스 2개 추가 CPU가 80% 이상이면 인스턴스 3개 추가
더 세밀한 제어가 필요할 때 사용합니다.
Scheduled Scaling (예약 스케일링)
시간 기반 스케일링입니다. 트래픽 패턴이 예측 가능할 때 유용합니다. "매일 오전 8시 30분에 인스턴스를 10대로 늘리고, 오후 6시에 3대로 줄여라"처럼 사전에 일정을 잡습니다. 업무 시간에 트래픽이 집중되는 기업 내부 시스템에 적합합니다.
Predictive Scaling (예측 스케일링)
머신러닝으로 과거 트래픽 패턴을 분석하고 미래 수요를 예측합니다. 트래픽이 갑자기 몰리기 전에 미리 인스턴스를 준비해둡니다. 예를 들어 매주 월요일 오전에 트래픽이 급증하는 패턴이 있다면, 일요일 밤부터 인스턴스를 미리 늘려놓습니다.
| 정책 | 특징 | 가장 적합한 상황 | |------|------|---------------| | Target Tracking | 목표값 설정, 자동 유지 | 대부분의 일반적인 상황 | | Step Scaling | 수준별로 다른 대응 | 세밀한 제어가 필요할 때 | | Scheduled Scaling | 시간 일정 기반 | 패턴이 예측 가능할 때 | | Predictive Scaling | ML로 미래 예측 | 주기적 패턴, 선제 대응이 필요할 때 |
!Auto Scaling 정책 4가지 유형
ELB — 트래픽을 여러 서버에 나눠주기
ELB(Elastic Load Balancer)는 들어오는 요청을 여러 EC2 인스턴스에 분산하는 서비스입니다. 은행 창구처럼, 고객을 여러 창구 직원에게 골고루 배분하여 누구도 너무 바빠지지 않게 합니다.
ELB의 네 가지 유형
ALB(Application Load Balancer)는 HTTP/HTTPS 트래픽을 다루는 7계층 로드 밸런서입니다. URL 경로나 호스트 이름에 따라 다른 서버 그룹으로 보낼 수 있습니다. 예를 들어 로 시작하는 요청은 API 서버로, 로 시작하는 요청은 이미지 서버로 보냅니다. 웹 애플리케이션, 마이크로서비스 아키텍처에 적합합니다.
NLB(Network Load Balancer)는 TCP/UDP 트래픽을 다루는 4계층 로드 밸런서입니다. 초당 수백만 건의 요청을 처리할 수 있고 지연 시간이 극히 낮습니다. 고정 IP 주소를 가질 수 있어서 IP 주소가 변하면 안 되는 환경에 유용합니다. 게임 서버, IoT, 실시간 금융 거래에 적합합니다.
CLB(Classic Load Balancer)는 예전 방식의 로드 밸런서로, 새로운 기능이 없습니다. 새로 만드는 시스템에서는 사용을 권장하지 않습니다.
GWLB(Gateway Load Balancer)는 네트워크 어플라이언스(방화벽, IDS/IPS 등)를 투명하게 삽입할 때 사용합니다. 모든 트래픽이 이 보안 장치를 거치도록 강제하는 아키텍처에서 사용합니다.
| ELB 유형 | 계층 | 핵심 특징 | 주요 용도 | |---------|------|---------|---------| | ALB | 7계층(HTTP) | 경로/호스트 기반 라우팅 | 웹 앱, 마이크로서비스 | | NLB | 4계층(TCP/UDP) | 초저지연, 고정 IP, 초당 수백만 요청 | 게임, IoT, 금융 | | CLB | 4/7계층 | 레거시 | 기존 시스템만 | | GWLB | 3계층 | 네트워크 어플라이언스 삽입 | 방화벽, IDS/IPS |
헬스 체크 — 서버가 살아있는지 확인
헬스 체크는 인스턴스가 정상인지 주기적으로 확인하는 기능입니다. 정상이 아닌 인스턴스는 트래픽에서 제외되고 새 인스턴스로 교체됩니다.
EC2 헬스 체크 vs ELB 헬스 체크
| 구분 | EC2 헬스 체크 | ELB 헬스 체크 | |------|-------------|-------------| | 무엇을 확인하나요? | 물리적 하드웨어와 하이퍼바이저 상태 | 애플리케이션이 HTTP 응답을 정상으로 보내는지 | | 어떤 문제를 감지하나요? | 서버가 물리적으로 죽은 경우 | 앱이 다운되어 500 에러를 반환하는 경우 | | ASG 기본 설정 | 기본으로 활성화 | 별도로 활성화해야 함 |
가장 중요한 시험 포인트: ASG에서 EC2 헬스 체크만 사용하면, 애플리케이션이 완전히 다운되어 HTTP 500 에러를 반환해도 EC2 인스턴스 자체(물리 서버)는 살아있으므로 "정상"으로 판단됩니다. 결국 ASG가 망가진 인스턴스를 교체하지 않습니다.
이 문제를 해결하려면 ASG에서 ELB 헬스 체크를 활성화해야 합니다. 그러면 앱이 다운되면 ELB가 헬스 체크 실패를 감지하고 ASG에 알려 인스턴스를 교체합니다.
Multi-AZ 설계 — 하나가 죽어도 살아남는 구조
가용 영역(AZ, Availability Zone)은 독립된 데이터센터입니다. 한 AZ가 정전이나 자연재해로 다운되어도 다른 AZ는 영향을 받지 않습니다.
Multi-AZ 설계의 핵심 원칙은 리소스를 여러 AZ에 분산하는 것입니다.
ASG를 여러 AZ에 걸쳐 구성하면, 한 AZ에 문제가 생겨도 다른 AZ의 인스턴스가 계속 트래픽을 처리합니다.
ALB와 NLB는 자동으로 여러 AZ에 걸쳐 트래픽을 분산합니다.
RDS Multi-AZ는 데이터베이스를 두 개의 AZ에 동기식으로 복제합니다. 하나가 다운되면 몇 초~몇 분 안에 자동으로 다른 AZ의 복제본으로 전환됩니다. 엔드포인트(주소)는 변하지 않으므로 애플리케이션 코드를 수정하지 않아도 됩니다.
ElastiCache도 여러 AZ에 복제본을 배치하여 읽기 성능 향상과 장애 대비를 동시에 달성할 수 있습니다.
혼합 인스턴스 정책(Mixed Instances Policy) — 비용 절감 전략
온디맨드 인스턴스는 언제든 사용할 수 있지만 비쌉니다. 스팟 인스턴스는 AWS가 남는 용량을 저렴하게(최대 90% 할인) 파는 것으로, 언제든 중단될 수 있습니다.
혼합 인스턴스 정책은 하나의 ASG에서 온디맨드와 스팟을 함께 사용합니다. 안정적으로 유지해야 하는 최소 용량은 온디맨드로, 추가로 필요한 용량은 스팟으로 채우는 방식입니다.
예를 들어 항상 최소 4대의 온디맨드 인스턴스를 유지하고, 트래픽이 많을 때 필요한 추가 서버는 스팟 인스턴스로 채웁니다.
용량 재균형(Capacity Rebalancing): AWS가 스팟 인스턴스를 회수하려 할 때 미리 새로운 스팟 인스턴스를 시작해서 갑작스러운 용량 감소를 방지합니다.
여러 인스턴스 유형 지정: 스팟 시장에서 특정 유형의 용량이 없을 때를 대비해 m5.large, m5a.large, m4.large처럼 비슷한 스펙의 여러 유형을 함께 지정합니다.
Capacity Reservations
특정 AZ에서 특정 인스턴스 유형의 용량을 미리 예약합니다. 재해 복구나 규정 준수 요건으로 "반드시 us-east-1a AZ에서 c5.xlarge 인스턴스 10대를 보장해야 한다"는 경우에 사용합니다.
시험 핵심 정리
"CPU를 50%로 유지하는 가장 간단한 스케일링" -- Target Tracking
"CPU 수준에 따라 추가 대수를 다르게" -- Step Scaling