目次


スマーター・モニタリング: 継続的パフォーマンス・モニタリング手法

よりスマートにモニタリングする鍵は、テクノロジーそのものではなく、その使い方にあります!

Comments

サービス指向アーキテクチャーとクラウド・ベースのアーキテクチャーは、既存のサービスを再利用することを前提としています。これまでは 1 台のサーバー上で簡単に制御してモニタリングできたモノリシックなアプリケーションであったものが、今では複数のサーバーと簡単にはモニタリングできない外部サーバーからなる集合体に変わっています。システムやサービスごとの固有のファイルが、場合によっては複数のサーバー上にさまざまなフォーマットで配置されることもあります。このようにかなりの数にのぼるファイルを検索しなければならないとなると、エラーを報告した特定のクライアントのログを簡単に特定するのは不可能です。そこで、関連するすべてのログに迅速にアクセスできるように、共通の一元管理されたロギング・インフラストラクチャーにログを収集することが一般的な手法になっています。相関 ID を使用すれば、システム全体で個々の要求をトラッキングできるものの、この手法は一般的にはなっていません。けれども、相関 ID は、エラー状態とパフォーマンスの問題を分析するのに極めて役立ちます。

スマーター・モニタリング手法では、パフォーマンス上の問題の分析とその解決に役立つ以下の側面も考慮されています。

  • 相関 ID へのコンテキストの追加
  • パフォーマンス測定のパラメーター化
  • リソース割り振りの測定
  • あらゆる環境のあらゆるデプロイメントにおける「オールウェイズ・オン」のモニタリング
  • 改善点を開発にフィードバックするパフォーマンス・エンジニアリグの役割

以降のセクションで、スマーター・モニタリングの一般的手法について説明します。さらに、「従来型」のアーキテクチャー (例えば、リレーショナル・データベースを使用した JEE アプリケーションなど) を使用して、1 日あたり最大 5 億件のログ・エントリーを処理する際の実装手法についても説明します。

スマーター・モニタリング手法

スマーター・モニタリング手法は、技術的側面と運用に関する側面からなります。ベースとなる材料として、すべてのログがデータベースまたはデータ・ストアに収集されます。各ログ・エントリーの相関 ID により、要求ごとにログ・エントリーを関連付けできるようにします。パラメーター化したストップウォッチ・ログは、関連するパフォーマンス情報を提供します。運用プロセス内で、パフォーマンス・エンジニアがこれらの材料を使用して、さまざまなパフォーマンス特性を測定します。それによって得られた洞察が、開発に取り込まれます。

ベース: すべてのログを収集する

近頃のアプリケーションでは、すべてのログを共通の中央ロギング・インフラストラクチャーに収集する必要があります。運用チームが手作業でログ・ファイルを検索しなければならないようなアプリケーションは時代遅れであり、チームの労力を無駄にするだけです。

最近のソリューションでは、(おそらく複数の) サーバーや複数のコンピューティング・センター、さらには共有ドライブをまたがってさえ、ファイルをコピーしなくてもログを検索したり参照したりして、サポート・チームがアクセスできるようになっています。コピーするのではなく、UI を使用して必要に応じてログを照会し、フィルタリングできるので、該当するログの情報に迅速にアクセスすることができます。

コンテキストを追加した相関 ID

ログにアクセスすることは一面でしかありません。それよりも重要なのは、正しい情報を見つけることです。そのための最初のステップは、相関 ID によって個々の要求をシステム全体でトラッキングできるようにすることです。相関 ID は、一般にクライアント上またはサーバー上で生成されます。その相関 ID が、生成元のすべてのログ・ステートメントに挿入されます。相関 ID を他のサービスに渡せば、それらのサービスからのログも要求に関連付けることができます。

