멀티 리전 배포

멀티 리전 배포는 단일 리전 최적화만으로는 해결할 수 없는 문제들을 해결하기 위해 애플리케이션을 여러 지리적 영역에 분산시킵니다. 복잡성은 분명히 존재하지만, 이를 필요로 하는 이유도 그만큼 분명합니다.

지리적 한계를 최적화로 극복할 수 없는 이유

빛의 속도는 타협이 없습니다. 캘리포니아에서 싱가포르까지 데이터가 이동하는 데는 최소 100밀리초의 왕복 시간이 필요합니다—그것도 빛이 진공 속에서 직선으로 이동한다고 가정했을 때의 이야기이며, 광섬유 케이블은 결코 그렇지 않습니다. 실제 라우팅에는 추가 오버헤드가 붙습니다. 어떤 캐싱 전략도, 엣지 최적화도, 영리한 엔지니어링도 이것을 없앨 수 없습니다. 유일한 해결책은 서버를 사용자 가까이에 배치하는 것입니다.

사용자가 북미, 유럽, 아시아에 걸쳐 있다면, 미국 단일 데이터 센터에서 모두 서비스하는 것은 유럽과 아시아 사용자에게 엔지니어링으로는 해결할 수 없는 지연 시간을 경험하게 합니다. 멀티 리전 배포만이 유일한 해결책입니다.

지연 시간 외에도, 지리적 분산은 다음을 제공합니다:

리전 이중화. 클라우드 제공업체들은 리전을 안정적으로 설계하지만, 허리케인, 홍수, 전력망 장애, 광섬유 절단 같은 일들은 실제로 발생합니다. 단일 리전에 있는 애플리케이션은 해당 리전 전체를 마비시키는 사건에 취약합니다.

빠른 재해 복구. 다른 곳에 이미 인프라가 실행 중이라면 장애 조치는 라우팅 변경으로 끝납니다—인프라를 처음부터 다시 구축할 필요가 없습니다. 멀티 리전이 없다면, 재해 복구는 위기 상황에서 모든 것을 처음부터 구축하는 것을 의미합니다.

규정 준수. 일부 규정은 데이터가 지리적 경계 내에 있어야 한다고 요구합니다. 멀티 리전 배포를 통해 유럽 데이터를 유럽 내에 유지하면서도 통합된 애플리케이션을 운영할 수 있습니다.

액티브-액티브: 최대 복원력, 최대 복잡성

액티브-액티브 배포에서는 여러 리전이 동시에 프로덕션 트래픽을 처리합니다. 사용자는 가장 가까운 리전으로 라우팅됩니다. 한 리전이 장애를 일으켜도, 다른 리전들은 별도의 개입 없이 트래픽을 계속 처리합니다.

데이터에 대한 함의를 고려하기 전까지는 이상적으로 들립니다.

근본적인 문제: 유럽과 아시아의 사용자가 모두 데이터를 쓸 수 있는 상황에서 네트워크 파티션이 발생하면 충돌이 생깁니다. 동일한 레코드가 두 곳에서 동시에 수정됩니다. 마법 같은 해결책은 없습니다—트레이드오프만 있을 뿐입니다.

충돌 해결 전략에는 다음이 포함됩니다:

• 최후 쓰기 우선(Last-write-wins): 단순하지만, 데이터를 조용히 버립니다. 유럽 사용자가 자신의 작업을 저장하고 아시아 사용자도 저장하면, 그 중 하나는 자신도 모르게 사라집니다.
• 벡터 클록(Vector clocks): 애플리케이션 수준 해결을 위해 충돌하는 모든 버전을 보존합니다. 구현이 복잡하지만, 데이터 손실이 없습니다.
• 지리적 파티셔닝: 유럽 사용자는 유럽 데이터만 수정할 수 있습니다. 가능성 자체를 없애 충돌을 제거합니다. 데이터 모델이 이를 지원할 때 사용할 수 있습니다.

데이터베이스 아키텍처는 액티브-액티브가 어려워지는 지점입니다. 대부분의 관계형 데이터베이스는 단일 데이터 소스를 가정합니다. 멀티 마스터 복제가 존재하지만 충돌 복잡성을 수반합니다. 대안으로는:

