Share via

サービスの監視と診断の重要性

  • Article

このポストは、4 月 27 日に投稿された Service Monitoring and Diagnostics の翻訳です。

企業の多くは、業務にソフトウェアを利用しています。そしてこのソフトウェアこそが、業務の推進力となっています。企業の良し悪しは、そのシステムを形成するコードに左右されるといっても過言ではありません。それは銀行であっても、町の本屋であっても同じことです。システムがダウンしたり、パフォーマンスが低下すれば、損失はそのときだけでなく、顧客を失うなど先々にまで影響が及ぶことになります。顧客が Web サイトを利用しているときに問題が発生したら、企業はそのことを即座に把握し、他の大勢の顧客が気付く前に原因を特定して問題を修正する必要があります。

これは、単なる可用性だけの問題ではありません。確かに、サイトのダウンは非常に深刻な問題で、SLA では一般的に 99.999% の可用性 (英語) が要求されます。しかし、応答性も問題になります。Amazon では 1 秒間のパフォーマンス低下で 16 億ドルの損失が発生し、Google では 0.4 秒のパフォーマンス低下で 800 万回のクエリを損失するというある調査結果 (英語) が出ています。こうしたサイトでは、データセンターの冗長性確保、コンテンツ配信ネットワーク、非同期レンダリングといったあらゆる戦略を駆使して、高レベルの応答性維持に努めています。

メトリックを高レベルに維持するためには、常時計測することが必要になります。その鍵となるのがテレメトリです。テレメトリとはアプリのパフォーマンスに関するデータを収集したもので、分析ツールによってアプリの実行状況やユーザーによるアプリの利用方法がさまざまな種類の図表で示されます。これを利用することで、特定のインシデントを詳細に調査することが可能になります。また、アラートを設定すれば、アプリが大量の例外をスローした場合や実行速度が低下した場合、存在が確認できなくなった場合などにすぐに対処することもできます。

通常の CRUD (英語) アプリケーションの監視には、主に次の 2 種類のシナリオがあります。

可用性

  • 稼働状況 : 顧客がサービスにアクセスできない場合、企業はすぐに対処する必要があります。
  • 信頼性 : パイプラインの中でデータ損失がないかを確認します。

可用性は公開されている SLA に影響し、エンド ユーザーのエクスペリエンスに影響します。そして、「代金をちゃんと支払っているのにシステムがダウンした。支払った代金はどうなるのか?」、「システムがダウンしていてチケットが取れない」などのクレームにつながります。

パフォーマンス

  • 応答性 : ユーザーがサイトを使用 (検索、読み込み) できるようになるまでに要した時間を確認します。
  • レイテンシ : ユーザーの要求からデータの処理や格納 (作成、更新、削除) までのラウンド トリップの長さを確認します。

通常、パフォーマンスは運用レベル アグリーメントに影響します。たとえば、データ アクセス レイヤー チームがクエリの 99% で 1 秒未満の応答時間を保証する、というような内容です。

ここからは、検出、トリアージ、診断という 3 つのプロセス フローの観点から、テレメトリの使用方法について説明します。

検出

問題の検出を完全に自動化することは難しく、人手に頼らざるを得ない部分があります。通常はライブ サイト インシデント (LSI) の 80% を自動検出することが目標となりますが、残りの 20% については、データの分析や顧客からのフィードバックによって自ら検出する必要があります。

自動検出は、製品や企業が成熟するにつれて進化します。

  • サイトの可用性: 世界中の拠点から一定間隔で企業のサイトに対して ping テストが実行され、応答時間、リターン コード、場合によってはいくつかのコンテンツを評価します。このテストが 3 回連続で失敗すると、何らかの深刻な事態が発生していることが考えられます。
  • リソースの可用性: 緻密な Web テストを実施し、商品を選択して購入する直前までの手順など、主なユーザー ストーリーにおける操作をシミュレートします。このテストでは、バックエンド サービスが実行されているかどうかを確認できます。しかし、実際のデータに影響を与えることは避けなければならないため、すべてをテストすることはできません。
  • ユーザーの可用性: 実際のユーザーからの要求に対する応答時間とエラー発生率は、サーバー アプリケーションおよびクライアント アプリケーションのインストルメンテーションの補助を利用して計測されます。これは実際のユーザー エクスペリエンスのインジケーターとして非常に有効ですが、結果の評価は慎重に行う必要があります。すべての HTTP 要求のうち 1% でエラーが発生しただけならそれほど悪くないように感じられるかもしれませんが、そのエラーが発生した場所が支払いを実行するボタンだったとしたら大きな問題です。

自動化の目標は 80% ですが、それを実現するには先にやらなければならないことがあります。まずは手動でテレメトリ データを把握し、高負荷時の応答時間の変化、例外の発生頻度、特に処理が遅い要求やエラーが発生しやすい要求の種類など、自社システムの通常の動作をよく知ることが重要です。この間に、管理者は異常時の動作がどのようなものであるかを把握することになります。また、ライブ サイト インシデント発生時に変化したメトリックを分析すると、パターンの認識を自動化する方法、および将来発生することが予測される種類の問題の検出方法について理解することができます。

