서버 배포 체크리스트: ④ 가용성 및 확장성 (Scalability & HA)

단일 장애점(SPOF)을 제거하고 트래픽 증가에 유연하게 대응할 수 있는 아키텍처 구축 방법이다.

1. 단일 장애점(SPOF) 제거하기

SPOF(Single Point of Failure)란 그 부분이 고장나면 전체 시스템이 중단되는 지점을 말한다.

• 위험한 구조: 1개의 가용 영역에 서버 1대만 가동 → 해당 데이터 센터에 불이 나거나 네트워크 장애 시 즉시 중단.
• 안전한 구조: 최소 2개 이상의 가용 영역에 서버를 나누어 배치

2. 로드 밸런서(ALB)의 역할

서버를 여러 대 띄웠다면 사용자 트래픽을 골고루 나누어줘야 한다. 이것이 바로 Application Load Balancer(ALB)이다.

• 상태 확인 (Health Check): ALB는 연결된 서버들이 살아있는지 주기적으로 핑을 보낸다. 특정 서버가 응답하지 않으면 해당 서버로의 트래픽을 즉시 차단하고 살아있는 서버로만 보낸다.
• SSL 중단 (SSL Termination): HTTPS 인증서를 로드 밸런서에 설치하여 개별 서버가 복잡한 암호화 계싼을 하지 않도록 부하를 덜어줄 숭 ㅣㅆ다.

3. 오토 스케일링 (Auto Scaling): 탄력적인 서버 관리

트래픽은 고정되어있지 않다. 낮에는 사람이 몰리고 밤에는 사람이 거의 없다. 그리고 이벤트를 하면 그 시간에는 폭발적으로 증가한다.

• Scale-out: 트래픽이 많아지면 서버를 자동으로 늘린다
• Scale-in: 트래픽이 줄어들면 서버를 줄여 비용을 아낀다.
• 효과: 갑작스러운 이벤트나 공격성 트래픽에도 서비스가 터지지 않게 보호한다.

4. 데이터베이스 가용성 (RDS Multi-AZ)

서버만 여러 대라고 안전한 것은 아니다. DB가 죽어버리면 소용이 없다.

• Standby Instance: 다른 가용 영역에 똑같은 복제본 DB를 하나 더 둔다.
• 장애 조치 (Failover): 메인 DB에 문제가 생기면 AWS가 자동으로 DNS를 변경하여 1~2분 내에 보조 DB를 메인으로 승격시킨다. 개발자는 코드를 수정할 필요가 없다.

5. 체크리스트

• Multi-AZ 배치: API 서버가 최소 2개 이상의 가용 영역(Subnet)에 분산되어 배포되었는가?
• Stateless 설계: API 서버 내부에 세션이나 파일을 저장하고 있지는 않은가? (서버가 여러 대가 되면 세션 공유 문제가 생기므로 Redis나 S3를 사용해야 함)
• 로드 밸런서 연결: 모든 트래픽이 서버 IP가 아닌 ALB의 DNS 주소를 통해 들어오는가?
• 상태 확인 경로: ALB가 서버의 상태를 체크할 수 있는 전용 엔드 포인가(예: /health)가 구현되어 있는가?
• RDS 가중 AZ: 운영 환경 DB의 ‘다중 AZ 배포’옵션이 활성화되어 있는가?