Repository navigation
Description
범위 변경 배경
처음에는 #67에서 합의하고 검증한 복구 매뉴얼 전체를 기준으로 이 워크플로우를 구현할 계획이었습니다. 하지만 매뉴얼 논의(Discussion #78)는 판단이 필요한 항목이 많아 확정까지 시간이 오래 걸리고 있습니다. 그동안 장애가 나면 복구 수단이 없는 상태가 이어집니다.
장애 시나리오 중 인스턴스·볼륨 장애는 판단할 여지가 적고 절차가 정해져 있습니다. 백업 체계를 설계할 때 RPO를 로컬 볼륨 상태에 따라 나눴는데(#78 2.1), 이 구분을 그대로 분기로 쓰면 됩니다. 그래서 이 이슈의 범위를 로컬 볼륨 상태에 따라 분기하는 인스턴스 재구성 복구 워크플로우로 좁혀 먼저 진행합니다.
논리적 데이터 손상(잘못된 DELETE/UPDATE, 마이그레이션 사고)에 대한 시점 복구는 이번 범위에서 제외합니다. 문제 시점을 특정하고 운영에 어떻게 반영할지 사람이 판단해야 하는 단계가 많기 때문입니다. 이 부분은 Discussion #78을 열어 둔 채 매뉴얼을 계속 다듬습니다(#67).
목표
GitHub Actions workflow_dispatch 기반의 수동 복구 워크플로우 하나를 만들고, 입력값으로 로컬 볼륨 상태를 받아 두 분기 중 하나를 실행합니다. GitHub Actions는 입력, 승인, 실행 요청을 맡고, 인스턴스 교체는 Terraform으로, 데이터 확인과 복원은 새 DB EC2에서 수행합니다.
분기 구분
분기를 가르는 기준은 기존 데이터 EBS를 그대로 쓸 수 있는가입니다.
| 분기 A — 로컬 볼륨 정상 | 분기 B — 로컬 볼륨 비정상 | |
|---|---|---|
| 해당 상황 | 인스턴스(compute)만 문제인 경우 | 볼륨을 마운트할 수 없거나, MySQL이 기동하지 못하거나, 정합성 확인에서 이상이 발견된 경우 |
| 인스턴스 | 새로 생성 | 새로 생성 |
| 데이터 볼륨 | 기존 볼륨 재연결 | 기존 스펙으로 새 볼륨 생성 (기존 볼륨은 보존) |
| 데이터 출처 | 기존 볼륨 그대로 (S3 백업 사용 안 함) | S3 dump + S3 binlog |
| RPO | 커밋 기준 0 | 최대 5분 (마지막으로 업로드된 binlog까지) |
| 하위 이슈 | #87 | #88 |
- 분기 A에서는 S3 백업으로 복원하지 않습니다. 볼륨에 최신 데이터가 그대로 있으므로 dump를 덮어쓰면 그 이후 데이터가 사라집니다. 볼륨이 정상인지 애매하면 먼저 분기 A로 기동해 확인하고, 이상이 있을 때 분기 B로 넘어갑니다.
- 두 분기 모두 복구 후 백업 체계를 다시 설치합니다. 분기 B는 새 볼륨이라 첫 dump가 자동으로 생성되어 새 복구 기준점이 됩니다.
- 두 분기 모두 서비스 연결 설정을 바꾸지 않습니다. DB EC2의 private IP가 고정(chore: DB EC2 의 private IP 를 현재 주소로 고정 #86)되어 있어 Parameter Store
spring.datasource.url갱신과 API 서버 재배포가 필요 없습니다.
작업 순서
#87(분기 A)을 먼저 진행합니다. 승인 게이트, Terraform 교체, DB EC2 접속, host key 갱신, 백업 재설치 같은 두 분기 공통 기반을 #87에서 만들고, #88(분기 B)은 그 위에 볼륨 교체와 S3 복원을 더합니다. 구체적인 작업 항목은 각 하위 이슈에서 관리합니다.
권한 관리 원칙
- GitHub OIDC 복구 역할을 포함한 IAM Role, IAM Policy, IAM User와 권한 연결은 AWS에서 수동으로 구성합니다.
- Terraform 코드에는 IAM 권한 정의와 연결 정보를 선언하지 않습니다.
- GitHub Actions에는 수동으로 생성된 IAM Role ARN만 GitHub Secret으로 전달합니다.
- 구체적인 권한 내용은 저장소 이슈와 코드에 노출하지 않고 별도 운영 문서에서 관리합니다.
완료 조건
- feat: [복구 분기 A] 로컬 볼륨 정상 시 DB EC2 재구성 워크플로우 구현 #87 분기 A 완료
- feat: [복구 분기 B] 로컬 볼륨 비정상 시 새 볼륨과 S3 백업으로 복원하는 워크플로우 구현 #88 분기 B 완료
- 승인된 사용자만 복구 워크플로우를 실행할 수 있고, 입력한 볼륨 상태에 따라 분기가 실행됩니다.
- 두 분기 모두 복구 후 백업 체계가 다시 동작하고, API 서버 설정을 바꾸지 않아도 연결됩니다.
- 리허설로 분기별 소요 시간을 측정해 기록합니다.
관련
- 복구 매뉴얼 논의: Discussion [논의] Prod DB 데이터 논리적 손상 시 시점 복구 절차 #78 (논리적 손상 시점 복구는 이곳에서 계속 다룸)
- 복구 매뉴얼 이슈: docs: DB 장애 상황별 복구 매뉴얼 수립 #67
- private IP 고정: chore: DB EC2 의 private IP 를 현재 주소로 고정 #86
Activity
chore: DB EC2 의 private IP 를 현재 주소로 고정 (#86)
[-]feat: Prod DB 수동 복구 GitHub Actions 워크플로우 구성[/-][+]feat: Prod DB 인스턴스·볼륨 장애 복구 GitHub Actions 워크플로우 구성[/+]