クラウドで正常なアプリを実行するための究極のガイド (The Ultimate Guide to Running Healthy Apps in the Cloud)

Posted: 2020/06/07 in Uncategorized
Tags: , , , ,

The Ultimate Guide to Running Healthy Apps in the Cloud


Khaled Zayed 著

現代のデータセンターは、きわめて複雑で、多くの変動要素があります。VMは再起動や移動をする可能性があり、システムはアップグレードされ、ファイル サーバーはスケール アップ/ダウンされます。これらすべてのイベントは、クラウド環境では当然のものです。しかし、次のベスト プラクティスに従うことで、クラウド アプリケーションを、これらのイベントに対して回復性のあるものにすることができます。このドキュメントでは、アプリをクラウド対応にするために従うことのできる、13の重要な手順の概要を説明しています。これらの手順に従うことで、データセンターのあらゆるイベントが、アプリにほとんど影響を及ぼさないようにし、アプリをより回復性があり時代遅れにならないものにします。

前述の通り、インスタンスは再起動されるはずであり、実際に再起動されます。インスタンスはアップグレードされ、時にはファイル サーバーの移動に悩まされます。しかし、アプリを、これらすべてのインシデントに対して回復性のあるものにできます。アプリに対して最大のアップタイムを保証するためには、すべてのプラクティスに従ってください

  1. 複数インスタンスを使う
  2. 既定の設定を更新する
  3. 運用環境向けのハードウェアを使う
  4. デプロイ スロットを活用する
  5. 正常性チェック パスを設定する
  6. アプリケーション初期化を使用する
  7. ローカル キャッシュを有効化する
  8. 自動復旧
  9. App Serviceプランの密度を最小化する
  10. ディスク スペースの使用量を監視する
  11. Application Insightsを有効化する
  12. 複数リージョンにデプロイする
  13. App Service診断を確認する

複数インスタンスを使う

アプリを1つのVMインスタンス上だけで実行すると、即座に単一障害点 (SPOF) になります。アプリに複数インスタンスを割り当てるようにすることで、特定のインスタンスで問題が発生した場合でも、アプリは、依然として他のインスタンスに向かうリクエストに応答できます。アプリのコードが、データ ソースに対して読み書きする際に、同期の問題なしに複数インスタンスに対処できるべきであることを、覚えておいてください。[スケール アウト (App Service プラン)] ブレードを使って、アプリに複数インスタンスを割り当てられます。

複数インスタンス

単一障害点を回避するためには、少なくとも2-3インスタンスでアプリを実行してください。これは、(コールド スタートとして知られている) アプリの開始にかなりの時間がかかる場合に、特に重要です。1つ以上のインスタンスを実行することで、App Serviceが基になるVMインスタンスを移動、アップグレードした際に、アプリケーションの可用性を維持するようにします。また、次のような事前定義されたルールを基にして、自動的にスケール アウトするように、ルールを構成できます。

  • 時刻 (いつ、アプリが最も多くのトラフィックを処理するか)
  • リソース使用率 (CPU、メモリーなど)
  • 両方の組み合わせ!

さらに学ぶ

既定の設定を更新する

App Serviceには、開発者が自分のユース ケース向けにWebアプリを構成するための、多数の設定があります。常時接続 (Always On) は、過去20分間にリクエストを受信していない時でも、VMインスタンスを起動させたままにします。既定では、常時接続は無効化されています。常時接続を有効化すると、アプリケーションのコールド スタートが起こらなくなります。ARRアフィニティは、スティッキー セッションを作成し、クライアントは後続のリクエストで同じアプリ インスタンスに接続します。しかし、ARRアフィニティは、インスタンス間でリクエストの不均衡な分散を引き起こし、インスタンスの過負荷を引き起こす可能性があります。堅牢性を目指す運用環境のアプリでは、常時接続をオンに、ARRアフィニティをオフに設定することが推奨されています。ARRアフィニティの無効化は、アプリケーションがステートレスであるか、または、セッション状態がキャッシュやデータベースといったリモート サービスに格納されていることを前提としています。

Azure Portalの [構成] セクションの [全般設定] タブで、これらの設定を変更できます。

常時接続

さらに学ぶ

運用環境向けのハードウェアを使う