ただし、相関 ID は最初のステップにすぎません。スマーター・ロギング手法を可能にするには、相関 ID (および要求) をコンテキストに関連付ける必要があります。コンテキストとしては、以下の情報を使用できます。

  • 事例番号、サービス、処理名、または要求のシステムへの入り口になる層
  • 該当する場合は、要求のシステムへの入り口となるチャネル (バッチ、EJB、Web サービス呼び出しなど)
  • 要求のユーザー ID
  • テナント(該当する場合)

コンテキストには、変更できない部分と、要件に応じて変更できる部分があります。例えば、1 つのシステム内でテナントが変わることはありませんが、複数のテナントが相互に通信できるようにシステムが設定されている場合、要求によってそのテナントのコンテキストが変わることはあります。

相関 ID によってシステムおよびサービスを通して要求をトラッキングすれば、それだけで、要求の実行パスの定性分析を行うことが可能になります。1 つの要求に関するログ・ステートメントを調べるだけで、新しい発見があることもあります。特にコストのかかる複数の処理で、何度も繰り返される予想もしていなかったループを発見したときの驚きは格別です。本番システム内でのデータ群が期待していたものではないために要求が長期間実行され、それによってパフォーマンスの問題が発生している場合、通常はログ・ステートメントを調べるとそれがわかります。パフォーマンス測定と組み合わせて相関 ID を使用するとなると、相関 ID のコンテキストの重要性はさらに増してきます。それについて、次のセクションで説明します。

パラメーター化したパフォーマンス測定

ログは一般に、特定の時点で、システム内で進行中の状況に関する情報を書き出すために使用されます。ほとんどの場合、この書き出しは手作業でコード化されたログ・ステートメントによって行われます。スマーター手法では、ストップウォッチ・ログという自動的に生成されるログ・ステートメントを追加します。ストウォッチ・ログは、コードの特定のセクションに要求が入ってきた時刻と、そのセクションを実行するのに費やされた時間を記述するものです。ここで言う、「自動的に生成される」とは、ストップウォッチ・ログが実際のコードに挿入されることを意味する、「書き込み」を表します。コードへの挿入は、例えば EJB 呼び出しに関連付けたインターセプター内で行えるため、プログラマーはどのようにして挿入するのかを考える必要すらありません。

単純なストップウォッチ・ログに加え、ログ・エントリーにパラメーターを追加することもできます。パラメーターを追加すると、例えば実行時間を要求内で処理した項目数に関連付けることができます。つまり、システムのスケーリング動作を分析することになります。

このように、ストップウォッチ・ログにコンテキストを追加すれば、パフォーマンス上の問題を分析する際の強力なツールになります。このツールは、機能に関する問題を分析する場合にも役立ちます。

パフォーマンス統計

ストップウォッチ・ログは常時書き込まれるため、各ログの測定時点での統計を生成することができます。生成される統計には、以下の情報が含まれます。

  • 平均
  • 微分
  • 一定の期間での最小値と最大値

パーセンタイル分析を使用すると、アルゴリズムの効率性を分析することができます。一例として、私たちが使用しているアプリケーション内では、ドキュメントをインポートするために多数のバッチ・ジョブを夜間に並列実行しています。図 1 に、これらのバッチ・ジョブの実行時間の測定結果を示します (これらのジョブはバッググラウンドで実行されるため、実行時間は分単位で測定できます)。最大値が 5 分を超えることは決してありません。この状況はバッチ・ジョブでトランザクションがタイムアウトになったことを意味するため、調整が必要です。

パフォーマンス分析を示す図
パフォーマンス分析を示す図

すべての最大パーセンタイル値のピークが基本的に横並びになっている場合、パーセンタイル分析は、外れ値を識別するのに役立ちます。これらの外れ値の原因が、インフラストラクチャーの一時的中断にあることは珍しくありません。一時的中断は、多くの場合、データベースへの大規模な書き込み処理 (例えば、BLOB) やストレージ・サブシステムへのアクセスに関連します。したがって、外れ値は、ストレージ・サブシステムが同意済みの必要なサービス・レベルを提供していないことを示唆する可能性があります (サービス・レベル・アグリーメントが存在する場合)。