• 데이터를 리전별로 파티셔닝 (사용자 데이터는 홈 리전에 유지)
• 최종 일관성 수용 (데이터가 동기화되지만 일시적으로 불일치할 수 있음)
• 글로벌 분산을 위해 설계된 데이터베이스 사용 (Spanner, DynamoDB Global Tables, Cosmos DB)

이러한 특수 데이터베이스들이 마법은 아닙니다—동일한 트레이드오프를 하되, API 뒤에 복잡성을 숨긴 것입니다. Spanner는 원자 시계와 GPS 수신기를 사용해 글로벌 일관성을 달성합니다. DynamoDB Global Tables는 기본적으로 최후 쓰기 우선을 사용합니다. Cosmos DB는 일관성 수준을 선택할 수 있게 합니다. 어떤 트레이드오프를 수용하는지 명확히 알아야 합니다.

세션 관리는 또 다른 레이어를 추가합니다. 사용자가 한 리전에서 시작하고 세션 도중 라우팅이 변경된다면, 세션 상태가 사용자를 따라가야 합니다—아니면 세션 기간 동안 사용자를 한 리전에 묶어두는 스티키 라우팅이 필요합니다.

액티브-패시브: 더 단순하고, 여전히 충분히 가치 있는

액티브-패시브는 하나의 리전이 모든 트래픽을 처리하면서 동기화된 대기 상태를 유지합니다. 액티브-액티브보다 단순하고 운영 비용도 적으며, 재해 복구 기능을 제공합니다.

**기본 리전(Primary region)**은 모든 것을 처리합니다. 모든 애플리케이션 인스턴스, 데이터베이스, 서비스가 여기서 활성 상태로 실행됩니다.

**보조 리전(Secondary region)**은 트래픽을 처리하지 않는 복제된 인프라를 유지합니다. 데이터베이스는 기본 리전에서 지속적으로 복제됩니다. 애플리케이션 코드는 배포되어 준비 상태이지만 유휴 상태입니다.

**장애 조치(Failover)**는 기본 리전에 장애가 생길 때 보조 리전을 활성화합니다. 자동(상태 확인이 장애를 감지하고 라우팅이 전환됨)으로 이루어지거나, 수동(운영자가 문제를 확인하고 장애 조치를 트리거함)으로 이루어질 수 있습니다.

두 가지 지표가 재해 복구 능력을 정의합니다:

복구 시간 목표(RTO, Recovery Time Objective): 서비스가 복구되는 데 걸리는 시간. 액티브-패시브는 몇 분(자동 장애 조치)에서 몇 시간(수동 개입 필요)까지의 RTO를 달성합니다.

복구 지점 목표(RPO, Recovery Point Objective): 손실되는 데이터의 양. 지속적인 복제를 통해 RPO는 몇 초에서 몇 분이 될 수 있습니다. 데이터 손실 제로를 달성하려면 동기식 복제가 필요하며, 이는 기본 리전의 쓰기가 보조 리전의 확인을 기다린다는 의미입니다—모든 쓰기에 지연 시간이 추가됩니다.

많은 애플리케이션에서 액티브-패시브가 올바른 선택입니다. 액티브-액티브의 복잡성 비용이 항상 그 이점을 정당화하지는 않습니다.

데이터 복제: 트레이드오프를 선택하세요

모든 복제 전략은 무언가를 다른 무언가와 맞바꿉니다.

동기식 복제는 성공을 확인하기 전에 모든 리전에 씁니다. 리전 간 강력한 일관성을 제공하지만, 모든 쓰기는 다른 리전으로의 왕복 지연 비용을 치릅니다. 버지니아의 애플리케이션은 사용자에게 데이터가 저장되었다고 알리기 전에 프랑크푸르트의 확인을 기다립니다.

비동기식 복제는 로컬에 쓰고 백그라운드에서 복제합니다. 쓰기가 빠르지만, 다른 리전들은 뒤처집니다. 복제가 완료되기 전에 기본 리전이 장애를 일으키면, 해당 데이터는 손실됩니다.

**읽기 복제본(Read replica)**은 쓰기는 하나의 기본 리전으로 가면서 로컬 읽기를 허용합니다. 읽기가 많은 워크로드에 잘 맞습니다. 대부분의 사용자는 읽기를 하고, 쓰기를 하는 소수는 더 높은 지연 시간을 감수합니다.

