- api.sam.kr/develop/ 접속 시 문서 목록 표시 - 5개 문서 항목 추가: * 시스템 아키텍처 다이어그램 (HTML) * 서버 사양 및 비용 분석표 (HTML) * CI/CD 파이프라인 흐름도 (HTML) * 재해복구(DR) 계획서 (Markdown) * 네트워크 토폴로지 다이어그램 (HTML) - 모달 팝업으로 문서 뷰어 구현 - HTML 파일: iframe으로 원본 표시 - Markdown 파일: 자동 HTML 변환 후 표시 - 반응형 디자인 적용 (모바일/태블릿/데스크톱) - Purple-Blue 그라디언트 UI 테마
370 lines
9.2 KiB
Markdown
370 lines
9.2 KiB
Markdown
# 🔥 재해복구(DR) 계획서
|
|
|
|
## 1. 개요 및 목적
|
|
|
|
### 1.1 문서 목적
|
|
- 시스템 장애 발생 시 신속한 복구를 위한 체계적인 절차 수립
|
|
- 데이터 손실 최소화 및 서비스 연속성 보장
|
|
- 비상 상황 대응 프로세스 표준화
|
|
|
|
### 1.2 적용 범위
|
|
- **대상 시스템**: 운영 서버 A/B, DB Master/Slave, 개발 서버
|
|
- **대상 서비스**: 웹 애플리케이션, API, 데이터베이스
|
|
- **관련 팀**: 개발팀, 인프라팀, 운영팀
|
|
|
|
---
|
|
|
|
## 2. 복구 목표 설정
|
|
|
|
### 2.1 RTO/RPO 목표
|
|
|
|
| 구분 | 목표 시간 | 설명 |
|
|
|------|-----------|------|
|
|
| **RTO** (Recovery Time Objective) | 4시간 | 장애 발생 후 서비스 정상화까지 목표 시간 |
|
|
| **RPO** (Recovery Point Objective) | 1시간 | 허용 가능한 최대 데이터 손실 시간 |
|
|
|
|
### 2.2 서비스별 우선순위
|
|
|
|
| 우선순위 | 서비스 | RTO | RPO | 비고 |
|
|
|---------|--------|-----|-----|------|
|
|
| **P0 (Critical)** | 결제 시스템 | 1시간 | 0분 | 실시간 백업 |
|
|
| **P1 (High)** | 사용자 인증 | 2시간 | 30분 | 핵심 기능 |
|
|
| **P2 (Medium)** | API 서비스 | 4시간 | 1시간 | 일반 서비스 |
|
|
| **P3 (Low)** | 통계/리포트 | 8시간 | 4시간 | 비핵심 기능 |
|
|
|
|
---
|
|
|
|
## 3. 재해 시나리오 및 대응 전략
|
|
|
|
### 3.1 시나리오별 대응 방안
|
|
|
|
#### 🔴 시나리오 1: 단일 서버 장애
|
|
**상황**: 운영 서버 A 또는 B 중 1대 장애
|
|
```
|
|
대응 절차:
|
|
1. 로드밸런서에서 장애 서버 제외 (자동)
|
|
2. 정상 서버로 모든 트래픽 라우팅
|
|
3. 장애 서버 재시작 시도
|
|
4. 복구 실패 시 새 인스턴스 생성
|
|
5. 서비스 정상화 확인
|
|
```
|
|
**예상 복구 시간**: 5분 (자동) ~ 30분 (수동)
|
|
|
|
#### 🔴 시나리오 2: 데이터베이스 장애
|
|
**상황**: DB Master 장애 발생
|
|
```
|
|
대응 절차:
|
|
1. DB 모니터링 알람 감지
|
|
2. Slave DB를 Master로 승격
|
|
3. 애플리케이션 DB 연결 정보 변경
|
|
4. 기존 Master 복구 또는 재구축
|
|
5. 새로운 Slave 구성
|
|
```
|
|
**예상 복구 시간**: 30분 ~ 1시간
|
|
|
|
#### 🔴 시나리오 3: 네트워크 장애
|
|
**상황**: 클라우드 리전 전체 네트워크 장애
|
|
```
|
|
대응 절차:
|
|
1. DR 사이트 활성화 (IDC 백업 서버)
|
|
2. DNS 전환 (TTL 5분)
|
|
3. 백업 데이터로 서비스 구동
|
|
4. 임시 운영 모드 전환
|
|
5. 주 사이트 복구 시 데이터 동기화
|
|
```
|
|
**예상 복구 시간**: 1시간 ~ 2시간
|
|
|
|
#### 🔴 시나리오 4: 랜섬웨어/보안 침해
|
|
**상황**: 악성코드 감염 또는 보안 침해
|
|
```
|
|
대응 절차:
|
|
1. 감염 시스템 즉시 격리
|
|
2. 네트워크 차단
|
|
3. 클린 백업에서 복구
|
|
4. 보안 패치 적용
|
|
5. 침해 분석 및 보고서 작성
|
|
```
|
|
**예상 복구 시간**: 4시간 ~ 8시간
|
|
|
|
### 3.2 데이터 백업 전략
|
|
|
|
#### 백업 정책
|
|
| 백업 유형 | 주기 | 보관 기간 | 저장 위치 | 자동화 |
|
|
|-----------|------|-----------|-----------|---------|
|
|
| **전체 백업** | 주 1회 (일요일) | 3개월 | IDC 백업서버 | ✅ |
|
|
| **증분 백업** | 일 1회 (새벽 2시) | 1개월 | 클라우드 스토리지 | ✅ |
|
|
| **실시간 복제** | 지속 | - | DB Slave | ✅ |
|
|
| **스냅샷** | 4시간마다 | 7일 | 클라우드 스냅샷 | ✅ |
|
|
|
|
#### 백업 스크립트 예시
|
|
```bash
|
|
#!/bin/bash
|
|
# Daily Backup Script
|
|
DATE=$(date +%Y%m%d)
|
|
BACKUP_DIR="/backup/daily/${DATE}"
|
|
|
|
# Database Backup
|
|
mysqldump -h 10.0.2.20 -u backup -p$DB_PASS \
|
|
--all-databases --single-transaction \
|
|
> ${BACKUP_DIR}/db_backup.sql
|
|
|
|
# Application Files Backup
|
|
tar -czf ${BACKUP_DIR}/app_backup.tar.gz \
|
|
/var/www/html
|
|
|
|
# Upload to Remote Storage
|
|
rsync -avz ${BACKUP_DIR}/ \
|
|
backup@172.16.1.11:/central-backup/
|
|
|
|
# Verify Backup
|
|
if [ $? -eq 0 ]; then
|
|
echo "Backup successful: ${DATE}"
|
|
# Send success notification
|
|
else
|
|
echo "Backup failed: ${DATE}"
|
|
# Send alert
|
|
fi
|
|
```
|
|
|
|
---
|
|
|
|
## 4. 복구 절차서
|
|
|
|
### 4.1 웹 서버 복구
|
|
|
|
```markdown
|
|
## 웹 서버 복구 체크리스트
|
|
- [ ] 1. 장애 서버 상태 확인
|
|
- [ ] 2. 로드밸런서에서 제외 확인
|
|
- [ ] 3. 새 인스턴스 생성 (필요시)
|
|
- [ ] 4. Docker 환경 구성
|
|
- [ ] 5. 최신 이미지 Pull
|
|
- [ ] 6. 환경 변수 설정 (.env)
|
|
- [ ] 7. 컨테이너 실행
|
|
- [ ] 8. Health Check 확인
|
|
- [ ] 9. 로드밸런서 재등록
|
|
- [ ] 10. 모니터링 확인
|
|
```
|
|
|
|
### 4.2 데이터베이스 복구
|
|
|
|
```markdown
|
|
## DB 복구 체크리스트
|
|
- [ ] 1. 백업 파일 확인 (최신 시점)
|
|
- [ ] 2. 새 DB 인스턴스 준비
|
|
- [ ] 3. 백업 데이터 복원
|
|
```sql
|
|
mysql -u root -p < backup.sql
|
|
```
|
|
- [ ] 4. 데이터 정합성 검증
|
|
- [ ] 5. Replication 재설정
|
|
- [ ] 6. 애플리케이션 연결 테스트
|
|
- [ ] 7. 성능 테스트
|
|
- [ ] 8. 모니터링 설정
|
|
```
|
|
|
|
### 4.3 전체 시스템 복구 (Full DR)
|
|
|
|
```markdown
|
|
## 전체 시스템 복구 순서
|
|
1. **네트워크 인프라** (10분)
|
|
- [ ] VPC/Subnet 구성
|
|
- [ ] Security Group 설정
|
|
- [ ] Load Balancer 생성
|
|
|
|
2. **컴퓨팅 리소스** (20분)
|
|
- [ ] EC2 인스턴스 생성
|
|
- [ ] Docker 설치
|
|
- [ ] 기본 패키지 설치
|
|
|
|
3. **데이터 복원** (30분)
|
|
- [ ] 최신 백업 확인
|
|
- [ ] DB 복원
|
|
- [ ] 파일 시스템 복원
|
|
|
|
4. **애플리케이션 배포** (20분)
|
|
- [ ] 컨테이너 이미지 Pull
|
|
- [ ] 환경 설정
|
|
- [ ] 서비스 시작
|
|
|
|
5. **검증 및 전환** (20분)
|
|
- [ ] 서비스 테스트
|
|
- [ ] DNS 전환
|
|
- [ ] 모니터링 확인
|
|
```
|
|
|
|
---
|
|
|
|
## 5. 비상 연락망
|
|
|
|
### 5.1 에스컬레이션 매트릭스
|
|
|
|
| 레벨 | 담당자 | 역할 | 연락처 | 대응 시간 |
|
|
|------|--------|------|---------|-----------|
|
|
| L1 | 운영팀 | 1차 대응 | 010-xxxx-xxxx | 24/7 |
|
|
| L2 | 인프라팀장 | 인프라 복구 | 010-xxxx-xxxx | 15분 이내 |
|
|
| L3 | 개발팀장 | 애플리케이션 복구 | 010-xxxx-xxxx | 30분 이내 |
|
|
| L4 | CTO | 최종 의사결정 | 010-xxxx-xxxx | 1시간 이내 |
|
|
|
|
### 5.2 외부 지원 연락처
|
|
|
|
| 구분 | 업체명 | 담당자 | 연락처 | 계약 SLA |
|
|
|------|--------|--------|---------|----------|
|
|
| 클라우드 | 호스팅사 | 기술지원 | 1544-xxxx | 4시간 |
|
|
| IDC | 코로케이션 | 24시간 NOC | 02-xxxx-xxxx | 2시간 |
|
|
| 보안 | 보안업체 | CERT팀 | 02-xxxx-xxxx | 1시간 |
|
|
|
|
---
|
|
|
|
## 6. 복구 테스트 계획
|
|
|
|
### 6.1 정기 DR 훈련
|
|
|
|
| 훈련 유형 | 주기 | 범위 | 소요 시간 |
|
|
|-----------|------|------|-----------|
|
|
| **Table Top** | 분기 1회 | 시나리오 검토 | 2시간 |
|
|
| **부분 복구** | 반기 1회 | 단일 시스템 | 4시간 |
|
|
| **전체 복구** | 연 1회 | 전체 시스템 | 8시간 |
|
|
|
|
### 6.2 테스트 시나리오
|
|
|
|
```markdown
|
|
## DR 테스트 시나리오 예시
|
|
1. **준비 단계** (30분)
|
|
- 테스트 환경 격리
|
|
- 백업 확인
|
|
- 팀 준비 상태 확인
|
|
|
|
2. **장애 시뮬레이션** (10분)
|
|
- Production 서버 A 강제 종료
|
|
- DB Master 연결 차단
|
|
|
|
3. **복구 실행** (60분)
|
|
- 절차서에 따른 복구
|
|
- 시간 측정
|
|
- 이슈 기록
|
|
|
|
4. **검증** (30분)
|
|
- 서비스 정상 동작 확인
|
|
- 데이터 정합성 검증
|
|
- 성능 테스트
|
|
|
|
5. **원복** (30분)
|
|
- 원래 상태로 복구
|
|
- 테스트 데이터 정리
|
|
|
|
6. **리뷰** (60분)
|
|
- 결과 분석
|
|
- 개선점 도출
|
|
- 문서 업데이트
|
|
```
|
|
|
|
---
|
|
|
|
## 7. 복구 후 조치사항
|
|
|
|
### 7.1 Post-Incident 체크리스트
|
|
|
|
- [ ] **즉시 조치** (1시간 이내)
|
|
- [ ] 서비스 정상화 공지
|
|
- [ ] 임시 조치사항 문서화
|
|
- [ ] 긴급 패치 적용
|
|
|
|
- [ ] **단기 조치** (24시간 이내)
|
|
- [ ] 장애 보고서 작성
|
|
- [ ] 근본 원인 분석 (RCA)
|
|
- [ ] 임시 조치 → 영구 조치 전환
|
|
|
|
- [ ] **장기 조치** (1주일 이내)
|
|
- [ ] 재발 방지 대책 수립
|
|
- [ ] 프로세스 개선
|
|
- [ ] 교육/훈련 계획
|
|
|
|
### 7.2 장애 보고서 템플릿
|
|
|
|
```markdown
|
|
# 장애 보고서
|
|
|
|
## 1. 장애 개요
|
|
- **발생 일시**: 2025-XX-XX HH:MM
|
|
- **복구 일시**: 2025-XX-XX HH:MM
|
|
- **영향 범위**:
|
|
- **심각도**: P0 / P1 / P2 / P3
|
|
|
|
## 2. 타임라인
|
|
| 시간 | 내용 |
|
|
|------|------|
|
|
| HH:MM | 장애 감지 |
|
|
| HH:MM | 1차 대응 시작 |
|
|
| HH:MM | 원인 파악 |
|
|
| HH:MM | 복구 작업 시작 |
|
|
| HH:MM | 서비스 정상화 |
|
|
|
|
## 3. 근본 원인
|
|
-
|
|
|
|
## 4. 대응 내역
|
|
-
|
|
|
|
## 5. 개선 사항
|
|
- [ ] Action Item 1
|
|
- [ ] Action Item 2
|
|
- [ ] Action Item 3
|
|
|
|
## 6. 교훈 (Lessons Learned)
|
|
-
|
|
```
|
|
|
|
---
|
|
|
|
## 8. 부록
|
|
|
|
### 8.1 주요 명령어 모음
|
|
|
|
```bash
|
|
# 서버 상태 확인
|
|
docker ps -a
|
|
systemctl status nginx
|
|
netstat -tlnp
|
|
|
|
# DB 상태 확인
|
|
mysql -e "SHOW SLAVE STATUS\G"
|
|
mysql -e "SHOW PROCESSLIST"
|
|
|
|
# 백업/복원
|
|
tar -xzf backup.tar.gz -C /restore/
|
|
mysql < backup.sql
|
|
|
|
# 네트워크 진단
|
|
ping -c 4 10.0.1.10
|
|
traceroute 10.0.1.10
|
|
nslookup domain.com
|
|
|
|
# 로그 확인
|
|
tail -f /var/log/nginx/error.log
|
|
docker logs container_name
|
|
journalctl -u docker -f
|
|
```
|
|
|
|
### 8.2 유용한 도구
|
|
|
|
| 도구 | 용도 | URL/명령어 |
|
|
|------|------|------------|
|
|
| htop | 시스템 모니터링 | `htop` |
|
|
| netdata | 실시간 모니터링 | http://server:19999 |
|
|
| mysqltuner | DB 성능 분석 | `perl mysqltuner.pl` |
|
|
| docker stats | 컨테이너 모니터링 | `docker stats` |
|
|
|
|
### 8.3 참고 문서
|
|
|
|
- AWS Disaster Recovery Whitepaper
|
|
- MySQL Replication Best Practices
|
|
- Docker Swarm DR Guide
|
|
- Laravel Backup Package Documentation
|
|
|
|
---
|
|
|
|
**문서 버전**: v1.0
|
|
**최종 수정일**: 2025-01-XX
|
|
**다음 검토일**: 2025-04-XX
|
|
**담당자**: 인프라팀 |