App Serviceは、異なるお客様のニーズに合う、多様な (SKUとしても知られる) ハードウェア レベルを提供しています。App Serviceプランを新規作成する際に、プランに対して異なるハードウェア レベルを選択するオプションがあります。

価格

App Serviceプランが運用環境で使われる場合、App Serviceプランが推奨される「運用」価格レベルの1つで動作するようにしてください。さらに、アプリケーションがリソース集中型の場合、アプリのニーズに従って、推奨される価格レベルの中から適切な価格レベルを選択するようにしてください。たとえば、アプリケーションが大量のCPUサイクルを消費する場合、S1価格レベルが高いCPU使用率を引き起こし、それがアプリのダウンタイムや遅延を引き起こす可能性があるので、S1価格レベルでの実行は理想的ではないでしょう。

さらに学ぶ

デプロイ スロットを活用する

新しいコードを運用環境にデプロイする前に、変更をテストするために、App Serviceのデプロイ スロット機能を活用できます。デプロイ スロットは、独自のホスト名を持つ動作中のアプリです。アプリの内容や構成要素は、運用スロットを含む2つのデプロイ スロット間でスワップ可能です。

アプリケーションの非運用スロットへのデプロイには、次の利点があります。

  • アプリの変更を運用スロットにスワップする前に、ステージング環境でアプリの変更を検証できます。
  • 最初にアプリをステージング スロットにデプロイし、それを運用スロットにスワップすることで、運用スロットにスワップする前に、ステージング スロットのすべてのインスタンスがウォーム アップされるようにします。これによって、アプリのデプロイ時にダウンタイムがなくなります。トラフィックのリダイレクトはシームレスであり、スワップ操作によって切断されるリクエストはありません。自動スワップを構成することで、このワークフロー全体を自動化できます。
  • スワップ後、これまでのステージング アプリを持っていたスロットが、これまでの運用アプリを持つようになります。運用スロットにスワップされた変更が、期待通りではなかった場合、「最新の既知の良好なサイト」に戻すために、即座にスワップを実行できます。

スロット

デプロイ スロットは、Standard、Premium、IsolatedのApp Serviceプラン レベルでのみ利用可能であることに、注意してください。

プレビューでのスワップ (Swap with Preview) を使うことを、強く推奨します。プレビューでのスワップによって、ステージング スロットのアプリを運用スロットの設定に対してテストし、また、アプリをウォーム アップすることができます。テストを行い、必要なすべてのパスをウォーム アップした後、スワップを完了できます。すると、アプリは、再起動なしに運用トラフィックを受信し始めます。これは、アプリの可用性とパフォーマンスに大きな影響を与えます。

さらに学ぶ

正常性チェック パスを設定する

App Serviceでは、アプリに対して正常性チェック パスを指定できます。プラットフォームは、アプリケーションが正常であり、リクエストに応答しているかどうかを判断するために、このパスにpingします。サイトが複数インスタンスにスケール アウトする際、App Serviceは、正常でないインスタンスをリクエスト処理から除外し、全体的な可用性を改善します。アプリの正常性チェック パスは、データベース、キャッシュ、メッセージング サービスといった、アプリケーションの重要なコンポーネントをポーリングすべきです。これによって、正常性チェック パスが返す状態が、アプリケーションの全体的な正常性を正確に表すものになります。

  1. Azure PortalのWebアプリ ブレードで、[開発ツール] > [リソース エクスプローラー] に進みます。

正常性チェック

  1. リソース エクスプローラー ページで、[config] セクションを開き、[web] タブをクリックします。名前が「healthCheckPath」、値が (我々のサービスがpingする) 正常性チェックURLの要素を追加します。

正常性チェック

(非常に強く推奨されている) 2つ以上のインスタンスがある場合にのみ、正常性チェック機能が動作することに、注意してください。単一インスタンスのWebアプリでは、たとえ単一インスタンスが問題に直面していたとしても、トラフィックは決してブロックされません。

さらに学ぶ

アプリケーション初期化を使用する

アプリケーション初期化によって、アプリ インスタンスがリクエストを処理し始める前に、完全に開始するようになります。サイトの再起動、自動スケール、手動スケールの際に、アプリケーション初期化が使われます。サイトのルート パスにアクセスするだけでは、アプリケーションの開始に十分ではない場合に、アプリケーション初期化は重要な機能となります。この目的のために、アプリで認証必要ないウォーム アップ パスを作成し、アプリケーション初期化がこのURLパスを使うように構成しなければなりません。

