지오드 패턴

지오드 패턴에는 백 엔드 서비스 컬렉션을 지리적 노드 집합에 배포하는 작업이 포함되며, 각각은 모든 지역의 모든 클라이언트에 대한 모든 요청을 처리할 수 있습니다. 이 패턴을 사용하면 활성-활성 스타일로 요청을 처리하여 대기 시간을 개선하고 전 세계에 요청 처리를 배포하여 가용성을 높일 수 있습니다.

컨텍스트 및 문제점

많은 대규모 서비스에는 지역 가용성 및 규모와 관련된 특정 문제가 있습니다. 클래식 디자인에서는 데이터의 컴퓨팅 계층 역할을 하는 원격 SQL 서버에 해당 데이터를 저장하여 데이터를 컴퓨팅으로 가져오는 경우가 많아서 성장이 스케일링 업에 의존합니다.

클래식 접근 방식은 다음과 같은 여러 가지 문제가 발생할 수 있습니다.

• 호스팅 엔드포인트에 연결하기 위해 지구 반대편에서 오는 사용자의 네트워크 대기 시간 문제
• 단일 지역의 서비스에 과부하가 될 수 있는 갑작스러운 수요 증가에 대한 트래픽 관리
• 연중무휴 서비스에 대해 여러 지역에 앱 인프라 복사본을 배포해야 하는 감수하기 어려운 비용과 복잡성

최신 클라우드 인프라는 프런트 엔드 서비스의 지리적 부하 분산을 가능하게 하는 동시에 백 엔드 서비스의 지리적 복제를 허용하도록 발전했습니다. 가용성 및 성능을 위해서는 사용자에게 데이터를 더 가깝게 가져오는 것이 좋습니다. 데이터가 멀리 떨어진 사용자 기반 간에 지리적으로 분산되는 경우 지리적으로 분산된 데이터 저장소도 데이터를 처리하는 컴퓨팅 리소스와 함께 배치되어야 합니다. 지오드 패턴은 컴퓨팅을 데이터로 가져옵니다.

해결 방법

전 세계에 분산된 여러 위성 배포에 배포된 각 서비스를 지오드라고 합니다. 지오드 패턴은 Azure의 주요 기능을 활용하여 가장 짧은 경로를 통해 가까운 지오드로 트래픽을 라우팅하여 대기 시간과 성능을 향상시킵니다. 전역 부하 분산 장치의 배후에는 지오드가 있으며 Azure Cosmos DB와 같은 지역 복제 읽기-쓰기 서비스를 사용하여 데이터 평면을 호스트하여 지오드 간에 데이터 일관성을 보장합니다. 데이터 복제 서비스는 데이터 저장소가 지오드 간에 동일하도록 보장하므로 모든 요청을 모든 지리적 위치에서 처리할 수 있습니다.

배포 스탬프와 지오드의 주요 차이점은 지오드는 결코 격리되어 존재하지 않는다는 것입니다. 하나의 프로덕션 플랫폼에는 항상 둘 이상의 지오드가 있어야 합니다.

지오드의 특징은 다음과 같습니다.

• 서로 다른 유형의 리소스 컬렉션으로 구성되며, 템플릿에 정의되는 경우가 많습니다.
• 지오드 공간 외부에 종속성이 없으며 자체 포함됩니다. 어떤 지오드도 작동하기 위해 다른 지오드에 의존하지 않으며, 하나가 죽더라도 다른 지오드는 계속 작동합니다.
• 에지 네트워크 및 복제 백플레인을 통해 느슨하게 결합됩니다. 예를 들어 지오드를 향하도록 Azure Traffic Manager 또는 Azure Front Door를 사용할 수 있는 반면, Azure Cosmos DB는 복제 백플레인 역할을 할 수 있습니다. 지오드는 복제 백플레인을 공유하기 때문에 클러스터와 같지 않으므로 플랫폼에서 쿼럼 문제를 처리합니다.

지오드 패턴이 발생하는 곳은 상용 하드웨어를 사용하여 동일한 컴퓨터에 공동 배치된 데이터를 처리하는 빅 데이터 아키텍처 및 컴퓨터 간에 결과를 통합하는 MapReduce입니다. 또 다른 사용법은 응답 시간을 줄이기 위해 컴퓨팅을 네트워크의 인텔리전트 에지에 더 가깝게 가져오는 가까운 에지 컴퓨팅입니다.

