단일 리전 Object Storage 재해 복구 운영 회고 3

이전 글에서는
Object Storage DR를 설계하면서 왜 수동 동기화가 아닌
리전 간 자동 복제를 선택했는지를 정리했다.

 

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

 

이번 글에서는 그 다음 단계로,
운영 환경에서 이 판단이 왜 필요했는지,
그리고 자동 복제를 어떤 아키텍처 위에서 떠올리게 되었는지를
실제 운영 경험을 바탕으로 정리해본다.

 

1. 자동 복제는 요청 흐름에 포함되지 않는다

Object Storage DR를 운영 관점에서 바라보기 시작하면서
가장 먼저 정리하게 된 기준은 하나였다.

사용자 요청 경로에 DR 로직이 섞이면 안 된다.

 

운영 중에는 다음과 같은 상황을 자주 마주하게 된다.

• 특정 시점에 네트워크 상태가 불안정해진다
• 일부 외부 의존성이 순간적으로 지연된다
• 평소에는 문제 없던 요청이 갑자기 느려진다

이런 상황에서 업로드, 수정, 삭제 요청 흐름 안에
다른 리전과의 통신이 포함되어 있다면,
DR을 위한 구조가 오히려 정상 요청의 안정성을 해칠 수 있다.

 

이 경험을 통해
DR은 요청 처리와 분리되어야 한다는 결론에 가까워졌다.

 

2. 요청 시 즉시 복제가 위험한 이유

요청과 동시에 다른 리전으로 복제하는 구조는 겉보기에는 안전해 보이지만 

실제 운영 관점에서는 다음과 같은 문제가 발생한다.

• 리전 간 네트워크 지연이 사용자 응답 지연으로 전파.
• 대상 리전 장애가 원본 리전의 쓰기까지 막을 수 있다.
• 하나의 장애가 전체 서비스 장애로 확산된다.

즉, 동기 복제 구조는 DR을 위한 설계가 아니라
장애 전파 구조가 되기 쉽다.

 

그래서 자동 복제는
요청 처리와 완전히 분리된 경로에서 동작해야 했다.

 

3. 핵심 구성 요소 sync-daemon

이 역할을 담당하는 것이
백그라운드에서 동작하는 sync-daemon 이다.

 

sync-daemon의 역할은 다음과 같다.

• 사용자 요청과 무관하게 동작하고
• 원본 Object Storage의 변경 사항을 추적하며
• 다른 리전으로의 복제를 책임지는
  운영 중심의 컴포넌트에 가깝다.

하지만 중요한 점은 

언제, 어떻게, 어떤 방식으로 동작하느냐다.

 

전체 흐름을 단순화하면 다음과 같다.

1. 원본 Object Storage에 오브젝트 변경 발생
2. 변경 이력 또는 상태 정보가 내부적으로 기록됨
3. sync-daemon이 이를 주기적으로 스캔
4. 아직 복제되지 않은 오브젝트를 대상 리전으로 전송
5. 성공/실패 상태를 기록하고 재시도 여부 판단

이 구조에서 핵심은
모든 과정이 백그라운드에서 비동기적으로 진행된다는 점이다.

사용자 요청은 복제 상태와 무관하게 즉시 종료된다.

 

eventual consistency를 전제로 한 구조

이 아키텍처는 처음부터 eventual consistency를 전제로 한다.

즉, 특정 시점에는
원본과 대상 리전의 데이터가 다를 수 있지만,

시간이 지나면 결국 동일한 상태로 수렴한다.

 

이 전제를 받아들이지 않으면
Object Storage 기반 DR 설계는 성립하기 어렵다.

 

중요한 것은 일시적인 불일치 자체가 아니라,

• 그 불일치를 어디까지 허용하는지
• 사용자와 운영자에게 어떻게 설명 가능한지
• 시간이 지나면 정상적으로 수렴하는지 이다.

 

4. 이 구조가 운영에서 가지는 의미

이 아키텍처의 가장 큰 장점은 명확하다.

• 사용자 요청 경로와 DR 로직이 분리된다
• 한 리전의 문제가 다른 리전에 영향을 주지 않는다
• 운영자는 “지금 복제가 되고 있는가”를 확인할 수 있다

즉, 장애 상황에서도 예측 가능한 행동을 한다는 점이다.

DR에서 가장 중요한 것은 완벽한 무결성이 아니라
통제 가능한 상태다.

 

 

정리하며

이 포스팅에서의 핵심은 다음 4가지다.

• Object Storage DR는 요청 처리 구조가 아니다
• 자동 복제는 백그라운드 비동기 구조여야 한다
• sync-daemon은 복제 도구가 아니라 운영 컴포넌트다
• eventual consistency는 선택이 아니라 전제다

 

이 경험을 통해,
자동으로 동작하는 DR를 고민할 때
아키텍처 단계에서 무엇을 분리해야 하는지에 대한 기준이 생겼다.