Freigeben über

Azure Storage の監視、診断、トラブルシューティング

  • Artikel

このポストは、9 月 25 日に投稿された Monitoring, Diagnosing and Troubleshooting Azure Storage の翻訳です。

最新のオンライン アプリケーションでは、従来のクライアント アプリケーションやサーバー アプリケーションと比べて、問題の診断やトラブルシューティングが難しくなっています。これには以下のような原因が考えられます。

  • PaaS や IaaS のインフラストラクチャ、オンプレミス、モバイル デバイス、またはこれらを組み合わせたものなど、コンポーネントで実行されるトポロジが複雑になっている
  • いつ接続されるかわからないデバイスなど、パブリック ネットワークとプライベート ネットワークを横断するネットワーク トラフィックが存在する
  • リレーショナル データベースなどのデータ格納方法の他に Microsoft Azure Storage の Table、BLOB、Queue、ファイルなどが追加され、ストレージ テクノロジが多様化している

Azure Storage サービスは、このような問題への対処に役立つ高度な機能を備えています。たとえば、アプリケーションが使用している Storage サービスを監視して予期しない動作 (応答時間が通常よりも長いなど) を検出する機能、および詳細なログ記録機能といったものが含まれており、この 2 つの機能はいずれも Storage Client Library で開発されたクライアント アプリケーションと Storage サービスの両方で使用できます。監視機能とログ記録機能の両方から得られる情報は、問題の診断とトラブルシューティングを実施して、それを修正する適切な手順を決定するために役立てられます。Storage サービスの監視機能とログ記録機能は運用パフォーマンスに影響を与えないように設計されており、さらに Storage の使用量管理の際に保持ポリシーを定義することもできます。

オンライン サービスの正常性を管理する方法については、「Microsoft Azure Storage の監視、診断、トラブルシューティング (英語)」の記事をご覧ください。この記事には、正常性、可用性、パフォーマンス、能力に関する問題の監視と診断についての規範的な説明、および開発チーム自身やサポート チームがお客様と共同で作業を行った際に直面した主な問題にすぐに適用可能なトラブルシューティングのヒントが含まれています。Azure Storage を基盤とするアプリケーションを開発している皆様はぜひこの記事をお読みください。以下は、アプリケーションのパフォーマンス管理方法についてを中心に説明しているセクションです。

サンプル シナリオ – アプリケーションのパフォーマンス低下を調査する

この記事の有用性を示すために、お客様からよく報告いただく一般的なシナリオとして、アプリケーションのパフォーマンスが通常より低下している場合を例にご説明します。お客様が監視に関する戦略をお持ちでない場合、この問題の根本原因の特定は困難で時間がかかります。

この記事の監視に関するセクション (英語) では、調査時に問題を把握するためのインジケーターとして使用する値の予想外の変化を発見するために、主要なメトリックのいくつかを継続的に取得および監視する方法を説明しています。このシナリオでは、特に AverageE2ELatency と AverageServerLatency の 2 つのメトリックに注目しています。AverageE2ELatency はエンドツーエンドのレイテンシの指標となる値で、要求を処理する時間の他にクライアントからサービスの要求を読み込み、クライアントに応答を返信する時間も含まれます (このため、要求が Storage サービスに到達した後のネットワーク レイテンシも含まれます)。AverageServerLatency は単純にサービスが処理に要した時間の指標となる値で、クライアントとの通信でのネットワーク レイテンシや、クライアント アプリケーションが送信/応答バッファーを貯めたり消費したりする時間は含まれません。

