Java 向け信頼性の高い Web アプリパターン

Azure App Service

Azure Front Door

この記事では、Reliable Web App パターンを実装するためのガイダンスを提供します。このパターンでは、クラウド移行のために Web アプリを変更 (再プラットフォーム化) する方法について説明します。 Azure Well-Architected Framework のの原則に沿った規範的なアーキテクチャ、コード、および構成のガイダンスを提供します。

Java 向け信頼性の高い Web アプリパターンを使用する理由

Reliable Web App パターンは、Web アプリをクラウドに移行するときに Web アプリを再プラットフォーム化する方法を定義する一連の原則と実装手法です。クラウドで成功するために必要な最小限のコード更新に焦点を当てています。次のガイダンスでは、全体の例として参照実装を使用します。これは、架空の Contoso Fiber 社の再プラットフォーム体験に従って、体験のビジネスコンテキストを提供します。 Java 用の Reliable Web App パターンを実装する前に、Contoso Fiber には Spring Boot フレームワークを使用するモノリシックオンプレミスカスタマーアカウント管理システム (CAMS) がありました。

ヒント

GitHub ロゴ。信頼性の高い Web アプリパターンの参照実装 (サンプル) が用意されています。これは、Reliable Web App 実装の終了状態を表します。この記事で説明する、コード、アーキテクチャ、構成に対するすべての更新プログラムを取り入れた実稼働グレードの Web アプリです。この参照実装をデプロイして使用し、信頼性の高い Web アプリパターンの実装について案内します。

信頼性の高い Web アプリパターンの実装方法

この記事には、Reliable Web App パターンを実装するためのアーキテクチャ、コード、および構成ガイダンスが含まれています。次のリンクを使用して、必要な特定のガイダンスに移動します。

ビジネスコンテキスト します。 このガイダンスをビジネスコンテキストに合わせて調整し、意思決定の再構築を促進する即時および長期的な目標を定義する方法について説明します。
アーキテクチャのガイダンス。 適切なクラウドサービスを選択し、ビジネス要件を満たすアーキテクチャを設計する方法について説明します。
コードガイダンス します。 3 つの設計パターンを実装して、クラウド内の Web アプリの信頼性とパフォーマンス効率を向上させます。再試行、サーキットブレーカー、Cache-Aside パターンです。
構成ガイダンス。 認証と承認、マネージド ID、権限付与された環境、コードとしてのインフラストラクチャ、監視を構成します。

ビジネスコンテキスト

Web アプリのリプラットフォームの最初の手順は、ビジネス目標を定義することです。サービスレベル目標 (SLO) やコスト最適化の目標など、すぐに目標を設定し、Web アプリケーションの将来の目標も設定する必要があります。これらの目標は、クラウドサービスの選択と、クラウド内の Web アプリケーションのアーキテクチャに影響します。 Web アプリのターゲット SLO を定義します (たとえば、99.9% アップタイム)。 Web アプリの可用性に影響を与えるすべてのサービスについて、複合 SLA を計算します。

たとえば、Contoso Fiber は、オンプレミスの CAMS Web アプリを拡張して他のリージョンに到達したいと考えていました。 Web アプリに対する需要の増加を満たすために、次の目標を確立しました。

低コストで価値の高いコード変更を適用します。
SLO 99.9%に到達します。
DevOps プラクティスを採用する。
コスト最適化環境を作成します。
信頼性とセキュリティを向上させます。

Contoso Fiber は、オンプレミスのインフラストラクチャが、アプリケーションをスケーリングするためのコスト効率の高いソリューションではないと判断しました。彼らは、CAMS Web アプリケーションを Azure に移行することが、即時および将来の目標を達成するための最もコスト効率の高い方法であると判断しました。

アーキテクチャのガイダンス

信頼性の高い Web アプリパターンには、いくつかの重要なアーキテクチャ要素があります。エンドポイント解決を管理するには DNS、悪意のある HTTP トラフィックをブロックする Web アプリケーションファイアウォール、受信ユーザー要求をルーティングして保護するためのロードバランサーが必要です。アプリケーションプラットフォームは、Web アプリコードをホストし、仮想ネットワーク内のプライベートエンドポイントを介してすべてのバックエンドサービスを呼び出します。アプリケーションパフォーマンス監視ツールは、Web アプリを理解するのに役立つメトリックとログをキャプチャします。

図 1. 信頼性の高い Web アプリパターンの重要なアーキテクチャ要素。

アーキテクチャの設計

目標復旧時間 (RTO) や目標復旧時点 (RPO) など、復旧メトリックをサポートするようにインフラストラクチャを設計します。 RTO は可用性に影響し、SLO をサポートする必要があります。 RPO を決定し、RPO 満たすようにデータ冗長性を構成します。

インフラストラクチャの信頼性を選択します。 可用性要件を満たすために必要な可用性ゾーンとリージョンの数を決定します。複合 SLA が SLO を満たすまで、可用性ゾーンとリージョンを追加します。信頼性の高い Web アプリパターンは、アクティブ/アクティブ構成またはアクティブ/パッシブ構成で複数のリージョンをサポートします。たとえば、参照実装では、アクティブ/パッシブ構成を使用して 99.9% の SLO を満たしています。

