다중 리전 기본 2: 데이터 이해

다중 리전 아키텍처를 채택할 때 데이터 관리는 사소한 문제가 아닙니다. 리전 간 지리적 거리는 리전 간에 데이터를 복제하는 데 걸리는 시간으로 나타나는 피할 수 없는 지연 시간을 부과합니다. 가용성, 데이터 일관성, 다중 리전 아키텍처를 사용하는 워크로드에 더 긴 지연 시간 도입 간의 절충이 필요합니다. 비동기식 복제를 사용하든 동기식 복제를 사용하든 관계없이 복제 기술이 부과하는 동작 변경을 처리하도록 애플리케이션을 수정해야 합니다. 데이터 일관성 및 지연 시간에 대한 문제로 인해 단일 리전용으로 설계된 기존 애플리케이션을 가져와 다중 리전으로 만드는 것이 매우 어렵습니다. 특정 워크로드에 대한 데이터 일관성 요구 사항 및 데이터 액세스 패턴을 이해하는 것은 장단점을 고려하는 데 매우 중요합니다.

2.a: 데이터 일관성 요구 사항 이해

CAP 이론은 데이터 일관성, 가용성 및 네트워크 파티션 간의 장단점을 추론하기 위한 참조를 제공합니다. 워크로드에 대해 이러한 요구 사항 중 두 가지만 동시에 충족할 수 있습니다. 기본적으로 다중 리전 아키텍처에는 리전 간 네트워크 파티션이 포함되므로 가용성과 일관성 중에서 선택해야 합니다.

리전 간 데이터 가용성을 선택하면 트랜잭션 쓰기 작업 중에 상당한 지연 시간이 발생하지 않습니다. 리전 간 커밋된 데이터의 비동기 복제에 의존하면 복제가 완료될 때까지 리전 간 일관성이 저하되기 때문입니다. 비동기식 복제를 사용하면 기본 리전에 장애가 있는 경우 쓰기 작업이 기본 리전에서 복제 보류 중일 가능성이 높습니다. 이로 인해 복제가 재개될 때까지 최신 데이터를 사용할 수 없고 중단이 발생한 리전에서 복제되지 않은 진행 중인 트랜잭션을 처리하기 위해 조정 프로세스가 필요한 시나리오가 발생합니다. 이 시나리오에서는 비즈니스 로직을 이해하고 특정 프로세스를 생성하여 트랜잭션을 재생하거나 리전 간 데이터 스토어를 비교해야 합니다.

비동기식 복제가 선호되는 워크로드의 경우 비동기식 리전 간 복제에 Amazon AuroraandAmazon DynamoDB와 같은 서비스를 사용할 수 있습니다. Amazon Aurora 글로벌 데이터베이스와 Amazon DynamoDB 글로벌 테이블 모두 복제 지연을 모니터링하는 데 도움이 되는 defaultAmazon CloudWatchmetrics가 있습니다. Aurora 글로벌 데이터베이스는 데이터가 기록되는 기본 리전 하나와 최대 5개의 읽기 전용 보조 리전으로 구성됩니다. DynamoDB 글로벌 테이블은 데이터를 쓰고 읽는 모든 리전의 다중 활성 복제본 테이블로 구성됩니다.

이벤트 기반 아키텍처를 활용하도록 워크로드를 엔지니어링하는 것은 다중 리전 전략의 이점입니다. 즉, 워크로드가 비동기식 데이터 복제를 수용하고 이벤트를 재생하여 상태를 재구성할 수 있기 때문입니다. 스트리밍 및 메시징 서비스는 단일 리전에서 메시지 페이로드 데이터를 버퍼링하기 때문에 리전 장애 조치 또는 장애 복구 프로세스에는 클라이언트 입력 데이터 흐름을 리디렉션하는 메커니즘이 포함되어야 합니다. 또한 프로세스는 중단이 발생한 리전에 저장된 진행 중이거나 전송되지 않은 페이로드를 조정해야 합니다.