集約値が保存されていれば、分析対象の期間を長くして統計分析を行うことができます。例えば以下の図には、3 年間にわたる本番環境での 3 つの関数の平均実行時間が示されています。赤の線で表されている関数については、2012年8月のリリースでパフォーマンスが改善されてから、2013年12月のリリースにかけて段階的にパフォーマンスが向上し、最終的に 2014年の7月と8月のリリースで最適化手法の効果が現れています。それと同時に、私たちは青の線で表されている関数も最適化する必要がありました。外れ値は、通常はインフラストラクチャーに関する他の問題も示します。

数年にわたる平均実行時間の値を示す図
数年にわたる平均実行時間の値を示す図

スケーリング動作の測定

通常、ユーザーがシステムを使い始めてからとる行動は予想できません。エンド・ユーザーがデータ群のタイプやサイズ (例えば、ショッピング・カートに入っている商品の数や、DMS の場合にはフォルダーに入っているドキュメントの数) を完全に理解していないことはよくあります。パフォーマンス管理内で 1 つ以上の追加パラメーターを使用すれば、システムのスケーリング動作 (データ群の変化に対してシステムがどのように動作するか) を測定できるようになります。スケーリング動作を測定すると、特定の要求の処理にかかる時間が他の要求よりもなぜ長いのかを突き止められるだけでなく、データ・サイズの増加に対するシステムの動作を、ある程度、事前に予測することもできます。

図 3 に、稼働中のシステムを対象とした分析例を示します。左上のグラフには、パラメーターから引き出された未処理の実行時間がそのまま示されています。この例の場合、パラメーターは、その特定の対話操作内で処理されたドキュメントの数です。右上のグラフに示されているデータは左上のグラフと同じですが、それぞれの実行時間を処理されたドキュメントの数で割ってあります。それによって、一定の時間オフセット、そして処理されたドキュメントの数と比例して増加する要素がわかるので、データ・セットにサイズが大きくなった場合の対話操作にかかる時間を予測することができます。

下のグラフには、右上と同じデータが時間軸に沿った分布として表示されています。このグラフから、実行時間と他の負荷状況を相互に関連付けることができます。対話操作には (おそらく、機能要件に応じて) 2 つのタイプがあり、それぞれに所要時間が異なることに注意してください。一方のタイプは、ドキュメントあたり 500 ミリ秒で実行可能であり、もう一方のタイプは実行するのに少なくとも 800 ミリ秒はかかると思われます。

パラメーター化したログを使用したスケーリング動作の測定を示す図
パラメーター化したログを使用したスケーリング動作の測定を示す図

リソース割り振りの測定

要求が実行された時刻だけではなく、実行にかかった実際の所要時間がわかれば、詳細なリソース割り振りを測定できます。特定の時点で実行中のすべての要求の所要時間を重ねると、システム内でどれだけの数の要求が実行されているかを判断することができます。システム上のユーザー数を把握するのが難しいことはよくあります。要求エンジニアリングの際にユーザー数が概算されるものの、結局は予測するのが困難になります。それは、デプロイメント時の設計の変更によって、対話操作ごとのサーバー呼び出しの数などが変わるためです。スマーター・モニタリング手法を適用すれば、並列度を簡単に測定できます。

図 4 に、バッチ・フレームワーク内での測定例を示します (56、57 ~ 60 の番号は、バッチの各タイプを示します)。問題となっていたのは、特定の並列度を達成するようにバッチ・フレームワークを構成することです。スマーター・モニタリングによる測定でなければ、その特定の並列度を達成しているかどうかを判断できませんでした。実際、構成済みの並列度をシステムで達成できなくしていたアプリケーション・サーバーの構成問題を識別できました。ある事例では、JEE アプリケーションあたりのスレッド数の構成が問題であり、別の事例では、アプリケーション・サーバーのワークロード・バランシングの設定が問題でした。

並列度を示す図
並列度を示す図