複数リージョンの Web アプリの場合は、ビジネスニーズに応じて、アクティブ/アクティブまたはアクティブ/パッシブの構成をサポートするように、トラフィックを 2 番目のリージョンにルーティングするようにロードバランサーを構成します。 2 つのリージョンには同じサービスが必要です。ただし、1 つのリージョンにリージョンを接続するハブ仮想ネットワークがある点が異なります。ハブアンドスポークネットワークトポロジを導入して、ネットワークファイアウォールなどのリソースを一元化および共有します。仮想マシンがある場合は、要塞ホストをハブ仮想ネットワークに追加して、セキュリティを強化して管理します。 (図 2 を参照してください。)

図 2. 2 つ目のリージョンを設定し、ハブアンドスポークトポロジを採用した信頼性の高い Web アプリパターン。
ネットワークトポロジを選択します。 Web とネットワークの要件に適したネットワークトポロジを選択します。複数の仮想ネットワークを使用する場合は、ハブアンドスポークネットワークトポロジを使用します。コスト、管理、セキュリティの利点と、オンプレミスと仮想ネットワークへのハイブリッド接続オプションが提供されます。

適切な Azure サービスを選択する

Web アプリをクラウドに移行するときは、ビジネス要件を満たし、オンプレミス Web アプリの機能に合った Azure サービスを選択する必要があります。この配置は、再プラットフォームの作業を最小限に抑えるのに役立ちます。たとえば、同じデータベースエンジンを維持し、既存のミドルウェアとフレームワークをサポートできるサービスを使用します。次のセクションでは、Web アプリに適した Azure サービスを選択するためのガイダンスを提供します。

たとえば、クラウドに移行する前の Contoso Fiber の CAMS Web アプリは、オンプレミスのモノリシック Java Web アプリでした。 PostgreSQL データベースを備えた Spring Boot アプリです。 Web アプリは基幹業務サポートアプリです。従業員向けです。 Contoso Fiber の従業員は、アプリケーションを使用して顧客からのサポートケースを管理します。 Web アプリは、スケーラビリティと機能のデプロイに関する一般的な課題に苦しんでいます。この出発点、ビジネス目標、SLO がサービスの選択を推進しました。

