3-6 안정성 설계
- 안정성에 관한 Well-Architected 프레임워크 설계 원칙
- 장애 자동 복구
- 복구 절차 테스트
- 수평적 확장으로 워크로드 전체 가용성 증대
- 용량 추정 불필요
- 자동화 변경 사항 관리
다중 AZ 구성을 통한 가용성 향상
- 다중 AZ(Availability Zone) 구성
- 여러 데이터 센터가 지리적으로 떨어져 있는 구성
- AWS의 물리적 장애나 광범위한 피해에 대한 가용성을 높일 수 있다.
- ECS/Fargate에서도 다중 AZ 구성을 할 수 있다.
- ECS 서비스 내부 스케줄러가 최적화를 통해 AZ 부하 균형을 조절하며 ECS 태스크를 배치
장애 시 전환 및 복구
CloudWatch를 활용한 ECS 태스크 장애 탐지
- CloudWatch에는 ECS의 각종 지표를 얻을 수 있으므로 자동으로 운영자에게 알림을 보내는 시스템을 구축할 수 있다.
- RunningTaskCount 지표 또는 TaskCount 지표와 CloudWatch 알람의 조합
- TaskCount - ECS 클러스터 차원에서의 태스크 수
- RunningTaskCount - ECS 서비스 차원에서 태스크 수
ECS 서비스를 통한 ECS 태스크의 자동 복구
- ECS 서비스는 지정한 태스크 수를 유지하려고 한다.
- 태스크가 자동으로 복구 되더라도 태스크 수가 줄었을 때 알람 통지를 통해 확인하는 것이 좋다.
- ECS 태스크가 1개라도 정지하면 데이터 정합성에 문제가 없는지 바로 확인해야 하는 경우도 생긴다.
ALB와 연계한 ECS 태스크의 제거 및 자동 복구
- ALB 타깃 그룹에 ECS 태스크를 등록해두면 ALB가 자동으로 장애 태스크를 타깃에서 제외한다.
- 단 취소가 완료될 때까지 ALB가 5xx 에러를 반환할 수 있다.
Fargate 작업 유지로 인한 ECS 태스크 정지
- ECS는 태스크의 장애뿐 아니라 제어 플레인이 ECS 태스크 정지를 지시할 때 처리에 대해서도 고려해야 한다.
- Fargate에서 실행 중인 태스크가 정지할 때 AWS가 사용자 계정으로 사용 중단 알람을 전송한다.
- 처리 무결성이 필요한 비즈니스에선 시스템 정지 시 적절한 처리를 해야할 필요가 있다.
- ECS는 태스크를 정지할 때 대상 태스크에 대해 SIGTERM 시그널을 전송한다.
- 애플리케이션이 이 시그널에 응답하지 않는 경우 기본적으로 30초를 기다리고 SIGKILL 시그널이 전송된다.
- 애플리케이션이 SIGTERM 시그널을 핸들링하지 않는다면 SIGKILL로 강제 종료당한다.
- 시그널을 핸들링한다면 적절히 종료 처리를 할 수 있고 SIGKILL은 송신되지 않는다.
- 애플리케이션이 SIGTERM 시그널을 받아 안전하게 종료될 수 있게 구현하는 것도 염두해 둬야 한다.
시스템 유지 보수를 위한 서비스 정지
- 시스템 점검이 필요한 상황에서 사용자에게 점검 중이라는 것을 알리며 배포 대상 애플리케이션에 요청이 전달되지 않게 하는 설계가 필요하다.
- ALB와 연계해 리스너 규칙 정의를 통해 해결할 수 있다.
- ECS 태스크에 전달하는 리스너 규칙과 점검 중 응답을 반환하는 리스너 규칙 2개를 만들고 태스크 전송 규칙의 우선도를 높인다.
- 점검을 실행할 때 관리 콘솔이나 Lambda를 이용한 API 등으로 점검 중 응답을 반환하는 리스너 규칙의 우선도를 더 높이도록 변경한다.
서비스 할당량 고려
- AWS의 각종 서비스에는 할당량 제한이 존재한다.
- ECS/Fargate와 관련된 대표적인 할당량은 다음과 같다.
- 리전 내에 계정이 가질 수 있는 클러스터 최대 수 (기본 10,000)
- 클러스터당 서비스 최대 수 (기본 5,000)
- 서비스당 태스크 최대 수 (기본 5,000)
- 리전의 Fargate에서 한 계정이 동시 실행 가능한 태스크와 EKS 포드 최대 수 (기본 1,000)
- 리전에서 한 계정이 Fargate Spot으로 동시 실행 가능한 태스크 최대 수 (기본 1,000)
- 위 할당량은 모두 값을 늘릴 수 있지만 값이 자동으로 증가하지 않는다는 점에 주의해야 한다.
- 할당량 증가가 예상되는 서비스라면 할당량을 지속해서 관찰할 수 있는 구조를 고려해라.