次の方法で共有

Azure App Service のベスト プラクティス

  • [アーティクル]

この記事では、 Azure App Serviceを使用するためのベスト プラクティスを概説します。

併置

Azure App Service ソリューションは、Web アプリと、コンテンツやデータを保持するためのデータベースまたはストレージ アカウントで構成されます。 これらのリソースが異なるリージョンにある場合、その状況から次の影響が生じる可能性があります。

  • リソース間の通信における待機時間の増大
  • Azure の料金に関するページに記載されている、リージョン間の送信データ転送にかかる料金の請求

コロケーションは、ソリューションを構成する Azure リソースに最適です。 リソースを作成する場合は、それらを必ず同じ Azure リージョン内に配置してください。ただし、特定のビジネスまたは設計上の理由で難しい場合はその限りでありません。 Premium App Service プランで利用できる App Service の複製機能を使うと、App Service アプリをデータベースと同じリージョンに移動することができます。

証明書のピン留め

証明書のピン留めは、アプリケーションで、受け入れ可能な証明機関 (CA)、公開キー、拇印、または証明書階層の任意の部分の特定のリストのみを許可する方法です。

アプリケーションがハードな依存関係を保持することや、既定のワイルドカード (*.azurewebsites.net) TLS 証明書をピン留めすることはできません。 App Service はサービスとしてのプラットフォーム (PaaS) であるため、この証明書はいつでもローテーションできます。 サービスが既定のワイルドカード TLS 証明書をローテーションした場合、証明書固定アプリケーションは中断され、特定の証明書属性のセットにハードコーディングされたアプリケーションの接続が中断されます。 証明書がローテーションされる周期性も、ローテーション頻度がいつでも変化される可能性があるため、保証されません。

証明書のピン留めに依存するアプリケーションも、App Service マネージド証明書に対するハードな依存関係を持つべきではありません。 App Service マネージド証明書は、いつでもローテーションでき、安定した証明書プロパティに依存するアプリケーションでも同様の問題が発生する可能性があります。 証明書のピン留めに依存するアプリケーションには、カスタム TLS 証明書を提供することをお勧めします。

アプリケーションが証明書のピン留め動作に依存する必要がある場合は、Web アプリにカスタム ドメインを追加し、そのドメインにカスタム TLS 証明書を指定することをお勧めします。 アプリケーションは、証明書のピン留めでカスタム TLS 証明書に依存できます。

メモリ リソース

監視またはサービスの推奨事項によって、アプリが予想よりも多くのメモリを消費していることが示された場合は、App Service の自動修復機能を検討してください。 web.config を使用して自動修復を構成できます。

自動修復機能のオプションの 1 つでは、メモリのしきい値に基づいて独自の処置を行います。 処置の内容は、電子メールによる通知から、メモリ ダンプによる調査、さらに worker プロセスのリサイクルによるその場での軽減処理まで広範囲に及びます。

CPU リソース

監視またはサービスの推奨事項によって、アプリが予想よりも多くの CPU リソースを消費していること、または CPU スパイクが繰り返し発生していることが示された場合は、App Service プランのスケールアップまたはスケールアウトを検討してください。 アプリケーションがステートフルな場合は、選択肢はスケールアップのみです。 アプリケーションがステートレスの場合、スケールアウトすると、柔軟性が高まり、スケールの可能性が高くなります。

App Service のスケール オプションおよび自動スケール オプションについて詳しくは、「Azure App Service でアプリをスケールアップする」をご覧ください。

ソケット リソース

送信 TCP 接続を使い果たしてしまう理由としては、一般的には、使っているライブラリが TCP 接続を再利用しないことや、HTTP keep-alive などの上位レベルのプロトコルが使われていないことなどが挙げられます。

App Service プランのアプリが参照する各ライブラリのドキュメントを見直します。 ライブラリが送信接続を効率的に再利用するようにコード内で構成またはアクセスされていることを確認します。 また、ライブラリのドキュメントのガイダンスに従って適切に作成しリリースするか、接続のリークを防ぐためにクリーンアップを行ってください。 クライアント ライブラリをこのように調査するときは、複数のインスタンスにスケールアウトすることで影響を軽減することができます。

Node.js と送信 HTTP 要求

Node.js と多数の送信 HTTP 要求を処理する場合は、HTTP keep-alive の処理が重要です。 agentkeepalive npm パッケージを使用して、コード内で簡単に処理することができます。

ハンドラーで何もしない場合でも、http 応答を常に処理します。 応答を適切に処理しなかった場合、使用できるソケットがなくなるため、アプリケーションは最終的にスタックします。

http または https パッケージを使用しているときに応答を処理する例を次に示します。

