# 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프로덕션_운영전환_계획](./260303_23테스트보조_24프로덕션_운영전환_계획.md)
- [260304_51123_임시복구_서비스연속성_조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md)