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

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

併置

Web アプリやデータベースなど、ソリューションを構成する Azure リソースを別々のリージョンに配置すると、次のような影響が考えられます。

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

Web アプリ、データベース、コンテンツやデータを保持するためのストレージ アカウントなど、ソリューションを構成する Azure リソースは、同じリージョンに配置すること (コロケーション) をお勧めします。 リソースを作成する場合は、それらを必ず同じ Azure リージョン内に配置してください。ただし、特定のビジネスまたは設計上の理由で難しい場合はその限りでありません。 Premium App Service プラン アプリで現在利用できる App Service の複製機能を使うと、App Service アプリをデータベースと同じリージョンに移動することができます。

証明書のピン留め

*.azurewebsites.net TLS 証明書は、サービスとしてのプラットフォームとしての App Service (PaaS) の性質上、いつでもローテーションできるため、アプリケーションにハード依存関係や既定の *.azurewebsites.net TLS 証明書へのピン留めはしないでください。 証明書のピン留めは、アプリケーションで、受け入れ可能な証明機関 (CA)、公開キー、拇印、または証明書階層の任意の部分の特定のリストのみを許可する方法です。 サービスが App Service 既定のワイルドカード TLS 証明書をローテーションした場合、証明書固定アプリケーションは中断され、特定の証明書属性のセットにハードコーディングされたアプリケーションの接続が中断されます。 *.azurewebsites.net TLS 証明書がローテーションされる周期性も、ローテーション頻度がいつでも変化される可能性があるため、保証されません。

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

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

アプリが予想よりも多くのメモリを消費している場合

監視またはサービスの推奨事項に示されている情報を基に、アプリが予想よりも多くのメモリを消費していることに気付いた場合は、App Service の自動修復機能を検討してください。 自動修復機能のオプションの 1 つでは、メモリのしきい値に基づいて独自の処置を行います。 処置の内容は、電子メールによる通知から、メモリ ダンプによる調査、さらに worker プロセスのリサイクルによるその場での軽減処理まで広範囲に及びます。 自動修復は、 App Service サポート サイトの拡張機能に関するこのブログ投稿の説明に沿って、Web.config またはわかりやすいユーザー インターフェイスを使用して構成することができます。

アプリが予想よりも多くの CPU リソースを消費している場合

監視またはサービスの推奨事項の説明を基に、アプリが予想よりも多くの CPU リソースを消費していること、または CPU スパイクが繰り返し発生していることに気が付いた場合は、App Service プランのスケール アップまたはスケール アウトを検討してください。 アプリケーションがステートフルである場合は、スケール アップが唯一のオプションとなります。一方、アプリケーションがステートレスである場合、スケール アウトにより、柔軟性と拡張性を高めることができます。

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

ソケット リソースを使い果たした場合

送信 TCP 接続を使い果たしてしまう理由としては、一般的には、使っているライブラリが TCP 接続を再利用するように実装されていないことや、HTTP - Keep-Alive などの上位レベルのプロトコルが使われていないことなどが挙げられます。 App Service プランでアプリによって参照される各ライブラリのドキュメントを再確認し、送信接続が効率的に再利用されるようにコード内でライブラリが構成またはアクセスされるようにしてください。 また、ライブラリのドキュメントのガイダンスに従って適切に作成しリリースするか、接続のリークを防ぐためにクリーンアップを行ってください。 このようなクライアント ライブラリの調査中は、複数のインスタンスにスケール アウトすることで影響を軽減することができます。

Node.js と送信 http 要求

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

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

http または https パッケージの処理例を次に示します。

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

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

4 つのインスタンスを開始する例を次に示します。

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

アプリのバックアップが失敗するようになった場合

アプリのバックアップが失敗する場合は、最も一般的な理由として、無効なストレージ設定と無効なデータベース構成の 2 つが考えられます。 通常、このようなエラーはストレージまたはデータベースのリソースに変更が加えられた場合か、これらのリソースへのアクセス方法が変更された場合 (バックアップ設定で選択したデータベースに関して資格情報が更新された場合など) に発生します。 バックアップは、通常はスケジュールに応じて実行され、ストレージへのアクセス (バックアップしたファイルの出力用) とデータベースへのアクセス (バックアップに含まれる内容のコピーと読み取り用) が必要になります。 これらのリソースのいずれかにアクセスできないと、バックアップは常に失敗します。

バックアップ エラーが発生した場合は、最新のバックアップ結果を確認してどちらの種類のエラーが発生しているのかを把握します。 ストレージへのアクセス エラーが発生している場合は、バックアップ構成で使用しているストレージ設定を確認し、更新します。 データベースへのアクセス エラーが発生している場合は、アプリ設定に含まれる接続文字列を確認し、更新してから、必要なデータベースが正しく含まれるようにバックアップ構成を更新します。 アプリのバックアップについて詳しくは、Azure App Service での Web アプリのバックアップに関する記事をご覧ください。

新しい Node.js アプリを Azure App Service にデプロイする場合

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

モノのインターネット (IoT) デバイスが App Service 上のアプリに接続されている場合

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

環境内の回復性を高めるためには、すべてのデバイスに対して単一のエンドポイントに依存しないようにする必要があります。 1 つの障害点を回避し、トラフィックをフェールオーバーする準備を整えるために、少なくとも 2 つの異なるリージョンで Web アプリをホストする必要があります。 App Service では、これらの Web アプリが異なるリージョンでホストされている限り、同じカスタム ドメインを異なる Web アプリに追加できます。 これにより、証明書をピン留めする必要がある場合は、指定したカスタム TLS 証明書をピン留めすることもできます。 もう 1 つのオプションは、Web アプリの高可用性を確保するために、Azure Front Door や Traffic Manager など、Web アプリの前でロード バランサーを使用することです。 詳細については、「クイック スタート: 高可用性グローバル Web アプリケーションの Front Door の作成」または「Azure Traffic Manager を使用した Azure App Service トラフィックの制御」を参照してください。

次の手順

ベスト プラクティスの詳細については、App Service 診断にアクセスして、リソース専用の実行可能なベスト プラクティスを確認してください。

  • Azure portal で Web App に移動します。
  • 左側のナビゲーションで [問題の診断と解決] をクリックすると、App Service 診断が開きます。
  • [ベスト プラクティス] ホームページ タイルを選択します。
  • [Best Practices for Availability & Performance](可用性 & パフォーマンスのベスト プラクティス) または [Best Practices for Optimal Configuration](最適な構成のベスト プラクティス) をクリックして、これらのベスト プラクティスに関するアプリの現在の状態を表示します。

また、こちらのリンクを使用して、リソースの 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