次の方法で共有

Azure アプリ サービスのベスト プラクティス

  • [アーティクル]

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

併置

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

  • リソース間の通信における待機時間の増大
  • Azure の価格ページで説明されているように、リージョン間の送信データ転送に対する 料金

コロケーションは、ソリューションを構成する Azure リソースに最適です。 リソースを作成するときは、特定のビジネスまたは設計上の理由がない限り、リソースが同じ Azure リージョンにあることを確認します。 App Service プランで使用可能な App Service 複製機能を使用して、App Service アプリをデータベースと同じリージョンプレミアム移動できます。

証明書のピン留め

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

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

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

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

メモリ リソース

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

自動復旧機能のオプションの 1 つは、メモリのしきい値に基づいてカスタム アクションを実行することです。 アクションの範囲は、電子メール通知からメモリ ダンプによる調査、ワーカー プロセスのリサイクルによるその場での軽減までです。

CPU リソース

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

App Service のスケーリングと自動スケールのオプションの詳細については、「Azure アプリ Service でのアプリのスケールアップ」を参照してください。

ソケット リソース

送信 TCP 接続を使い果たす一般的な理由は、TCP 接続を再利用しないクライアント ライブラリ、または HTTP キープアライブなどの上位レベルのプロトコルを使用しないクライアント ライブラリの使用です。

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

Node.js と送信 HTTP 要求

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

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

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

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 アプリ Service でのアプリのバックアップと復元」を参照してください。

Node.js アプリ

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

IoT デバイス

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

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

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

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

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

次のステップ

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

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

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