Geode 패턴

Geode 패턴은 모든 지역에서 모든 클라이언트에 대 한 요청을 서비스 할 수 있는 geographical nodes 집합에 백 엔드 서비스 컬렉션을 배포 하는 과정을 포함 합니다. 이 패턴은 전 세계에 요청 처리를 배포 하 여 활성-활성 스타일에서 요청을 처리 하 고, 대기 시간을 개선 하 고, 가용성을 높일 수 있습니다.

Geode 지도

컨텍스트 및 문제점

많은 대규모 서비스에는 지리적 가용성 및 규모와 관련 된 특정 과제가 있습니다. 클래식 디자인은 데이터를 계산 계층으로 사용 하는 원격 SQL 서버에 데이터를 저장 하 여 증가에 대 한 확장을 사용 하 여 데이터를 계산 하 는 경우가 많습니다.

일반적인 접근 방식은 다음과 같은 많은 문제를 나타낼 수 있습니다.

  • 전 세계의 다른 쪽에서 들어오는 사용자에 대 한 네트워크 대기 시간 문제로 인해 호스팅 끝점에 연결할 수 있습니다.
  • 단일 지역에서 서비스를 지나치게 많이 사용할 수 있는 수요 버스트를 위한 트래픽 관리
  • 연중 무휴 서비스를 위해 앱 인프라의 복사본을 여러 지역에 배포 하는 것의 비용에 대 한 복잡성

최신 클라우드 인프라는 프런트 엔드 서비스의 지리적 부하 분산을 가능 하 게 하는 동시에 백 엔드 서비스의 지리적 복제를 허용 하도록 발전 되었습니다. 가용성 및 성능을 위해 사용자에 게 더 가까운 데이터를 가져오는 것이 좋습니다. 데이터가 먼 flung 사용자 기반에 걸쳐 지리적으로 분산 된 경우 데이터를 처리 하는 계산 리소스를 사용 하 여 지리적으로 분산 된 데이터 저장소도 공동 배치 해야 합니다. Geode 패턴은 데이터에 계산을 가져옵니다.

솔루션

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

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

Geode 개요

Geodes에는 다음과 같은 특징이 있습니다.

  • 템플릿에 정의 된 여러 유형의 리소스 컬렉션으로 구성 됩니다.
  • Geode 공간 외부에는 종속성이 없으며 자체 포함 되어 있습니다. Geode는 다른 작업에 종속 되지 않으며, 그 중 하나는 계속 작동 합니다.
  • 는에 지 네트워크 및 복제 후면판을 통해 느슨하게 결합 됩니다. 예를 들어 Azure Traffic Manager 또는 Azure Front 도어 를 사용 하 여 앞단에를 사용할 수 있지만, Azure Cosmos DB는 복제 후면판으로 작동할 수 있습니다. Geodes는 복제 후면판을 공유 하기 때문에 클러스터와 동일 하지 않으므로 플랫폼이 쿼럼 문제를 처리 합니다.

geode 패턴은 상용 하드웨어를 사용 하 여 동일한 컴퓨터에서 공동 배치 데이터를 처리 하 MapReduce 고 여러 컴퓨터에서 결과를 통합 하는 데 사용 되는 빅 데이터 아키텍처에서 발생 합니다. 또 다른 용도는 네트워크의 intelligent edge에 대 한 계산을 통해 응답 시간을 줄이기 위해에 지에 가까운 계산입니다.

서비스는 수십 또는 수백 개의 geodes에서이 패턴을 사용할 수 있습니다. 또한 지역 가동 중단이 하나 이상의 geodes를 오프 라인으로 전환 하는 경우 모든 geodes에서 사용할 수 있으므로 전체 솔루션의 복원 력을 추가 된 각 geode로 늘어납니다.

또한 글로벌 가용성에 대 한 geode 패턴을 사용 하 여 가용성 영역 또는 쌍을 이루는 지역과 같은 로컬 가용성 기술을 강화할 수 있습니다. 이렇게 하면 복잡성이 증가 하지만 아키텍처가 쌍을 이루는 지역에만 복제할 수 있는 blob 저장소와 같은 저장소 엔진에 의해 고정 되어 있는 경우에 유용 합니다. 위치에 대 한 규제 또는 대기 시간 제약 조건을 염두에 두면 영역 간, 영역 또는 지역 공간에 geodes를 배포할 수 있습니다.

문제 및 고려 사항

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

  • 다 수의 지역 또는 인스턴스에 걸쳐 동일한 geodes를 생성 하 고 신속 하 게 배포 하는 최신 DevOps 사례 및 도구입니다.
  • Geode 내에서 계산 및 데이터베이스 처리량 인스턴스 규모를 확장 합니다. 각 geode는 일반적인 후면판 제약 조건 내에서 개별적으로 확장 됩니다.
  • 동적 콘텐츠 가속, 분할 TCP 및 애니캐스트 라우팅을 수행 하는 Azure Front 도어와 같은 프런트 엔드 서비스입니다.
  • 데이터 일관성을 제어 하기 위해 Azure Cosmos DB와 같은 복제 데이터 저장소입니다.
  • 가능 하면 서버를 사용 하지 않는 기술로, 특히 전 세계에서 부하가 자주 균형 되는 경우 항상 배포 비용을 줄일 수 있습니다. 이 전략을 사용 하면 최소한의 추가 투자로 많은 geodes를 배포할 수 있습니다. 서버 리스 및 소비 기반 청구 기술은 중복 지리적으로 분산 된 배포에서 낭비와 비용을 절감 합니다.
  • API Management 디자인 패턴을 구현 하는 데 필요 하지 않지만, 해당 지역의 Azure 함수 앱를 향한 각 geode에 추가 하 여 보다 강력한 API 계층을 제공 하 여 예를 들어 요율 제한 등의 추가 기능을 구현할 수 있습니다.

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

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

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

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

  • 사용자가 넓은 영역에서 배포 하는 대규모 플랫폼을 구현 합니다.
  • 모든 서비스에서 geode 패턴을 기반으로 하는 서비스는 동시에 여러 서비스 지역 손실을 방지할 수 있기 때문입니다.

이 패턴은 다음에 적합 하지 않을 수 있습니다.

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

예제

  • Windows Active Directory는이 패턴의 초기 변형을 구현 합니다. 다중 기본 복제는 이론적으로 모든 업데이트 및 요청을 모든 시작 가능한 노드에서 제공할 수 있다는 것을 의미 하지만, FSMO (신축 단일 마스터 작업) 역할은 모든 geodes가 같지 않다는 것을 의미 합니다.
  • GitHub의 geode 패턴 가속기 는이 디자인 패턴을 실제로 소개 하 고 개발자가 실제 api를 사용 하 여 구현할 수 있도록 설계 되었습니다.
  • Cosmos DB 문서를 사용 하는 전역적으로 분산 된 응용 프로그램 에서는 부하 분산을 위해 Traffic Manager를 활용 하 고 API 코드를 호스팅하는 Azure App Service 지리적 기반 배포를 검토 합니다.
  • GitHub의 QnA 샘플 응용 프로그램 은 실제로이 디자인 패턴을 보여 줍니다.
  • sap odata api를 통한geode 캐시: sap 소매 응용 프로그램을 위해 전역적으로 가속화 된 데이터 캐시로 Cosmos에서 지 원하는 샘플 OData API geode 집합입니다.