단일 리전 Object Storage DR, 리전 간 자동 복제

이전 글에서는 단일 리전 Object Storage가
재해 복구(DR) 관점에서 왜 구조적으로 취약한지 살펴보았다.

 

단일 리전 Object Storage는 왜 재해 복구에 취약할까?

 

이번 글에서는
그 한계를 어떻게 해결할 것인지, 

Object Storage DR를 설계하는 과정에서 고려했던 대안들과,
리전 간 자동 복제를 선택한 이유를 정리했다.

 

그리고 이 선택이 단순한 구현 방식이 아니라
운영 관점에서 어떤 의미를 가지는지에 대해 이야기해본다.

 

---

1. DR 설계에서 마주치는 유혹

Object Storage DR를 처음 고민했을때, 
이런 생각을 했다.

다른 리전에 컨테이너 하나 만들어두고
필요할 때 데이터를 복사하면 되지 않을까?

 

이 방식은 단순하다는 장점이 있었지만, 

DR의 본질을 정상 상황 기준으로 바라본 선택이었다.

 

수동 동기화가 전제로 하는 것들

수동 동기화 방식은 은근히 많은 전제를 깔고 있다.

• 장애를 사람이 빠르게 인지한다
• 상황을 판단할 여유가 있다
• 동기화 작업을 실행할 수 있다
• 그 작업이 실패하지 않는다

그러나 재해 상황에서는 이 전제들이 쉽게 무너진다.

장애 인지는 늦을 수 있고,

운영자는 이미 다른 대응으로 정신이 없고, 

네트워크 등 기본 시스템 자체가 불안정할 수 있다.

 

2. 그래서 선택한 전략, 리전 간 자동 복제

이 문제를 피하기 위해 

사람이 개입하지 않아도 데이터가 다른 리전에 이미 존재하도록 

리전 간 자동 복제를 선택했다.

 

이 선택의 핵심은 얼마나 빠르게 복제되는가? 가 아니라

장애가 발생하기 전에 복제가 이미 진행되고 있었는가? 이다.

 

자앵 상황은 항상 예고 없이 온다.

DR은 필요할 때 실행하는 기능이 아니라
항상 작동하고 있어야 의미가 있다.

 

3. 비동기 복제 eventual consistency

자동 복제는 왜 비동기 구조일 수밖에 없는가?

 

자동 복제라고 해서
모든 요청을 즉시 다른 리전에 반영하는 구조를 선택하지는 않는다.

Object Storage DR에서는 비동기 복제가 사실상 전제가 된다.

이유는 명확하다.

• 리전 간 네트워크 지연은 피할 수 없디.
• 동기 복제는 쓰기 지연을 서비스 전체로 확산시킨다.
• 한 리전의 문제가 다른 리전까지 끌고 들어올 수 있다.

그래서 이 구조는 다음을 전제로 설계된다.

• 즉시 일관성은 보장하지 않는다
• 대신 최종 일관성을 목표로 한다
• 복제는 백그라운드에서 처리된다

eventual consistency는 운영 안정성을 위한 전제 조건에 가깝다.

 

 

DR에서 가장 치명적인 상태는 

장애 발생 시, 다른 리전에 데이터가 전혀 없는 상태다.

몇 초, 몇 분의 지연보다

아예 복제 자체가 안 된 상태가 훨씬 위험하다.

 

DR의 목적은 모든 데이터를 실시간으로 동일하게 유지하는 것이 아니라,
장애 시 복구 가능한 지점을 확보하는 데 있다.

사람이 개입하지 않아도 유지되는지, 

장애 상황에서도 예측 가능한지, 

운영 부담을 구조적으로 줄이는지가 중요하다.

 

결론

결국 Object Storage DR에서 중요한 것은
복제가 항상 자동으로 이루어지고 있었는가 이다.

그래서 수동 동기화가 아니라 리전 간 자동 복제를 선택했다.

 

다음 글에서는
이 자동 복제 전략을 실제로 어떻게 구현했는지,

• sync-daemon은 어떤 역할을 했는지
• 왜 요청 시 즉시 복제하지 않았는지
• 백그라운드 기반 구조는 어떤 장단점이 있는지

아키텍처 관점에서 핵심 구성 요소를 하나씩 풀어본다.