ウォーム アップURLが実装するメソッドが、すべての重要なルートにアクセスすることに対処し、ウォーム アップが完了した際にだけレスポンスを返すようにしてください。ウォーム アップURLがレスポンス (成功、または失敗) を返し、アプリケーション初期化が「アプリのすべてが問題ない」と見なした時にだけ、サイトが運用環境に置かれます。アプリケーション初期化は、アプリのweb.configファイルで構成できます。

さらに学ぶ

ローカル キャッシュを有効化する

この機能を有効化すると、サイト コンテンツを (サイト コンテンツが格納されている) Azure Storage からフェッチする代わりに、サイト コンテンツをローカルの仮想マシン インスタンスから読み書きします。これは、アプリのリサイクル回数を削減します。Azure Portalの [構成] > [アプリケーション設定] で、この機能を有効化できます。このページの [アプリケーション設定] セクションで、キーに「WEBSITE_LOCAL_CACHE_OPTION」、値に「Always」を追加します。また、キーに「WEBSITE_LOCAL_CACHE_SIZEINMB」を、値に最大2,000 MBの好みのローカル キャッシュ サイズ (未指定の場合、既定で300 MB) を追加します。特にサイト コンテンツが300 MB以上の際に、これは適切なキャッシュ サイズを提供するのに役立ちます。この機能を動作させるには、サイト コンテンツが2,000 MB以下となるようにしてください。また、これらの設定をスロット設定にして、スワップの際に削除されないようにすることは、優れたプラクティスです。ここで留意すべき最も重要なことは、アプリは、アプリのデータ/トランザクションの状態永続化のために、ローカル ディスクへの書き込みをすべきではない、ということです。ストレージの目的には、ストレージ コンテナー、データベース、Azure Cosmos DBといった外部ストレージを使うべきです。

ローカル キャッシュの動作は、使っている言語やCMSに依存することに、注意してください。最良の結果を得るには、我々は、アプリがローカル書き込みをしていない場合に限って、.NETや.NET Coreのアプリでローカル キャッシュを使うことを推奨しています。

ローカル キャッシュ

ローカル キャッシュ

さらに学ぶ

自動復旧

時には、アプリケーションが、単なる再起動で解決できる予期せぬ動作をする場合があります。自動復旧機能によって、まさにこれを行えます! この機能によって、自動復旧を引き起こす「条件」と、その条件が満たされた時に自動復旧が開始する「アクション」を定義できます。

[問題の診断と解決] セクション > [Diagnostic Tools] (診断ツール) タイルに進み、[Proactive tools] (プロアクティブ ツール) セクションの [Auto-Heal] (自動復旧) に進むことで、自動復旧緩和ルールを作成できます。

自動復旧

設定するフィルター値の例を示します。他のエラー コード値や頻度が自分のアプリケーションに合う場合、適宜修正してください。

条件
リクエスト数 70
状態コード 500
サブ状態コード 0
Win32状態コード 0
頻度 (秒) 60

この条件が満たされた際のアクションとして、次のアクションを構成することを推奨します。

  • プロセスのリサイクル

そして、[Override when Action executes] (いつアクションが実行されるかをオーバーライドする) を追加します。

  • 自動復旧が実行されるまでのプロセスの起動時間: 3600秒 (1時間)

さらに学ぶ

App Serviceプランの密度を最小化する

正常なパフォーマンスを保証するために、App Serviceプランで8個以上のアプリが実行されないようにしてください。Azure PortalのApp Serviceプランの [設定] セクションの [アプリ] で、App Serviceプランで実行されているすべてのアプリを確認できます。

App Serviceプランの密度についてさらに学ぶには、こちらを確認してください。

ディスク スペースの使用量を監視する

wwwフォルダーが使っているディスク スペースが、1 GB以下になるようにしてください。これは、アプリの再起動中のダウンタイムを削減し、アプリケーション パフォーマンスを改善するための、健全なプラクティスです。Azure Portalの [App Serviceプラン] > [クォータ] で、ファイル システム使用量を追跡できます。

ディスク使用量

Application Insightsを有効化する

Application Insightsは、アプリで発生したインシデントをトラブルシューティングする力を与える、一連の機能を提供します。コード エラーのデバッグ、依存関係によって引き起こされたパフォーマンス劣化の診断などを行うために、Application Insightsを使えます。