その他の分析タイプには、以下があります。

  • 送信の所要時間の分析: 非同期システム内でメッセージを受信するまでにかかる時間、リソース枯渇の兆候 (予想外の待機時間など) があるかどうかを分析します。
  • ワークロード分析: 複数のサーバーにワークロードが均等に (あるいは少なくとも意図通りに) 配分されているかどうかを分析します。
  • ネットワーク・レイテンシー分析: あるシステム上で要求が送信された時点のストップウォッチ・ログと、同じ要求 (相関 ID) を別のシステムで受信した時点のストップウォッチ・ログがあれば、2 つのシステム間のネットワーク・レイテンシーを測定できます。

オールウェイズ・オンのパフォーマンス・エンジニアリング

多くの場合、パフォーマンス分析ツールはアプリケーションから切り離されています。つまり、パフォーマンスに関する問題が発生した場合は、おそらく本番環境とは別のテスト環境内でツールをセットアップしなければならないことを意味します。さらに、問題を再現しなければなりませんが、それが上手く行かないことは度々あります。

スマーター・モニタリング・ソリューションの重要な側面の 1 つは、オールウェイズ・オンであることです。このソリューションはシステムの一部として統合されます。私たちが利用している環境では、開発環境内でさえ、開発者がログ・ステートメントを収集するログ・サーバーを有効にできるようになっています。なぜなら、デプロイメントのそれぞれにロギングおよびモニタリング・インフラストラクチャーを含めているからです。有効なスマーター・モニタリング・ソリューションは、デプロイメントの品質ゲートとなります。このソリューションによって、あらゆる環境内でデプロイメントごとのログを分析できるようになります。

Smarter Monitoring の別の重要な側面として、問題を再現して分析できるようにするためのアクティビティーが別途必要になることはありません。各デプロイメントが、必要なステップを行うトレーニングとなり、デプロイメント・チームがデプロイメントのエラーや機能しないデプロイメントを回避できるようになります。

私たちのプロジェクト内では、開発チームとテスト・チームがスマーター・モニタリング手法に従って、パフォーマンスや機能に関する問題を分析しています。スマーター・モニタリングは、品質管理プロセスに欠かせない貴重なツールです。

パフォーマンス・アーキテクトの役割

スマーター・モニタリングがかけがえのないツールとなるわけは、このソリューションが「オールウェイズ・オン」であるためです。スマーター・モニタリングによって、問題を分析する労力は激減しています。

スマーター・モニタリング・ソリューションはあらゆる環境内で利用できるため、開発のあらゆる段階で問題を調査する際に手軽に使用できます。パフォーマンス・アーキテクトとは、私たちがパフォーマンス上の問題を調査するために設けた役割です。パフォーマンス・アーキテクトは本番環境内のパフォーマンス上の問題だけでなく、負荷テストでのパフォーマンスも調査し、開発チームをサポートしてパフォーマンス最適化に関するアドバイスを提供します。実際の設計および開発に取り掛かる前に、パフォーマンス・アーキテクトがプロジェクトや変更リクエストに関わることは必須です。早期から関与することで、パフォーマンス・アーキテクトはパラメーター化されたパフォーマンス・ログから収集した情報を基に、パフォーマンスに不可欠の変更や使用事例を特定することができます。また、パフォーマンス・リスクも早い段階で識別されて、迅速かつ効率的にリスクが軽減されます。

実装に関する考慮事項

スマーター・モニタリング・ソリューションは、さまざまなテクノロジーをベースに実装することができます。実際、このソリューションはテクノロジーにとらわれません。ただし、どのように実装する場合でも、共通の考慮事項があります。

データ・サイズの影響

