CRM 애플리케이션과 EC2 장애 시 영향

1. 장애가 발생하면 어떤 일이 일어나는가?

• 여러 가용 영역에 분산된 EC2 인스턴스 중 하나에서 장애가 발생하면, 해당 인스턴스는 더 이상 요청을 처리할 수 없다.
• 하지만, Application Load Balancer(ALB) 가 자동으로 해당 인스턴스를 대상 그룹(Target Group)에서 제외하고, 정상적으로 동작하는 다른 인스턴스로 트래픽을 분배한다.
• 결과적으로 사용자는 서비스 중단 없이 애플리케이션을 계속 사용할 수 있다.

2. 장애 감지와 복구 프로세스

✅ Application Load Balancer(ALB)의 상태 확인(Health Check)

• ALB는 일정 간격으로 Health Check(상태 점검) 을 실행하여 EC2 인스턴스의 정상 여부를 판별한다.
• 특정 임계값(예: 연속 3번 응답 실패)을 초과하면, 해당 인스턴스를 비정상으로 판단하고 트래픽을 전달하지 않는다.

✅ Auto Scaling을 통한 복구 (선택 사항)

• Auto Scaling이 설정되어 있다면, 장애가 발생한 인스턴스를 자동으로 종료하고 새로운 인스턴스를 생성하여 가용성을 유지할 수 있다.
• 최소 인스턴스 개수를 3개로 설정한 경우, 하나가 장애를 일으키면 새로운 EC2 인스턴스가 자동으로 추가된다.

✅ CloudWatch 알람을 활용한 장애 감지

• Amazon CloudWatch는 EC2 인스턴스의 상태를 모니터링하며, 장애가 감지되면 관리자에게 알림을 보낼 수 있다.
• 이를 통해 운영팀이 장애 상황을 신속하게 파악하고 추가적인 조치를 취할 수 있다.

3. 가용성을 높이기 위한 추가적인 고려 사항

• 멀티 AZ 배포: 모든 인스턴스를 하나의 가용 영역(AZ)에 배치하면 해당 AZ가 장애를 겪을 경우 서비스가 중단될 수 있다. 따라서 다중 가용 영역에 인스턴스를 배포하는 것이 중요하다.
• Auto Scaling과 Load Balancer 연동: Auto Scaling 그룹을 설정하여 EC2 인스턴스를 자동으로 추가 및 제거하면, 트래픽 증가 및 장애 상황에서도 안정적인 운영이 가능한다.
• RDS의 Multi-AZ 배포(데이터베이스 고려): CRM 애플리케이션이 데이터베이스를 사용한다면, Amazon RDS의 Multi-AZ 배포를 설정하여 데이터베이스 장애에도 대비해야 한다.