You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: Prod DB 인스턴스·볼륨 장애 복구 GitHub Actions 워크플로우 구성 #68
처음에는 #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이 기동하지 못하거나, 정합성 확인에서 이상이 발견된 경우
#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으로 전달합니다.
Activity
chore: DB EC2 의 private IP 를 현재 주소로 고정 (#86)
[-]feat: Prod DB 수동 복구 GitHub Actions 워크플로우 구성[/-][+]feat: Prod DB 인스턴스·볼륨 장애 복구 GitHub Actions 워크플로우 구성[/+]