アプリケーションプラットフォーム:Azure App Service をアプリケーションプラットフォームとして使用します。 Contoso Fiber は、次の理由でアプリケーションプラットフォームとして Azure App Service を選択しました。
- 自然な進行。 Contoso Fiber は、オンプレミスサーバーに Spring Boot jar ファイルをデプロイし、そのデプロイモデルの再設計の量を最小限に抑えたいと考えていました。 App Service では、Spring Boot アプリを実行するための堅牢なサポートが提供されており、Contoso Fiber が App Service を使用するのは自然な判断でした。 Azure Container Apps も、このアプリの魅力的な代替手段です。詳細については、「 Azure Container Apps とは」と「Java on Azure Container Apps」の概要を参照してください。
- 高 SLA。 App Service は、運用環境の要件を満たす高い SLA を提供します。
- 管理オーバーヘッドの削減。 App Service は、フルマネージドのホスティングソリューションです。
- コンテナー化機能。 App Service は、Azure Container Registry などのプライベートコンテナーイメージレジストリで動作します。 Contoso Fiber は、これらのレジストリを使用して、将来 Web アプリをコンテナー化できます。
- 自動スケーリング。 Web アプリは、ユーザートラフィックに基づいて迅速にスケールアップ、スケールダウン、イン、スケールアウトできます。
ID 管理: ID およびアクセス管理ソリューションとして Microsoft Entra ID を使用します。 Contoso Fiber は、次の理由で Microsoft Entra ID を選択しました。
- 認証と承認。 アプリケーションは、コールセンターの従業員を認証して承認する必要があります。
- スケーラビリティ。 Microsoft Entra ID は、大規模なシナリオをサポートするためにスケーリングされます。
- ユーザー ID コントロール。 コールセンターの従業員は、既存のエンタープライズ ID を使用できます。
- 承認プロトコルのサポート。 Microsoft Entra ID では、マネージド ID に対して OAuth 2.0 がサポートされています。
データベース: 同じデータベースエンジンを維持できるサービスを使用します。データストアのデシジョンツリーを使用して、選択をガイドします。 Contoso Fiber では、次の理由から Azure Database for PostgreSQL とフレキシブルサーバーデプロイモデルを選択しました。
- 確実。 フレキシブルサーバーデプロイモデルでは、複数の可用性ゾーンにまたがるゾーン冗長高可用性がサポートされます。この構成により、ウォームスタンバイサーバーが同じ Azure リージョン内の別の可用性ゾーンに維持されます。この構成では、スタンバイサーバーにデータが同期的にレプリケートされます。
- リージョン間レプリケーション。 Azure Database for PostgreSQL には、別のリージョンの読み取り専用レプリカデータベースにデータを非同期的にレプリケートできる読み取りレプリカ機能が用意されています。
- パフォーマンス。 Azure Database for PostgreSQL は、実際の使用状況データを使用してデータベースのパフォーマンスを向上させる、予測可能なパフォーマンスとインテリジェントなチューニングを提供します。
- 管理オーバーヘッドの削減。 これは、管理の義務を軽減するフルマネージドの Azure サービスです。
- 移行のサポート。 オンプレミスの単一サーバー PostgreSQL データベースからのデータベース移行をサポートします。 Contoso は移行ツールを使用して、移行プロセスを簡略化できます。
- オンプレミスの構成との整合性。 Contoso Fiber が現在使用しているバージョンなど、さまざまなコミュニティバージョンの PostgreSQL がサポートされています。
- 回復性。 フレキシブルサーバーのデプロイでは、サーバーバックアップが自動的に作成され、同じリージョン内のゾーン冗長ストレージ (ZRS) に格納されます。 Contoso は、バックアップ保有期間内の任意の時点にデータベースを復元できます。バックアップと復元の機能により、Contoso Fiber がオンプレミスで作成できるよりも優れた RPO (許容可能なデータ損失量) が作成されます。
アプリケーションパフォーマンスの監視:Application Insights を使用して、アプリケーションのテレメトリを分析します。 Contoso Fiber は、次の理由で Application Insights を使用することを選択しました。
- Azure Monitor との統合。 Azure Monitor との最適な統合が提供されます。
- 異常の検出。 パフォーマンスの異常が自動的に検出されます。
- トラブルシューティング。 実行中のアプリの問題を診断するのに役立ちます。
- モニタリング。 これにより、ユーザーがアプリをどのように使用しているかに関する情報が収集され、カスタムイベントを簡単に追跡できます。
- 可視性のギャップ。 オンプレミスソリューションには、アプリケーションパフォーマンス監視ソリューションがありませんでした。 Application Insights は、アプリプラットフォームとコードとの簡単な統合を提供します。
キャッシュ: Web アプリアーキテクチャにキャッシュを追加するかどうかを選択します。 Azure Cache for Redis は、プライマリ Azure キャッシュソリューションです。これは、Redis ソフトウェアに基づくマネージドインメモリデータストアです。 Contoso Fiber は、次の理由で Azure Cache for Redis を追加しました。
- 速度と音量。 これは、一般的にアクセスされる低速なデータに対して、高いデータスループットと低待機時間の読み取りを提供します。
- 多様なサポート可能性。 これは、Web アプリのすべてのインスタンスが使用できる統合キャッシュの場所です。
- 外部データストア。 オンプレミスのアプリサーバーは、VM ローカルキャッシュを実行しました。このセットアップでは、頻度の高いデータがオフロードされず、データを無効にできませんでした。
- 非スティックセッション。 キャッシュを使用すると、Web アプリはセッション状態を外部化し、不安定なセッションを使用できます。オンプレミスで実行されるほとんどの Java Web アプリでは、メモリ内クライアント側キャッシュが使用されます。メモリ内クライアント側のキャッシュは適切にスケーリングされないため、ホスト上のメモリ占有領域が増加します。 Azure Cache for Redis を使用すると、Contoso Fiber には、アプリケーションのスケーラビリティとパフォーマンスを向上させるためのフルマネージドのスケーラブルなキャッシュサービスがあります。 Contoso はキャッシュ抽象化フレームワーク (Spring Cache) を使用しており、キャッシュプロバイダーを交換するために必要な構成の変更は最小限でした。 Ehcache プロバイダーから Redis プロバイダーに切り替えることができました。
ロードバランサー: サービスとしてのプラットフォーム (PaaS) ソリューションを使用する Web アプリケーションでは、Web アプリのアーキテクチャと要件に応じて、Azure Front Door、Azure Application Gateway、またはその両方を使用する必要があります。ロードバランサーのデシジョンツリーを使用して、適切なロードバランサーを選択します。 Contoso Fiber には、複数のリージョン間でトラフィックをルーティングできるレイヤー 7 ロードバランサーと、99.9%の SLO を満たす複数リージョンの Web アプリが必要でした。 Contoso は、次の理由で Azure Front Door を選択しました。
- グローバル負荷分散。 これは、複数のリージョン間でトラフィックをルーティングできるレイヤー 7 ロードバランサーです。
- Web アプリケーションファイアウォール。 Azure Web Application Firewall とネイティブに統合されます。
- ルーティングの柔軟性。 これにより、アプリケーションチームは、アプリケーションの将来の変更をサポートするイングレスニーズを構成できます。
- トラフィックアクセラレーション。 エニーキャストを使用して、最も近い Azure プレゼンスポイントに到達し、Web アプリへの最速のルートを見つけます。
- カスタムドメイン。 柔軟なドメイン検証でカスタムドメイン名をサポートします。
- 正常性プローブ。 アプリケーションにはインテリジェントな正常性プローブの監視が必要です。 Azure Front Door は、プローブからの応答を使用して、クライアント要求をルーティングするための最適な配信元を決定します。
- 監視のサポート。 Azure Front Door では、Azure Front Door とセキュリティパターンの両方に対して、オールインワンダッシュボードを備えた組み込みのレポートがサポートされています。 Azure Monitor と統合するアラートを構成できます。 Azure Front Door を使用すると、アプリケーションは各要求と失敗した正常性プローブをログに記録できます。
- DDoS 保護。 レイヤー 3 から 4 の DDoS 保護が組み込まれています。
- コンテンツ配信ネットワーク。 コンテンツ配信ネットワークを使用するように Contoso Fiber を配置します。コンテンツ配信ネットワークは、サイトアクセラレーションを提供します。
Web アプリケーションファイアウォール:Azure Web Application Firewall を使用して、Web での一般的な悪用や脆弱性からの一元的な保護を提供します。 Contoso Fiber は、次の理由から、Azure Web Application Firewall を使用しました。
- グローバル保護。 パフォーマンスを犠牲にすることなく、グローバル Web アプリの保護を強化します。
- Botnet の保護。 チームは、ボットネットに関連するセキュリティ上の問題に対処するための設定を監視および構成できます。
- オンプレミスと同等です。 オンプレミスソリューションは、IT が管理する Web アプリケーションファイアウォールの背後で実行されました。
- 使いやすさ。 Web アプリケーションファイアウォールは、Azure Front Door と統合されます。
シークレットマネージャー: Azure での管理にシークレットを使用している場合は、Azure Key Vault を使用します。 Contoso Fiber は、次の理由で Key Vault を使用しました。
- 暗号化。 保存時と転送中の暗号化をサポートします。
- マネージド ID のサポート。 アプリケーションサービスは、マネージド ID を使用してシークレットストアにアクセスできます。
- 監視とログ記録。 Key Vault は、監査アクセスを容易にし、格納されているシークレットが変更されたときにアラートを生成します。
- 統合。 Key Vault は、Azure 構成ストア (Azure App Configuration) と Web ホスティングプラットフォーム (App Service) とのネイティブ統合を提供します。
エンドポイントセキュリティ:Azure Private Link を使用して、仮想ネットワーク内のプライベートエンドポイント経由で PaaS ソリューションにアクセスします。仮想ネットワークとサービスとの間のトラフィックは、Microsoft バックボーンネットワークをまたがります。 Contoso Fiber は、次の理由で Private Link を選択しました。
- セキュリティ強化された通信。 これにより、アプリケーションは Azure プラットフォーム上のサービスにプライベートにアクセスでき、データ漏えいから保護するためにデータストアのネットワークフットプリントが削減されます。
- 最小限の労力。 プライベートエンドポイントは、Web アプリが使用する Web アプリプラットフォームとデータベースプラットフォームをサポートします。どちらのプラットフォームも既存のオンプレミス構成をミラーリングするため、最小限の変更が必要です。
ネットワークセキュリティ:Azure Firewall を使用して、ネットワークレベルで受信トラフィックと送信トラフィックを制御します。 Azure Bastion を使用して、RDP/SSH ポートを公開することなく、セキュリティが強化された仮想マシンに接続します。 Contoso Fiber はハブアンドスポークネットワークトポロジを採用し、共有ネットワークセキュリティサービスをハブに配置したいと考えていました。 Azure Firewall では、スポークからのすべての送信トラフィックを検査することでセキュリティとネットワークセキュリティを強化しました。 Contoso Fiber では、DevOps サブネット内のジャンプホストからのセキュリティ強化デプロイに Azure Bastion が必要です。

