Geode パターン

Geode パターンでは、バックエンド サービスを一連の Geographical node(地理的ノード) にデプロイする必要があり、それぞれによって任意のリージョンで任意のクライアントの任意の要求を処理できます。 このパターンにより、"アクティブ/アクティブ" スタイルで要求を処理できるようになり、要求処理が世界中に分散されることで可用性が向上し、待機時間が短縮されます。

コンテキストと問題

大規模なサービスの多くに、地理的な可用性とスケールに関する特定の課題があります。 従来の設計では、多くの場合、データのコンピューティング層として機能するリモート SQL サーバーにデータを格納することでデータを "コンピューティングに取り込み"、スケールアップによって拡張します。

この従来のアプローチには、課題がいくつか存在することがあります。

• 地球の反対側からホスティング エンドポイントに接続しているユーザーのネットワーク待ち時間の問題
• 1 つのリージョンのサービスに大きな負荷をかける需要急増のトラフィック管理
• 24 時間 365 日体制での複数リージョンへのアプリ インフラストラクチャ コピーのデプロイが複雑で、莫大にコストがかかる

最新のクラウド インフラストラクチャは、フロントエンド サービスの地理的な負荷分散と、バックエンド サービスの地理的なレプリケーションの両方を実現するように進化してきました。 可用性とパフォーマンスのためにも、データはユーザーに近いほど良いとされます。 地理的に広範囲にわたるユーザー ベースにデータが分散されていると、地理的に分散されているデータストアも、データを処理するコンピューティング リソースと同じ場所に配置しなければなりません。 Geode パターンによって、"データにコンピューティングがもたらされます"。

解決策

世界各地の Geode と呼ばれる数多くのサテライト拠点にサービスにデプロイしてください。 Geode パターンは Azure の主要機能を利用して、近くの Geode に最短パスでトラフィックをルーティングするため、待機時間が短縮され、パフォーマンスが向上します。 各 Geode はグローバル ロード バランサーの内側にあり、 Azure Cosmos DB などの geo レプリケートされた読み取り/書き込みサービスを使用してデータ プレーンをホストし、Geode データの一貫性を確保します。 データ レプリケーション サービスにより、Geode が違ってもデータ ストアは確実に同じになるため、"すべて" の要求を、"すべて" の Geode から提供することができ ます。

デプロイ スタンプ と Geode の主な違いは、Geode が単独で存在しないことです。 運用プラットフォームには常に複数の Geode が必要です。

Goode の特性は次のとおりです。

• さまざまなリソースの種類のコレクションで構成され、多くの場合、テンプレートで定義されます。
• Geode 占有領域外で依存関係はなく、自己完結しています。 他の Geode に依存する Geode がないため、1 つが停止していも、他の Geode は動作し続けます。
• エッジ ネットワークとレプリケーション バックプレーンを介して疎結合されています。 たとえば、 Azure Traffic Manager または Azure Front Door を使用して Geode をフロントに配置しても、Azure Cosmos DB はレプリケーション バックプレーンとして動作できます。 Geodes はレプリケーション バックプレーンを共有するため、クラスターと同じではありません。したがって、プラットフォームによってクォーラムの問題が処理されます。

Geode パターンは、ビッグデータ アーキテクチャで発生します。このアーキテクチャでは、汎用的なハードウェアを使用して、同じマシンに配置されているデータが処理されます。また、MapReduce を使用して、複数のマシンにまたがる結果が統合されます。 エッジ コンピューティングに近い使用方法もあります。この方法では、コンピューティングをネットワークのインテリジェント エッジに近づけることで、応答時間を短縮します。

このパターンは、サービスが数十または数百の Geode に対して使用できます。 さらに、リージョンの障害によって 1 つ以上の Geode がオフラインになった場合は、どの Geode でも引き継ぐことが可能なので、Geode を追加すれば、その分だけソリューション全体の回復性が向上します。

また、グローバル可用性用の Geode パターンを使って、ローカル可用性手法 (可用性ゾーン、ペア リージョンなど) を拡張することもできます。 これにより複雑になりますが、ペア リージョンにのみレプリケートできる BLOB ストレージなどのストレージ エンジンによってアーキテクチャが支えられている場合は、便利です。 場所に対する規制または待ち時間の制約を考慮して、Geode をゾーン内、ゾーン ベース、またはリージョン専有領域にデプロイできます。

問題と注意事項

このパターンを実装するには、次の手法とテクノロジを使用します。

• 最新の DevOps プラクティスおよびツールで Geode を作成し、同じ Geode を多数のリージョンまたはインスタンスに迅速にデプロイ。
• 自動スケール機能を使用して、Geode 内でコンピューティングおよびデータベース スループット インスタンスをスケールアウト。 共通のバックプレーン制約内で、各 Geode が個別にスケールアウトされます。
• Azure Front Door などのフロントエンド サービス (動的なコンテンツ アクセラレーション、分割 TCP、エニーキャスト ルーティングを実施)。
• データの整合性を制御する Azure Cosmos DB などのレプリケーション データ ストア。
• 可能な場合はサーバーレス テクノロジにより Always-On デプロイ コストを削減 (特に、世界中で負荷が頻繁に再分散される場合)。 この戦略により、最小限の追加投資で多くの Geode をデプロイできます。 サーバーレス テクノロジと使用量ベースの課金テクノロジは、地理的に分散された重複デプロイによる無駄とコストを削減します。
• API Management は設計パターンを実装する際に必須ではありませんが、リージョンの Azure Function App に面する各 Geode に追加することでより堅牢な API レイヤーとなり、レート制限などの追加機能の実装が可能になります。