上図のようにポータルでメトリックのデータを見ると、AverageE2Elatency の値は AverageServerLatency よりもかなり大きいことがわかります。最初に、この 2 つをサービスを継続的に監視するための基準となるメトリックと比較します (まずはアプリケーションのパフォーマンス テストと運用環境への限定リリースでのみこれを適用します)。ここでは、このギャップが発生している原因は Azure Storage サービス以外にあると見なします。これについては、「トラブルシューティングのデシジョン ツリー (英語)」の「メトリックで AverageE2ELatency の値が高く AverageServerLatency の値が低い (英語)」セクションを参照してください。ここでは、他の原因について説明します。

  • クライアントのパフォーマンスの問題 - クライアントの応答が遅い場合に考えられる原因としては、使用可能な接続数やスレッド数が限られていること、または CPU、メモリ、ネットワークの帯域幅などのリソースが不十分であることなどが挙げられます。これは、Storage サービスへの非同期呼び出しを使用するなど、クライアントのコードを変更して効率を向上させるか、またはコア数とメモリ容量が多い、より大きなサイズの Virtual Machines を使用すると解決できます。詳細についてはこちらのセクション (英語) を参照してください。
  • ネットワークレイテンシの問題 - 通常、ネットワークによるエンドツーエンドのレイテンシの増大は一時的なものです。一時的か慢性的かにかかわらず、パケットの欠落などのネットワークに関する問題は、Wireshark や Microsoft Message Analyzer などのツールを使用すると調査できます。Wireshark でネットワークに関する問題のトラブルシューティングを実施する場合の詳細については、「付録 2: Wireshark でネットワーク トラフィックを取得する (英語)」を参照してください。Microsoft Message Analyzer でネットワークに関する問題のトラブルシューティングを実施する場合の詳細については、「付録 3: Microsoft Message Analyzer でネットワーク トラフィックを取得する (英語)」を参照してください。また、こちらのセクション (英語) の情報もご活用いただけます。

クライアントのパフォーマンスに関するセクションの内容を把握し、AverageE2ELatency と AverageServerLatency の差が Queue 処理の時にだけ発生し BLOB 処理の時には発生しないことを確認したら、次は Nagle アルゴリズムの記事を読み、これが小規模な要求に向いていないことを理解してください。適切なテストを行った結果、これは問題であることが判明し、Nagle アルゴリズムを無効にするようにコードを変更しました。その後再度 AverageE2ELatency の値を監視したところ、改善が見られました。

他に、応答時間の一時的な変動の原因としては、ネットワーク状態の悪化やサーバー側の不具合が考えられます。このどちらの場合でもクライアント アプリケーションは処理を再試行するため、それぞれの処理のレイテンシが長くなります。このような場合、AverageE2ELatency と AverageServerLatency の両方の値が低くなります。このような状況になったときは、「トラブルシューティングのデシジョン ツリー」の「メトリックで AverageE2ELatency と AverageServerLatency の両方が低い値を示しているがクライアントのレイテンシが長い (英語)」を参照してください。適切なトラブルシューティング手順が記載されています。また、「エンドツーエンドのトレース (英語)」セクションには、クライアントとサーバーの要求の関連付けがこの種の問題のトラブルシューティングに役立つということが記載されています。

このシナリオが積極的なサービスの監視が重要であることを理解するために、そして問題発生時に使用可能なツールがあることを知っていただくためにお役に立てば幸いです。

まとめと次のステップ

オンライン サービスの正常性を管理する方法をより深くご理解いただくために、マイクロソフトは「Microsoft Azure Storage の監視、診断、トラブルシューティング (英語)」記事をご用意しました。この記事には、正常性、可用性、パフォーマンス、能力に関する問題の監視と診断についての規範的な説明、および開発チーム自身やサポート チームがお客様と共同で作業を行った際に直面した主な問題にすぐに適用可能なトラブルシューティングのヒントが含まれています。

また、このコンテンツに関連するその他の記事、および新規/更新ドキュメントは次のとおりです。

次のステップとしては、下記の項目を実行することを推奨します。

  • メトリックス (英語) とログ記録 (英語) を運用環境のストレージ アカウントで有効化する。これは既定で無効になっています。
  • こちらの記事 (英語) の監視と診断に関するセクションを読み、管理ポリシーを更新する
  • 問題発生時にトラブルシューティングに利用するために、記事にブックマークを設定する

この記事が、オンライン サービス管理の大幅な省力化に貢献できますと幸いです。