コードのガイダンス

Web アプリをクラウドに正常に移動するには、再試行パターン、サーキットブレーカーパターン、および Cache-Aside パターンを使用して Web アプリコードを更新する必要があります。

図 3。設計パターンの役割。

各設計パターンには、Well-Architected Framework の 1 つ以上の柱に合ったワークロード設計上の利点があります。実装する必要があるパターンの概要を以下に示します。

再試行パターン。 再試行パターンは、断続的に失敗する可能性のある操作を再試行することで、一時的なエラーを処理します。このパターンは、他の Azure サービスに対するすべての送信呼び出しに実装します。
サーキットブレーカーパターン。 サーキットブレーカーパターンにより、アプリケーションが一時的ではない操作を再試行できなくなります。このパターンは、他の Azure サービスに対するすべての送信呼び出しに実装します。
Cache-Aside パターン。 Cache-Aside パターンは、データストアからキャッシュにオンデマンドでデータを読み込みます。このパターンは、データベースに対する要求に実装します。

設計パターン	信頼性 (RE)	パフォーマンス効率 (PE)	WAF の原則のサポート
再試行パターン	✔		RE:07
サーキットブレーカーパターン	✔	✔	RE:03 RE:07 PE:07 PE:11
Cache-Aside パターンの	✔	✔	RE:05 PE:08 PE:12

再試行パターンを実装する