CAP 일관성 요구 사항을 선택하고 리전 간에 동기식으로 복제된 데이터베이스를 사용하여 여러 리전에서 동시에 실행되는 애플리케이션을 지원하는 경우 데이터 손실 위험을 제거하고 리전 간에 데이터를 동기화된 상태로 유지합니다. 그러나 쓰기는 둘 이상의 리전에 커밋해야 하고 리전은 서로 수백 또는 수천 마일 떨어져 있을 수 있으므로 지연 시간 특성이 더 높습니다. 애플리케이션 설계에서이 지연 시간 특성을 고려해야 합니다. 또한 동기식 복제는 성공하려면 둘 이상의 리전에 쓰기를 커밋해야 하므로 상관관계가 있는 오류가 발생할 수 있습니다. 한 리전 내에 장애가 있는 경우 쓰기에 성공하려면 쿼럼을 구성해야 합니다. 여기에는 일반적으로 세 리전에 데이터베이스를 설정하고 세 리전 중 두 리전의 쿼럼을 설정하는 작업이 포함됩니다. Paxos와 같은 기술은 데이터를 동기적으로 복제하고 커밋하는 데 도움이 되지만 상당한 개발자 투자가 필요합니다.

강력한 일관성 요구 사항을 충족하기 위해 여러 리전에서 쓰기에 동기식 복제가 포함되는 경우 쓰기 지연 시간이 크게 증가합니다. 쓰기 지연 시간이 길어지는 것은 일반적으로 애플리케이션의 제한 시간 재검토 및 재시도 전략과 같은 중요한 변경 없이 애플리케이션에 개량할 수 있는 것이 아닙니다. 애플리케이션을 처음 설계할 때 이를 고려하는 것이 가장 좋습니다. 동기식 복제가 우선순위인 다중 리전 워크로드의 경우 AWS Partner 솔루션이 도움이 될 수 있습니다.

2.b: 데이터 액세스 패턴 이해

워크로드 데이터 액세스 패턴은 읽기 집약적 또는 쓰기 집약적입니다. 특정 워크로드에 대한이 특성을 이해하면 적절한 다중 리전 아키텍처를 선택하는 데 도움이 됩니다.

완전히 읽기 전용인 정적 콘텐츠와 같은 읽기 집약적인 워크로드의 경우 쓰기 집약적인 워크로드에 비해 엔지니어링 복잡성이 적은 액티브-액티브 다중 리전 아키텍처를 달성할 수 있습니다. 콘텐츠 전송 네트워크(CDN)를 사용하여 엣지에서 정적 콘텐츠를 제공하면 최종 사용자에게 가장 가까운 콘텐츠를 캐싱하여 가용성을 보장할 수 있습니다. Amazon CloudFront 내에서 오리진 장애 조치와 같은 기능 세트를 사용하면 이를 달성하는 데 도움이 될 수 있습니다. 또 다른 옵션은 상태 비저장 컴퓨팅을 여러 리전에 배포하고 DNS를 사용하여 사용자를 가장 가까운 리전으로 라우팅하여 콘텐츠를 읽는 것입니다. Amazon Route 53를 지리적 위치 라우팅 정책과 함께 사용하여 이를 달성할 수 있습니다.

쓰기 트래픽보다 읽기 트래픽 비율이 높은 읽기 집약적 워크로드의 경우 읽기 로컬, 쓰기 글로벌 전략을 사용할 수 있습니다. 즉, 모든 쓰기 요청은 특정 리전의 데이터베이스로 이동하고, 데이터는 다른 모든 리전에 비동기적으로 복제되며, 모든 리전에서 읽기를 수행할 수 있습니다. 이 접근 방식은 쓰기의 리전 간 복제 지연 시간 증가로 인해 로컬 읽기가 오래될 수 있으므로 최종 일관성을 수용하는 워크로드가 필요합니다.