서비스는 수십 또는 수백 개의 지역에서 이 패턴을 사용할 수 있습니다. 또한 지역 가동 중단이 하나 이상의 지오드를 오프라인으로 만들 경우 어떤 지오드도 대신할 수 있기 때문에 각 지오드를 추가할 때마다 전체 솔루션의 복원력이 증가합니다.

전역 가용성을 위한 지오드 패턴을 사용해 가용성 영역 또는 쌍을 이루는 지역과 같은 로컬 가용성 기술을 보강할 수도 있습니다. 이렇게 하면 복잡성이 증가하지만, 쌍을 이루는 지역에만 복제할 수 있는 BLOB 스토리지 엔진이 아키텍처의 기반인 경우에는 유용합니다. 위치에 대한 규제 제약 또는 대기 시간 제약을 염두에 두고 영역 간, 영역별 또는 지역별 공간에 지오드를 배포할 수 있습니다.

문제 및 고려 사항

다음 기법과 기술을 사용하여 이 패턴을 구현합니다.

• 많은 수의 지역 또는 인스턴스에 걸쳐 동일한 지오드를 생성하고 신속하게 배포하는 최신 DevOps 사례 및 도구.
• 지오드 내에서 컴퓨팅 및 데이터베이스 처리량 인스턴스를 스케일 아웃하는 자동 스케일링. 각 지오드는 공통 백플레인 제약 조건 내에서 개별적으로 스케일 아웃됩니다.
• 동적 콘텐츠 가속, 분할 TCP 및 Anycast 라우팅을 수행하는 Azure Front Door와 같은 프런트 엔드 서비스.
• 데이터 일관성을 제어하기 위한 Azure Cosmos DB와 같은 복제 데이터 저장소.
• 특히 전 세계적으로 부하가 자주 다시 분산되는 경우 Always On 배포 비용을 절감하기 위한 서버리스 기술(가능한 경우). 이 전략을 사용하면 최소한의 추가 투자로 많은 지오드를 배포할 수 있습니다. 서버리스 및 소비 기반 청구 기술은 중복 지역 분산 배포로 인한 낭비와 비용을 줄입니다.
• API Management는 디자인 패턴을 구현할 필요가 없지만, 지역 Azure Function App을 향한 각 지오드에 추가하여 보다 강력한 API 계층을 제공함으로써 예를 들어, 속도 제한과 같은 추가 기능의 구현을 지원할 수 있습니다.

이 패턴을 구현할 방법을 결정할 때 다음 사항을 고려하세요.