一時的なサービスの中断に対処するために、再試行パターンをアプリケーションコードに追加します。これらの中断は、一時的な障害と呼ばれます。一時的な障害は、通常は数秒以内に解決されます。再試行パターンを使用すると、失敗した要求を再送信できます。また、再試行の間の遅延と、失敗を認める前の試行回数を構成することもできます。

軽量フォールトトレランスライブラリである Resilience4j を使用して、Java で再試行パターンを実装します。参照実装では、サービスプランコントローラーの listServicePlans メソッドを再試行注釈で修飾することで、再試行パターンを追加します。このコードは、最初の呼び出しが失敗した場合に、データベースからサービスプランの一覧への呼び出しを再試行します。参照実装の再試行ポリシーには、最大試行回数、待機時間、再試行する必要がある例外が含まれます。再試行ポリシーは application.propertiesで構成されます。

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

サーキットブレーカーパターンを実装する

サーキットブレーカーパターンを使用して、一時的な障害ではないサービスの中断を処理します。サーキットブレーカーパターンは、アプリケーションが応答しないサービスに継続的にアクセスすることを防ぎます。アプリケーションを解放し、CPU サイクルの無駄を防ぐのに役立ちます。これにより、アプリケーションはエンドユーザーのパフォーマンス整合性を維持します。

Spring Cloud サーキットブレーカーと Resilience4j を使用して、サーキットブレーカーパターンを実装します。リファレンス実装では、サーキットブレーカー属性を使用してメソッドを修飾することで、サーキットブレーカーパターンを実装します。

キャッシュアサイドパターンを実装する

キャッシュアサイドパターンを Web アプリに追加して、メモリ内データ管理を改善します。このパターンにより、データ要求を処理し、キャッシュと永続ストレージ (データベースなど) の間の整合性を確保する責任がアプリケーションに割り当てられます。これにより、応答時間が短縮され、スループットが向上し、さらなるスケーリングの必要性が軽減されます。また、プライマリデータストアの負荷も軽減され、信頼性とコストの最適化が向上します。キャッシュアサイドパターンを実装するには、次の推奨事項に従います。

キャッシュを使用するようにアプリケーションを構成します。 キャッシュを有効にするには、spring-boot-starter-cache パッケージを依存関係として pom.xml ファイルに追加します。このパッケージは、Redis Cache の既定の構成を提供します。
必要性の高いデータをキャッシュします。 必要性の高いデータに Cache-Aside パターンを適用して、その有効性を高めます。 Azure Monitor を使用して、データベースの CPU、メモリ、ストレージを追跡します。これらのメトリックは、Cache-Aside パターンを適用した後に、より小さなデータベース SKU を使用できるかどうかを判断するのに役立ちます。コード内の特定のデータをキャッシュするには、@Cacheable 注釈を追加します。この注釈は、結果をキャッシュする必要があるメソッドを Spring に指定します。
キャッシュデータを最新の状態に保ちます。 最新のデータベース変更と同期するように、定期的なキャッシュ更新をスケジュールします。データのボラティリティを使用し、ユーザーは最適なリフレッシュレートを決定する必要があります。この方法により、アプリケーションは Cache-Aside パターンを使用して、迅速なアクセスと最新の情報の両方を提供できます。既定のキャッシュ設定は、Web アプリケーションに適していない可能性があります。これらの設定は、application.properties ファイルまたは環境変数でカスタマイズできます。たとえば、 spring.cache.redis.time-to-live 値 (ミリ秒単位で表されます) を変更して、削除前にキャッシュにデータを保持する期間を制御できます。
データの一貫性を確保します。 データベース書き込み操作の直後にキャッシュを更新するメカニズムを実装します。イベント駆動の更新または専用のデータ管理クラスを使用して、キャッシュの一貫性を確保します。キャッシュとデータベースの変更を一貫して同期することは、キャッシュアサイドパターンの主要な部分です。

構成ガイダンス

以降のセクションでは、構成の更新プログラムの実装に関するガイダンスを提供します。各セクションは、Well-Architected フレームワークの 1 つ以上の柱と一致します。

構成	信頼性 (RE)	セキュリティ (SE)	コスト最適化 (CO)	オペレーショナルエクセレンス (OE)	パフォーマンス効率 (PE)	WAF の原則のサポート
認証と承認を構成する		✔		✔		SE:05 OE:10
マネージド ID を実装する		✔		✔		SE:05 OE:10
Rightsize 環境			✔			CO:05 CO:06
自動スケーリングを実装する	✔		✔		✔	RE:06 CO:12 PE:05
リソースのデプロイの自動化				✔		OE:05
監視を実装する			✔	✔	✔	OE:07 PE:04

認証と承認を構成する

Web アプリケーションを Azure に移行する場合は、ユーザーの認証と承認のメカニズムを構成します。次の推奨事項に従ってください。

ID プラットフォームを使用します。 Microsoft ID プラットフォームを使用して、Web アプリ認証を設定します。このプラットフォームは、1 つの Microsoft Entra ディレクトリ、異なる組織の複数の Microsoft Entra ディレクトリ、および Microsoft ID またはソーシャルアカウントを使用するアプリケーションをサポートします。