Application Insightsの強力な機能の1つは、Application Insights Profilerです。Application Insights Profilerを有効化すると、Azureの運用環境で動作しているアプリケーションのパフォーマンス トレースが提供されます。Profilerは、ユーザーに悪影響を与えることなく、自動的に大規模にデータをキャプチャします。Profilerは、Web リクエストの処理時に、最も長く時間のかかっている「ホット」コード パスを識別するのに役立ちます。Profilerは、.NETアプリケーションで動作します。Profilerを有効化するには、Azure PortalでApplication Insightsに進みます。[調査] > [パフォーマンス]をクリックします。

  1. [パフォーマンス] ペインで、「プロファイラーの構成」をクリックします。

Application Insights

  1. 表示されたペインで [今すぐプロファイル] をクリックし、プロファイルを開始します。

Application Insights

  1. Profilerの実行中、Profilerは、1時間に1回、2分間だけランダムにプロファイルします。アプリケーションが定常的にリクエストを処理している場合、Profilerは、1時間ごとにトレースをアップロードします。トレースを表示するには、[パフォーマンス] ペインで [アクションの実行] を選択し、[プロファイラー トレース] ボタンを選択します。

Application Insights

  1. Application Insightsでは、アプリケーションの依存関係を追跡できます。遅いリクエストをトラブルシューティングするために、この機能を活用できます。.NETコンソール アプリから依存関係を自動的に追跡するには、Nugetパッケージ「Microsoft.ApplicationInsights.DependencyCollector」をインストールし、「DependencyTrackingTelemetryModule」を次のように初期化します。
DependencyTrackingTelemetryModule depModule = new DependencyTrackingTelemetryModule();
depModule.Initialize(TelemetryConfiguration.Active);
  1. 各リクエスト イベントは、アプリがリクエストを処理している間の依存関係の呼び出し、例外、追跡されている他のイベントと関連付けられています。そのため、あるリクエストの結果がひどい場合、それが依存関係からの遅いレスポンスのためかどうか、確認できます。[パフォーマンス] ブレードの [依存関係] タブで、リクエストのウォーターフォール ビューを表示できます。

Application Insights

また、こちらで詳しく説明している、新たにリリースされたApplication InsightsのApp Service診断との統合を活用できます。

さらに学ぶ

複数リージョンにデプロイする

トラフィックがサイトにアクセスする前にトラフィックをインターセプトするために、Azure Front Door、またはAzure Traffic Managerをデプロイできます。これは、インスタンス/リージョン間でのトラフィックのルーティング/分散に役立ちます。Azure Front DoorやAzure Traffic Managerに投資することで、Azureデータセンターの1つで壊滅的なインシデントが発生した場合、引き続きアプリが実行され、リクエストを処理することを保証できます。

Azure Front DoorやAzure Traffic Managerを使うことには、ユーザーに最短の応答時間を提供するためのユーザーの地理を基にした受信リクエストのルーティング、インスタンスの1つをリクエストで過負荷しないためのインスタンス間の負荷分散といった、他の利点もあります。

さらに学ぶ

App Service診断を確認する

最後に、App Service診断で利用可能な「ベスト プラクティス」検出機能を活用することで、アプリを回復性のあるものにすることに関して達成した進捗を確認できます。

ベスト プラクティス

2つのオプションがあります。

  • 可用性とパフォーマンスのベスト プラクティス
  • 最適な構成のベスト プラクティス

これらの検出機能で一覧表示されるすべてのベスト プラクティスに従い、すべてを緑色 (訳注: ベスト プラクティスに対応済みであることの表示) にすることを推奨します!


最後に、アプリケーションの起動時間を最小化し、さらなる回復性のための推奨事項に従うために、「クラウド設計パターン」ドキュメントを見てみることも推奨します。

MSDNフォーラムで、自由にアプリの回復性に関する質問を投稿してください。

Comments
  1. […] translation – S/N Ratio (by SATO Naoki (Neo)) > クラウドで正常なアプリを実行するための究極のガイド (The Ultimate Guide to Running Healthy Apps in the Cloud)https://satonaoki.wordpress.com/2020/06/07/robust-apps-for-the-cloud/ […]

  2. […] クラウドで正常なアプリを実行するための究極のガイド (The Ultimate Guide to R… […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s