Aurora 글로벌 데이터베이스는 모든 읽기 트래픽을 로컬에서만 처리할 수 있는 대기 리전에서 읽기 전용 복제본을 프로비저닝하고 쓰기 트래픽을 처리하기 위해 특정 리전에서 단일 기본 데이터 스토어를 프로비저닝하는 데 도움이 될 수 있습니다. 데이터는 기본 데이터베이스에서 대기 데이터베이스(읽기 전용 복제본)로 비동기식으로 복제되며, 작업을 대기 리전으로 장애 조치해야 하는 경우 대기 데이터베이스를 기본 데이터베이스로 승격할 수 있습니다. 이 접근 방식에서도 DynamoDB를 사용할 수 있습니다. DynamoDB 글로벌 테이블은 리전 간에 복제본 테이블을 프로비저닝할 수 있으며, 각 테이블은 모든 볼륨의 로컬 읽기 또는 쓰기 트래픽을 지원하도록 확장할 수 있습니다. 애플리케이션이 한 리전의 복제 테이블에 데이터를 쓰면 DynamoDB가 이 쓰기를 다른 리전에 있는 다른 복제 테이블에 자동으로 전파합니다. 이 구성을 사용하면 정의된 기본 리전에서 대기 리전의 복제본 테이블로 데이터가 비동기식으로 복제됩니다. 모든 리전의 복제본 테이블은 항상 쓰기를 허용할 수 있으므로 대기 리전을 기본 리전으로 승격하는 것은 애플리케이션 수준에서 관리됩니다. 다시 말하지만 워크로드는 최종 일관성을 수용해야 하므로 처음부터 이를 위해 설계되지 않은 경우 다시 작성해야 할 수 있습니다.

쓰기 집약적인 워크로드의 경우 기본 리전을 선택하고 대기 리전으로 장애 조치할 수 있는 기능을 워크로드로 엔지니어링해야 합니다. 액티브-액티브 접근 방식과 비교하여 기본-대기 접근 방식에는 추가적인 장단점이 있습니다. 이는 액티브-액티브 아키텍처의 경우 리전으로의 지능형 라우팅을 처리하고, 세션 선호도를 설정하고, 멱등성 트랜잭션을 보장하고, 잠재적 충돌을 처리하기 위해 워크로드를 다시 작성해야 하기 때문입니다.

복원력을 위해 다중 리전 접근 방식을 사용하는 대부분의 워크로드에는 액티브-액티브 접근 방식이 필요하지 않습니다. 샤딩 전략을 사용하여 클라이언트 기반 전반에서 장애의 영향 범위를 제한하여 복원력을 높일 수 있습니다. 클라이언트 베이스를 효과적으로 샤딩할 수 있는 경우 각 샤드에 대해 서로 다른 기본 리전을 선택할 수 있습니다. 예를 들어 클라이언트의 절반이 리전 1에 정렬되고 절반이 리전 2에 정렬되도록 클라이언트를 샤딩할 수 있습니다. 리전을 셀로 취급하면 다중 리전 셀 접근 방식을 생성하여 워크로드에 미치는 영향 범위를 줄일 수 있습니다. 자세한 내용은이 접근 방식에 대한 AWS re:Invent 프레젠테이션을 참조하세요.

샤딩 접근 방식을 기본 대기 접근 방식과 결합하여 샤드에 대한 장애 조치 기능을 제공할 수 있습니다. 테스트된 장애 조치 프로세스를 워크로드로 엔지니어링하고 데이터 조정 프로세스도 엔지니어링하여 장애 조치 후 데이터 스토어의 트랜잭션 일관성을 보장해야 합니다. 이에 대해서는이 가이드의 뒷부분에서 자세히 설명합니다.

주요 지침

• 오류가 발생할 때 복제 보류 중인 쓰기가 대기 리전에 커밋되지 않을 가능성이 높습니다. 복제가 재개될 때까지 데이터를 사용할 수 없습니다(비동기 복제 가정).

• 장애 조치의 일환으로 비동기 복제를 사용하는 데이터 스토어에 대해 트랜잭션 일관성 상태가 유지되도록 하려면 데이터 조정 프로세스가 필요합니다. 이를 위해서는 특정 비즈니스 로직이 필요하며 데이터 스토어 자체에서 처리하는 것이 아닙니다.

• 강력한 일관성이 필요한 경우 동기식으로 복제되는 데이터 스토어의 필수 지연 시간을 허용하도록 워크로드를 수정해야 합니다.