このプロセスは、Microsoft Entra ID 用 Spring Boot Starter によって合理化されます。 Spring Security と Spring Boot を使用して、簡単な構成を実現します。さまざまな認証フロー、自動トークン管理、カスタマイズ可能な承認ポリシー、Spring Cloud コンポーネントとの統合機能が提供されます。このサービスを使用すると、手動ライブラリや設定の構成なしで、簡単に Microsoft Entra ID と OAuth 2.0 を Spring Boot アプリケーションに統合できます。

参照実装では、Web アプリの ID プロバイダーとして Microsoft ID プラットフォーム (Microsoft Entra ID) を使用します。これは、OAuth 2.0 の認証コード付与を使用して、Microsoft Entra アカウントでユーザーをサインインさせます。次の XML スニペットでは、OAuth 2.0 承認コード付与フローで必要な 2 つの依存関係を定義しています。依存関係 com.azure.spring: spring-cloud-azure-starter-active-directory により、Spring Boot アプリケーションで Microsoft Entra の認証と承認が有効になります。依存関係 org.springframework.boot: spring-boot-starter-oauth2-client により、Spring Boot アプリケーションで OAuth 2.0 の認証と承認が有効になります。
```
<dependency>
    <groupid>com.azure.spring</groupid>
    <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-oauth2-client</artifactid>
</dependency>
```
アプリケーション登録を作成します。 Microsoft Entra ID では、プライマリテナントにアプリケーションを登録する必要があります。アプリケーションの登録は、Web アプリにアクセスするユーザーがプライマリテナントに ID を持っていることを確認するのに役立ちます。このリファレンス実装では、Terraform を使用して、アプリ固有のアカウントマネージャーロールと共に Microsoft Entra ID アプリの登録を作成します。
```
resource "azuread_application" "app_registration" {
  display_name     = "${azurecaf_name.app_service.result}-app"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADMyOrg"  # single tenant

  app_role {
    allowed_member_types = ["User"]
    description          = "Account Managers"
    display_name         = "Account Manager"
    enabled              = true
    id                   = random_uuid.account_manager_role_id.result
    value                = "AccountManager"
  }
}
```
アプリケーションで承認を強制します。 ロールベースのアクセス制御 (RBAC) を使用して、アプリケーションロールに最小限の特権を割り当てます。重複を回避し、明確にするために、さまざまなユーザーアクションに対して特定のロールを定義します。ユーザーを適切なロールにマップし、必要なリソースとアクションにのみアクセスできることを確認します。 Spring Boot Starter for Microsoft Entra ID を使用するには、Spring Security を構成します。このライブラリは、Microsoft Entra ID との統合を可能にし、ユーザーが安全に認証されるようにするのに役立ちます。 Microsoft Authentication Library (MSAL) を構成して有効にすると、より多くのセキュリティ機能にアクセスできるようになります。その機能には、トークンキャッシュとトークンの自動更新が含まれています。

参照実装では、Contoso Fiber のアカウント管理システムのユーザーロールの種類を反映するアプリロールが作成されます。ロールは承認時にアクセス許可に変換されます。 CAMS のアプリ固有のロールの例としては、アカウントマネージャー、レベル 1 (L1) サポート担当者、フィールドサービス担当者などがあります。 Account Manager ロールには、新しいアプリユーザーとお客様を追加するためのアクセス許可があります。 Field Service の担当者は、サポートチケットを作成できます。 PreAuthorize 属性は、特定のロールへのアクセスを制限します。
```
    @GetMapping("/new")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    public String newAccount(Model model) {
        if (model.getAttribute("account") == null) {
            List<ServicePlan> servicePlans = accountService.findAllServicePlans();
            ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
            NewAccountRequest accountFormData = new NewAccountRequest();
            accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
            model.addAttribute("account", accountFormData);
            model.addAttribute("servicePlans", servicePlans);
        }
        model.addAttribute("servicePlans", accountService.findAllServicePlans());
        return "pages/account/new";
    }
    ...
```
Microsoft Entra ID と統合するために、リファレンス実装では OAuth 2.0 承認コード付与フローが使用されます。このフローにより、ユーザーは Microsoft アカウントでサインインできます。次のコードスニペットは、認証と承認に Microsoft Entra ID を使用するように SecurityFilterChain を構成する方法を示しています。
```
@Configuration(proxyBeanMethods = false)
@EnableWebSecurity
@EnableMethodSecurity
public class AadOAuth2LoginSecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
            .and()
                .authorizeHttpRequests()
            .requestMatchers(EndpointRequest.to("health")).permitAll()
            .anyRequest().authenticated()
            .and()
                .logout(logout -> logout
                            .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                            .clearAuthentication(true)
                            .invalidateHttpSession(true));
        return http.build();
    }
}
...
```

