DOCS/journey/plans/260304_24장애시_23자동임시프로덕션전환_계획.md

260304 24장애시 23자동임시프로덕션전환 계획

작성일: 2026-03-04
상태: draft
목표: 51124 물리/시스템 장애 시 51123이 자동으로 robeing 임시 프로덕션 역할을 승격 수행

---

1. 문제 정의

• 현재 구조는 24 실행 서버 의존도가 높아 물리 장애 시 서비스 연속성이 급격히 저하된다.
• 수동 복구는 운영자 가용성(물리 접근/원격 접속 가능 여부)에 강하게 의존한다.
• 목표 RTO(복구 시간)와 RPO(데이터 손실 허용량)를 명시하고 자동 전환 체계를 구축해야 한다.

권장 기준:

• RTO: 5분 이내
• RPO: 0~수초(공유 DB/공유 스토리지 전제)

2. 결론 먼저 (도구 선택)

1. 지금 당장(단기): Kubernetes/Swarm 없이 Docker Compose + systemd + nginx upstream 자동전환으로 구현 가능
2. 중기(안정화 후): k3s(경량 Kubernetes) 권장
3. Swarm: 신규 도입 비권장 (생태계/운영 표준/장기 유지보수 측면에서 k3s 대비 이점이 작음)

3. 아키텍처 원칙

• 단일 진입점 유지: 외부 트래픽은 기존 gateway/nginx 경유
• 장애 감지와 승격 분리: detect(헬스) -> promote(기동/라우팅 전환) -> verify(스모크 테스트)
• 이중 실행 방지: 스케줄러/배치 작업은 반드시 단일 리더만 실행(DB advisory lock)
• 데이터 일관성 우선: 23/24가 같은 DB와 동일 스키마를 사용하도록 관리

4. 단기 구현안 (즉시 실행 가능)

4-1. 23 Warm Standby 상시 준비

• 23에 아래 서비스 compose를 상시 준비(이미지 pull/빌드 캐시 유지):
  • rb8001, skill-email, skill-calendar, robeing-monitor (+필요 스킬)
• .env 및 시크릿 동기화:
  • JWT secret, API key, DB 접속정보를 23/24 동일 정책으로 관리
• UFW/포트 사전 허용:
  • 23에서 내부 브리지 대역 -> 필요 포트 접근 허용 사전 적용

4-2. 자동 장애 감지

• systemd timer(1분 주기) 또는 runner cron으로 감지 스크립트 실행
• 감지 조건 예시:
  • http://192.168.0.106:8001/health 3회 연속 실패
  • • TCP check 실패(이중 확인)

4-3. 자동 승격

• 승격 스크립트 동작 순서:

1. 락 획득(중복 승격 방지)
2. 23에서 대상 compose down && up -d --build
3. nginx upstream을 24 -> 23으로 스위치
4. nginx reload
5. 스모크 테스트(/healthz, /api/message, 이메일 핵심 API)
6. 성공 시 상태 파일 기록 및 알람 전송

4-4. 자동 복귀(24 복구 시)

• 24 헬스 일정 시간 안정(예: 10분) 확인 후 역전환
• 역전환도 동일하게: 락 -> upstream 복귀 -> 스모크 테스트 -> 성공 기록

5. 필수 안전장치

• 스케줄 중복 방지:
  • scheduler 실행 전 pg_try_advisory_lock 획득 실패 시 해당 노드 작업 skip
• 배포/전환 충돌 방지:
  • 배포 파이프라인과 failover 스크립트가 같은 락 파일/DB 락 사용
• 관측성:
  • 전환 이벤트를 /mnt/hdd/logs/에 구조화 로그(JSON)로 기록
  • 실패 시 Slack/이메일 알림

6. Kubernetes vs Swarm 판단

Kubernetes(k3s) 권장 조건

• 서비스 수 증가, 셀프힐링/오토스케일/롤링업데이트 필요
• 장애자동복구를 플랫폼 기능으로 흡수하고 싶을 때
• 장기적으로 운영 표준화 필요할 때

Docker Swarm 비권장 이유

• 신규 기능/생태계 확장성이 제한적
• 장애 대응 및 관측 도구 선택폭이 Kubernetes 대비 좁음
• 장기 투자 대비 이득이 작아 현재 시점 도입 우선순위 낮음

7. 단계별 실행 로드맵

1. Day 1: 23 standby compose/시크릿/UFW 정합화 + 수동 승격 리허설
2. Day 2: 자동 감지/승격 스크립트 + nginx 자동 스위치 + 알람 연동
3. Day 3: DB advisory lock 기반 스케줄 단일 실행 적용
4. Day 4: 강제 DR 테스트(24 down 가정) 2회, RTO 계측
5. Week 2+: k3s PoC 착수 여부 결정(비용/운영복잡도 평가 후)

8. 완료 판정 기준

• 24 차단 시 5분 이내 23 자동 승격 성공
• /api/message, 9~10시 이메일/브리핑 스케줄 정상 수행
• 중복 실행/중복 발송 없음
• 전환/복귀 이벤트가 로그와 알림으로 추적 가능

9. 후속 문서 연결

• 260303_23테스트보조_24프로덕션_운영전환_계획
• 260304_51123_임시복구_서비스연속성_조치내역