ソリューションのアイデア
このアーティクルはソリューションのアイデアです。 このコンテンツにさらに多くの情報 (想定されるユース ケース、代替サービス、実装に関する考慮事項、価格ガイダンスなど) の掲載をご希望の方は、GitHub のフィードバックでお知らせください。
このアーキテクチャでは、大量のデータを使用する Web アプリケーション用の高可用性ソリューションを提供します。 セカンダリ リージョンは、プライマリへのスタンバイとして機能し、可用性を向上させます。 プライマリ リージョンでは、Azure Storage の組み込みのレプリケーション機能を使用して、セカンダリにデータを送信します。
データは Azure Table Storage テーブルに格納されます。 すべての Azure Storage サービスと同様に、Table Storage データはプライマリ リージョンで 3 回同期的にレプリケートされます。 スタンバイで使用できるようにするために、セカンダリ リージョンでも 3 回非同期的にレプリケートされます。 Azure Storage のレプリケーションについては、「Azure Storage の冗長性」を参照してください。
このアーキテクチャには、アクセスの負荷を軽減し、アプリケーションの応答を向上させるためのテーブルのキャッシュが含まれています。
注意
アプリケーションでは、状況によって複数のストレージ アカウントが必要になる場合があります。 詳しくは、「考慮事項」を参照してください。
考えられるユース ケース
このアーキテクチャは、常に使用可能にする必要がある大量のデータを使用するアプリケーションに適している可能性があります。 たとえば、次のようなアプリが含まれます。
- 顧客の消費性向と消費行動を追跡する。
- 天気予報。
- スマート トラフィックシステムを提供する、スマート トラフィック システムを実装する、またはスマート テクノロジを使用してトラフィックを監視する。
- 製造のモノのインターネット (IoT) データを分析する。
- スマート メーター データを表示する、またはスマート テクノロジを使用してメーター データを監視する。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
- クライアントは Microsoft Entra ID によって認証され、Azure App Service 上でホストされている Web アプリケーションに対するアクセス権が付与されます。
- ファイアウォールとレイヤー 7 ロードバランサーである Azure Front Door により、リージョンの障害発生時に、ユーザー トラフィックをスタンバイ リージョンに切り替えます。
- 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 アプリケーションによって使用されるデータを保持します。
- Table Storage では、リージョン内の可用性ゾーン間のデータの同期レプリケーションをサポートして、データセンターの停止を軽減します。 また、さまざまな Azure リージョン間でデータをレプリケートするための非同期レプリケーションを使用して、リージョンの障害を修復し、アプリケーションの可用性を向上させます。
コンポーネント
- 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 Kubernetes Service (AKS) は、コンテナー化されたアプリケーションをデプロイおよび管理するためのフル マネージド Kubernetes サービスです。 これを使用して、コンポーネントがオンデマンドで個別にスケーリングされるマイクロサービス アーキテクチャを実装できます。
- Azure Container Instances により、インフラストラクチャを管理することなくタスクをすばやく簡単に実行できます。 これは、開発時や、スケジュールされていないタスクの実行で役立ちます。
- Azure Service Bus は、シンプルなハイブリッド統合のための信頼性の高いクラウド メッセージング サービスです。 このアーキテクチャでは、Queue Storage の代わりに使用できます。 詳細については、「Storage キューと Service Bus キューの比較」を参照してください。
考慮事項
Table Storage にはパフォーマンスの制限があり、ストレージ アカウントを追加することで克服できます。 次の状況で、追加のアカウントが必要になる場合があります。
- 複数の顧客をサポートするマルチテナントを実装する
- トランザクション レートが高い顧客をサポートする
- 大規模なデータセットを持つ顧客をサポートする
- 複数のストレージ アカウント間でデータを分散することによってデータ アクセスを高速化する
- ホット、コールド、アーカイブ層にデータを分離する
- バックアップとレポートのためにデータのコピーを作成する
詳細については、「Table Storage のスケーラビリティおよびパフォーマンスのターゲット」を参照してください。
一部の Azure リージョンでは、Table Storage レプリケーションを使用できません。
セカンダリ リージョンのデータには最終的な整合性があります。つまり、プライマリ リージョンで更新が発生した時間からセカンダリリージョンでそれが確認されるときまでに遅延が生じます。 プライマリ リージョンからセカンダリ リージョンへのレプリケーションは非同期であるため、プライマリ リージョンで障害が発生して復旧しない場合に、データが失われる可能性があります。 現在、セカンダリ リージョンにデータをレプリケートするためにかかる時間には、サービス レベル アグリーメント (SLA) がありません。 詳細については、「Azure Storage の冗長性」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Nabil Siddiqui | クラウド ソリューション アーキテクト - デジタルとアプリケーション イノベーション