スマーター・モニタリング・ソリューションによって生成される大量のログを保管することが課題となることが考えられます。私たちの現在の実装内では、ピーク時間のスループットを高くして、1 日あたり最大 5 億件のエントリーをパフォーマンス・ログに記録しています。この大量のデータに関する要件は以下のとおりです。

  • ストレージ・サブシステムは、必要な時間枠内で大量のデータ書き込みに対応できるものでなければなりません。
  • ログ・データベースまたはストレージ (リレーショナルまたは NoSQL) は、この大量のデータを管理できるものでなければなりません。
  • ストレージ・システムは、大量のデータを保管可能でなければなりません。
  • 古くなったデータを集約し、必要に応じて削除する必要があります。

非同期ロギング

多くの場合、標準的なロギング・フレームワーク内でのログ・ファイルの書き込みは同期で行われます。ログを同期で書き込むと、アプリケーションはロギングおよびモニタリング・インフラストラクチャーのスループットの問題に影響されやすくなります。

したがって、ログを同期で書き込むのではなく、ログ・エントリーを 1 つのバッチに収集し、非同期で書き込むようにしてください。ロギング・インフラストラクチャー自体のパフォーマンス上の問題を軽減するには、あまり重要ではないログ・エントリーを破棄して、アプリケーション自体がスローダウンしないようにします。

私たちのアプリケーション内では、ログ・エントリーを特定のログ・アペンダー (log4 の用語) に渡し、このアペンダーによって、ログ・エントリーをバッチに収集してから単一の要求内でログ・ストレージに非同期で転送しています。アペンダーは特定の量のログをメモリーにバッファリングします。ログの数がデータベースに書き込める量を超えたことを検出すると、ログをドロップして特定のログ警告メッセージを追加します。このようにすると、警告されている状況を調査できる一方で、実際の本番システムがスローダウンすることはありません。

注意点

ストップウォッチ・ログを扱うようになった頃、私たちはシステムに関して測定して調べられる内容に興奮しました。そこで、多数のストップウォッチ・ログを追加したのですが、あまりにも多く追加したため、ロギング・インフラストラクチャーがロギングを扱いきれなくなり、アプリケーションの速度が低下する結果になりました。そこから学んだ教訓として、ストップウォッチ・ログのエントリーは主にコンポーネントの境界が交差するところに制限することにしました。このようにすれば、パフォーマンス上の問題の原因となっているコンポーネントを識別することができます。必要不可欠なストップウォッチ・ログは、システムへの要求の入り口またはシステム内に要求が存在する部分のログです。このように制限したとしても、ストップウォッチ・ログは通常のログよりも 10 倍多くのスペースを占めます。

実際の問題が存在しないとしても、システムを理解しようとして、システムの動作を過剰に深く掘り下げたくなるものですが、実際の問題に集中するようにしてください。例えば、このチュートリアルに図を記載したシステムには、線形ではないものの、データ・セットのサイズが大きくなると処理時間が急激に増加する対話操作が 1 つあります。ただし、対話操作自体の所要時間は短いため (最長で 100 ミリ秒)、データ・セットのサイズを制限して見積もっています。アルゴリズムを調査して修正しようという気になりますが、今のところ、それは無駄な取り組みです。

事例研究: 大規模な DMS プロジェクト

この事例研究から、選り抜きの実装手法が明らかになります。

ドイツの大規模な公営企業のクライアントが、電子ドキュメント管理システム (DMS) プロジェクト内でスマーター・モニタリング・ソリューションを実装しました。このクライアントは、スマーター・モニタリング・ソリューションを利用して、パフォーマンス要件を満たし、その状態を維持しています。このソリューションは、ドキュメントのインポート時に必要なパフォーマンス改善を加える際にも役立ちました。新しい要件により、毎晩インポートするドキュメントの数を 5 倍に増やさなければならなくなったのです。スマーター・モニタリングによるシステム分析のおかげで、この目標を達成することができました。

あらゆるパフォーマンス上の問題 (そして多くの場合、他の機能に関する問題も) についての迅速な分析とフィードバックを可能にするためには、スマーター・モニタリング・インフラストラクチャーを標準的なデプロイメントに組み込んで、すべての環境をまたがって使用できるようにすることが重要でした。

ソリューション