지리적 파티셔닝은 데이터를 생성된 리전에 유지합니다. 유럽 사용자 데이터는 유럽에 남습니다. 단순하고 데이터 거주 요건을 준수하지만, 리전 간 쿼리는 느리거나 불가능합니다.

CDN은 정적 콘텐츠를 전 세계 엣지 위치에 복제합니다. 자주 변경되지 않는 이미지, 동영상, 파일에는 가장 효과적인 방법입니다.

비용의 현실

멀티 리전 배포는 비용을 배가시킵니다.

리전 간 데이터 전송은 비쌉니다. 클라우드 제공업체들은 리전 간 데이터 이동에 상당한 요금을 청구합니다. 대용량 데이터셋을 복제하는 애플리케이션은 전송 비용이 컴퓨팅 비용을 초과하는 경우도 있습니다.

인프라 증가. 한 리전에 서버가 10대 필요하다면, 3개 리전 각각에 10대가 필요할 수 있습니다. 데이터베이스, 로드 밸런서, 지원 서비스를 고려하기 전에 이미 컴퓨팅 비용이 세 배입니다.

엔지니어링 복잡성은 숨겨진 비용입니다. 분산 시스템을 구축, 테스트, 유지 관리하는 데는 더 많은 엔지니어링 시간이 필요합니다. 특정 리전 간 조건에서만 나타나는 문제를 디버깅하는 것은 고통스럽습니다.

최적화 전략:

• 모든 곳에서 전체 용량을 실행하는 것을 피하기 위해 액티브-액티브 대신 액티브-패시브 사용
• 보조 리전에서 최소한의 장애 조치 능력만 유지 (실제 장애 조치 때만 확장)
• 리전 간 데이터 전송을 줄이는 지리적 파티셔닝
• 전 세계 전체 애플리케이션 배포 대신 정적 콘텐츠에 CDN 활용

테스트: 모두가 빼먹는 부분

대부분의 조직은 실제로 장애 조치를 테스트하지 않습니다. 멀티 리전 아키텍처를 구축하고, 장애 조치 절차를 문서화하고, 작동하기를 바랍니다. 그러다 실제 장애가 발생하면 문서가 틀렸거나, 자동화가 작동하지 않거나, 복제된 데이터베이스가 세 시간이나 뒤처져 있다는 것을 발견합니다.

장애 조치 테스트는 기본 리전을 의도적으로 장애 상태로 만들고 트래픽이 보조 리전으로 이동하는지 확인하는 것입니다. 실제로 이것을 하세요. 가능하다면 프로덕션에서, 그렇지 않다면 프로덕션과 최대한 유사한 환경에서.

카오스 엔지니어링은 지속적으로 장애를 주입합니다. Netflix의 Chaos Monkey는 무작위 인스턴스를 종료합니다. Chaos Kong은 전체 리전을 마비시킵니다. 이러한 도구들이 존재하는 이유는 Netflix가 테스트되지 않은 복원력은 복원력이 아니라는 것을 직접 체험했기 때문입니다.

데이터 일관성 테스트는 복제가 올바르게 작동하는지 확인합니다. 한 리전에서 데이터를 쓰고, 다른 리전에서 읽고, 일치하는지 확인합니다. 여러 리전에서 동시에 동일한 레코드를 쓰는 방식으로 충돌 해결을 테스트합니다.

재해 복구 훈련은 실제로 이 절차를 실행할 사람들과 함께 완전한 장애 조치 절차를 테스트합니다. 팀이 어떻게 대응해야 하는지 알고, 문서화된 절차가 실제로 작동하는지 확인합니다.

테스트하지 않았다면, 작동하지 않는다고 가정하세요.

사용자를 올바른 리전으로 라우팅하기

GeoDNS는 쿼리 출처에 따라 다른 IP 주소를 반환합니다. 유럽 사용자는 유럽 리전의 IP로 연결되고, 아시아 사용자는 아시아 IP로 연결됩니다. 단순하지만 정밀하지는 않습니다—DNS가 캐시될 수 있고, 사용자는 실제 위치와 먼 곳의 확인자를 통해 쿼리할 수도 있습니다.

**애니캐스트(Anycast)**는 여러 위치에서 동일한 IP를 광고합니다. 인터넷 라우팅이 자동으로 패킷을 가장 가까운 광고 지점으로 보냅니다. 대부분의 애플리케이션에는 없는 BGP 제어가 필요하지만, 이를 갖춘 경우에는 잘 작동합니다.