このパターンの実装方法を決めるときには、以下の点に注意してください。

• リージョンごとにローカルでデータを処理するか、1 つの Geode に集計を配布し、結果を世界中にレプリケートするかを選択します。 Azure Cosmos DB 変更フィード プロセッサ は、その "リース コンテナー" の概念によってこの詳細な制御を実現し、対応する Azure Functions バインディング で leasecollectionprefixを提供します。 各アプローチに、それぞれ長所と短所があります。
• Geode の連携には、Azure Cosmos DB 変更フィード、および SignalR などのリアルタイム通信プラットフォームが使用されます。 Geode は、メッシュ パターンで他の Geode を介してリモート ユーザーと通信できます。その際、そのリモート ユーザーの場所を把握したり、気にしたりする必要はありません。
• この設計パターンでは、すべてのものが暗黙的に分離されるため、アーキテクチャは、広範囲に分散および分離されたものになります。 同じ要求のさまざまなコンポーネントが、さまざまなインスタンスで非同期的に実行される可能性があるため、それらを追跡する方法を検討してください。 適切な監視戦略が不可欠です。 Azure Front Door と Azure Cosmos DB はどちらも Log Analytics と簡単に統合できます。また、アーキテクチャの各コンポーネントに堅牢な監視システムを提供するために、Application Insights と共に Azure Functions をデプロイする必要があります。
• 分散デプロイの場合、プロパティのセキュリティ対策が必要なシークレットとイングレス ポイントの数が増えます。 Key Vault ではシークレット管理用にセキュリティで保護されたレイヤーが提供されます。API アーキテクチャ内の各レイヤーを適切にセキュリティで保護して、API への唯一のイングレス ポイントが Azure Front Door などのフロントエンド サービスになるようにする必要があります。 Azure Cosmos DB ではトラフィックを Azure 関数アプリに制限する必要があり、関数アプリから Azure Front Door についても同様です。そのためには、Microsoft Entra ID または IP 制限などのプラクティスを使用します。
• デプロイされている Geode の数と、各 Geode の API テクノロジに適用されている特定の App Service プランにより、パフォーマンスは大きく影響を受けます。 追加の Geode のデプロイまたは Premium レベルへの移行には追加のメモリとコンピューティングによるコスト増加が伴いますが、トランザクションごとにこれを行わないようにしてください。 API アーキテクチャをデプロイしたらロード テストを行って、Geode 数の増加と価格レベルの上昇とを比較し、ニーズに対して最もコスト効率の高いモデルを使用することをご検討ください。
• ご使用のデータについて可用性の要件を決定します。 Azure Cosmos DB には、複数リージョンへの書き込み、可用性ゾーンなどを有効にするためのオプションのフラグがあります。 これらを使用すると、Azure Cosmos DB インスタンスの可用性が向上し、回復性があるデータ レイヤーとなりますが、追加の費用が発生します。
• Azure には、トラフィックを分散させるための各種機能を提供するさまざまなロード バランサーが用意されています。 API のフロントエンドに適したオプションを選択するのに役立つ デシジョン ツリー をご使用ください。

このパターンを使用する状況

このパターンは次の目的で使用します。

• ユーザーが広範囲に分散している大規模プラットフォームを実装する場合。
• サービスに非常に高い可用性と回復性が必要な場合 (Geode パターンに基づくサービスは、複数のサービス リージョンが同時に失われても耐えることができるため)

このパターンが適していないと考えられる状況は次のとおりです

• アーキテクチャの制約によって、データ ストレージに対する Geode をすべて同じにすることができない。 たとえば、データの保存要件がある、アプリケーションで特定のセッションの一時的な状態を維持する必要がある、1 つのリージョンに対する要求の重み付けが高い、といった状況が考えられます。 この場合は、 デプロイ スタンプ と、ユーザーのデータの場所を認識するグローバル ルーティング プレーン (デプロイ スタンプ パターンで説明されているトラフィック ルーティング コンポーネントなど) を組み合わせて使用することを検討してください。
• 地理的な分散が不要。 代わりに、クラスタリング用の可用性ゾーンとペア リージョンを検討してください。
• レガシ プラットフォームを新しいバージョンに合わせて改良する必要がある。 このパターンは、クラウド ネイティブ開発にのみ使用できます。新しいバージョンに合わせて改良するのは困難です。
• アーキテクチャと要件がシンプルで、geo 冗長性と地理的な分散が不要。あるいはメリットがない。

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ワークロードの設計でどのようにジオード パターンを使用できるかを評価する必要があります。 次に例を示します。

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

例

• Windows Active Directory では、このパターンの初期バリアントが実装されます。 マルチプライマリ レプリケーションは、理論上、すべての更新と要求を、保守可能なすべてのノードから提供できることを意味しますが、Flexible Single Master Operation (FSMO) の役割は、すべてのジオードが同じだとは限らないことを意味します。
• GitHub にある ジオード パターン アクセラレータは、この設計パターンを実際に示しており、開発者が実際の API と一緒にこれを実装できるように設計されています。