地理的に分散したデータ アーキテクチャを設計する
このアプリケーションのアーキテクチャ設計で考慮する必要がある最後の部分は、データ ストレージ層です。 リージョン全体の障害が発生した後でも、完全な機能でデータの読み取りと書き込みの両方を実行できるようにする必要があります。
配送追跡ポータルでは、Azure Front Door を使用して、すべての要求を米国東部リージョンの App Services に送信することを選択しました。 米国東部リージョンで障害が発生した場合は、Front Door によって障害が検出され、米国西部リージョンの重複する App Services コンポーネントに要求が送信されます。 元の単一リージョンのアーキテクチャでは、リレーショナル データを Azure SQL Database に格納し、半構造化データを Cosmos DB に格納していました。 次に、米国東部リージョンで障害が発生した場合に、両方のデータベースを引き続き使用可能にできる方法について理解する必要があります。
ここでは、リージョン間でデータをレプリケートする方法と、必要に応じて、迅速にフェールオーバーが行われることを保証する方法について学習します。
Azure SQL Database
リレーショナル データを格納するために Azure SQL Database の複数リージョンの実装を作成するには、次のいずれかを使用できます。
- アクティブな地理的レプリケーション
- 自動フェールオーバー グループ
アクティブ geo レプリケーション
Azure SQL Database では、アクティブ geo レプリケーション機能を使って、データベースとそのすべての変更を、あるデータベースから別のデータベースに自動的にレプリケートできます。 データベースの書き込み可能なコピーは、プライマリ論理サーバーだけでホストされます。 データベースの読み取り専用コピーをホストする論理サーバーを、他に最大 4 つまで作成できます。
配送追跡ポータルの場合は、米国西部リージョンにセカンダリ データベースを作成し、米国東部リージョンからの geo レプリケーションを構成します。 リージョン規模の障害が発生すると、ユーザーの要求は Front Door によって米国西部リージョンの App Services にリダイレクトされます。 米国西部リージョンにコピーが既にレプリケートされているため、App Services と Azure Functions はリレーショナル データにアクセスできます。
この変更は自動で行われますが、米国西部のセカンダリ データベースは読み取り専用であることに注意してください。 新しい配送の作成など、ユーザーがデータを変更しようとすると、エラーが発生する可能性があります。 Azure portal で問題に気付いたらすぐに、米国西部へのフェールオーバーを手動で開始できます。 このプロセスを自動化したい場合、開発者は Azure SQL Database REST API で failover メソッドを呼び出すコードを記述できます。
Note
Azure SQL Database のマネージド インスタンスでは、アクティブ geo レプリケーションはサポートされていません。 マネージド インスタンスは、セキュリティを維持しながらオンプレミスの SQL Server からデータを簡単に移行できるようにすることを目的に設計されています。 マネージド インスタンスを使用している場合は、代わりにフェールオーバー グループの使用を検討します。
自動フェールオーバー グループ
自動フェールオーバー グループは、データがプライマリから 1 つまたは複数のセカンダリ サーバーに自動的にレプリケートされるデータベースのグループです。 この設計は、アクティブ geo レプリケーションと似ており、同じデータ レプリケーション方法が使われます。 ただし、ポリシーを定義することにより、エラーへの対応を自動化できます。
配送ポータルでは、セカンダリ データベースを米国西部リージョンに作成します。 そして、米国東部で壊滅的な障害が発生した場合に、データベースのプライマリ レプリカを米国西部リージョンにフェールオーバーするポリシーを追加します。 それが発生した場合、米国西部のレプリカが自動的に書き込み可能なプライマリ データベースになり、すべての機能が保持されます。
書き込み可能なデータベースのフェールオーバーを、それをトリガーするカスタム コードを記述せずに自動化したい場合は、自動フェールオーバー グループを使用することを検討します。 また、データベースが Azure SQL Database のマネージド インスタンスで実行されている場合も、自動フェールオーバー グループを使用します。
重要
アクティブ geo レプリケーションと自動フェールオーバー グループ両方の基になっているレプリケーションは非同期処理です。 変更がプライマリ レプリカに適用されると、確認がクライアントに送信されます。 この時点で、トランザクションは完了したと見なされ、レプリケーションが行われます。 障害が発生した場合、プライマリ データベースで行われた最新の変更が、セカンダリにレプリケートされていない可能性があります。 障害が発生した後、データベースの最新の変更が失われている可能性があることに注意してください。
Azure Cosmos DB
Azure Cosmos DB はマルチリージョンのクラウド データベース システムとして設計されているため、その構成はそれほど複雑ではありません。 Cosmos DB は、マルチモデル データベースであり、リレーショナル データ、半構造化データ、および他の形式のデータを格納できます。 1 つのリージョンで Cosmos DB を実行している場合でも、可用性を最適にするため、異なる障害ドメインの複数のインスタンスにデータがレプリケートされます。
複数リージョンの Cosmos DB アカウントを作成するときは、次のいずれかのモードを選択できます。
複数の書き込みリージョンで構成された複数リージョン アカウント。
このモードでは、データベースのすべてのコピーを常に書き込むことができます。 リージョンで障害が発生した場合、フェールオーバーは必要ありません。
単一の書き込みリージョンで構成された複数リージョン アカウント。
このモードでは、書き込み可能なデータベースはプライマリ リージョンにのみ含まれています。 セカンダリ リージョンにレプリケートされたデータは読み取り専用です。 プライマリ リージョンで障害が発生した場合、更新は既定では無効になります。 ただし、自動フェールオーバーの有効化を選択し、Cosmos DB により、データベースのプライマリの書き込み可能なコピーが別のリージョンに自動的にフェールオーバーされるようにすることができます。
重要
Cosmos DB では、データのレプリケーションは同期処理です。 変更が適用されるときは、レプリカのクォーラムにレプリケートされるまで、トランザクションは完了と見なされません。 その後、確認がクライアントに送信されます。 障害が発生した場合、レプリケーションが既に行われているため、最新の変更は失われません。