この記事では、信頼性の高い Web アプリ パターンの実装を計画する方法について説明します。 信頼性の高い Web アプリ パターンは、クラウドへの移行時に Web アプリを変更する方法 (再プラットフォーム) を定義する一連の原則と実装手法です。 クラウドで成功するために行う必要がある最小限のコード更新に焦点を当てています。
このガイダンスの適用を容易にするために、デプロイできる信頼性の高い Web アプリ パターンのリファレンス実装があります。
リファレンス実装アーキテクチャのアーキテクチャ。このアーキテクチャの Visio ファイルをダウンロードします。
次のガイダンスでは、全体の例としてリファレンス実装を使用します。 信頼性の高い Web アプリ パターンの実装を計画するには、次の手順を実行します。
ビジネス目標を定義する
クラウド コンピューティングへの移行の最初の手順は、ビジネス目標を明確にすることです。 信頼性の高い Web アプリ パターンでは、Web アプリケーションの即時目標と将来目標の両方を設定することの重要性が強調されています。 これらの目標は、クラウド サービスの選択と、クラウド内の Web アプリケーションのアーキテクチャに影響します。
例: 架空の会社 Contoso Fiber は、オンプレミスの顧客アカウント管理システム (CAMS) Web アプリを拡張して他のリージョンにリーチしたいと考えています。 Web アプリに対する需要の増加を満たすために、次の目標を確立しました。
- 低コストで価値の高いコード変更を適用
- 99.9% のサービス レベル目標 (SLO) にリーチ
- DevOps プラクティスを採用
- コスト最適化環境を作成
- 信頼性とセキュリティを改善
Contoso Fiber は、オンプレミスのインフラストラクチャが、アプリケーションをスケーリングするためのコスト効率の高いソリューションではないと判断しました。 そこで、CAMS Web アプリケーションを Azure に移行することが、即時および将来の目標を達成するための最もコスト効率の高い方法であると判断しました。
適切なマネージド サービスを選択する
Web アプリをクラウドに移行する場合は、ビジネス要件を満たし、オンプレミス Web アプリの現在の機能に合わせた Azure サービスを選択する必要があります。 この配置により、リプラットフォーム工数を最小限に抑えることができます。 たとえば、同じデータベース エンジンを維持し、既存のミドルウェアとフレームワークをサポートできるサービスを使用します。 次のセクションでは、Web アプリに適した Azure サービスを選択するためのガイダンスを提供します。
例: クラウドに移行する前、Contoso Fiber の CAMS Web アプリは、オンプレミスのモノリシックな Java Web アプリでした。 PostgreSQL データベースを備えた Spring Boot アプリです。 Web アプリは基幹業務サポート アプリです。 従業員向けです。 Contoso Fiber の従業員は、アプリケーションを使用して顧客からのサポート ケースを管理します。 このオンプレミスの Web アプリは、一般的な課題に直面しています。 これらの課題には、より高い負荷のもとで新機能を構築して配布するのに時間がかかることや、さまざまなアプリケーション コンポーネントをスケーリングするのが難しいといった問題が含まれます。
アプリケーション プラットフォーム
Web アプリに最適なアプリケーション ホスティング プラットフォームを選択します。 Azure には、さまざまな Web アプリの要件を満たすさまざまなコンピューティング オプションがあります。 絞り込みオプションに関するヘルプについては、Azure コンピューティング デシジョン ツリーを参照してください。
例: Contoso Fiber は、次の理由でアプリケーション プラットフォームとして Azure App Service を選択しました。
自然な進展。 Contoso Fiber は、オンプレミス サーバーに Spring Boot
jarファイルをデプロイし、そのデプロイ モデルの再設計の量を最小限に抑えたいと考えていました。 App Service では、Spring Boot アプリを実行するための堅牢なサポートが提供されており、Contoso Fiber が App Service を使用するのは自然な判断でした。 Azure Spring Apps も、このアプリの魅力的な代替手段です。 Contoso Fiber CAMS Web アプリが Spring Boot ではなく Jakarta Enterprise Edition を使用していた場合は、Azure Spring Apps の方が適しています。 詳細については、「Azure Spring Apps とは」および「Azure の Java EE、Jakarta EE、MicroProfile」を参照してください。高い SLA。 運用環境の要件を満たす高い SLA を備えています。
管理オーバーヘッドの削減。 これはフル マネージドのホスティング ソリューションです。
コンテナー化機能。 App Service は、Azure Container Registry などのプライベート コンテナー イメージ レジストリで動作します。 Contoso Fiber は、これらのレジストリを使用して、将来 Web アプリをコンテナー化できます。
自動スケーリング。 Web アプリは、ユーザーのトラフィックに基づいて、迅速にスケールアップ/ダウン/イン/アウトできます。
ID 管理
Web アプリに最適な ID 管理ソリューションを選択します。 詳細については、「ID 管理ソリューションの比較」と「認証方法」を参照してください。
例: Contoso Fiber は、次の理由で Microsoft Entra ID を選択しました。
認証と認可。 従業員の認証と認可を処理します。
スケーラビリティ。 より大規模なシナリオをサポートするようにスケーリングされます。
ユーザー ID の制御。 従業員は、既存のエンタープライズ ID を使用できます。
認可プロトコルのサポート。 マネージド ID の OAuth 2.0 がサポートされています。
データベース
Web アプリに最適なデータベースを選択します。 オプションの絞り込みについては、Azure データ ストアのデシジョン ツリーを参照してください。
例: Contoso Fiber は、次の理由から Azure Database for PostgreSQL とフレキシブル サーバー オプションを選択しました。
信頼性のいずれか。 フレキシブル サーバー デプロイ モデルでは、複数の可用性ゾーンにわたるゾーン冗長の高可用性がサポートされます。 この構成により、ウォーム スタンバイ サーバーが同じ Azure リージョン内の別の可用性ゾーンに維持されます。 この構成では、スタンバイ サーバーにデータが同期的にレプリケートされます。
リージョン間レプリケーション。 読み取りレプリカ機能を備えています。これにより、データを別の リージョンの読み取り専用レプリカ データベースに非同期的にレプリケートできます。
パフォーマンス。 予測可能なパフォーマンスとインテリジェント チューニングを提供し、実際の使用状況データを使用してデータベースのパフォーマンスを向上させます。
管理オーバーヘッドの削減。 管理義務を軽減するフル マネージドの Azure サービスです。
移行のサポート。 オンプレミスの単一サーバー PostgreSQL データベースからのデータベース移行がサポートされています。 移行ツールを使用すると、移行プロセスを簡略化できます。
オンプレミス構成との整合性。 Contoso Fiber が現在使用しているバージョンを含む、さまざまなコミュニティ バージョンの PostgreSQL がサポートされています。
回復性。 フレキシブル サーバー デプロイによってサーバー バックアップが自動的に作成され、同じリージョン内のゾーン冗長ストレージ (ZRS) を使用して格納されます。 データベースはバックアップ保有期間内の任意の時点に復元できます。 バックアップと復元の機能により、Contoso Fiber がオンプレミスで作成できるよりも優れた RPO (許容可能なデータ損失量) が作成されます。
アプリケーション パフォーマンス監視
Web アプリのアプリケーション パフォーマンス監視を選択します。 Application Insights は、Azure ネイティブ アプリケーション パフォーマンス管理 (APM) ソリューションです。 これは、Azure の監視ソリューションである Azure Monitor の機能です。
例: Contoso Fiber は、次の理由で Application Insights を追加しました。
異常の検出。 パフォーマンスに異常があると、自動的に検出されます。
トラブルシューティング: 実行中のアプリの問題を診断するのに役立ちます。
テレメトリ。 ユーザーによるアプリの使用方法に関する情報が収集され、アプリで追跡するカスタム イベントを簡単に送信できます。
オンプレミスの可視性のギャップ。 オンプレミス ソリューションには、アプリケーション パフォーマンス監視ソリューションがありませんでした。 Application Insights は、アプリ プラットフォームとコードとの簡単な統合を提供します。
キャッシュ
Web アプリ アーキテクチャにキャッシュを追加するかどうかを選択します。 Azure Cache for Redis は、Azure のプライマリ キャッシュ ソリューションです。 これは、Redis ソフトウェアに基づくマネージド インメモリ データ ストアです。
例: Contoso Fiber には、次の利点があるキャッシュが必要です。
速度と量。 アクセス頻度が高く、緩やかに変化するデータは、データ スループットが高く、読み取りの待機時間が短くなります。
多様なサポート性。 Web アプリのすべてのインスタンスが使用できる統合キャッシュの場所です。
外部データ ストア。 オンプレミスのアプリ サーバーは、VM ローカル キャッシュを実行しました。 このセットアップでは、頻度の高いデータがオフロードされず、データを無効にできませんでした。
非スティッキー セッション。 キャッシュを使用すると、Web アプリは非スティッキー セッションを使用してセッション状態を外部化できます。 オンプレミスで実行されているほとんどの Java Web アプリでは、メモリ内のクライアント側キャッシュが使用されます。 メモリ内のクライアント側キャッシュは適切にスケーリングされないため、ホスト上のメモリ占有領域が増加します。 Azure Cache for Redis を使用することで、Contoso Fiber はフル マネージドでスケーラブルなキャッシュ サービスを利用して、アプリケーションのスケーラビリティとパフォーマンスを向上させました。 Contoso Fiber はキャッシュ抽象化フレームワーク (Spring Cache) を使用しており、キャッシュ プロバイダーを交換するために必要な構成の変更は最小限でした。 Ehcache プロバイダーから Redis プロバイダーに切り替えることができました。
Load Balancer
Web アプリに最適なロード バランサーを選択します。 Azure にはいくつかのロード バランサーがあります。 オプションの絞り込みに関するヘルプについては、「アプリに最適なロード バランサーを選択する」を参照してください。
例: Contoso Fiber は、次の理由により、グローバル ロード バランサーとして Front Door を選択しました。
ルーティングの柔軟性。 アプリケーション チームは、アプリケーションの将来の変更に対応するために必要なイングレスを構成できます。
トラフィックの高速化。 エニーキャストを使用して、最も近い Azure のポイント オブ プレゼンスに到達し、Web アプリへの最速のルートを見つけます。
カスタム ドメイン。 柔軟なドメイン検証でカスタム ドメイン名をサポートします。
正常性プローブ。 アプリには、インテリジェントな正常性プローブの監視が必要です。 Azure Front Door は、プローブからの応答を使用して、クライアント要求をルーティングするための最適な配信元を決定します。
監視サポート。 Front Door とセキュリティ パターンの両方に対応するオールインワン ダッシュボードがある組み込みレポートをサポートします。 Azure Monitor と統合するアラートを構成できます。 アプリケーションが各要求と失敗した正常性プローブをログに記録できるようにします。
DDoS 保護。 第 3 から 4 層の DDoS 保護が組み込まれています。
Web アプリケーション ファイアウォール
Web アプリを Web 攻撃から保護する Web アプリケーション ファイアウォールを選択します。 Azure Web Application Firewall は、Azure の Web Application Firewall (WAF) で、一般的な Web 悪用や脆弱性から一元的に保護します。
例: Contoso Fiber は、次の利点があるため Web Application Firewall を選択しました。
グローバル保護。 パフォーマンスを犠牲にすることなく、グローバルな Web アプリ保護を向上させます。
ボットネットからの保護。 ボット保護ルールを構成して、ボットネット攻撃を監視できます。
オンプレミスとの同等性。 オンプレミスのソリューションは、IT によって管理される Web アプリケーション ファイアウォールの内側で実行されていました。
シークレット マネージャー
Azure で管理するシークレットがある場合は、Azure Key Vault を使用します。
例: Contoso Fiber には、管理するシークレットがあります。 次の理由で Key Vault を使用しました。
暗号化。 保存時と転送中の暗号化をサポートします。
マネージド ID のサポート。 アプリケーション サービスは、マネージド ID を使用してシークレット ストアにアクセスできます。
監視とログ記録。 監査アクセスを簡単にし、格納されているシークレットが変更されたときにアラートを生成します。
統合。 Web アプリがシークレットにアクセスするための 2 つの方法がサポートされています。 Contoso Fiber は、ホスティング プラットフォーム (App Service) でアプリ設定を使用することも、アプリケーション コード (アプリのプロパティ ファイル) でシークレットを参照することもできます。
エンドポイントのセキュリティ
Azure サービスへのプライベート アクセスのみを有効にすることを選択します。 Azure Private Link は、仮想ネットワーク内のプライベート エンドポイント経由で Platform-as-a-Service ソリューションへのアクセスを提供します。 仮想ネットワークとサービスとの間のトラフィックは、Microsoft バックボーン ネットワークをまたがります。
例: Contoso Fiber は、次の理由で Private Link を選択しました。
セキュリティの強化。 アプリケーションが Azure 上のサービスにプライベートにアクセスでき、データ ストアのネットワーク占有領域が削減されるため、データ漏えいからの保護に役立ちます。
最小限の作業量。 プライベート エンドポイントでは、Web アプリが使用する Web アプリ プラットフォームとデータベース プラットフォームがサポートされます。 どちらのプラットフォームも、必要な変更が最小限になるように既存のオンプレミス構成をミラーリングします。
適切なアーキテクチャを選択する
Web アプリで使用可能な方法を定義し、適切なクラウド サービスを選択したら、Web アプリに最適なアーキテクチャを決定する必要があります。 アーキテクチャでは、ビジネス要件、技術要件、およびサービス レベルの目標をサポートする必要があります。
アーキテクチャの冗長性を選択する
ビジネス目標によって、Web アプリが必要とするインフラストラクチャとデータの冗長性のレベルが決まります。 Web アプリ SLO は、冗長性の要件を理解するための適切なベースラインを提供します。 可用性のクリティカル パスに対するすべての依存関係を複合 SLA で計算します。 依存関係には、Azure サービスとMicrosoft 以外のソリューションを含める必要があります。
依存関係ごとに可用性の見積もりを割り当てます。 サービス レベル アグリーメント (SLA) は適切な開始点を提供しますが、SLA はコード、デプロイ戦略、アーキテクチャ接続の決定を考慮していません。
例: リファレンス実装では、アクティブ/パッシブ構成で 2 つのリージョンを使用します。 Contoso Fiber の SLO は 99.9% で、SLO を満たすために 2 つのリージョンを使用する必要がありました。 アクティブ/パッシブ構成は、クラウド工程のこのフェーズでコードの変更を最小限に抑えるという Contoso Fiber の目標と合致しています。 アクティブ/パッシブ構成では、シンプルなデータ戦略が提供されます。 イベントベースのデータ同期や、データ シャード、その他のデータ管理戦略を設定する必要がなくなります。 すべての受信トラフィックは、アクティブなリージョンに送信されます。 アクティブ リージョンで障害が発生した場合、Contoso Fiber はフェールオーバー プランを手動で開始し、すべてのトラフィックをパッシブ リージョンにルーティングします。
ネットワーク トポロジを選択する
Web とネットワークの要件に適したネットワーク トポロジを選択します。 ハブ アンド スポーク ネットワーク トポロジは、Azure の標準的な構成です。 コスト、管理、セキュリティの面での利点があります。 また、オンプレミス ネットワークへのハイブリッド接続オプションもサポートしています。
例: Contoso Fiber は、コストと管理のオーバーヘッドを削減してマルチリージョン デプロイのセキュリティを強化するために、ハブ アンド スポーク ネットワーク トポロジを選択しました。
データの冗長性を選択する
Azure のリージョンと Availability Zones に分散することで、データの信頼性を確保します。地理的な分離が大きいほど、信頼性が高くなります。
目標復旧時点 (RPO) を設定します。 RPO は、障害発生時の許容される最大データ損失を定義し、データがレプリケーションを必要とする頻度を示します。 たとえば、1 時間の RPO は、最近のデータ損失を最大 1 時間分受け入れることを意味します。
データ レプリケーションを実装します。 データ レプリケーションをアーキテクチャと RPO に合わせます。 Azure では、通常、Availability Zones 内での同期レプリケーションがサポートされます。 複数のゾーンを利用して信頼性を簡単に向上させます。 アクティブ/パッシブ セットアップの複数リージョン Web アプリの場合は、Web アプリの RPO ごとにパッシブ リージョンにデータをレプリケートし、レプリケーションの頻度が RPO を超えるのを確認します。 アクティブ/アクティブ構成では、リージョン間で凖リアルタイムのデータ同期が必要であり、コードの調整が必要になる場合があります。
フェールオーバー プランを作成します。 ダウンタイムまたは機能の損失によって決定される、障害に対する対応戦略の概要を説明するフェールオーバー (障害復旧) 計画を立てます。 許容可能な最大ダウンタイムの目標復旧時間 (RTO) を指定します。 フェールオーバー プロセスが RTO よりも高速であることを確認します。 一貫性と制御のために自動または手動のフェールオーバー メカニズムを決定し、通常の運用プロセスへの戻りについて詳しく説明します。 フェールオーバー計画をテストして、有効性を確認します。
例: Azure Database for PostgreSQL の場合、リファレンス実装では、2 つの Availability Zones 内のスタンバイ サーバーでゾーン冗長高可用性を使用します。 また、データベースは、パッシブ リージョン内のリードレプリカに非同期的にレプリケートします。
次のステップ
この記事では、信頼性の高い Web アプリ パターンの実装を計画する方法について説明しました。 次の手順では、信頼性の高い Web アプリ パターンの実装手法を適用します。