以下の図に、当初のソリューションを示します。

スマーター・モニタリングの概要を示す図
スマーター・モニタリングの概要を示す図

ユーザーがシステムを対話操作するたびに、固有の ID が作成されて、要求と一緒にその ID がシステムを通過します。クライアントからのログ、100 台を超えるアプリケーション・エンジン・サーバーからのログ、そしてローカル・バックエンド・サーバーからのログは、リレーショナル・データベースに収集されます。ユーザーが自主的にデータ・プライバシーの規約を受け入れた場合にのみ、Java ベースのクライアントがそのログをサーバーにアップロードします。サーバー・ログは log4j ログ・サーバーを介して書き込まれてから、非同期でリレーショナル・データベースに書き込まれます。

JMX クライアントから収集されるメトリックによって、パフォーマンス・データはインフラストラクチャーの正常性に関する情報で増補されます。その上で、UI をモニタリングすれば、パフォーマンス・データを照会して分析することができます。各ログ・エントリーには、インフラストラクチャーに関する情報 (発信元のサーバーの名前やロガーの名前など) が含まれます。さらに、テナント、要求の送信元、ユーザー ID などのコンテキスト情報も含まれます。

UI を使用して (例えば相関 ID を基準に) フィルタリング済みのログをエクスポートできるため、運用チームは開発チームにフィルタリングしたログを渡して、さらに分析および調査を進めることができます。この手法では、1 日当たり最大 5 億件のログ・エントリーの約 70 GB のデータをロギング・データベースに記録できます。

スマーター・モニタリング・アプリケーションに含まれている、将来再考する可能性のあるアーキテクチャー上の決定事項には、以下のようなものがあります。

  • アプリケーションを実際のログ書き込みから分離する、ログ・サーバーの使用。アペンダーを直接アプリケーション・サーバーのログ・インフラストラクチャーに統合するという方法が考えられます。
  • ログ・サーバー内での JDBC アペンダーの使用。クラウド環境内では、HTTPS アップローダーを使用するほうが実際的でしょう。
  • 標準的なリレーショナル・データベースを使用したのは、利用可能なスキルセットとツールが理由となっています。当時は、NoSQL データベースもインメモリー・データベースも使用できませんでした。

必要なインフラストラクチャーは使用するツールに大きく依存するため、テクノロジーに関する決定は慎重に行わなければなりません。私たちは単一の大規模なデータベースを使用していますが、「How do you scale a logging infrastructure to accept a billion messages a day?」で紹介されている別の NoSQL ソリューションを使用する場合、私たちのソリューションに比べ、2 倍の量のログをモニタリングするためだけでも多数のサーバーが必要になります。

まとめ

スマーター・モニタリング手法は、テクノロジーに依存しない貴重なパフォーマンス・モニタリング手法です。この手法では以下のように、さまざまな機能を独特の方法で組み合わせています。

  • 相関 ID を使用して、マイクロサービスを含むシステム内で要求をトラッキングします。
  • さまざまなサービスからのログを収集し、中央のログ・データベース内に集約します。
  • コンテキスト対応のパラメーター化したパフォーマンス・ログにより、詳細なパフォーマンス分析とスケーリング動作の調査を可能にします。
  • 並列度の測定により、リソースの使用状況をトラッキングできます。
  • テスト環境内でも本番環境内でも、最初から完全なパフォーマンス・メトリックを提供します。
  • パフォーマンス・アーキテクトが、開発チームに洞察をフィードバックします。

私たちの最初の実装では、JEE 環境と Intel アーキテクチャー上のリレーショナル・データベースからなる分散環境を使用しましたが、System p や System z などの他の環境に実装することもできます。

この結合手法を使用するプロジェクトは、ますます加速化する最近の開発サイクルに不可欠なパフォーマンスおよびスケーラビリティーの要件を常に満たすことができます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=1039679
ArticleTitle=スマーター・モニタリング: 継続的パフォーマンス・モニタリング手法
publish-date=11172016