• 각 지역에서 로컬로 데이터를 처리할지 또는 집계를 단일 지오드에 배포하고 전 세계에 결과를 복제할지 선택합니다. Azure Cosmos DB 변경 피드 프로세서는 임대 컨테이너 개념과 해당 Azure Functions 바인딩에 leasecollectionprefix를 사용하여 이러한 세분화된 컨트롤을 제공합니다. 각 방법에는 고유한 장점과 단점이 있습니다.
• 지오드는 Azure Cosmos DB 변경 피드 및 SignalR과 같은 실시간 통신 플랫폼을 사용하여 동시에 작동할 수 있습니다. 지오드는 원격 사용자가 있는 위치를 모르거나 신경 쓰지 않고도 메시 패턴의 다른 지오드를 통해 원격 사용자와 통신할 수 있습니다.
• 이 디자인 패턴은 모든 것을 암시적으로 분리하므로 매우 높은 분산 및 분리 아키텍처가 생성됩니다. 동일한 요청의 여러 구성 요소가 서로 다른 인스턴스에서 비동기적으로 실행될 때 이를 추적하는 방법을 고려합니다. 적절한 모니터링 전략은 매우 중요합니다. Azure Front Door 및 Azure Cosmos DB는 Log Analytics와 쉽게 통합할 수 있으며, Application Insights와 함께 Azure Functions 배포하여 아키텍처의 각 구성 요소에서 강력한 모니터링 시스템을 제공해야 합니다.
• 분산 배포에는 속성 보안 조치가 필요한 많은 수의 비밀 및 수신 지점이 있습니다. Key Vault는 비밀 관리를 위한 보안 계층을 제공하며, API 아키텍처 내의 각 계층을 적절하게 보호하여 API의 유일한 수신 지점이 Azure Front Door와 같은 프런트 엔드 서비스가 되도록 해야 합니다. Azure Cosmos DB는 Microsoft Entra ID 또는 IP 제한과 같은 사례를 사용하여 Azure Function Apps 및 함수 앱의 트래픽을 Azure Front Door로 제한해야 합니다.
• 성능은 배포되는 지오드의 수와 각 지오드의 API 기술에 적용되는 특정 App Service 요금제의 영향을 매우 크게 받습니다. 지오드를 추가 배포하거나 프리미엄 계층으로 이동하면 추가 메모리 및 컴퓨팅을 위한 비용이 증가하지만 트랜잭션별로 그렇게 되지는 않습니다. API 아키텍처가 배포되면 부하 테스트를 고려하고, 지오드 수와 가격 책정 계층의 인상을 대조하여 가장 비용 효율적인 모델을 요구 사항에 맞게 사용할 수 있도록 합니다.
• 데이터에 대한 가용성 요구 사항을 결정합니다. Azure Cosmos DB에는 다중 지역 쓰기, 가용성 영역 등을 사용하도록 설정하기 위한 선택적 플래그가 있습니다. 이들은 Azure Cosmos DB 인스턴스의 가용성이 높이고 복원력이 더 뛰어난 데이터 계층을 만들지만 추가 비용이 발생합니다.
• Azure는 다양한 트래픽 분산 기능을 제공하는 여러 가지 부하 분산 장치를 제공합니다. 의사 결정 트리를 사용하면 API의 프런트 엔드에 적합한 옵션을 선택하는 데 도움이 됩니다.

이 패턴을 사용해야 하는 경우

다음과 같은 경우에 이 패턴을 사용합니다.

• 사용자가 넓은 영역에 분산된 대규모 플랫폼을 구현하려는 경우.
• 지오드 패턴을 기반으로 하는 서비스는 동시적인 여러 서비스 지역의 손실에서 생존할 수 있기 때문에 극단적인 가용성 및 복원력 특성이 필요한 모든 서비스의 경우.

다음 경우에는 이 패턴이 적합하지 않습니다.

• 제약이 있어서 모든 지오드가 데이터 스토리지에 대해 동등할 수 없는 아키텍처. 예를 들어, 데이터 상주 요구 사항, 특정 세션에 대한 임시 상태를 유지해야 하는 애플리케이션 또는 단일 지역에 대한 요청에 큰 가중치가 부여되는 경우 등일 수 있습니다. 이 경우 배포 스탬프와 사용자의 데이터가 있는 위치를 인식하는 전역 라우팅 평면을 함께 사용하는 것이 좋습니다. 예를 들어, 배포 스탬프 패턴 내에 설명된 트래픽 라우팅 구성 요소의 사용을 고려할 수 있습니다.
• 지리적 배포가 필요하지 않은 경우. 대신 클러스터링을 위해 가용성 영역 및 쌍을 이루는 지역을 고려합니다.
• 레거시 플랫폼을 개조해야 하는 상황. 이 패턴은 클라우드 네이티브 개발에만 제대로 작동하며 개조는 어려울 수 있습니다.
• 지역 중복성 및 지역 배포가 필요하거나 유리하지 않은 간단한 아키텍처 및 요구 사항.

워크로드 디자인

설계자는 Geode 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.

예제

• Windows Active Directory는 이 패턴의 초기 변형을 구현합니다. 다중 기본 복제는 모든 업데이트 및 요청이 모든 서비스 가능한 노드에서 제공될 수 있음을 이론적으로 의미하지만, FSMO(Flexible Single Master Operation) 역할은 모든 지오드가 동등하지는 않음을 의미합니다.
• GitHub의 지오드 패턴 가속기는 실제로 이 디자인 패턴을 보여 주며, 개발자가 실제 API를 사용하여 구현할 수 있도록 설계되었습니다.
• GitHub의 QnA 샘플 애플리케이션은 실제로 이러한 디자인 패턴을 보여 줍니다.