このアーキテクチャでは、大量のデータを使用する Web アプリケーション用の高可用性ソリューションを提供します。 これは、アプリケーションとデータを分散して、ユーザーの近くに維持するグローバル ソリューションを提供できる柔軟なアプローチです。
このアーキテクチャには、カスタム レプリケーション ソフトウェアが必要です。 これは、アプリケーションと構成によっては、この作成が困難な場合があります。
考えられる構成を次に示します。
アクティブ/パッシブ: 通常、すべてのユーザーにサービスを提供するプライマリ リージョンがあります。 また、プライマリ リージョンが機能できない場合にアクティブになるスタンバイ リージョンもあります。 プライマリ システムがアクティブな場合、レプリケーション サービスによって、データベースの変更がスタンバイ リージョンにレプリケートされます。
アクティブ/アクティブ: 通常はアクティブなプライマリリージョンがあり、近くのユーザーに読み取りサービスを提供し、すべてのユーザーに書き込みサービスを提供します。 他の 1 つ以上のリージョンがアクティブであり、近くのユーザーに読み取り専用サービスを提供します。 書き込みは常にプライマリ リージョンに送られ、読み取りは常に最も近いアクティブなリージョンに送られます。
アクティブ/パッシブ構成と同様に、プライマリ リージョンが機能できない場合にアクティブになるスタンバイ リージョンがあります。 プライマリ システムがアクティブな場合、レプリケーション サービスによって、データベースの変更が読み取り専用リージョンとスタンバイ リージョンにレプリケートされます。 スタンバイ リージョンがアクティブな場合、レプリケーション サービスによって、データベースの変更が読み取り専用リージョンにレプリケートされます。
このアプローチの欠点の 1 つは、書き込み操作の長い待機時間です。
マルチアクティブ: 複数のアクティブなリージョンがあり、それぞれがユーザーに完全なサービスを提供できます。 ユーザー アクティビティは常に、最も近いアクティブなリージョンに送られます。
マルチアクティブの実装は非常に困難であり、専門家の設計と実装が必要になる可能性があります。
レプリケーションはカスタム実装であるため、必要な任意の整合性レベルにすることができます。
カスタム レプリケーションの実装に見込まれる困難と、その実行に必要な時間は、このアーキテクチャの重要な考慮事項です。
注意
アプリケーションでは、状況によって複数のストレージ アカウントが必要になる場合があります。 詳しくは、「考慮事項」を参照してください。
考えられるユース ケース
このアーキテクチャは、常に使用可能にする必要がある大量のデータを使用するアプリケーションに適している可能性があります。 たとえば、次のようなアプリが含まれます。
- 顧客の消費性向と消費行動を追跡する (小売業界)。
- 天気を予測する (農業、環境、メディア/ニュース業界)。
- スマート トラフィックシステムを提供する、スマート トラフィック システムを実装する、またはスマート テクノロジを使用してトラフィックを監視する (自動車および輸送業界)。
- 製造のモノのインターネット (IoT) データを分析する。
- スマート メーター データを表示する、またはスマート テクノロジを使用してメーター データを監視する (エネルギー業界)。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
- クライアントは Microsoft Entra ID によって認証され、Azure App Service 上でホストされている Web アプリケーションに対するアクセスが許可されます。
- ファイアウォールとレイヤー 7 ロード バランサーである Azure Front Door は、リージョンの停止が発生した場合に、ユーザー トラフィックを別の Azure リージョンに切り替えます。
- Azure App Service により、Web サイトおよび RESTful Web API をホストします。 ブラウザー クライアントでは、API を使用する AJAX アプリケーションを実行します。
- Web API では、関数アプリにバックグラウンド タスクを処理するように委任します。 これらのタスクは、Azure Queue Storage キューに登録されます。
- Azure Functions によってホストされる関数アプリでは、キューに登録されたメッセージによってトリガーされるバックグラウンド タスクを実行します。
- カスタム レプリケーション ソフトウェアにより、テーブルを確実にリージョン間で同じままにします。
- Azure Cache for Redis では、関数アプリのテーブル データをキャッシュします。 これにより、データベース アクティビティがオフロードされるため、関数アプリと Web アプリの速度が向上します。
- Azure Table Storage は、Web アプリケーションによって使用されるデータを保持します。
コンポーネント
- Microsoft Entra ID は、オンプレミスのディレクトリと同期できる ID およびアクセス管理のサービスです。 Azure DNS は、アプリに高速の DNS クエリと DNS レコードの迅速な更新を提供する DNS ドメインの高可用性ホスティング サービスです。 Azure DNS の管理は、他の Azure サービスの管理に似ており、同じ資格情報、API、ツール、および課金を使用します。
- Azure Front Door は、セキュリティで保護されたコンテンツ配信ネットワーク (CDN) と、インスタント フェールオーバーを備えたロード バランサーです。 ユーザーに近いエッジで動作し、アプリ、API、Web サイトをサイバーの脅威から保護しながらコンテンツ配信を高速化します。
- Azure App Service は、Web アプリを構築、デプロイ、およびスケーリングするためのフル マネージド サービスです。 .NET、.NET Core、Node.js、Java、Python、または PHP を使用してアプリを構築できます。 アプリは、コンテナー内または Windows 上または Linux 上で実行できます。 メインフレームの移行では、フロントエンド画面または Web インターフェイスを HTTP ベースの REST API としてコード化できます。 それらは、マイクロサービスベースのシステムを調整するために、分離でき、ステートレスにすることができます。 Web API の詳細については、「RESTful Web API の設計」を参照してください。
- Azure Functions は、アプリケーション インフラストラクチャを確立することなく、関数と呼ばれる小さなコードを実行するための環境を提供します。 これを使用して、一括データの処理、システムの統合、IoT との連携、単純な API とマイクロサービスの構築を行うことができます。 マイクロサービスを使用すると、Azure サービスに接続するサーバーを作成して、常に最新の状態にすることができます。
- Azure Storage は、データ、アプリ、およびワークロード向けの、非常にスケーラブルで安全なクラウド サービスのセットです。 これには、 Azure Files、 Azure Table Storage、 Azure Queue Storageが含まれます。 Azure Files は、多くの場合、メインフレーム ワークロードを移行するための効果的なツールです。
- Azure Queue Storage では、大規模ワークロード向けのシンプルでコスト効果に優れた非消費型のメッセージ キューが提供されます。
- Azure Table Storage は、大量の半構造化データセットを使用する迅速な開発のための NoSQL キー値ストアです。 テーブルはスキーマレスであり、ニーズの変化に合わせてすぐに調整できます。 アクセスは、多くの種類のアプリケーションにとって高速でコスト効率が高く、他の種類のキー付きストレージよりも一般にコストがかかりません。
- Azure Cache for Redis は、コンピューティング リソース間でデータと状態を共有するための、フル マネージド メモリ内キャッシュ サービスおよびメッセージ ブローカーです。 これには、オープンソースの Redis と、マネージド サービスとしての Redis Labs の商用製品の両方が含まれています。 高スループットのオンライン トランザクション処理アプリケーションのパフォーマンスを向上させるには、スケーリングできるように、また Azure Cache for Redis などのインメモリ データ ストアを利用できるように、それらを設計します。
代替
- Azure Traffic Manager により、選択したトラフィック ルーティング方法に基づいて、グローバル Azure リージョン全体に受信 DNS 要求を送信できます。 また、自動フェールオーバーとパフォーマンス ルーティングも提供されます。
- Azure Content Delivery Network は、静的コンテンツをエッジ サーバーにキャッシュして迅速な応答を実現し、ネットワーク最適化を使用して動的コンテンツの応答を改善します。 Content Delivery Network は、ユーザー ベースがグローバルである場合に特に便利です。
- Azure Container Apps は、モダン アプリを大規模に構築してデプロイするために使用されるフル マネージドのサーバーレス コンテナー サービスです。
- Azure Kubernetes Service (AKS) は、コンテナー化されたアプリケーションをデプロイおよび管理するためのフル マネージド Kubernetes サービスです。 これを使用して、コンポーネントがオンデマンドで個別にスケーリングされるマイクロサービス アーキテクチャを実装できます。
- Azure Container Instances により、インフラストラクチャを管理することなくタスクをすばやく簡単に実行できます。 これは、開発時や、スケジュールされていないタスクの実行で役立ちます。
- Azure Service Bus は、シンプルなハイブリッド統合のための信頼性の高いクラウド メッセージング サービスです。 このアーキテクチャでは、Queue Storage の代わりに使用できます。 詳細については、「Storage キューと Service Bus キューの比較」を参照してください。
考慮事項
このアーキテクチャには、カスタム レプリケーション ソフトウェアが必要です。 これは、アプリケーションと構成によっては、作成が困難な場合があります。 カスタム レプリケーションの実装に見込まれる困難と、その実行に必要な時間は、このアーキテクチャの重要な考慮事項です。
レプリケーションはカスタム設計なので、開発者はデータ整合性戦略の実装に大きな柔軟性があります。
Table Storage にはパフォーマンスの制限があり、ストレージ アカウントを追加することで克服できます。 次の状況では、さらに多くのアカウントが必要になる場合があります。
- 複数の顧客をサポートするマルチテナントを実装する
- トランザクション レートが高い顧客をサポートする
- 大規模なデータセットを持つ顧客をサポートする
- 複数のストレージ アカウント間でデータを分散することによってデータ アクセスを高速化する
- ホット、コールド、アーカイブ層にデータを分離する
- バックアップとレポートのためにデータのコピーを作成する
詳細については、「Table Storage のスケーラビリティおよびパフォーマンスのターゲット」を参照してください。
アプリケーションに既にデータが含まれている場合は、古いデータをストレージ アカウントにコピーするルーチンを記述する必要があります。 データの移行の進行状況を追跡するために、タイムスタンプとコピー フラグがあることを確認してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
- Nabil Siddiqui | クラウド ソリューション アーキテクト - デジタルとアプリケーション イノベーション