재해 복구 파일 전송: 비즈니스 연속성 확보

재해 복구 파일 전송은 주 사이트가 실패할 때 운영을 지속합니다. 교차 리전 복제(S3 CRR, Azure GRS), 웜 스탠바이 인프라, 문서화된 장애 조치 런북을 통해서입니다. DR 준비된 파일 시스템은 RPO 수초에서 수시간 이내로 보조 위치에 변경 사항을 지속적으로 복사하고, RTO 목표 이내에 장애 조치를 지원하며, 현실적인 조건에서 테스트됐습니다. 유용한 DR로 가는 가장 짧은 길: 워크로드 하나를 선택하고, 두 번째 리전에 복제하고, 토요일에 리전 장애를 시뮬레이션하고, 실제로 무슨 일이 일어나는지 측정하세요.

비즈니스 영향으로 워크로드 분류

모든 파일 시스템이 핫-핫 복제를 받을 자격이 있지는 않습니다. 비즈니스 영향 분석은 가동 중단과 데이터 손실에 대한 내성으로 시스템을 분류합니다.

티어 0(미션 크리티컬): 결제 처리, 임상 시스템. RPO <1분, RTO <15분.
티어 1(중요): 주문 관리, 고객 대상 앱. RPO <15분, RTO <1시간.
티어 2(중요도 높음): 내부 도구, 리포팅. RPO <24시간, RTO <8시간.
티어 3(표준): 교육 자료, 아카이브. RPO <1주, RTO <3일.

티어 0은 복제 비용이 티어 3의 3~10배입니다. 시스템을 정직하게 매핑하세요. 대부분의 기업은 시스템의 5~10%가 티어 0~1에 속하며, 모든 것을 똑같이 고급화하는 대신 거기에 지출을 집중해야 합니다.

복제 토폴로지

파일 스토리지에서 세 가지 복제 모델이 주를 이룹니다.

액티브-패시브: 주 사이트가 쓰기를 받고 보조 사이트가 복제본을 받습니다. 장애 조치 시 승격이 필요합니다. 대부분의 리전 DR 설정에 사용됩니다.
액티브-액티브: 두 리전이 모두 쓰기를 받으며 충돌 해결이 있습니다. 복잡도가 높지만 RTO가 거의 0에 가깝습니다. 글로벌 시스템에 사용됩니다.
백업 기반: 보조 사이트에 주기적 백업. RPO가 가장 높지만 가장 단순합니다. 티어 3에 사용됩니다.

S3 교차 리전 복제(CRR)는 1분 미만 RPO로 액티브-패시브를 구현합니다. S3 다중 리전 액세스 포인트는 장애 조치 라우팅을 추가합니다. 액티브-액티브의 경우 DynamoDB Global Tables와 CockroachDB가 데이터베이스를 처리하고, 파일에는 충돌 해결 태그가 있는 양방향 rclone이 DIY 접근법 중 하나입니다.

보조 리전 선택

주 리전과 보조 리전은 독립적으로 실패해야 합니다. 경험칙:

다른 지리적 리전(us-east-1 → us-west-2, us-east-1 → us-east-2 아님)
다른 전력망(미국 서해안 대 동해안, 다른 유럽 국가 전력망)
해당되는 경우 다른 지각 구역(둘 다 환태평양 조산대에 있지 않도록)

컴플라이언스 워크로드의 경우 두 리전 모두 규정을 만족해야 합니다. GDPR 데이터는 EU 내에 있어야 합니다. 파리를 프랑크푸르트나 더블린으로 복제하고, 버지니아는 피하세요. HIPAA는 보조 리전에도 BAA가 필요합니다. 리전 선택과 근거를 문서화하세요. 감사인이 물어볼 것입니다.

교차 리전 복제 비용

복제에는 세 가지 비용 요소가 있습니다.

스토리지: 주 비용의 두 배(두 리전 모두 복사본 유지)
데이터 전송: AWS는 리전 간 CRR에 GB당 $0.02를 청구
요청 요금: 대상의 PUT 작업

버지니아와 오리건 간에 월 10 TB를 복제하면 AWS에서 약 월 $700을 예상하세요. 완화 방법: 대상에서 더 저렴한 스토리지 클래스로 복제(Standard 대신 S3 Glacier Instant Retrieval), 접두사나 태그로 복제를 필터링해 비중요 데이터 제외, 버킷 복제 메트릭으로 과도한 복제 감지.

장애 조치 런북

아이디어로만 존재하는 런북은 실패하는 런북입니다. 프로덕션 준비된 런북이 다루는 것:

트리거 기준: 장애 조치를 시작하는 조건(리전 상태 페이지, 애플리케이션 상태 확인, P99 지연 시간 임계값 초과)
결정 권한: 누가 결정을 내리는가(보통 엔지니어링 VP + SRE 리드, 자동 트리거를 위한 사전 승인된 임계값 포함)
단계: 정확한 명령어, 순서대로, 예상 출력 포함
검증: 각 단계가 작동했는지 확인하는 방법
롤백: 장애 조치 자체가 문제를 일으킨 경우 되돌리는 방법
소통: 상태 페이지 업데이트, 고객 알림, 내부 카카오워크/Slack

