626. 재해 복구 시스템 (DRS) 스토리지 미러링

핵심 인사이트 (3줄 요약)

서버 랙 수준의 이중화(RAID, 이중 파워)는 데이터센터 건물 자체에 화재가 나거나 정전이 발생하면 속수무책으로 당할 수밖에 없다.

이를 대비하기 위해 국가나 대기업은 수백 km 떨어진 안전한 곳에 1:1 똑같은 쌍둥이 데이터센터를 지어두는데 이를 **재해 복구 시스템(DRS, Disaster Recovery System)**이라 부른다.

주 센터와 DR 센터 간에 데이터를 똑같이 맞추는 스토리지 미러링(Mirroring) 기술이 핵심이며, 거리와 네트워크 속도에 따라 동기식(Synchronous)과 비동기식(Asynchronous) 방식 중 하나를 선택해야 한다.

Ⅰ. 카카오 사태가 일깨워준 재해 복구(DR)의 중요성

데이터센터 지하에 불이 나서 전력이 몽땅 끊어지는 사태가 발생하면, 디스크가 무사해도 서비스를 켤 수가 없습니다. 은행의 경우 하루만 서비스가 죽어도 국가 경제가 마비됩니다.

이를 막기 위해 등장한 것이 **DRS (Disaster Recovery System)**입니다.

주 센터 (Primary Center / Active): 서울에 위치하며 평소 고객의 모든 결제 트래픽을 처리합니다.
재해 복구 센터 (DR Center / Standby): 부산에 위치하며 평소에는 놀고 있습니다. 서울 센터가 파괴되면, 10분 내로 부산 센터가 깨어나서 서울 행세를 하며 서비스를 그대로 이어받습니다.

이게 가능하려면 서울에서 발생한 결제 데이터가 **거의 0.1초의 오차도 없이 부산 센터의 스토리지(하드디스크)에 똑같이 저장(미러링)**되어 있어야 합니다.

📢 섹션 요약 비유: 비행기의 기장(주 센터)이 갑자기 심장마비로 쓰러졌습니다. 이때 비행기가 추락하지 않게 하려면, 옆자리에 똑같은 조종간을 잡고 기장이 하는 모든 행동을 실시간으로 따라 하고 있던 부기장(DR 센터)이 즉시 비행기를 몰아야 합니다.

Ⅱ. 스토리지 미러링의 2가지 아키텍처

주 센터의 스토리지에 데이터를 쓸 때, 먼 거리에 있는 DR 센터에 어떻게 복사할 것인가가 핵심입니다. 물리적인 빛의 속도 한계 때문에 두 가지 타협점이 존재합니다.

1. 동기식 미러링 (Synchronous Mirroring)

동작 원리: 서울 서버가 데이터를 쓸 때, 서울 스토리지에 씁니다. 동시에 광케이블을 타고 부산 스토리지에도 씁니다. 부산 스토리지에서 "나도 잘 적었어!(ACK)"라는 응답이 서울에 도착해야만, 비로소 서울 서버가 "결제 완료!" 화면을 띄웁니다.
장점: 서울 센터가 불타도 데이터 유실(RPO)이 완벽하게 0입니다. (가장 안전)
단점 (거리의 한계): 서울에서 부산까지 빛의 속도로 갔다 와도 수 밀리초가 걸립니다. 고객은 결제 버튼을 누를 때마다 이 딜레마(Latency)를 견뎌야 합니다. 거리가 50km~100km를 넘어가면 서비스 속도가 너무 느려져서 쓸 수 없습니다.

2. 비동기식 미러링 (Asynchronous Mirroring)

동작 원리: 서울 서버는 일단 서울 스토리지에 데이터를 쓰자마자 즉시 고객에게 "결제 완료!"를 띄웁니다(초고속). 그리고 뒤에서 몰래(비동기적으로), 1분 단위로 묶어서 부산 스토리지에 툭툭 던져놓습니다.
장점: 거리 제한이 없습니다. 서울과 뉴욕 사이에서도 미러링이 가능하며, 결제 속도가 매우 빠릅니다.
단점 (데이터 유실): 서울 서버가 결제 완료를 띄웠는데 부산에 데이터를 보내기 전 1분 사이에 서울 센터가 불타버리면? **방금 결제한 1분 치의 데이터는 영원히 공중 분해(유실)**됩니다.

미러링 아키텍처 (ASCII)

 [ 동기식 (느리지만 완벽) ]                   [ 비동기식 (빠르지만 찜찜함) ]
  서울 서버                                    서울 서버 
    │ (1. Write)                               │ (1. Write)
    ▼             (2. 부산 전송)               ▼
 [서울 스토리지] ════════════▶ [부산]      [서울 스토리지] ──▶ (3. 결제 완료 띄움!)
    │             (3. ACK)       │             │
    ▼ ◀══════════════════════════┘             │ (4. 뒤에서 천천히 복사)
 (4. 늦게 결제 완료!)                               ▼
                                            [부산 스토리지]

📢 섹션 요약 비유: 동기식은 문서를 쓸 때 아예 서울과 부산에 먹지를 대고 동시에 볼펜으로 꾹꾹 눌러 쓰는 것입니다(느리고 손 아프지만 완벽). 비동기식은 서울에서 빠르게 막 갈겨쓴 다음, 1시간마다 복사기로 복사해서 부산으로 팩스를 보내는 것입니다(빠르지만 중간에 불나면 1시간 치 날아감).

Ⅲ. 현대의 타협: 3 Data Center (3DC) 전략

동기식과 비동기식의 단점을 모두 없애기 위해, 거대 은행이나 금융권은 아예 **데이터센터를 3개 짓는 무식한 방법(3DC)**을 사용합니다.

Active (서울): 메인 센터.
Sync Standby (분당/판교): 서울에서 20~30km 떨어진 매우 가까운 곳에 지어, 딜레이를 최소화한 동기식 미러링을 돌립니다. (수도권 지진 대비)
Async Standby (부산): 400km 떨어진 먼 곳에 지어, 서울/판교에서 비동기식으로 여유롭게 데이터를 받아 놓습니다. (수도권 전체에 핵이 떨어지는 상황 대비)

이로써 성능, 무손실, 거대한 지역 재난 대비라는 세 마리 토끼를 모두 잡는 극한의 하드웨어 스토리지 뼈대를 구축하게 됩니다. (다음 장의 RPO/RTO 개념과 직결됨)