Web ファームでの ASP.NET Core のホスト

  • [アーティクル]

作成者: Chris Ross

"Web ファーム" とは、アプリのインスタンスを複数ホストする、2 つ以上の Web サーバー (または "ノード") のグループのことです。 ユーザーからの要求が Web ファームに到着すると、"ロード バランサー" が要求を Web ファームのノードに分散します。 Web ファームの利点は次のとおりです。

  • 信頼性/可用性:1 つまたは複数のノードに障害が発生した場合、ロード バランサーによって要求が機能しているノードにルーティングされ、要求の処理を続行することができます。
  • 容量/パフォーマンス:複数のノードは 1 台のサーバーよりもより多くの要求を処理できます。 ロード バランサーは、ノードへの要求を分散することにでワークロードのバランスをとります。
  • スケーラビリティ:より多くの (またはより少ない) 容量が必要になると、ワークロードに一致するようにアクティブなノードの数を増加 (または減少) させることができます。 Azure App Service などの Web ファーム プラットフォーム テクノロジでは、システム管理者の要求に応じて、または人の介入なしに、自動的にノードを追加したり削除したりできます。
  • 保守容易性:Web ファームのノードでは一連の共有サービスを利用できるため、システム管理が簡単になります。 たとえば、Web ファームのノードにおいて、画像やダウンロード可能ファイルなどの静的リソースのために、単一のデータベース サーバーと共通のネットワークの場所を利用することができます。

このトピックでは、共有リソースを利用する Web ファームでホストされている ASP.NET Core アプリ用の構成と依存関係について説明します。

全般構成

ASP.NET Core のホストと展開
ホスティング環境を設定し、ASP.NET Core アプリを展開する方法を学習します。 Web ファームの各ノード上のプロセス マネージャーを構成して、アプリの起動と再起動を自動化します。 各ノードには ASP.NET Core ランタイムが必要です。 詳細については、ドキュメントのホストと展開に関する部分のトピックをご覧ください。

プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する
プロキシ サーバーとロード バランサーの背後にホストされているアプリの構成について説明します。このような構成では、要求の重要な情報がわからなくなることがよくあります。

Azure App Service に ASP.NET Core アプリを展開する
Azure App Service は ASP.NET Core を含む Web アプリをホストするための Microsoft クラウド コンピューティング プラットフォーム サービスです。 App Service は、自動スケーリング、負荷分散、修正プログラムの適用、および継続的配置を提供する、フル マネージドのプラットフォームです。

アプリのデータ

アプリが複数のインスタンスに対してスケーリングされると、ノード間での共有を必要とするアプリの状態が出現する可能性があります。 この状態が一時的である場合は、IDistributedCache を共有することを検討してください。 共有状態を永続的に保つ必要がある場合は、共有状態をデータベースに格納することを検討してください。

必要な構成

Web ファームに展開されるアプリに対して、データの保護とキャッシュを構成する必要があります。

データの保護

アプリでは、データを保護するために ASP.NET Core データ保護システムが使用されます。 データ保護では、"キー リング" に格納されている一連の暗号化キーが利用されます。 データ保護システムを初期化すると、キー リングをローカルに格納する既定の設定が適用されます。 既定の構成では、Web ファームの各ノード上に一意のキー リングが格納されます。 このため、Web ファームの各ノードは、他のノード上のアプリが暗号化したデータを暗号化解除することはできません。 既定の構成が Web ファームでのアプリのホスト全般に対して適切であるわけではありません。 共有キー リングを実装する代わりに、ユーザー要求を常に同じノードにルーティングすることもできます。 Web ファーム デプロイ向けのデータ保護システムの構成の詳細については、「ASP.NET Core データ保護の構成」を参照してください。

キャッシュ

Web ファーム環境におけるキャッシュのメカニズムでは、Web ファームのノード間でキャッシュされる項目を共有する必要があります。 キャッシュは、一般的な Redis Cache (SQL Server 共有データベース) を利用するか、またはキャッシュされる項目を Web ファーム間で共有するカスタム実装のキャッシュを利用する必要があります。 詳細については、「ASP.NET Core の分散キャッシュ」を参照してください。

依存コンポーネント

次のシナリオに追加構成は必要ありませんが、シナリオが依存するテクノロジには、Web ファーム用の構成が必要です。

シナリオ 依存先
認証 データ保護 (「ASP.NET Core データ保護の構成」を参照してください)。

詳細については、ASP.NET Core Identity を使わずに cookie 認証を使う方法に関するページと「ASP.NET アプリ間で認証 cookie を共有する」を参照してください。
Identity 認証とデータベースの構成。

詳細については、「ASP.NET Core の Identity の概要」を参照してください。
Session データ保護 (暗号化された cookie) (「ASP.NET Core データ保護の構成」を参照してください) およびキャッシュ (「ASP.NET Core の分散キャッシュ」を参照してください)。

詳細については、セッションと状態の管理に関するページの「セッション状態」を参照してください。
TempData データ保護 (暗号化された cookie) (「ASP.NET Core データ保護の構成」を参照してください) またはセッション (セッションと状態の管理に関するページの「セッション状態」を参照してください)。

詳細については、セッションと状態の管理に関するページの「TempData」を参照してください。
偽造防止 データ保護 (「ASP.NET Core データ保護の構成」を参照してください)。

詳細については、「ASP.NET Core でのクロスサイト リクエスト フォージェリ (XSRF/CSRF) 攻撃の防止」を参照してください。

トラブルシューティング

データ保護とキャッシュ

データ保護またはキャッシュが Web ファーム環境用に構成されていない場合、要求の処理中に断続的にエラーが発生します。 このエラーは、ノード間で同じリソースが共有されておらず、ユーザー要求が同じノードにルーティングされない場合があるために発生します。

ユーザーが cookie 認証を使用してアプリにサインインする場合を考えてみます。 このユーザーは、1 つの Web ファームのノード上にあるアプリにサインインします。 ユーザーの次の要求が、ユーザーがサインインしたノードと同じノードに届いた場合、アプリは認証 cookie の暗号化を解除して、アプリのリソースへのアクセスを許可することができます。 ユーザーの次の要求が異なるノードに届いた場合、アプリはユーザーがサインインしたノードの認証 cookie の暗号化を解除できず、要求されたリソースに対する認証は失敗します。

次の現象のいずれかが断続的に発生するときは、多くの場合、データ保護またはキャッシュが Web ファーム環境に向けて適切に構成されていないことが問題の原因です。

  • 認証の中断:認証 cookie が正しく構成されていない、または暗号化解除できない。 OAuth (Facebook、Microsoft、Twitter) ログインまたは OpenIdConnect ログインが「関連付けできませんでした」というエラーで失敗する。
  • 承認の中断: Identity が失われる。
  • セッション状態でデータが失われる。
  • キャッシュされた項目が消える。
  • TempData が失敗する。
  • POST の失敗:偽造防止チェックが失敗する。

Web ファーム デプロイ向けのデータ保護の構成の詳細については、「ASP.NET Core データ保護の構成」を参照してください。 Web ファーム デプロイ向けのキャッシュの構成の詳細については、「ASP.NET Core の分散キャッシュ」を参照してください。

アプリからデータを取得する

Web ファーム アプリが要求に応答できる場合は、ターミナル インライン ミドルウェアを使用して、要求、接続、その他のデータをアプリから取得します。 詳細とサンプル コードについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。

その他の技術情報