S3 기반 애플리케이션의 장애 조치 단계 예시: Route 53을 업데이트해 files.example.com을 주 버킷의 CloudFront에서 보조 버킷의 CloudFront로 변경. dig와 카나리 업로드로 테스트. 시간 목표: 10분 이내.

DNS와 라우팅 전략

DNS가 보통 장애 조치를 구동합니다. 옵션:

Route 53 Failover 라우팅: 상태 확인 기반 자동 전환이 있는 액티브-패시브
Route 53 지연 시간 라우팅: 가장 가까운 정상 리전으로 트래픽
오리진 장애 조치가 있는 CloudFront: 클라이언트에 투명
다중 리전 백엔드가 있는 로드 밸런서: 작동하지만 복잡도 추가

TTL이 중요합니다. 300초 TTL이 있는 DNS 레코드는 5분에 장애 조치됩니다. 3,600초 TTL은 한 시간이 걸립니다. DR 크리티컬 레코드는 TTL 60~300초로 설정해 더 빠른 수렴을 위해 약간 더 많은 DNS 트래픽을 허용하세요.

장애 조치 중 데이터 무결성

복제 지연은 보조 사이트가 약간 뒤처져 있음을 의미합니다. 장애 조치 시 가장 최근 쓰기를 잃을 수 있습니다. RPO를 예상되는 최악의 손실로 문서화하고 조정 계획을 가지세요.

재실행할 수 있도록 애플리케이션 레이어에서 미커밋 쓰기 기록
진행 중인 트랜잭션을 캡처하고 이벤트 로그에서 재실행
손실을 명시적으로 수용(비중요 데이터의 경우 더 단순한 것이 낫습니다)

파일 업로드의 경우 장애 조치로 중단된 멀티파트 업로드가 보조 사이트에 불완전한 업로드를 남길 수 있습니다. 두 리전 모두에 AbortIncompleteMultipartUpload 라이프사이클 규칙을 설정해 정리하세요.

DR 진지하게 테스트하기

테스트된 DR 계획과 테스트되지 않은 DR 계획은 다른 동물입니다. 테스트 단계:

테이블탑 연습: 런북을 구두로 검토. 분기별.
부분 장애 조치: 하나의 서브시스템(예: 파일 서비스만) 장애 조치. 반기별.
전체 리전 장애 조치: 예정된 유지보수 창에서 모든 것을 장애 조치. 연간.
카오스 엔지니어링: 업무 시간 중 비예정, 시뮬레이션된. 티어 0 시스템에 분기별.

모든 것을 기록하세요. 무엇이 고장났는지. 각 단계가 실제로 얼마나 걸렸는지. 필요할 때 문서에 접근할 수 없었던 사람이 누구였는지. 각 테스트 후 런북을 개선하세요. 이를 하는 팀은 작동하는 장애 조치를 가지고, 하지 않는 팀은 실제 사고 중에 문제를 발견합니다.

소통 채널이 중요합니다

사고 중에 클라우드 내 소통이 불가능할 수 있습니다. 실패하는 것과 같은 AWS 리전에 호스팅된 Slack은 쓸모없습니다. 대역 외 채널을 사전에 준비하세요.

다른 리전에 호스팅된 보조 Slack 워크스페이스
Twilio 또는 Telnyx를 통한 SMS 브리지
최후의 수단으로 개인 전화 트리
주 인프라 외부에 호스팅된 공개 상태 페이지(Atlassian Statuspage, StatusGator)

채널을 물리적 바인더에 문서화하세요. 전환을 연습하세요.

사람들 간 복구 파일 전송

리전 장애로 정상 협업 도구 접근이 차단되면 현재 데이터베이스 덤프, 설정 내보내기, 사고 대응 플레이북 같은 특정 파일을 인프라와 독립적으로 작동하는 채널로 전송해야 합니다.

HexaTransfer는 계정 설정 없이 모든 브라우저에서 실행됩니다. SSO 공급자도 다운됐을 때, 또는 외부 컨설턴트가 테넌트에 프로비저닝 없이 파일을 받아야 할 때 유용합니다. 종단간 AES-256-GCM 암호화는 손이 떨리는 긴급 상황에서도 비밀이 네트워크를 통해 유출되지 않음을 보장합니다.

사후 검토

모든 DR 테스트와 실제 사고는 비난 없는 사후 검토를 받을 자격이 있습니다. 문서화할 것:

사건 타임라인
무엇이 작동했는지
무엇이 작동하지 않았는지
근본 원인(기술적 및 프로세스)
소유자와 기한이 있는 조치 항목

조치 항목을 완료까지 추적하세요. 20개의 조치가 있고 완료된 것이 하나도 없는 사후 검토는 사후 검토가 없는 것보다 나쁩니다. 팀에게 개선이 중요하지 않다는 신호를 줍니다. 마무리를 짓고, 다음 사고는 이전보다 나아집니다.

재해 복구는 대부분 기율입니다. RPO/RTO를 설정하고, 지속적으로 복제하고, 런북을 문서화하고, 분기별로 테스트하고, 대역 외에서 소통하세요. 기술은 쉬운 부분입니다.

hexatransfer.com에서 사용해보세요 — 무료, 계정 불필요, 최대 10 GB.