ストレージに対しては一時的なアクセスを優先します。 一時的なアクセス許可を使用して、不正アクセスや侵害から保護します。たとえば、Shared Access Signature (SAS) を使用して、アクセスを一定期間に制限できます。一時的なアクセス権を付与するときに、ユーザー委任 SAS を使用してセキュリティを最大化します。これは、Microsoft Entra ID の資格情報を使用し、永続的なストレージアカウントキーを必要としない唯一の SAS です。
Azure で承認を強制します。 Azure RBAC を使用して、ユーザー ID に最小限の特権を割り当てます。 Azure RBAC では、ID がアクセスできる Azure リソース、それらのリソースでできること、アクセスできる領域を定義します。
永続的で高度なアクセス許可は避けます。 Microsoft Entra Privileged Identity Management を使用して、特権操作の Just-In-Time アクセスを許可します。たとえば、開発者は多くの場合、データベースの作成/削除、テーブルスキーマの変更、ユーザーのアクセス許可の変更を行うために、管理者レベルのアクセス権を必要とします。 Just-In-Time アクセスを使用すると、ユーザー ID は特権タスクを実行するための一時的なアクセス許可を受け取ります。

マネージド ID を実装する

マネージド ID をサポートするすべての Azure サービスに使用します。マネージド ID を使用すると、Azure リソース (ワークロード ID) は、資格情報の管理を必要とせずに、他の Azure サービスに対する認証と対話を行うことができます。移行を簡略化するには、ハイブリッドシステムとレガシシステム用のオンプレミス認証ソリューションを引き続き使用できますが、できるだけ早くマネージド ID に移行する必要があります。マネージド ID を実装するには、次の推奨事項に従います。

適切な種類のマネージドIDを選択します。同じアクセス許可のセットを必要とする複数の Azure リソースがある場合は、ユーザー割り当てのマネージド ID を優先します。この方法は、各リソースに対してシステム割り当てマネージド ID を作成し、それらのすべてに同じアクセス許可を割り当てるよりも効率的です。そうでない場合は、システム割り当てのマネージド ID を使用します。
最小特権を構成します。 Azure RBAC 使用して、データベースの CRUD アクションやシークレットへのアクセスなど、操作に不可欠なアクセス許可のみを付与します。ワークロード ID のアクセス許可は永続的であるため、ワークロード ID にジャスト・イン・タイムまたは短期のアクセス許可を提供することはできません。 Azure RBAC が特定のシナリオに対応していない場合は、Azure サービスレベルのアクセスポリシーで Azure RBAC を補完します。
残りのシークレットのセキュリティを提供します。 残りのシークレットを Azure Key Vault に格納します。各 HTTP 要求中ではなく、アプリケーションの起動時に Key Vault からシークレットを読み込みます。 HTTP 要求内での高頻度のアクセスにより、Key Vault のトランザクション制限を超える可能性があります。アプリケーション構成を Azure App Configuration に格納します。

Rightsize 環境

各環境のニーズを超えることなく、Azure サービスのパフォーマンスレベル (SKU) を使用します。環境を適切にサイズ変更するには、次の推奨事項に従います。

コストを見積もる。 Azure 料金計算ツールを使用して、各環境のコストを見積もります。
運用環境のコスト最適化。 運用環境には、運用に必要なサービスレベルアグリーメント (SLA)、機能、スケールを満たす SKU が必要です。リソースの使用状況を継続的に監視し、実際のパフォーマンスニーズに合わせて SKU を調整します。
運用前環境のコスト最適化。運用前環境低コストのリソースを使用し、azure Dev/Test 価格などの割引を利用する必要があります。これらの環境では、不要なサービスを無効にする必要があります。同時に、実稼働前環境が運用環境環境と十分に類似していることを確認して、リスクが発生しないようにします。このバランスを維持することで、不要なコストを発生させずにテストを効果的に維持できます。
コードとしてのインフラストラクチャ (IaC) を使用して SKU を定義します。 IaC を実装することで、環境に基づいて適切な SKU を動的に選択してデプロイします。このアプローチにより、一貫性が向上し、管理が簡略化されます。

たとえば、参照実装には、デプロイする SKU を指定する省略可能なパラメーターがあります。環境パラメーターは、Terraform テンプレートで開発 SKU をデプロイすることを指定します。

azd env set APP_ENVIRONMENT prod

自動スケーリングを実装する

自動スケーリングは、Web アプリが回復性と応答性を維持し、動的なワークロードを効率的に処理できるようにするのに役立ちます。オートスケールを実装するには、次の推奨事項に従います。

スケールアウトを自動化します。Azure オートスケールを使用して、実稼働環境での水平スケーリングを自動化します。アプリケーションがさまざまな負荷を処理できるように、主要なパフォーマンスメトリックに基づいてスケールアウトするように自動スケールルールを構成します。
スケーリングトリガーを調整します。 アプリケーションのスケーリング要件に慣れていない場合は、初期スケーリングトリガーとして CPU 使用率を使用します。スケーリングトリガーを調整して、RAM、ネットワークスループット、ディスク I/O などの他のメトリックを含めます。目標は、Web アプリケーションの動作を合わせることで、パフォーマンスを向上させることです。
スケールアウトバッファーを指定します。 最大容量に達する前にトリガーするようにスケーリングのしきい値を設定します。たとえば、100% に達するまで待機するのではなく、CPU 使用率 85% で実行するようにスケーリングを構成します。このプロアクティブなアプローチは、パフォーマンスを維持し、潜在的なボトルネックを回避するのに役立ちます。

