fail-over 시스템 아키텍쳐를 구축해보세요.

면접용 답변

트래픽이 과다해지는 상황에 대비한 Failover 시스템은 서비스의 고가용성(High Availability) 과 무중단 처리를 위해 중요합니다. 각 계층(로드밸서, 애플리케이션 서버, 데이터베이스, 캐시 등)에 장애 감지 및 자동 전환(Failover) 메커니즘을 구축해야 하며, 무상태(stateless) 아키텍처, 헬스체크, Auto Scaling, 멀티 AZ 구성 등을 조합해 탄력적으로 대응할 수 있습니다.

핵심 설계원칙은 아래와 같습니다.

• 무상태 서버 + 외부 세션 저장소

• Auto Scaling Group 구성

• 모든 계층에 헬스체크 기반 이중화 적용

• 데이터 계층은 복제 + 자동 전환 도구 사용

• 모니터링 + 경고 시스템(CloudWatch, Prometheus, Grafana 등) 필수

개념 정리

Failover 시스템이란, 서비스 구성 요소 중 일부에 장애가 발생했을 때 자동으로 대체 자원으로 전환되어 서비스 중단 없이 트래픽을 처리하는 구조를 의미합니다.

장애 시나리오 및 fail-over 대응

1. 단일 EC2 인스턴스 장애:

                +-------------+
                |  Client     |
                +------+------+
                       |
                 +-----v-----+
                 | Load Balancer (ALB/NLB)
                 +--+------+--+
                    |      |
         (Healthy)  |      |  (Unhealthy)
                +--v--+  +--v--+
                | EC2 |  | EC2 |  ← 장애 발생
                +-----+  +-----+
                             ↑
       Auto Scaling 감지 → 종료 후 대체 인스턴스 프로비저닝

• Auto Scaling Group에서 자동 감지

• 비정상 인스턴스 종료 및 새 인스턴스 시작

• 로드밸런서에서 비정상 인스턴스 제외

2. 가용 영역(AZ) 장애:

         +-------------+
         |   Client    |
         +------+------+
                |
         +------v------+
         |  Load Balancer (Multi-AZ) |
         +------+--------+-----------+
                |        |
        +-------v+    +--v--------+
        | AZ A   |    | AZ B      |
        | EC2 x  |    | EC2 o     |  ← 정상
        +--------+    +-----------+
                ↑
     장애 발생시 AZ A 트래픽 → AZ B 로 자동 우회
     Auto Scaling Group → AZ B에 인스턴스 추가

• 다른 AZ의 인스턴스로 트래픽 자동 전환

• Auto Scaling Group에서 정상 AZ에 추가 인스턴스 프로비저닝

• RDS Multi-AZ 자동 Failover 작동

데이터베이스 장애:

                 +------------+
                 | Application|
                 +-----+------+
                       |
                 +-----v------+
                 | RDS Proxy  |
                 +-----+------+
                       |
         +-------------+-------------+
         |                           |
  +------v------+           +--------v------+
  | RDS Writer  |           | RDS Standby   |
  | (AZ A, down)|           | (AZ B)        |
  +-------------+           +---------------+

      장애 발생 → Standby가 자동 승격됨

• RDS Multi-AZ: 스탠바이로 자동 Failover

• 애플리케이션 연결은 RDS Proxy를 통해 유지 관리

새끼 질문

Q. Fail-over와 Load Balancing의 차이는 무엇인가요?

답변:

• Fail-over: 시스템 장애 발생 시 대체 시스템으로 자동 전환하는 메커니즘

• Load Balancing: 여러 서버로 **트래픽을 분산시켜 성능과 가용성을 높이는 기술

---

Q2. Fail-over 시 사용자 세션은 어떻게 유지하나요?

답변:

• Stateless 설계: 세션 정보를 클라이언트에 저장 (예: JWT, 토큰 기반 인증)

• 세션 스토리지 공유: Redis 등의 중앙 세션 저장소를 이용

---

Q3. Active-Active와 Active-Passive 아키텍처의 차이는?

답변:

구분	Active-Active	Active-Passive
처리 방식	다수 인스턴스가 동시에 처리	하나만 처리, 나머지는 대기
성능	고성능, 자원 활용 극대화	자원 낭비 가능성 있음
복잡도	세션/데이터 일관성 이슈	상대적으로 단순
예시	Aurora 글로벌 DB	RDS Multi-AZ

---