トリアージ

LSI の症状には、タイルの読み込みの遅延から完全なサービス停止までさまざまなものがあります。トリアージは、まず事態の深刻さを把握することから始まります。すべてのユーザーがホーム ページをまったく表示することができない場合は、障害が発生していると言えます。また、一部のユーザーが「最近表示した商品」を表示できない場合は、不具合が起きていることが考えられます。問題の規模が判明したら、その修正に投入するリソースを決定します。トリアージを早期に実行することは、運用コストの削減に大きく貢献します。このために必要なのは、どれだけの顧客がすべての主要なビジネス シナリオを完全に実現できなかったかを把握することです。ユーザーの可用性レベルで自動化を進めることは、影響を受けたユーザーの数を把握するうえでのインストルメンテーションとなります。

LSI を自動検出する機能には重要度スコアをあらかじめ割り当てておくことが可能で、このスコアはその後 DevOps チームの調査に使用されます。顧客への影響の大きさは、エラーが発生した要求に関連しているユニーク ユーザー数により決定されます。

ログイン中のユーザーにシステムがサービスを提供している場合、ログを分析すると、特定の問題の影響を受けたユーザーを特定し、そのユーザーと緊密なコミュニケーション経路を維持することができます。これにより、他の全ユーザーに問題が拡大することを防止できます。ユーザーの多くは、バグがまったく存在しないサービスを提供するよりも、問題発生時に適切なコミュニケーションを取ることができるという点を高く評価します。

診断

ここからは原因の特定に入ります。診断は、不具合を修正することとは異なります。問題の発生原因は、コードの欠陥以外にも、構成上の問題、ストレージやその他のリソースによるもの、使用しているサービスに由来するものなどが考えられます。

そのため、問題がどこで発生したのかを特定する必要があります。たとえば、フロントエンド開発者からは注文がキューに入ったという報告があり、別の開発者からは注文が正常に処理されたという報告があったとします。しかし、顧客の注文が受注されなければ、どこかで何らかの問題が発生していると考えられます。

この場合、通信境界上の正確なテレメトリ データを把握し、どの部分でさらに詳しい調査を行う必要があるかを特定することが重要です。

この問題の発生場所を特定するには、テレメトリを使用するのが効率的です。

  • 要求の監視 : 要求数やエラー応答数のカウント、応答時間の測定を行います。要求の頻度が高くなると急激に応答時間が長くなることがありますが、その場合はメモリなどのリソースの問題が考えられます。
  • 処理能力 : パフォーマンス カウンターがメモリの使用量、I/O レート、CPU 使用率を測定するため、リソースの使用状況を直接把握できます。
  • 依存性の監視 : 外部サービス (データベースや REST サービスなど) の呼び出し数をカウントし、それぞれの呼び出しの成否と応答に要した時間のログを記録します。たとえば、ある要求のサービスに 4.2 秒の時間を要し、そのうちの 4 秒がウェアハウス サーバーで経過している場合、その場所で問題が発生していると考えられます。
  • トレースしたイベントのログ記録 : これは、プロセス内の重要なポイントを記録するため、そして、内部インターフェイスの問題をトレースするために特に重要です。あるユーザーの注文が受注されなかった場合、その原因がフロントエンドとバックエンドのどちらにあるかを切り分けます。
  • デプロイメントの記録 : 突然問題が発生したときに、それに関連するシステムの更新に役立ちます。

 

診断の役割は、問題の原因を特定することにあります。問題の原因がコードの欠陥であれば、修正、テスト、リリースを即座に実施する必要があり、リソースの問題であれば、スケールアップで解決できる可能性があります。あるいは、外部サービスの問題であると特定できるかも知れません。

まとめ

絶えず状況が変化するサービスを常に正常に運用することは、やりがいはありますが、とても難しいタスクでもあります。適切に対処するには、極力無駄を省き、応答性を高めるためのプロセスの規範とツールが必要です。企業は、継続的にデプロイメントを実施したり、A/B テストやその他のアジャイルな手法を採用したりするうちに、アプリケーションのライフサイクル管理とパフォーマンス管理の両方の規範を持つ 1 つのソリューションが必要であることに気付き、継続的に DevOps プロセスに組み込むことの重要性を意識することになります。

マイクロソフトは、APM テレメトリの統合を支援するサービスを提供しており、開発サイクルの初期段階では、.NET/Java/Node.JS/Python/Ruby/PHP/ObjectiveC 向け (英語) の IDE (Visual Studio、Eclipse (英語)、xCode (英語)、Android Studio (英語) など) でご利用いただけます。また、その後も Azure プラットフォーム (Azure Websites、Virtual Machines (英語)、Mobile Services、Cloud Services の各サービス) から監視 (Application Insights) までの各段階で利用可能です。

参考情報 : 分散型システムの監視については Netflix のブログ記事 (英語) を、サービス品質の監視については Brian Harry のブログ記事 (英語) を併せてお読みください。