AWS 기술 블로그
AWS 기반 재해복구(DR) 아키텍처, 4부: 액티브/액티브 멀티 사이트
이 글은 AWS Architecture Blog에 게시된 Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active by Seth Eliot 을 한국어로 번역 및 편집하였습니다.
AWS 블로그의 재해복구 연재 글에서 네 가지 재해복구 전략을 소개하였습니다. 이 중 세가지 전략, 백업/복구, 파이럿 라이트와 웜 스탠바이 액티브/패시브 전략의 구성을 예제와 함께 알아보았습니다.
이번 블로그에서는 워크로드와 사용자 요청을 두 개이상의 분리된 지역에서 수행할 수 있도록 하는 액티브/액티브 전략을 구현하는 방법에 대해 소개하겠습니다. 다른 재해복구 전략과 마찬가지로 액티브/액티브 전략 또한 자연재해, 기술 결함 또는 인적 오류에 의한 재해 사고에서도 서비스를 유지할 수 있습니다.
재해복구 전략: 멀티 사이트 액티브/액티브
이제는 익숙한 [그림 1] 재해복구(DR) 전략 그림에서 보는 것처럼, 멀티사이트 액티브/액티브 전략은 가장 낮은 RTO (recovery time objective)와 RPO (recovery point objective)를 제공합니다. 주의할 것은 멀티 사이트에서 운영환경을 유지할 때의 운영 복잡성과 잠재적 비용을 함께 고려해야 한다는 것입니다.
[그림1. 재해복구 전략]
멀티사이트(Multi-Site) 액티브/액티브 구현하기
[그림 2] 의 아키텍처는 AWS 리전(Region)을 활용한 멀티사이트 액티브/액티브 아키텍처를 구현하는 예제를 제시 합니다. 예제에서는 두 개의 리전(Region)이 사용되었으나, 더 많은 리전(Region)이 사용될 수도 있습니다. 각 리전(Region)에는 고가용성을 위해 다중 가용영역(AZ)를 구성하여 워크로드를 처리 하였습니다. 데이터는 각 리전에서 데이터 저장소 간에 실시간으로 복제되며, 주기적으로 백업됩니다. 백업은 데이터 삭제 또는 훼손을 포함한 재해에서 데이터를 가장 최신의 정상 상태로 복원할 수 있어 반드시 필요 합니다.
[그림 2. 멀티사이트 액티브/액티브 재해복구 전략]
트래픽 라우팅
각 리전의 인프라는 사용자가 보낸 요청을 처리합니다. 트래픽 라우팅을 구현 하는방법에 따라 어떤 리전이 사용자 요청을 처리할 지 결정합니다. [그림 2]에서는, 고가용성의 확장 가능한 클라우드 도메인 네임 시스템(DNS)인 Amazon Route 53가 라우팅의 주체로 사용되었습니다. Route 53은 다중 라우팅 정책을 제공합니다. 예를 들어, 위치기반(geolocation) 또는 지연시간기반(latency) 라우팅 정책은 액티브/액티브 구성에 적합한 옵션을 제공합니다. 위치기반(geolocation) 라우팅은 최초 요청이 발생하는 지역을 기반으로 처리할 리전(Region)을 선택하는 방식입니다. 지연시간기반(latency) 라우팅은 AWS가 자동으로 가장 짧은 네트워크 왕복시간을 제공하는 리전(Region)으로 요청을 보내는 방식입니다.
데이터의 보안과 정책을 정의한 데이터 거버넌스(data governance)는 라우팅 전략을 선택할때 중요하게 고려해야하는 요소 입니다. 위치기반(geolocation) 라우팅을 이용하여 특정 사용자의 접속 위치를 기반으로 특정 리전(Region)에 종속 시킬수 있습니다. 이 방식으로 특정 사용자의 데이터가 특정 리전(Region)내에서만 처리되도록 할수 있습니다. 특히 쓰기 작업이 특정 리전에서 처리되도록 제어할 수 있어 데이터 쓰기 경합을 방지할 수 있습니다. 하지만 성능 최적화가 최우선 순위라면, 응답속도를 기반으로 하는 지연시간기반(latency) 라우팅을 선택하는 것이 보다 효율적 입니다.
읽기/쓰기 패턴
로컬 읽기/로컬 쓰기 패턴
요청이 전달되는 리전을 해당 요청에 대한 “로컬 리전”이라 부릅니다. 지연시간을 줄이고 잠재적 네트워크 에러를 감소시키기 위해서 멀티리전 액티브/액티브 아키텍처에서는 로컬 리전에서 모든 읽기/쓰기 요청을 처리해야 합니다.
[그림 2]의 예제 아키텍처에서는 Amazon DynamoDB가 사용되었습니다. DynamoDB 글로벌 테이블은 여러 리전(Region)으로 테이블 데이터를 복제합니다. 모든 리전(Region)에서의 테이블의 쓰기 작업은 수 초내에 다른 리전(Region)으로 복제되어, 로컬 읽기/로컬 쓰기가 매우 유용합니다. 하지만 쓰기 경합이 발생할 가능성도 있어, 같은 시간에 각각 다른 리전에서 동일한 아이템을 업데이트할 때 쓰기 경합이 발생할 수 있습니다. 일관성(eventual consistency)을 보장하기 위해, DynamoDB 글로벌 테이블은 동시 업데이트를 수행할 경우, 마지막 쓰기 작업이 최종 저장되는 방식을 사용합니다. 이 경우에는 첫번째 쓰기 작업이 작성한 데이터가 손실됩니다. 응용 프로그램은 이를 처리할 수 없고, 보다 강한 일관성(strong consistency)이 필요한 경우 다른 방법을 사용하여 쓰기 경합을 방지해야 합니다.
로컬 읽기/전역 쓰기 패턴
보다 강한 일관성(strong consistency)를 보장하기 위해서, 로컬 쓰기 대신 한 리전(Region)에서만 쓰기가 허용되는 전역 쓰기 패턴을 사용할수도 있습니다. 예를 들면 DynamoDB에서는 로컬로 수신된 모든 쓰기 요청을 전역 쓰기 리전(Region)으로 전달하여 처리하고, DynamoDB 글로벌 테이블로 데이터를 전역적으로 복제하게 구성할수 있습니다.
Amazon Aurora역시 합리적인 대안이 될수 있습니다. Aurora global database를 생성하면, 기본 클러스터가 전역 쓰기 리전에 생성되고, 다른 리전에는 읽기 전용 인스턴스(Aurora 복제)가 생성됩니다. 데이터는 이러한 읽기 전용 인스턴스에 실시간으로 복제되며, 지연시간은 수초 미만입니다. Aurora global database 쓰기 전달(Aurora MySQL-호환 버전에서 사용 가능) 기능을 사용하면 읽기 전용 인스턴스의 쓰기 작업을 전역 쓰기 리전의 기본 클러스터로 자동으로 전달해 처리 할 수 있습니다. 이렇게 하면 모든 리전의 읽기 전용 복제본을 읽기/쓰기가 가능한 것처럼 구성 할수 있습니다.
Amazon ElastiCache for Redis 또한 리전 간에 데이터를 복제할 수 있습니다. 예를 들어 세션데이터를 저장하는 경우, 전역 쓰기 리전에 기록하고 다른 리전에서 읽기가 가용하도록 Global Datastore를 사용할 수 있습니다.
로컬 읽기/쓰기 분할(partitioned)패턴
전 세계에 사용자가 있는 쓰기 위주 워크로드의 경우, 전역 쓰기 리전에 모든 쓰기 작업을 집중하는 것은 적합하지 않을 수 있습니다. 이 쓰기 부하를 완화하기 위해 쓰기 분할 패턴(write partitioned pattern)을 고려할 수 있습니다. 쓰기 분할 패턴은 모든 아이템 또는 레코드가 홈 리전에 할당됩니다. 이 할당 작업은 쓰기가 처음 발생한 리전을 기반으로 할 수도 있고, 또는 파티션 키의 값을 기준으로 홈 리전을 미리 할당하여 레코드(예, user ID)의 파티션키 기준으로 분산할 수도 있습니다. [그림 3]에서 보여지듯, 이 사용자의 레코드는 홈 리전(Region)으로 왼쪽 AWS 리전(Region)이 할당되어 있습니다. 이 구성의 목표는 대부분의 쓰기 요청이 가까운 홈 리전에 레코드를 매핑하는 것입니다.
[그림3. 멀티사이트 액티브/액티브 DR 전략에서 로컬 읽기/분할 쓰기 패턴]
[그림 3]에서 사용자가 먼 곳으로 이동할 때, 읽기 작업은 이동한 곳에 가까운 리전(Region)에서 처리 되지만 쓰기 작업은 홈 리전으로 다시 전달되어 처리되는 것을 보여주고 있습니다. 일반적으로 쓰기 작업은 홈 리전 근처에서 올 것으로 예상되므로 긴 처리 시간이 걸리지는 않을 것입니다. 그리고 쓰기 작업이 모든 리전에서 허용 되므로 워크로드가 분산되는 효과를 얻을수 있습니다. 구현의 예로 Amazon DynamoDB 글로벌 테이블을 활용하여 특정 사용자의 쓰기 워크로드를 특정 리전(Region)의 엔드포인트(endpoint)에 할당하는 형태로 구현할수 있습니다.
장애 조치(Failover)
멀티사이트 액티브/액티브 전략을 사용했을 때, 워크로드가 특정 리전(Region)의 장애로 작동할 수 없는 경우, 장애 조치(Failover)를 통하여 다른 리전(Region)으로 요청을 전달 합니다. 이 방법은 Route 53에서 DNS 레코드를 갱신하여 다른 리전(Region)을 지정하게 하여 구성할수 있습니다. 주의할 것은 DNS 레코드의 TTL(time to live) 설정을 충분히 짧게 하여, DNS resolver가 빠르게 변화를 반영할 수 있도록 설정해서 정의된 RTO 목표를 충족시킬수 있게 해야 합니다. 다른 방법으로는 라우팅과 장애 조치(Failover)를 위해 AWS Global Accelerator를 사용할 수 있습니다. AWS Global Accelerator는 DNS에 의존하지 않고, 트래픽을 고정된 비율로 여러 가용한 리전(Region)에 분산 시키거나 가중치를 기준으로 분산시키는 기능을 제공 합니다.
만약 전역 쓰기 패턴이 사용 중이고 전역 쓰기 리전에 장애가 발생했다면, 새로운 리전이 새로운 전역 쓰기 리전(Region)으로 승격되어야 합니다. 그리고 쓰기 분할 패턴이 사용 중일 경우에 영향을 받는 지역에 있는 레코드가 다른 리전(Region) 중 하나에 할당되도록 워크로드를 다시 분배해야 합니다. 로컬 쓰기를 사용하면 모든 리전에서 쓰기 작업을 수락할 수 있게 되어 별도의 변화가 필요가 없어서 가장 빠른(거의 0에 가까운) RTO를 만족 시킬수 있습니다.
결론
복구 시간이 가장 빠르고(가장 낮은 RTO), 데이터 손실이 가장 적은(가장 낮은 RPO) 재해복구가 필요한 경우 워크로드에 대한 멀티사이트 액티브/액티브 전략을 고려할 수 있습니다. 위치를 최대한 분리하여 완전한 독립성을 유지하려는 경우 또는 전 세계적으로 다양한 위치에 있는 사용자의 워크로드에 대한 짧은 지연시간 액세스를 제공해야 하는 경우에, 여러 리전(Region)에 걸쳐 워크로드를 처리하는 것이 좋은 옵션입니다.
주의할 것은 재해 복구 전략에 따른 손실도 고려해야 한다는 것입니다. 특히 다중 리전을 사용하여 재해 복구 전략을 구현하고 운영하는 것은 다른 재해 복구 전략보다 더 복잡하고 비용이 많이 발생할 수 있습니다.
AWS에서는 다중 리전 액티브/액티브를 구현할 때 반드시 필요한 여러가지 라우팅 정책과, 저장소의 읽기/쓰기 패턴을 선택하여 비지니스에 가장 적합한 재해 복구 전략을 구성할수 있습니다.
연재 문서
- AWS 기반 재해 복구(DR) 아키텍처, 1부: 클라우드 에서의 재해 복구 전략
- AWS 기반 재해 복구(DR) 아키텍처, 2부: 신속한 복구를 위한 백업 및 복원
- AWS 기반 재해 복구(DR) 아키텍처, 3부: 파일럿 라이트 및 웜 스탠바이
관련 정보