애플리케이션 수준 라우팅은 CDN 또는 로드 밸런서가 실제 사용자 위치, 리전 상태, 현재 부하를 기반으로 요청별 결정을 내릴 수 있게 합니다. 더 정교하며, 별도의 구현이 필요합니다.

상태 인식 라우팅은 비정상 리전으로의 트래픽 전송을 중단합니다. 한 리전에서 상태 확인이 실패하면, 트래픽이 자동으로 정상 리전으로 흐릅니다.

단순하게 시작하고, 필요에 따라 확장하세요

모든 곳에 즉시 배포할 필요는 없습니다.

단일 리전으로 시작하세요. 대부분의 애플리케이션은 여기서 시작하며, 새로운 지역에서의 사용자 증가, 규정 준수 요건, 가용성 요구와 같은 구체적인 필요가 생길 때만 리전을 추가합니다.

두 번째로 재해 복구를 추가하세요. 액티브-액티브로 가기 전에, 먼저 액티브-패시브 보조 리전을 추가하세요. 여러 리전에서 동시에 트래픽을 처리하는 복잡성에 맞서기 전에 복제와 장애 조치에 익숙해지세요.

점진적으로 확장하세요. 사용자 규모가 복잡성을 정당화하는 리전에 추가하세요. 하나 또는 두 개의 주요 리전으로 대부분의 글로벌 애플리케이션을 처리할 수 있으며, 세 개에서 다섯 개로 거의 모든 경우를 커버합니다.

멀티 리전 배포에 관한 자주 묻는 질문

CDN만 사용하는 것과 비교해 멀티 리전 배포는 언제 필요한가요?

CDN은 정적 콘텐츠를 처리하고 엣지에서 동적 콘텐츠를 캐시할 수 있지만, 사용자 가까이에서 애플리케이션 로직이나 데이터베이스를 실행할 수 없습니다. 지연 시간 문제가 이미지와 정적 자산 제공에 관한 것이라면 CDN으로 충분합니다. 사용자가 데이터베이스 쿼리나 복잡한 애플리케이션 처리를 기다리고 있다면, 사용자 가까이에 실제 컴퓨팅이 필요합니다.

액티브-액티브와 액티브-패시브 중 어떻게 선택하나요?

주된 관심사가 재해 복구이고 장애 조치 중 몇 분에서 몇 시간의 다운타임을 허용할 수 있다면 액티브-패시브를 선택하세요. 글로벌 사용자를 위한 낮은 지연 시간과 리전 장애 시 거의 제로에 가까운 다운타임이 모두 필요하고 분산 데이터 일관성 문제를 해결하는 데 투자할 의향이 있다면 액티브-액티브를 선택하세요. 대부분의 애플리케이션은 액티브-패시브로 시작해야 합니다.

장애 조치 중 처리 중이던 요청은 어떻게 되나요?

실패합니다. 사용자는 리전이 다운될 때 처리 중이던 요청에서 오류를 봅니다. 애플리케이션은 이를 매끄럽게 처리해야 합니다—재시도 로직, 명확한 오류 메시지, 그리고 재시도된 요청이 중복 작업을 일으키지 않도록 하는 멱등성 연산이 필요합니다.

PostgreSQL 같은 전통적인 관계형 데이터베이스로 멀티 리전을 구현할 수 있나요?

네, 하지만 제약이 있습니다. 여러 리전의 읽기 복제본은 읽기가 많은 워크로드에 잘 작동합니다. 쓰기의 경우, 모든 쓰기를 하나의 리전으로 보내거나(원격 사용자에게 지연 시간 추가), 애플리케이션 수준 충돌 해결을 갖춘 멀티 마스터 복제를 구현해야 합니다. PostgreSQL의 논리적 복제와 BDR 같은 도구가 이를 가능하게 하지만, 복잡합니다.

새 리전을 추가하면 지연 시간이 얼마나 개선되나요?

대략, 현재 리전까지의 왕복 시간에서 새롭고 더 가까운 리전까지의 왕복 시간을 뺀 만큼 절약됩니다. 유럽 사용자가 현재 US-East(왕복 80ms)에 접속하고 EU-West(왕복 10ms)를 추가한다면, 요청당 약 70ms를 절약합니다. 여러 순차적 요청을 하는 애플리케이션에서는 이 효과가 크게 누적됩니다.