const request = https.request(options, function(response) {
    response.on('data', function() { /* do nothing */ });
});

複数のコアを備えた Linux コンピューターで App Service アプリを実行している場合、もう 1 つのベスト プラクティスは、PM2 を使用して複数の Node.js プロセスを開始して、アプリケーションを実行することです。 これは、コンテナーにスタートアップ コマンドを指定することによって実行できます。

たとえば、次のコマンドを使用して 4 つのインスタンスを開始します。

pm2 start /home/site/wwwroot/app.js --no-daemon -i 4

アプリのバックアップ

バックアップは、通常はスケジュールに応じて実行され、ストレージへのアクセス (バックアップしたファイルの出力用) とデータベースへのアクセス (バックアップに含まれる内容のコピーと読み取り用) が必要になります。 これらのリソースのいずれかにアクセスできないと、バックアップは常に失敗します。

アプリのバックアップが失敗する場合は、最も一般的な理由として、無効なストレージ設定と無効なデータベース構成の 2 つが考えられます。 通常、このような失敗が発生するのは、ストレージまたはデータベース リソースの変更後、またはそれらのリソースにアクセスするための資格情報の変更後です。 たとえば、バックアップ設定で選択したデータベースの資格情報が更新されることがあります。

バックアップ エラーが発生した場合は、最新のバックアップ結果を確認してどちらの種類のエラーが発生しているのかを把握します。 ストレージへのアクセス エラーが発生している場合は、バックアップ構成のストレージ設定を確認し、更新します。 データベースのアクセス エラーの場合は、アプリ設定内で接続文字列を確認して更新します。 次に、バックアップ構成を更新して、必要なデータベースを適切に組み込みます。

アプリのバックアップの詳細については、「Azure App Service でアプリをバックアップおよび復元する」を参照してください。

Node.js アプリ

Node.js アプリ向けの Azure App Service の既定の構成は、最も一般的なアプリのニーズに最も合うように設計されています。 Node.js アプリの既定構成をカスタマイズして、パフォーマンスの向上または CPU/メモリ/ネットワーク リソースのリソース使用量の最適化を行う場合には、「Azure App Service でのノード アプリケーションのベスト プラクティスとトラブルシューティング ガイド」をご覧ください。 この記事では、Node.js アプリのために構成する必要がある iisnode 設定について説明します。 また、アプリのシナリオや問題に対処する方法についても説明します。

IoT デバイス

App Service に接続されているモノのインターネット (IoT) デバイスを実行している際に環境を改善できます。

IoT デバイスの一般的なプラクティスの 1 つは、"証明書のピン留め" です。 サービスのマネージド証明書の変更による予期しないダウンタイムを回避するには、証明書を既定の *.azurewebsites.net 証明書や App Service マネージド証明書にピン留めしないでください。 システムが証明書のピン留め動作に依存する必要がある場合は、Web アプリにカスタム ドメインを追加し、そのドメインにカスタム TLS 証明書を指定することをお勧めします。 アプリケーションは、証明書のピン留めでカスタム TLS 証明書に依存できます。 詳細については、この記事の「証明書のピン留め」セクションを参照してください。

環境内の回復性を高めるためには、すべてのデバイスで単一のエンドポイントに依存しないようにします。 1 つの障害点を回避し、トラフィックをフェールオーバーする準備を整えるために、少なくとも 2 つのリージョンで Web アプリをホストします。

App Service では、これらの Web アプリが異なるリージョンでホストされている限り、同じカスタム ドメインを複数の Web アプリに追加できます。 この機能により、証明書をピン留めする必要がある場合は、指定したカスタム TLS 証明書をピン留めすることもできます。

もう 1 つのオプションは、Web アプリの高可用性を確保するために、Azure Front Door や Azure Traffic Manager など、Web アプリの前でロード バランサーを使用することです。 詳細については、「クイック スタート: 高可用性グローバル Web アプリケーションの Front Door インスタンスの作成」または「Azure Traffic Manager を使用した Azure App Service トラフィックの制御」を参照してください。

次のステップ

ご使用のリソースに固有の実用的なベスト プラクティスを入手するには、App Service 診断を使用します。

  1. Azure portal で、Web アプリに移動します。
  2. 左側のウィンドウで [問題の診断と解決] を選択して、App Service 診断を開きます。
  3. [ベスト プラクティス] タイルを選択します。
  4. [可用性とパフォーマンスのベスト プラクティス] または [最適な構成のベスト プラクティス] を選び、これらのベスト プラクティスに関するアプリの現在の状態を確認します。

また、こちらのリンクを使用して、リソースの App Service 診断を直接開くこともできます: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot。