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

この記事では、 Azure App Serviceを使用するためのベスト プラクティスを概説します。This article summarizes best practices for using Azure App Service.

コロケーションColocation

Web アプリやデータベースなど、ソリューションを構成する Azure リソースを別々のリージョンに配置すると、次のような影響が考えられます。When Azure resources composing a solution such as a web app and a database are located in different regions, it can have the following effects:

  • リソース間の通信における待機時間の増大Increased latency in communication between resources
  • Azure の料金に関するページに記載されている、リージョン間の送信データ転送にかかる料金の請求Monetary charges for outbound data transfer cross-region as noted on the Azure pricing page.

Web アプリ、データベース、コンテンツやデータを保持するためのストレージ アカウントなど、ソリューションを構成する Azure リソースは、同じリージョンに配置すること (コロケーション) をお勧めします。Colocation in the same region is best for Azure resources composing a solution such as a web app and a database or storage account used to hold content or data. リソースを作成する場合は、それらを必ず同じ Azure リージョン内に配置してください。ただし、特定のビジネスまたは設計上の理由で難しい場合はその限りでありません。When creating resources, make sure they are in the same Azure region unless you have specific business or design reason for them not to be. Premium App Service プラン アプリで現在利用できる App Service の複製機能を使うと、App Service アプリをデータベースと同じリージョンに移動することができます。You can move an App Service app to the same region as your database by using the App Service cloning feature currently available for Premium App Service Plan apps.

アプリが予想よりも多くのメモリを消費している場合When apps consume more memory than expected

監視またはサービスの推奨事項に示されている情報を基に、アプリが予想よりも多くのメモリを消費していることに気付いた場合は、App Service の自動修復機能を検討してください。When you notice an app consumes more memory than expected as indicated via monitoring or service recommendations, consider the App Service Auto-Healing feature. 自動修復機能のオプションの 1 つでは、メモリのしきい値に基づいて独自の処置を行います。One of the options for the Auto-Healing feature is taking custom actions based on a memory threshold. 処置の内容は、電子メールによる通知から、メモリ ダンプによる調査、さらに worker プロセスのリサイクルによるその場での軽減処理まで広範囲に及びます。Actions span the spectrum from email notifications to investigation via memory dump to on-the-spot mitigation by recycling the worker process. 自動修復は、 App Service サポート サイトの拡張機能に関するこのブログ投稿の説明に沿って、Web.config またはわかりやすいユーザー インターフェイスを使用して構成することができます。Auto-healing can be configured via web.config and via a friendly user interface as described at in this blog post for the App Service Support Site Extension.

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

監視またはサービスの推奨事項の説明を基に、アプリが予想よりも多くの CPU リソースを消費していること、または CPU スパイクが繰り返し発生していることに気が付いた場合は、App Service プランのスケール アップまたはスケール アウトを検討してください。When you notice an app consumes more CPU than expected or experiences repeated CPU spikes as indicated via monitoring or service recommendations, consider scaling up or scaling out the App Service plan. アプリケーションがステートフルである場合は、スケール アップが唯一のオプションとなります。一方、アプリケーションがステートレスである場合、スケール アウトにより、柔軟性と拡張性を高めることができます。If your application is stateful, scaling up is the only option, while if your application is stateless, scaling out gives you more flexibility and higher scale potential.

"ステートフル" アプリケーション対 "ステートレス" アプリケーションについて詳しくは、次のビデオをご覧ください:「Planning a Scalable End-to-End Multi-Tier Application on Azure App Service (Azure App Service でスケーラブルなエンド ツー エンドの多層アプリケーションを計画する)」。For more information about “stateful” vs “stateless” applications you can watch this video: Planning a Scalable End-to-End Multi-Tier Application on Azure App Service. App Service のスケール オプションおよび自動スケール オプションについて詳しくは、Azure App Service での Web アプリのスケーリングに関する記事をご覧ください。For more information about App Service scaling and autoscaling options, see Scale a Web App in Azure App Service.

ソケット リソースを使い果たした場合When socket resources are exhausted

送信 TCP 接続を使い果たしてしまう理由としては、一般的には、使っているライブラリが TCP 接続を再利用するように実装されていないことや、HTTP - Keep-Alive などの上位レベルのプロトコルが使われていないことなどが挙げられます。A common reason for exhausting outbound TCP connections is the use of client libraries, which are not implemented to reuse TCP connections, or when a higher-level protocol such as HTTP - Keep-Alive is not used. App Service プランでアプリによって参照される各ライブラリのドキュメントを再確認し、送信接続が効率的に再利用されるようにコード内でライブラリが構成またはアクセスされるようにしてください。Review the documentation for each of the libraries referenced by the apps in your App Service Plan to ensure they are configured or accessed in your code for efficient reuse of outbound connections. また、ライブラリのドキュメントのガイダンスに従って適切に作成しリリースするか、接続のリークを防ぐためにクリーンアップを行ってください。Also follow the library documentation guidance for proper creation and release or cleanup to avoid leaking connections. このようなクライアント ライブラリの調査中は、複数のインスタンスにスケール アウトすることで影響を軽減することができます。While such client libraries investigations are in progress, impact may be mitigated by scaling out to multiple instances.

Node.js と送信 http 要求Node.js and outgoing http requests

Node.js と多数の送信 http 要求を処理する場合は、HTTP - Keep-Alive の処理が重要です。When working with Node.js and many outgoing http requests, dealing with HTTP - Keep-Alive is important. これは、agentkeepalive npm パッケージを使用して、コード内で簡単に処理することができます。You can use the agentkeepalive npm package to make it easier in your code.

ハンドラーで何もしない場合でも、http 応答を常に処理します。Always handle the http response, even if you do nothing in the handler. 応答を適切に処理しなかった場合、使用できるソケットがなくなるため、アプリケーションは最終的にスタックします。If you don't handle the response properly, your application gets stuck eventually because no more sockets are available.

http または https パッケージの処理例を次に示します。For example, when working with the http or https package:

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

複数のコアを備えた Linux コンピューターで App Service で実行している場合の別のベスト プラクティスは、PM2 を使用して複数の Node.js プロセスを開始して、アプリケーションを実行することです。If you are running on App Service on Linux on a machine with multiple cores, another best practice is to use PM2 to start multiple Node.js processes to execute your application. これは、コンテナーにスタートアップ コマンドを指定することによって実行できます。You can do it by specifying a startup command to your container.

4 つのインスタンスを開始する例を次に示します。For example, to start four instances:

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

アプリのバックアップが失敗するようになった場合When your app backup starts failing

アプリのバックアップが失敗する場合は、最も一般的な理由として、無効なストレージ設定と無効なデータベース構成の 2 つが考えられます。The two most common reasons why app backup fails are: invalid storage settings and invalid database configuration. 通常、このようなエラーはストレージまたはデータベースのリソースに変更が加えられた場合か、これらのリソースへのアクセス方法が変更された場合 (バックアップ設定で選択したデータベースに関して資格情報が更新された場合など) に発生します。These failures typically happen when there are changes to storage or database resources, or changes for how to access these resources (for example, credentials updated for the database selected in the backup settings). バックアップは、通常はスケジュールに応じて実行され、ストレージへのアクセス (バックアップしたファイルの出力用) とデータベースへのアクセス (バックアップに含まれる内容のコピーと読み取り用) が必要になります。Backups typically run on a schedule and require access to storage (for outputting the backed-up files) and databases (for copying and reading contents to be included in the backup). これらのリソースのいずれかにアクセスできないと、バックアップは常に失敗します。The result of failing to access either of these resources would be consistent backup failure.

バックアップ エラーが発生した場合は、最新のバックアップ結果を確認してどちらの種類のエラーが発生しているのかを把握します。When backup failures happen, review most recent results to understand which type of failure is happening. ストレージへのアクセス エラーが発生している場合は、バックアップ構成で使用しているストレージ設定を確認し、更新します。For storage access failures, review and update the storage settings used in the backup configuration. データベースへのアクセス エラーが発生している場合は、アプリ設定に含まれる接続文字列を確認し、更新してから、必要なデータベースが正しく含まれるようにバックアップ構成を更新します。For database access failures, review and update your connections strings as part of app settings; then proceed to update your backup configuration to properly include the required databases. アプリのバックアップについて詳しくは、Azure App Service での Web アプリのバックアップに関する記事をご覧ください。For more information on app backups, see Back up a web app in Azure App Service.

新しい Node.js アプリを Azure App Service にデプロイする場合When new Node.js apps are deployed to Azure App Service

Node.js アプリ向けの Azure App Service の既定の構成は、最も一般的なアプリのニーズに最も合うように設計されています。Azure App Service default configuration for Node.js apps is intended to best suit the needs of most common apps. Node.js アプリの構成で、パーソナライズされたチューニングの利点を活用してパフォーマンスの向上または CPU/メモリ/ネットワーク リソースのリソース使用量の最適化を行う場合には、「Azure Web Apps でのノード アプリケーションのベスト プラクティスとトラブルシューティング ガイド」をご覧ください。If configuration for your Node.js app would benefit from personalized tuning to improve performance or optimize resource usage for CPU/memory/network resources, see Best practices and troubleshooting guide for Node applications on Azure App Service. この記事では、Node.js アプリでの構成に必要となる可能性のある iisnode 設定について、また、アプリが直面する可能性のあるさまざまなシナリオや問題を説明し、これらの問題に対処する方法が示されています。This article describes the iisnode settings you may need to configure for your Node.js app, describes the various scenarios or issues that your app may be facing, and shows how to address these issues.