リソースのデプロイの自動化

自動化を使用して、すべての環境に Azure のリソースとコードをデプロイおよび更新します。次の推奨事項に従ってください。

コードとしてのインフラストラクチャを使用します。 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して、インフラストラクチャをコードとしてデプロイします。 Azure には、すべての Azure リソースに Bicep、ARM (JSON)、Terraform テンプレート事前構築済みテンプレートが用意されています。
継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインを使用します。 CI/CD パイプラインを使用して、ソース管理からさまざまな環境 (テスト、ステージング、運用など) にコードをデプロイします。 Azure DevOps を使用している場合は、Azure Pipelines を使用します。 GitHub プロジェクトに GitHub Actions を使用します。
単体テストの統合。 App Services にデプロイする前に、パイプライン内のすべての単体テストの実行と受け渡しに優先順位を付けます。 SonarQube などのコード品質およびカバレッジツールを組み込んで、包括的なテストカバレッジを実現します。
モックフレームワークを採用する。 外部エンドポイントを含むテストでは、モックフレームワークを使用します。これらのフレームワークを使用すると、シミュレートされたエンドポイントを作成できます。これにより、実際の外部エンドポイントを構成し、環境間でテスト条件を統一する必要がなくなります。
セキュリティスキャンを実行します。 静的アプリケーションセキュリティテスト (SAST) を使用して、ソースコードのセキュリティの欠陥とコーディングエラーを見つけます。さらに、ソフトウェア構成分析 (SCA) を実行して、サードパーティのライブラリとコンポーネントのセキュリティリスクを調べます。これらの分析用のツールは、GitHub と Azure DevOps の両方に簡単に統合できます。

監視の構成

アプリケーションとプラットフォームの監視を実装して、Web アプリのオペレーショナルエクセレンスとパフォーマンス効率を向上させます。監視を実装するには、次の推奨事項に従います。

アプリケーションテレメトリを収集します。 Azure Application Insights 自動侵入を使用して、要求スループット、平均要求期間、エラー、依存関係の監視など、アプリケーションテレメトリを収集します。このテレメトリを使用するためにコードを変更する必要はありません。 Spring Boot では、Java 仮想マシン (JVM)、CPU、Tomcat など、いくつかのコアメトリックが Application Insights に登録されます。 Application Insights は、Log4j や Logback などのログ記録フレームワークから自動的に収集されます。

参照実装では Application Insights を使用します。これは、App Service の app_settings 構成で Terraform を介して有効になります。
```
app_settings = {
    APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
    ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
    ...
}
```
詳細については、以下を参照してください:
カスタムアプリケーションメトリックを作成します。 Application Insights SDK を追加し、その API を使用することで、カスタムアプリケーションテレメトリをキャプチャするコードベースのインストルメンテーションを実装します。
プラットフォームを監視します。 サポートされているすべてのサービスの診断を有効にします。関連付けのために、アプリケーションログと同じ宛先に診断を送信します。 Azure サービスはプラットフォームログを自動的に作成しますが、診断を有効にした場合にのみ保存します。診断をサポートするサービスごとに、診断設定を有効にします。

参照実装では、Terraform を使用して、サポートされているすべてのサービスで Azure 診断を有効にしています。次の Terraform コードは、App Service の診断設定を構成します。
```
# Configure diagnostic settings for app service
resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
  name                           = "app-service-diagnostic-settings"
  target_resource_id             = azurerm_linux_web_app.application.id
  log_analytics_workspace_id     = var.log_analytics_workspace_id
  #log_analytics_destination_type = "AzureDiagnostics"

  enabled_log {
    category_group = "allLogs"

  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}
```

参照実装をデプロイする

このリファレンス実装では、オンプレミスの Java アプリケーションを Azure にシミュレートして移行する手順を開発者に案内し、最初の導入フェーズで必要な変更を強調します。この例では、架空の会社 Contoso Fiber の CAMS Web アプリを使用します。 Contoso Fiber は、Web アプリケーションの次の目標を設定します。

低コストで価値の高いコード変更を実装します。
99.9%の SLO を達成します。
DevOps プラクティスを採用する。
コスト最適化環境を作成します。
信頼性とセキュリティを強化します。

Contoso Fiber では、オンプレミスインフラストラクチャは、これらの目標を達成するコスト効率の高いソリューションではないと判断しました。彼らは、CAMS Web アプリケーションを Azure に移行することが、即時および将来の目標を達成するための最もコスト効率の高い方法であると判断しました。次のアーキテクチャは、Contoso Fiber の Reliable Web App パターン実装の終了状態を表しています。

図 4. 参照実装のアーキテクチャ。このアーキテクチャの Visio ファイルをダウンロードできます。

参照の実装

次の方法で共有

Java 向け信頼性の高い Web アプリ パターン