モダンな Monitoring インフラストラクチャの ...€¦ · クラウドコンピューティングのインスタンスは、わずか数時間や数日間実行されただけで破棄されることも多く、コンテナに至っては利用

Monitoring Modern InfrastructureJohn Matson K Young

“Measure what is measurable, and make measurable what is not so.”

— Galileo

モダンなインフラストラクチャの監視John Matson K Young

「測定できるものは測定し、できないものはできるようにせよ」

— ガリレオ

モダンなインフラストラクチャの監視John Matson K Young

「測定できるものは測定し、できないものはできるようにせよ」

— ガリレオ

著者について

John Matson は Datadog の技術研究者、著者、編集者であり、監視や可観測性について執筆しています。Datadog に入社する前は、科学雑誌「サイエンティフィック・アメリカン」の編集者として、天文学、惑星科学、および物理学についての記事を執筆していました。カリフォルニア州ネバダシティで家族と一緒に暮らしています。

K Young は、Datadog の戦略的イニシアチブ担当ディレクターです。前職は、ソフトウェアアーキテクトであり、Datadog が 2015 年に買収した Mortar Data 社の共同創設者兼 CEO でした。彼は妻と 2 人の子供と一緒にマンハッタンで暮らしています。

目次クラウド環境の監視

第 1 章：絶えざる変化 1

第 2 章：優れたデータを収集せよ 6

第 3 章：本当に重要な問題についてアラートを発行する 14

第 4 章：パフォーマンス問題の調査 20

第 5 章：時系列グラフによるメトリクスの可視化 24

第 6 章：サマリーグラフによるメトリクスの視覚化 34

第 7 章：あらゆる情報を一元化する：ELB の監視方法 43

第 8 章：あらゆる情報を一元化する：Docker の監視 54

第 9 章： Datadog は、動的でクラウドスケールの監視ソリューション 73

1

第 1 章絶えざる変化

第 1 章：絶えざる変化

この数年間で、IT インフラストラクチャの性格は劇的に変化しました。多くの組織が、従来型のデータセンターを使用しなくなり、パブリッククラウドとプライベートクラウドのインフラストラクチャによってもたらされる俊敏性とスケーラビリティを活用するようになりました。新しい組織にとって、クラウド向けにアプリケーションを設計することが当然になっています。

クラウドにより、インフラストラクチャを迅速に利用するための障害となっていた物流的および経済的な障壁が崩れ去りました。あらゆる組織や個人が、世界有数の大企業が利用しているのと同じテクノロジを利用できるようになりました。

クラウドへの移行は、運用についても根本的な変化をもたらしました。現在はインフラストラクチャが動的で絶えず変化する時代であり、監視についても新しいツールや手法が求められています。

2


インスタンス、コンテナ、

マイクロサービスなど

10

回以上

ツールの数

人

インフラストラクチャユニットの数

変更頻度

使用されるツールとサービスの数関係するエンジニア数

1 日に 1 回

多くの OSS と SAAS

DEV ＋ OPS

1 年に 1 回

いくつかのベンダーの総合製品

=> 大規模な監視の必要性

OPS のみ

時間時間

時間時間

本書では、現在の複雑で動的なインフラストラクチャとアプリケーションを監視するための効果的なフレームワークについて概説します。現在の監視に求められるフレームワークについて説明した後には、監視における重要な要素であるメトリクスのグラフ化と視覚化について詳しく説明します。最後に、これらの監視方法が、広く利用されている Amazon ELB（Elastic Load Balancing）と Docker の 2 つのインフラストラクチャテクノロジにどのように適用されるのか説明し、これらの概念を説明します。

弾力的、動的、そしてエフェメラル（短命）になるインフラストラクチャ開発者やシステム管理者は、コンピュートインスタンスからマネージドデータベースやその他の高価値のホスティングサービスまで、ほぼ無限のクラウドリソースをオンデマンドですばやく利用できるようになりました。

多くの場合、自動スケーリング機能により、ニーズの変化に合わせて、インフラストラクチャを拡張または縮小でき、新しいリソースをプロビジョニングする場合に手動で介入する必要もありません。自動スケーリングは、Amazon の EC2 などのクラウドサービスや Kubernetes などのコンテナオーケストレーションツールにとって重要な機能です。

現在のインフラストラクチャは弾力的であり、個々のコンポーネントが利用される期間はエフェメラル（短命）になっています。クラウドコンピューティングのインスタンスは、わずか数時間や数日間実行されただけで破棄されることも多く、コンテナに至っては利用期間が数分または数時間単位で計測されるほど短命である場合も多くあります。コンテナ環境への移行は、動的と短命という傾向をさらに強める結果になっています。

3


ペットと家畜の違い動的なインフラストラクチャでは、個別のサーバーに着目してもあまり意味はありません。各コンピュートインスタンスやコンテナは、大規模なサービスをサポートする機能を実行するための単なる交換可能な歯車に過ぎません。

動的なインフラストラクチャを考えるときに役立つ比喩は、「ペットと家畜です」。ペットは特別な存在であり、名前があり、飼い主は健康と幸せについて気遣います。一方、家畜に付けられるのは名前ではなく番号です。家畜は群れの一部です。群れを構成する個体は出入りしますので、個体よりも群れ全体の健康が重要になります。

通常、サーバー、コンテナ、その他のインフラストラクチャのコンポーネントは家畜として考える必要があります。つまり、ホストの個別のデータポイントではなく、サービスの全体的なヘルスとパフォーマンスに注目する必要があります。CPU 使用率の上昇などのホストレベルの問題について、エンジニアに電話で深夜に問い合わせるべきではありません。一方、Web アプリケーションのレイテンシが急増し始めた場合は、迅速な対処が必要となります。

DevOps

クラウドおよびコンテナテクノロジにより、基盤となるインフラストラクチャのカタチが大きく変わり、ソフトウェアの開発と運用も同じように一層動的になりました。

「DevOps」では、開発チームと運用チーム間の緊密なコラボレーションが非常に重要になり、開発、展開、運用の段階を通じて両方のチームがサービスに携わります。DevOps では、ソフトウェアを効率的かつ安全にテスト、展開、および管理できように、コミュニケーション、コラボレーション、再現性、および自動化に重点が置かれます。

継続的デリバリ継続的デリバリは、多くの DevOps のアプローチの礎石です。大規模で不定期なリリースをオーケストレーションするのではなく、継続的デリバリを実践しているチームは、迅速かつ頻繁に小規模なコードを追加および変更しています。これにより、変更内容を簡単かつ自動的にテストできるようになり、開発チームはバグ修正や新機能を早くリリースできます。また、本番環境で予期しない問題を引き起こすような変更があった場合、エンジニアは迅速にロールバックできます。

可観測性制御理論における「可観測性」とは、外部出力を使用してシステム内部の状態を記述または再現できる特性を意味します。実際、企業や組織のインフラストラクチャに対する可観測性とは、すべてのコンピュートリソース、アプリ、およびサービスのコンポーネントのメトリクスを正確に報告するセンサーを使用し、これらのすべてのコンポーネントを測定することを意味します。また、簡単にアクセスできる中央のプラットフォームでこれらのメトリクスを利用できるようにして、監視担当者がすべての情報を一元化し、システムのステータスと運用状況の全体像を再現できることを意味します。

4


可観測性は、これまでサイロ化され断片的であった重要ないくつものシステムのビューを、組織全体で共有できる詳細でありながら包括的なインフラストラクチャのビューへと移行するカルチャーであり、DevOps 環境と完全に符合します。

監視におけるモダンなアプローチ監視は、開発と運用チームがシステムの可観測性を実現するための DevOps ツールチェーンの一部です。通常、監視する理由は、パフォーマンスの問題がエンドユーザーに対する問題を引き起こす前に、その問題を検出して解決することです。開発チームはかつてないほど迅速に活動しています。1 日に何十回も新しいコードをリリースしている開発チームもあるような状況において、詳細な監視が必須です。

モダンな監視システムに求められる最重要機能について以下に説明します。

集計機能の組み込み強力なタグ付けまたはラベル付けの仕組みにより、エンジニアはメトリクスを自由にセグメント化して集計でき、ホストレベルではなくサービスレベルで問題を捉えることができます（ペットと家畜の比喩を思い出してください）。

包括的な監視対象インフラストラクチャのすべてのレイヤーを監視できると、エンジニアはシステム間でメトリクスを相関でき、サービス間の相互作用を把握できます。

スケーラビリティ現在の動的な監視システムは、個々のホストの追加や削除を把握し、インフラストラクチャが拡張または縮小されると適切に拡張されます。新しいホストが起動されると、システムはそれを検出して自動的に監視を開始します。

高度なアラート作成ほぼすべての監視ツールは、設定したしきい値をメトリクスが超過するときに、アラートを発行できます。しかし、このようなアラートのアプローチは柔軟性が欠如しており、急速に拡大する環境では更新と調整が常に必要となります。さらに高度な監視システムでは、相対的変化についてのアラート、外れ値と異常値の自動検出など、ベースラインの変化に対応する柔軟なアラートが提供されます。

コラボレーション問題が発生した場合には、監視システムは、エンジニアができるだけ迅速に問題を発見して修正できるようにする必要があります。つまり、チームが使用しているコミュニケーションチャンネルからアラートを配信し、インシデント対応の担当者がグラフ、ダッシュボード、イベント、およびコメントを簡単に共有できるようにします。

5


モダンな監視フレームワークの仕組み次章では、モダンなインフラストラクチャに対応する実践的な監視フレームワークの詳細を説明し、その仕組みについて詳述します。まず、データについて説明します。データは、あらゆる監視アプローチにおける中核です。次章では、システムで生成されるさまざまな種類の監視データを収集、分類、および集計する技法を習得できます。また、どのようなデータが問題を特定して解決するために最も役立つ可能性が高いかを把握できます。

このフレームワークは、何千もの顧客の大規模なインフラストラクチャを監視してきた Datadog の経験と AWS クラウドで急速に普及している Datadog のアプリケーションで培った経験から生まれています。また、Netflix 社の Brendan Gregg 氏、Google 社の Rob Ewaschuk 氏、VividCortex 社の Baron Schwartz 氏の著書も参考にしています。

6

第 2 章優れたデータを収集せよ

第 2 章：優れたデータを収集せよ

データ監視の形式はさまざまです。データを継続的に出力するシステムもあれば、特定のイベントが発生したときにデータを生成するシステムもあります。問題を特定するために役立つデータもあれば、主に問題を調査するのに役立つデータもあります。本章では、収集するべきデータについて、そして収集したデータを分類し、以下を実現する方法について説明します。

1. 不要なアラートを最小限に抑えながら、潜在的な問題を知らせるアラートを自動的に生成すること。

2. 迅速な調査を可能にして、パフォーマンスの問題の原因を特定すること。

監視するデータがどのような形式であっても、以下の共通項があります。

データを収集すること自体は安価ですが、必要なときにデータがないと多額の費用がかかる恐れがあります。そのため、すべてを測定しておき、有用なデータを合理的な範囲で収集する必要があります。

ほとんどの監視データは、メトリクスとイベントの 2 つのカテゴリのいずれかに分類されます。以下では、各カテゴリの例について説明し、その用途を説明します。

7


メトリクスメトリクスは、特定の時点におけるシステム関連の値、たとえば、Web アプリケーションに現在ログインしているユーザー数など取得します。そのため、メトリクスは通常、システムを時間の経過と共に監視するため一定期間（15 秒ごと、1 分ごとなど）に収集されます。

Datadog のフレームワークでは、ワークメトリクスとリソースメトリクスの 2 つの重要なカテゴリが使用されます。インフラストラクチャにある各システムで、どのようなワークメトリクスとリソースメトリクスを合理的に利用できるかを検討して、これらのすべてを収集します。

ワークメトリクス

スループット

成功

エラー

パフォーマンス

リソースメトリクス

使用率

サチュレーション

エラー

可用性

イベント

コード変更

アラート

スケーリングイベント

その他

ワークメトリクスワークメトリクスは、有用な出力を測定することで、システムのトップレベルのヘルスを示します。次章で説明しますが、これらのメトリクスは、実質的な問題、多くの場合はユーザーが直面する問題を洗い出すうえで非常に有用です。ワークメトリクスを検討する場合、次の 4 つのサブタイプに分類すると便利です。

－スループットは、ある時間単位でシステムが実行している作業量です。スループットは通常、絶対数として記録されます。

－成功メトリクスは、正常に実行した作業の割合を表します。

－エラーメトリクスは、エラーになった結果数を取得します。これは通常、ある時間単位におけるエラー率として示されます。また、ある作業単位でエラーを生成したスループットにより正規化されます。エラーメトリクスは、その潜在的な原因がいくつかある場合、成功メトリクスとは別に取得されることが多くあります。取得されるエラーメトリクスの中には他のメトリクスよりも重大な意味を持ち、対策がすぐに必要となるものがあります。

－パフォーマンスメトリクスは、コンポーネントが処理をどれほど効率的に実行しているか定量化します。最も一般的なパフォーマンスメトリクスは、ある処理単位を完了するために必要な時間を示すレイテンシです。レイテンシは、「要求の 99% が 0.1 秒以内に返される」など、平均値またはパーセンタイルで表すことができます。

8


以下に、Web サーバーとデータストアの 2 つの一般的なシステムのワークメトリクスにおける 4 つすべてのサブタイプの例を示します。

ワークメトリクスの例：WEB SERVER (AT TIME 2016-05-24 08:13:01 UTC)

サブタイプ説明値

スループット 1 秒あたりの要求数 312

成功最後に測定してから 2XX（成功）であった応答の割合

99.1

エラー最後に測定してから 5XX（エラー）であった応答の割合 0.1

パフォーマンス応答時間の 90 パーセンタイル値（秒） 0.4

ワークメトリクスの例：DATA STORE (AT TIME 2016-05-24 08:13:01 UTC)

サブタイプ説明値

スループット 1 秒あたりのクエリ数 949

成功最後の測定から正常に実行されたクエリの割合 100

エラー最後の測定から例外を発生したクエリの割合 0

エラー最後の測定から古いデータを戻したクエリの割合 4.2

パフォーマンス応答時間の 90 パーセンタイル値（秒） 0.02

リソースメトリクスソフトウェアインフラストラクチャのほとんどのコンポーネントは、他のシステムのリソースとして機能します。下位レベルのリソースも存在します。たとえば、サーバーのリソースには、CPU、メモリ、ディスク、ネットワークインターフェイスなどの物理コンポーネントが含まれます。しかし、データベースや地理情報マイクロサービスなどの上位レベルのコンポーネントも、他のシステムがそのコンポーネントを使用することを要求する場合、リソースとして考えることができます。

リソースメトリクスは、本書の第 4 章で説明する問題の調査と診断に特に役立ちます。システムの各リソースについては、次の 4 つの主要な領域をカバーするメトリクスを収集してください。

－使用率は、リソースがビジーである時間の割合、または使用されているリソースキャパシティの割合です。

－サチュレーション（飽和）は、リソースがまだ処理できていない要求された作業量を測定したものです。サチュレーションは多くの場合、キューの長さによって測定されます。

－エラーは、リソースが生成する作業では観測できない可能性がある内部エラーを示します。

9


－可用性は、リソースが要求に応答した時間の割合を表します。このメトリクスは、目的を持って可用性を定期的にチェックできるリソースについてのみ明確に定義されます。

以下に、一般的なリソースタイプのメトリクスのいくつかの例を示します。

リソース利用率サチュレーションエラー可用性

ディスク IO デバイスがビジーだった時間の割合

待ち行列の長さデバイスエラーの数書き込み可能な時間の %

メモリ使用されている総メモリキャパシティの %

スワップの使用率 N/A（通常は観測不能） N/A

マイクロサービス各要求が処理しているスレッドがビジーになっている時間の平均 %

待機状態の要求の数例外発生などの内部エラーの数

サービスにアクセスできる時間の %

データベース各接続がビジーになっている時間の平均 %

待機状態になっているクエリの数

内部エラーの数。例、レプリケーションエラー

データベースにアクセスできる時間 %

その他のメトリクスワークでもリソースでもないメトリクスもいくつか存在しますが、これらのメトリクスも問題の原因を診断するうえで役立つ場合があります。一般的な例としては、キャッシュヒット数やデータベースロック数などがあります。何か疑念がある場合には、データを収集しましょう。

イベント一部の監視システムでは、一定のレベルで連続的に収集されるメトリクスの他に、イベントも収集されます。イベントは個別かつ不定期に発生する事象ですが、システムの動作の変化を把握するための重要なコンテキストを提供します。イベントの例には以下があります。

－変更：コードのリリース、ビルド、ビルド失敗

－アラート：プライマリの監視システムまたは統合型のサードパーティツールから生成された通知

－スケーリングイベント：ホストまたはコンテナの追加または削除

文脈（コンテキスト）の中でのみ有意となる単一のメトリクスデータポイントとは異なり、イベントには通常十分な情報が含まれており、イベントだけでその意味を解釈できます。イベントは、ある時点で何が起こったのかを取得します。また、オプションで追加の情報が収集されます。たとえば、以下の例を参照してください。

10


発生した事象時間追加の情報

ホットフィックス F464BFE が本番環境にリリースされた

2016–04–15 04:13:25 UTC 経過時間：1.2 秒

プルリクエスト 1630 がマージされた

2016–04-19 14:22:20 UTC コミット：EA720D6

夜間のデータロールアップに失敗した

2016–04-27 0:03:18 UTC 失敗したジョブのログリンク

イベントはアラートを生成する場合に使用されることがあります。上の表の 3 番目の例のように、最重要の処理が失敗したことを示すイベントは、適切なユーザーに通知しなければなりませんが、イベントは通常は問題を調査し、システム間で相関するために使用されます。したがって、メトリクスほど頻繁にイベントを確認していない場合でも、可能な場合には収集するべき価値のあるデータです。

タグ付け第 1 章で説明したように、現在のインフラストラクチャは常に流動的です。大量に作成されたサーバーは自動的にスケーリングされ、すぐに破棄されます。コンテナはそれ以上の頻度で追加および削除されます。これらの一時的な変化の全データを監視対象にすると、SN 比（信号雑音比）が非常に低くなる場合があります。

通常、監視対象をホスト、VM、またはコンテナの基本レベルからシフトすることでシグナルを強化できます。結局のところ、特定の EC2 インスタンスがダウンしても大きな問題ではありませんが、特定のサービス、顧客カテゴリ、または地理的なリージョンのレイテンシが長くなっている場合には、十分に注意する必要があります。

メトリクスにタグを付けると、データ監視の戦略を別の方向に向けることができます。メトリクスにタグを追加することで、さまざまなアベイラビリティゾーン、インスタンスタイプ、ソフトウェアバージョン、サービス、ロール、または必要な他のあらゆるレベルのメトリクスを監視してアラートを発行できます。

メトリクスタグとは？タグとは、データポイントが属するさまざまなすべての範囲を宣言するメタデータです。以下に例を示します。

メトリクス名: 何が？

メトリクス値：どのぐらい？

タイムスタンプ:いつ？

タグ: どこで？

system.net.bytes_rcvd 3 2016‒03‒02 15:00:00 [’availability-zone :us-east-1a ’, ’file-server ’, ’hostname :foo’, ’instance-type :m3.xlarge’]

データポイント

11


タグを使用すると、データポイントをフィルタリングおよびグループ化して、最重要のデータのビューを正確に生成できます。また、メトリクスを報告および収集する方法を変更せずに、オンザフライでメトリクスを集計できます。

簡易なメトリクスタグによるフィルタリング次の例では、file-server という簡易なタグを使用してデータポイントを表示しています。

system.net.bytes_rcvd 4 2016‒0 3‒02 15:00:00 [’file-server ’]

タイムスタンプ:いつ？

タグ: どこで？

メトリクス名: 何が？

メトリクス値：どのぐらい？

データポイント

簡易なタグは、データポイントをフィルタリングし、指定されたタグがあるデータポイントとタグのないデータポイントを表示するためにのみ使用されます。

キー : 値タグを使用した新しいディメンションの作成メトリクスにキー : 値タグを追加すると、新しいディメンション（キー）とそのディメンションの新しい属性（値）が追加されます。たとえば、instance-type:m3.xlarge タグがあるメトリクスは、instance-type というディメンションを宣言し、メトリクスにそのディメンションの属性 m3.xlarge が提供されます。キー : 値のタグを使用する場合、「キー」には考慮する抽象化レベル（例：インスタンスタイプ）を選択します。また、「値」はデータポイントが共通して属する対象を決定します（例：インスタンスタイプ m3.xlarge のメトリクス）。

インスタンスタイプ

アベイラビリティゾーン

ロール

database cache appserver

database

database cache

cache

appserver

appserver

database cache appserver

12


同じキーがあるものの値が異なる他のメトリクスを追加すると、それらのメトリクスには自動的にそのディメンションの新しい属性が設定されます（例：m3.medium）。キー : 値のタグを追加したら、任意のディメンションを組み合わせて分析が可能になります。

監視のためのより良いデータとは収集するべきデータには、4 つの特徴があります。

－簡単に理解できる。各メトリクスやイベントがどのように取得されたか、またそれが何を意味しているのかをすばやく判断できる必要があります。システムが停止しているときに、悠長にデータの意味を理解するための時間をかけることはできません。メトリクスとイベントはできるだけシンプルにし、上記で説明された標準的な概念を利用して、簡明な名前を設定します。

－粒度。メトリクスを収集する頻度が低すぎたり、あまりにも長い期間の平均値を収集したりすると、システムの動作についての重要な情報を得られない場合があります。たとえば、リソースの使用率が 100% である期間があっても、使用率が低い期間との平均値を取得してしまうと、その状況はわかりにくくなります。過度に高頻度でサンプリングしても有意なデータが得られない場合もあります。監視によってシステムに過度の負担をかけることなく、問題を適切に検出できる頻度で各システムのメトリクスを収集してください。

－スコープ別のタグ付。各ホストはさまざまなスコープ（範囲）で同時に稼働しています。そのため、任意のスコープ、またはスコープの組み合わせについて全体的なヘルスを確認したい場合もあるでしょう。たとえば、本番用の Web アプリケーションは全体としてどのように稼働しているか？ AWS リージョン

「us-east-1」における稼働状況はどうなっているか？ソフトウェアバージョンと EC2 インスタンスタイプの特定の組み合わせはどうなっているか？などの質問に答える必要があります。任意のスコープを視点として問題を警告し、ホスト階層に制限されることなく、システムが停止した原因を迅速に調査できるように、データと複数のスコープを関連付けて保持することが大切です。前に説明したように、これは動的なクラウドインフラストラクチャで特に重要です。

－長期間の保持。ストレージコストを削減するために、あまりにも早い段階でデータを破棄したり、一定期間が経過した後に監視システムがメトリクスを集計したりすると、過去に何が起こったのかを示す重要な情報が失われます。元のデータを 1 年以上保持することで、特に「メトリクスが月ごと、季節ごと、または年ごとに変動する場合」、「通常」の状態を容易に把握できるようになります。

13


すべてを収集するここまで、イベントとメトリクスの違い、およびワークメトリクスとリソースメトリクスの違いについて詳しく説明しました。次章では、動的なインフラストラクチャを監視するために、これらのデータポイントを効果的に活用する方法について説明します。しかし、その前に本章の要点について簡単に復習しておきましょう。

－すべてを計測し、合理的な範囲でできる限り多くのワークメトリクス、リソースメトリック、およびイベントを収集します。

－重要な指標となる急激な増加や減少を把握できるように十分な粒度でメトリクスを収集します。適切な粒度は、測定しているシステム、測定コスト、およびメトリクスが変化する一般的な期間によって異なります。

－データの価値を最大化するために、適切な範囲でメトリクスとイベントにタグを付け、少なくとも 1 年間は完全な粒度でこれらのデータを保持します。

14

第 3 章本当に重要な問題についてアラートを発行する

第 3 章：本当に重要な問題についてアラートを発行する

自動的にアラートを発行する機能は監視ソリューションにとって不可欠です。このようなアラート機能によりインフラストラクチャのどこに問題があっても検出でき、原因を迅速に特定し、サービスの低下や中断を最小限に抑えることができます。

アラートでは、システムの状況について簡明な言葉で伝えるべきです。「2 つの Cassandra ノードが停止している」または「すべての Web 要求のうちの 90% が処理と応答に 0.5 秒以上を費やしている」など明確に説明します。できるだけ多くのシステムでアラートを自動化することで、迅速に問題に対応し、より優れたサービスを提供できます。また、手動でメトリクスを検査する必要がなくなるため、時間を節約できます。

しかし、アラートが常に効果的であるとは限りません。特に、大量の誤ったアラートに本当の問題が埋もれてしまう場合が多くあります。本章では、監視するシステムの拡張性や弾力性といった性質に関わらず、効果的なアラートを発行するための簡単な方法について説明します。

要点：

1. 原因ではなく、症状について緊急メッセージを送信します。

2. アラートの設定自体は自由で構いませんが、( 人へ ) 緊急メッセージを通知するかどうかにおいては十分慎重になるべきです。

15


アラートの緊急レベルすべてのアラートの緊急度は同じではありません。速やかな介入が求められるアラートもあれば、時間の余裕があるときに対応すればよいアラートもあります。また、将来的に注意しなければならない可能性がある領域を指摘するアラートもあります。少なくとも、すべてのアラートを簡単にアクセスできる中央の場所に記録し、他のメトリクスやイベントと相関できるようにする必要があります。

記録するアラート（重大度が低い場合）多くのアラートはサービスの問題に関連しておらず、ユーザーが気付く必要もない場合があります。たとえば、ユーザーに表示するサービスをサポートするデータストアのクエリ処理が通常時よりもはるかに低速になっている場合でも、サービス全体の応答時間が通常時と明確な差異が生じるほど低速ではない場合は、緊急度の低いアラートが生成されます。このアラートは監視システムに記録され、将来的に参照または調査するときに利用できますが、業務を中断してすぐに対応することはありません。ネットワークの輻輳などの一時的な問題は、結局のところ、人が介入しなくても解決されることが多くあります。しかし、たとえば、サービスから多くのタイムアウトが返され始めるなど、重大な問題に発展する場合、記録されたアラートは調査に非常に役立つコンテキスト情報になります。

通知するアラート（重大度が中程度の場合）次の段階のアラート緊急度は、介入が必要ですが、すぐに対応する必要はありません。たとえば、データストアのディスク容量が不足しており、今後数日以内にスケールアウトする必要があるケースが該当します。これらのアラートを配信するには、電子メールを送信したり、サービスオーナーのチャットルームに通知したりすると良いでしょう。このような通知方法では、担当者が見逃すことなく確認してもらいやすくなりますが、エンジニアが就寝中の深夜に起こしたり、集中している作業を中断させたりするものではありません。

緊急メッセージを送信するアラート（重大度が高い場合）最も緊急度の高いアラートは特別な対応が必要となります。緊急対応を喚起するために、直接担当者にメッセージを送信するようにエスカレートする必要があります。たとえば、Web アプリケーションの応答時間には、少なくとも顧客向けの最も厳格な SLA と同程度の厳しい内部的な SLA が必要です。内部的な SLA を超過する応答時間が発生した場合は、発生した時間にかかわらず、即時対応が必要になります。

16


アラートのためのデータと診断のためのデータ

診　断：

緊急メッセージ調　査

ワークメトリクスワークメトリクス

リソースメトリクスイベント

症　状：

以下の表は、前章で説明したさまざまなデータタイプの例をさまざまなレベルのアラート緊急度にマッピングしたものです。重大度に応じて、緊急メッセージを送信するよりも、通常の通知方法が適切になる場合もあれば、その逆になる場合もあります。

データアラートトリガー

ワークメトリクス：スループット

緊急メッセージの送信値が通常よりもはるかに高いか低いか、または変化率が異常

ワークメトリクス：成功

緊急メッセージの送信正常に処理された作業の割合がしきい値を下回る

ワークメトリクス：エラー

緊急メッセージの送信エラー率がしきい値を超過する

ワークメトリクス：パフォーマンス

緊急メッセージの送信作業が完了するまでに時間がかかりすぎる

（例、パフォーマンスが内部的な SLA に違反している）

リソースメトリクス：利用率

通知クリティカルなリソース制限に近づいている

（例、空きディスク領域がしきい値を下回る場合）

リソースメトリクス：サチュレーション

記録待機しているプロセスの数がしきい値を超えている

リソースメトリクス：エラー

記録一定期間における内部エラー数がしきい値を超えている

リソースメトリクス：可用性

記録リソースを利用できない時間の割合が、しきい値を超えている。

イベント：業務関連

緊急メッセージの送信完了していなければならない最重要作業が、未完了または失敗したと報告されている

17


アラート緊急度の設定方法アラートを設定するときはいつでも、アラートの緊急度とアラートの対処方法を決定するために、3 つの質問について自問しましょう。

1. これは本当に問題か？

当たり前のことのように思われるかもしれませんが、本当の問題でない場合、通常、アラートを生成するべきではありません。次の例は、アラートを発生させる可能性がありますが、本当の問題の兆候ではない可能性があります。実際の問題にならない事象が発生したときに、目立つアラートや緊急メッセージを送信すると、アラート疲れが蓄積し、本当に深刻な問題が見過ごされる恐れがあります。

－テスト環境のメトリクスは範囲外

－単一サーバーの作業は非常に低速になっていますが、他のマシンへ迅速にフェイルオーバーできるクラスタの一部になっており、定期的に再起動している

－計画的なアップグレードがあり、多数のコンピュータがオフラインとして報告される

これが本当に問題である場合には、アラートを生成する必要があります。アラートを通知しない場合でも、後で分析および相関するために監視システムで記録する必要があります

2. この問題に対する注意は必要か？

問題への対応を合理的に自動化できるのであれば、自動化を検討する必要があります。仕事中、就寝中、またはプライベートな時間を過ごしているときに担当者を呼び出すことは非常に大きな負担になります。本当の問題で注意が必要な場合は、アラートを生成し、問題を調査および修正する担当者に通知する必要があります。少なくとも、電子メール、チャット、またはチケット発行システムから通知を送信して、通知を受け取った担当者が問題への対応の優先度を決定できるようにします。

3. この問題は緊急か？

すべての問題が緊急対応を必要とするわけではありません。たとえば、低速なシステム応答の割合が通常よりもやや高い場合や、古いデータを返すクエリの割合がいくぶん高い場合などがあります。どちらの問題も早急な対応が必要かもしれませんが、午前 4 時に対応することはありません。一方、重要なシステムの動作が許容される範囲を超過している場合、エンジニアは直ちに問題を調査する必要があります。症状が実際の問題を示しており、注意が必要で緊急に対応するべき場合は、緊急メッセージを生成する必要があります。

18


症状に関する緊急メッセージ緊急メッセージを使用する場合、十分に注意する必要があります。緊急メッセージは、情報を伝える手段としては非常に効果的ですが、過度に使用したり、動揺やパニックを引き起こすようなアラートに関連したりする場合、破壊的な結果を引き起こす場合があります。通常、自分が担当しているシステムが、許容可能なスループット、レイテンシ、またはエラー率の範囲内で動作しなくなった場合に、緊急メッセージを使用して警告するのは最適な方法です。これらは即座に把握するべき問題です。

自分のシステムが適切に稼働しなくなったという事実は、症状です。これは問題の兆候であり、さまざまな原因が考えられます。たとえば、Web サイトの直近の 3 分間の反応が非常に低速である場合、これは症状です。データベースのレイテンシが高い、アプリケーションサーバーで障害が発生した、Memcached がダウンした、負荷が高いなどの原因が考えられます。可能な限り、原因ではなく症状に基づいて緊急メッセージを作成してください。第 2 章で説明したワークメトリクスとリソースメトリクスの区別は、症状と原因を区別するのに役立つ場合が多くあります。ワークメトリクスは通常、症状に関連付けられ、リソースメトリクスは原因に関連付けられます。

症状に関する緊急メッセージにより、仮定または内部的な問題というよりも、現実の問題で多くの場合にユーザーに対して発生している問題を明らかにできることが多くあります。Web サーバーの負荷が高いなど、症状として考えられる原因について緊急メッセージを送信する場合と、Web サイトの応答が遅いなどの症状について緊急メッセージを送信する場合の違いを考えてみてください。Web サイトがすばやく応答しているのであれば、ユーザーはサーバーの負荷を知ることはありませんし、気にする必要もありません。また、エンジニアはシステム内部の微細な問題で、介入しなくても通常レベルに戻る可能性があるちょっとした問題であるのに、煩わされたと憤慨することになります。

長期間継続するアラートの定義症状について緊急メッセージを送信するもう 1 つの正当な理由は、症状によってトリガーされるアラートは長期間継続する傾向があることです。つまり、バックエンドのシステムアーキテクチャがどのように変わっても、システムが正常に機能しなくなった場合は、アラート定義を更新しなくても適切な緊急メッセージを受け取ることになります。

このルールの例外：早期警戒のサインシステムが適切に動作していても、いくつかのメトリクスについては担当者が注意する必要がある場合があります。早期警戒のメトリクスは、深刻な症状が今後すぐに発生し、緊急介入が必要となるような、許容できない問題が発生する可能性が高いことを示します。

ディスク容量がその典型的な例です。空きメモリや CPU が不足している場合とは異なり、ディスク容量が不足しているとシステムは回復しない恐れがあり、わずか数秒でシステムが完全に停止してしまう場合も多くあります。もちろん、十分なリードタイムを確保して問題を通知できれば、真夜中に誰かを起こす必要はありません。さらに良い対策は、ディスク容量が低下する状況を予測し、ログや他の場所にあるデータなど、データを消去することで、自動的な対策を構築することです。

19


“症状”について真剣に捉える次章では、アラートを受信した後の対応について説明します。しかし、その前に、本章の要点を簡単に復習しましょう。

－緊急対応が必要となる問題の兆候が、システムの動作で検出された場合や、重大な問題および重要なリソースの上限に達しようとしている場合にのみ、緊急メッセージを送信します。

－インフラストラクチャで実際の問題が検出される場合、これらの問題が全体のパフォーマンスに影響を与えていない場合であっても、必ずアラートは記録しておくように監視システムを設定します。

20

第 4 章パフォーマンス問題の調査

第 4 章：パフォーマンス問題の調査

監視システムが実施するべきタスクは、症状を検出することだけではありません。注意が必要な実際の症状が監視システムから通知されたら、根本原因を診断できるように支援することも監視システムのタスクの 1 つです。根本原因の診断は、監視システムで体系化が最も遅れている領域であり、多くの場合、勘に頼ったり、推測して検証する手法が主に使用されたりしています。本章では、根本原因を効率的に見つけて修正するために役立つ明確な方向性を持ったアプローチについて説明します。

21


データに関する復習

ワークメトリクス

スループット

成功

エラー

パフォーマンス

リソースメトリクス

使用率

サチュレーション

エラー

可用性

イベント

コード変更

アラート

スケーリングイベント

その他

第 2 章を思い出してみましょう。インフラストラクチャの問題の根本原因を調査するときに役立つ 3 つの主要なタイプの監視データがありました。

－ワークメトリクスは、有用な出力を測定することで、システムの上位レベルのヘルスを示します

－リソースメトリックは、システムが依存しているリソースの使用率、サチュレーション、エラー、または可用性を定量化します

－イベントは、コード変更、内部アラート、スケーリングイベントなど、システムで不定期に発生する個別の事象を示します

概して、ワークメトリクスは最も深刻な症状を把握する場合に役立ち、前章で説明したように最も深刻なアラートを生成します。一方で、他のメトリクスタイプはこれらの症状の原因を調査するための非常に貴重な情報になります。

すべてはリソースと考えることができるインフラストラクチャのほぼすべてのコンポーネントはリソースと考えることができます。最上位レベルでは、処理を実施している各システムは他のシステムに依存している可能性があります。たとえば、LAMP スタック内の Apache サーバーは、要求を処理する作業をサポートするためのリソースとして MySQL データベースを利用しています。1 つ下位のレベルを見ると、MySQL には、このデータベースが処理を実行するために使用する固有のリソース（クライアント接続の有限のプールなど）があります。さらに下位のレベルを見ると、CPU、メモリ、ディスクなど、MySQL を実行するサーバーの物理リソースが存在します。

どのシステムが処理を実施しており、どのリソースがその処理をサポートしているかを考えることは、特定された問題の根本原因を効率的に解決するために役立ちます。問題が発生している可能性があることがアラートで通知されたら、次の手順を活用して、体系的な調査を実施できます。

22


ワークリソースイベント




1. ワークメトリクスから最初に取り掛かる

最初に「問題が発生しているか？問題にはどのような特徴があるか？」という質問に回答できるようにしましょう。初期段階で問題を明確に説明できないと、問題を診断するためにシステムを詳細に調査するときに、問題の原因を適切に追及できないことが多くあります。

次に、問題が発生している最上位システムのワークメトリックを調査します。これらのワークメトリクスは、通常、問題の原因を示したり、少なくとも調査の方向性を決定したりするために役立ちます。たとえば、正常に完了した処理の割合が設定されたしきい値を下回った場合、エラーメトリクス、特に返されたエラータイプを詳しく調査することができ、調査対象を絞り込むのに役立ちます。あるいは、レイテンシが長く、外部システムから要求されている処理のスループットも非常に高い場合、システムに過度の負荷がかかっている恐れがあります。

2. リソースの詳細な調査

最上位のワークメトリクスを調べても問題の原因を特定できない場合は、次にシステムが使用しているリソース（物理リソース、およびシステムのリソースとして機能しているソフトウェアや外部サービス）を調べます。以下に概説しますが、各システムのダッシュボードを事前に設定しておくと、関連するリソースのメトリクスをすばやく見つけて詳しく調査できます。これらのリソースが利用できなくなっているか？利用率が高くなっているか？飽和しているか？これらの問題に該当するのであれば、これらのリソースについて手順 1 の各項目について再帰的に調査を開始します。

3. 何かを変更したか？

次に、アラートとメトリクスと相関する可能性があるその他のイベントについても検討します。問題が発生した少し前にコードリリース、内部アラート、またはその他のイベントが登録されている場合、それらが問題に関連している可能性があるかどうかを調べます。

4. 修正する（そして忘れずに記録する）

問題の原因を特定したら、修正します。症状がなくなったら調査は完了です。今後、同様の問題を回避するためにシステムを変更する方法について検討することが可能になります。

23


必要となる前にダッシュボードを構築する

システムが停止しているときは、1 分も無駄にすることはできません。迅速に調査し、作業に集中するために、あらかじめダッシュボードを設定しておきましょう。上位レベルのアプリケーションメトリクス用にダッシュボードを 1 つ設定し、サブシステム別にダッシュボードを 1 つ設定することをお勧めします。各システムのダッシュボードは、そのシステム自体のリソースメトリクスとそのシステムが依存するサブシステムの主要なメトリクスと一緒に、そのシステムのワークメトリクスを表示できるようにします。イベントデータを利用できる場合、関連するイベントをグラフに重ね合わせて、相関性を分析します。

メトリクスを追う標準化された監視フレームワークに従うことで、問題を体系的に調査できます。

－インフラストラクチャの各システムについて、主要なメトリクスすべてを表示するダッシュボードを事前に設定し、関連するイベントを重ね合わせます。

－症状を示している最上位レベルのシステムから調査を開始し、そのワークメトリクスとリソースメトリクス、および関連するイベントを検証し、問題の原因を調査します。

－問題のあるリソースが検出された場合、問題の根本原因を突き止めて修正できるまで、同じ調査パターンをそのリソース（およびその構成リソース）に適用します。

これまで、データの収集とタグ付け（第 2 章）、自動アラート発行（第 3 章）、およびインシデント対応と調査（第 4 章）に関する上位レベルのフレームワークについて概説しました。次章では、さまざまなグラフやその他の視覚要素を使用してメトリクスを監視する方法について詳しく説明します。

24

第 5 章時系列グラフによるメトリクスの可視化

第 5 章：時系列グラフによるメトリクスの可視化

メトリクスを問題解決のための有用な情報（インサイト）として活用するために、データを適切に視覚化する方法を選択することが重要となります。万能型の解決策は存在しませんが、同じメトリクスであっても異なるグラフの種類を使用すると、違った情報が見えてくることもあります。

本章では、メトリクスを効果的に視覚化するために使用できる、折れ線グラフ、積み上げ面グラフ、棒グラフ、ヒートマップの 4 種類の時系列グラフについて説明します。これらのすべてグラフでは x 軸が時間で y 軸がメトリクス値になります。各種のグラフについて、機能、使用するケース、別のグラフの種類に切り替えるケースについて説明します。

最初は、時系列グラフの集計について簡単に説明します。これは、動的なクラウドスケールのインフラストラクチャのメトリクスを視覚化するために重要です。

25


空間を横断する集計すべてのメトリクスクエリを、ホスト、コンテナ、またはその他のインフラストラクチャの単位で分類しても意味がない場合があります。メトリクスを可視化して有効に活用するには、空間を横断した集計が必要になることが多くあります。この集計には、メッセージングキュー、データベーステーブル、アプリケーション、またはホスト自体に関する任意の属性（オペレーティングシステム、アベイラビリティゾーン、ハードウェアプロファイルなど）を基準としてメトリクスを集計する場合など、さまざまな方法があります。

空間を横断して集計することにより、インフラストラクチャを多次元に分析し、最も重要なメトリクスを正確に切り分けることができます。また、不要な情報が溢れるグラフを簡潔にして読みやすくすることも可能になります。たとえば、Web 要求についてホストレベルのグラフを作成しても、有用な情報を読み取ることは困難ですが、メトリクスをアベイラビリティゾーン別に集計すると、同じデータでも簡単に解釈することが可能になります。

第 2 章で説明したように、メトリクスにタグを付けると、グラフやダッシュボードを作成するときにこのような集計をグラフ描画と同時にアドホックに簡単に実行できます。

26


折れ線グラフ

折れ線グラフは、メトリクスデータを視覚的に変換する最も簡単な方法です。デフォルトで使用されることが多くありますが、異なるグラフを使用したほうが良い場合もあります。たとえば、数百台のホストの変化の激しいメトリクスを折れ線グラフにすると、スチールウールのような密に絡み合った状態になり、データの解釈が困難になります。

折れ線グラフを使用する場合

表示対象理由例

さまざまなスコープ別に報告される同じメトリクス

外れ値を一目で把握するためクラスタにある各ホストの CPU アイドル

あるソースの単一のメトリクスまたは集計を追跡する

時間の経過による重要なメトリクスの推移を明確に伝えるため

全 Web サービスの平均レイテンシ

インフラストラクチャの特定スライスにおける非集計値が特に有用となるメトリクス

個別の逸脱値が許容外になるかを判断するためデータベースノード別のディスク容量の使用率

27


同じ単位を共有する関連メトリクス

一目で相関を識別するため同じマシンのディスク読み取りとディスク書き込みのレイテンシ

許容可能な明確な領域があるメトリクス

サービスの低下を簡単に把握するため Web 要求の処理のレイテンシ

別のグラフを使用する場合

表示対象理由代わりに使用するグラフ ...

膨大な数のソースから報告される変動の激しいメトリクス

全ホストの CPU 不要なデータを解釈しやすくするヒートマップ

個別のデータポイントよりも集計したほうがより有用になるメトリクス

多くの Web サーバーに関する 1 秒間の Web 要求の処理の数

タグされたグループ全体を集計する面グラフ

スパース（疎）なメトリクス

比較的少ない S3 アクセスエラーの回数あいまいな補間を避けるための棒グラフ

28


積み上げ面グラフ

面グラフは折れ線グラフに似ていますが、メトリクスの値が線ではなく 2 次元のバンドで表示される点が異なります。バンドを積み上げることで、複数の時系列を集計できます。

積み上げ面グラフを使用する場合


別のスコープから見た同じメトリクス

（積み重ね）

各部分の合計と寄与の両方を一目で把握するためアベイラビリティゾーン別のロードバランサ要求数

同じ単位を共有する補完的なメトリクスの合計

有限のリソースがどのように使用されているか表示するため

CPU 使用率のメトリクス（ユーザー、システム、アイドルなど）

29



表示対象例代わりに使用するグラフ

多数のホストの集計していないメトリクス

（詳細にスライスすることでデータを解釈しやすくする）

数百のアプリサーバー全体のスループットメトリクス

折れ線グラフまたは単色の面グラフによって合計された集計値を追跡する

ホストレベルのデータを追跡するためのヒートマップ

合理的に追加できないメトリクス

複数のサーバーにわたるシステムの負荷折れ線グラフまたは多くのホストのヒートマップ

棒グラフ

棒グラフの各棒は、特定の時間間隔におけるメトリクスの集計を表します。この機能があるため、棒グラフはカウント（回数）を表すのに最適です。ある瞬間の値を表すゲージメトリクスとは異なり、カウントメトリクスは特定の時間間隔と組み合わせて初めて意味を持ちます（たとえば、過去 5 分間に 13 回クエリエラーがあったなど）。

30


棒グラフは、ある間隔と次の間隔における補間を必要としないため、スパース（疎）メトリクスを表す場合に特に役立ちます。積み上げ面グラフと同じように、メトリクスの積み重ねと集計に対応します。

棒グラフを使用する場合


スパース（疎）なメトリクス

曖昧または誤解しやすい補間なしでメトリクスを伝えるため

Cassandra の内部キューでブロックされたタスク

回数を示すメトリクス ( ゲージではなく )

合計回数と対応する時間間隔の両方を伝えるため失敗したジョブ数（データセンター別） (4 時間おき )

31



表示対象例代わりに使用するグラフ

合理的に追加できないメトリクス

ロードバランサごとの平均レイテンシ各ホストの時系列を切り離す折れ線グラフ

多数のソースの集計していないメトリクス

（詳細にスライスすることでデータを解釈しやすくする）

大量の Cassandra ノード全体で完了したタスクの数

単色の棒グラフによって合計された集計値を追跡する

ヒートマップでホストレベルの値を追跡する

32


ヒートマップ

ヒートマップは、時間とともに変化するメトリクスの値の分布を示します。具体的には、各列は特定のタイムスライスにおける値の分布を表します。各セルの網掛けは、その特定期間に特定の値を報告したエンティティ数に対応します。

ヒートマップは、多数のエンティティのメトリクスを視覚化するように設計されており、個々のホストやコンテナレベルでは集計されないメトリクスをグラフ化するために使用されます。ヒートマップは分布グラフと密接に関係していますが、ヒートマップは時間の経過による変化を示し、分布グラフは特定の期間におけるスナップショットを示す点が異なります。分布については次章で説明します。

ヒートマップを使用する場合


多数のグループによって報告される単一のメトリクス

一般的な傾向を一目で把握できるようにするためホストごとの Web レイテンシ

あるグループメンバーの瞬間的な変動を表示するホスト別に受信した要求数

33




いくつかの個別のソースからのみ提供されるメトリクス

少数の RDS インスタンス全体の CPU 使用率各ホストの時系列を切り離す折れ線グラフ

個別の値よりも集計値が重要となるメトリクス

Cassandra 列ファミリ別のディスク使用率特定のタグセットで値を合計する面グラフ

さまざまなグラフを知る各時系列グラフを最も有効に活用できるユースケースと制約を理解することで、問題を解決するための有用な情報をメトリクスから迅速に抽出できます。

次章では、ビューの期間を圧縮してメトリクスのサマリービューを視覚化するサマリーグラフについて説明します。

34

第 6 章サマリーグラフによるメトリクスの視覚化

第 6 章：サマリーグラフによるメトリクスの視覚化

第 5 章では、時間の経過によるインフラストラクチャメトリクスの変化を視覚化した時系列グラフについて説明しました。本章では、サマリーグラフについて説明します。これは、特定の期間を平坦化して視覚化し、インフラストラクチャの概要を確認できるようにしたものです。本章で説明するサマリーグラフの種類は、単一値のサマリー、トップリスト、推移グラフ、ホストマップ、および分布です。

グラフの種類ごとに、機能と使用するタイミングについて説明します。その前に、インフラストラクチャのサマリーグラフを理解するために必要となる、時間を横断する集計（「時間の平坦化」または「スナップショット」と考えることができます）と空間を横断する集計の 2 つの概念について簡単に説明します。

時間を横断する集計メトリクスのサマリービューを表示するには、ビューの時間次元を圧縮して、時系列を単一値に平坦化する必要があります。時間を横断する集計では、メトリッククエリによって返される最新の値を単純に表示したり、時間枠を変えながら計算した値を返す複雑な集計を表示したりできます。

35


たとえば、メトリクスクエリの最新の報告値のみを表示するのではなく、過去 60 分間で各ホストによって報告された最大値を表示して、問題となる可能性がある急激な変化を把握できます。

ホスト別の最大 Redis レイテンシ2.61 i-25crx5f60.72 i-4ad7841t0.57 i-dmx3210b0.45 i-99d91x390.36 i-53b0f0e90.33 i-79cd6ma00.29 i-9cmd5o760.13 i-2bdcd2fc0.12 i-d0bnra670.12 i-nnd3775a

1 時間

空間を横断する集計第 5 章で説明しましたが、メトリクスを視覚化して活用するためには、空間を横断した集計が必要になることがよくあります。これは、ホストのいくつかのプロパティ（アベイラビリティゾーン、インスタンスタイプ、オペレーティングシステム）を基準として、あるいはメトリクスに適用したタグ（サービス名、メッセージングキュー、データベーステーブルなど）を基準として集計することを意味します。

上記の例のように、ホストレベルでピークの Redis レイテンシを表示するのではなく、Redis で構築されている各内部サービスのピークレイテンシーを表示したほうが有用となる場合があります。あるいは、インフラストラクチャにある任意の 1 台のホストによって報告された最大値のみを表示することもできます。

サービス別の最大 Redis レイテンシ

2.61 sobotka

0.72 lamar

0.01 delancie-query-alert

0.01 templeton

1 時間

36


2.61s最大 Redis レイテンシ 1 時間

単一値のサマリー単一値のサマリーには、特定のメトリクスクエリの現在値が条件を示す書式設定（緑 / 黄/赤の背景など）と共に表示され、値が予想範囲内かどうかが示されます。単一値のサマリーで表示する値は、瞬間的な測定値である必要はありません。このウィジェットには、報告された最新の値、または時間枠全体のすべてのクエリ値から計算された集計を表示できます。

431ホスト

状態が OK のホストの現在の数、本番環境

1 空間を横断する集計本番環境にあるすべてのホストを合計する

2 時間を横断する集計過去 1 時間を合計した平均値を取得する

1 時間

37


単一値のサマリーを使用する場合

対象のメトリクス例例

特定のシステムのワークメトリクス

主要なメトリクスを速やかに視覚化する 1 秒あたりの Web サーバー要求数

最重要のリソースメトリクス

リソースステータスとヘルスの概要を一目で把握できるようにする

ロードバランサの背後にある健全なホスト数

エラーメトリクス潜在的な問題についての注意喚起を素早く行うこと

致命的なデータベースの例外

前の値と比較したメトリクスの変更

重要な傾向を明確に伝える 1 週間前と比較した使用されているホスト数

トップリストトップリストは順位リストであり、ホスト、クラスタ、またはインフラストラクチャの他のセグメントをメトリクス値でランク付けできます。トップリストは非常に分かりやすいリストであり、全体概要を把握するためのハイレベルなステータスボードで特に役立ちます。

38


単一値のサマリーとは異なり、トップリストには空間を横断する集計の追加レイヤーがあり、このレイヤーでメトリクスクエリの値をグループごとに分けることができます。各グループには、単一のホストまたは関連するホストの集合を指定できます。

アベイラビリティゾーン別の最大 Redis レイテンシ

1.74 us-east-1a

0.7 us-east-1b

0.09 us-east-1e

1 空間を横断する集計各アベイラビリティゾーンから最もレイテンシの高いホストを取得する

2 時間を横断する集計過去 1 時間の最大瞬間値を取得する

1 時間

トップリストを使用する場合


異なるホストやグループから取得されたワークメトリクスまたはリソースメトリクス

外れ値、低パフォーマンス、またはリソースの過剰消費を一目で把握できるようにする

アプリサーバーごとに処理されたポイント数

値のリストとして返されたカスタムメトリクス

KPI を分かりやすい形式で伝える（たとえば、壁掛のディスプレイのステータスボード）

使用されている Datadog Agent のバージョン

39


推移グラフトップリストには最近のメトリクス値のサマリーが表示されますが、推移グラフではメトリクスの現在値と過去のある時点の値を比較できます。

推移グラフと他の視覚化の主な違いは、推移グラフにはパラメータとして 2 つの異なる時間枠があることです。1 つの時間枠には評価期間を、もう 1 つにはルックバック期間を設定します。

方法別のログイン失敗回数

148 standard

29 oauth2

9 saml

-23%

-47%

-53%

1 空間を横断する集計各ログイン方法について失敗したすべてのログイン回数を合計する

2 時間を横断する集計過去 4 時間のデータを要約する

3 時間を横断する集計 #2昨日の同じ 4 時間の期間のデータを要約して比較する

4 時間

推移グラフを使用する場合


毎日、毎週、または毎月上昇または下降する周期的なメトリクス

周期的な基準値から傾向を分離するためデータベース書き込みスループットの先週の同じ時間との比較

40


ハイレベルなインフラストラクチャメトリクス

大規模な傾向をすばやく特定するため合計ホスト数の昨日の同じ時間との比較

ホストマップホストマップは、インフラストラクチャ全体または一部を簡単に確認できる固有の方法です。ただし、インフラストラクチャを（アベイラビリティゾーン、サービス名、インスタンスタイプ毎に）多次元に分析すると、選択したグループの各ホストが六角形で表示され、これらのホストにより報告されるメトリクスによって色分けされ形状が決定されます。

これは、Datadog 独自の視覚化の手法です。この視覚化は、本章で説明されている一般的な視覚化とは対照的に、インフラストラクチャの監視のために特別に設計されています。

1 空間を横断する集計ホスト別にメトリクスを集計し、アベイラビリティゾーン別にホストをグループ化する

2 時間を横断する集計各ホスト別に報告された最新の値を表示する

41


ホストマップを使用する場合

対象のメトリクス理由例

リソース使用率メトリクス

過剰な負荷がかかっているコンポーネントを一目で把握できるようにするため

アプリホストごとの負荷（クラスタによってグループ化）

リソースの不適切な割り当てを特定するため（たとえば、過剰なサイズまたは過小なサイズに設定されているインスタンス）

EC2 インスタンスタイプごとの CPU 使用率

エラーまたはその他のワークメトリクス

パフォーマンスが低下したホストを迅速に識別するため

サーバーごとの HAPROXY 5XX エラー数

関連するメトリクス単一のグラフで相関を表示するためアプリサーバーのスループットと使用されているメモリの対比

分布分布グラフは、インフラストラクチャのあるセグメント全体におけるメトリクス値のヒストグラムを示します。グラフの各バーは分割された値の範囲を表し、その高さはその範囲の値を報告したエンティティの数と一致します。

分布グラフはヒートマップと密接に関係しています。これらの 2 つグラフの主な違いは、ヒートマップは時間の経過による推移を示すのに対し、分布はある時間枠の要約を示すことです。ヒートマップのように、分布グラフでは特定のメトリクスを報告する多数のエンティティを簡単に視覚化でき、個々のホストまたはコンテナレベルでメトリクスをグラフ化する場合によく使用されます。

42


1 空間を横断する集計ホスト別のレイテンシの平均

2 時間を横断する集計過去の 1 時間のレイテンシの平均を取得する

3 ヒストグラムレイテンシの範囲別にホストの分布をプロットする

分布グラフを使用する場合

対象のメトリクス理由例

多くのエンティティから報告される単一のメトリクス

一般的なヘルスやステータスを一目で把握できるようにするため

ホストごとの Web レイテンシ

グループメンバー間の変化を表示するためホストごとのアップタイム

要約これまで見てきたように、各サマリーグラフにはそれぞれ異なる利点とユースケースがあります。お使いのツールキットで利用できるすべての視覚化と、各タイプをどのような場合に使用するかを理解しておくと、ダッシュボードで有用な情報を明確に伝えることができるようになります。

次章では、Amazon ELB ロードバランサと Docker コンテナという一般的に利用されている 2 つのインフラストラクチャテクノロジに、これらの視覚化の手法を適用して、これらの監視の概念をより具体的に説明します。

43

第 7 章あらゆる情報を一元化する：ELB の監視方法

第 7 章：あらゆる情報を一元化する：ELB の監視方法

Elastic Load Balancing（ELB）は、さまざまなアベイラビリティゾーンにある Amazon EC2 バックエンドインスタンス間で、アプリケーションから受信した Web トラフィックを分散するために使用される AWS サービスです。

ELB は、スムーズなユーザーエクスペリエンスを実現し、フォールトトレランスを向上させ、トラフィックピークや障害が発生した EC2 インスタンスを中断することなく処理するために、Web やモバイルアプリケーションで広く使用されています。

ELB は、健全ではない EC2 インスタンスを継続的にチェックします。不健全な EC インスタンスが検出されると、ELB はこれらのインスタンスが復旧されるまで、ただちにトラフィックを再ルーティングします。アベイラビリティゾーン全体がオフラインになると、Elastic Load Balancing は他のアベイラビリティゾーンのインスタンスにトラフィックをルーティングすることも可能です。Auto Scaling を使用すると、インフラストラクチャで適切な数の EC2 ホストを確実に利用でき、変動するアプリケーションの負荷パターンに対応できます。

44


本章は、次の 2 つの部分から構成されます。

1. 主要な ELB パフォーマンスメトリクス

2. Datadog を使用した ELB の監視

主要な ELB パフォーマンスメトリクスロードバランサは、ユーザーとアプリケーション間にある最初のゲートウェイであり、スケーラブルなインフラストラクチャにとって重要な部分です。ロードバランサが適切に機能しないと、アプリケーションの応答時間が大幅に遅くなったり、まったくアクセスできないエラーが発生したりする恐れがあり、ユーザーの不満を募らせたり、トランザクションの損失につながる場合があります。そのため、ロードバランサとその背後にある EC2 インスタンスが正常な状態を維持できるようにするには、ELB のパフォーマンスを継続的に監視し、その主要なメトリクスを十分に理解する必要があります。監視する ELB パフォーマンスメトリックには、次の 2 つの大きなカテゴリに分類されます。

－ロードバランサメトリクス

－バックエンド関連のメトリクス

以下に簡単に説明するすべてのメトリクスは、Amazon の監視サービスである CloudWatch から利用できます。

メトリクスの種類（例：ワークメトリクスとリソースメトリクス）を忘れてしまった方は、第 2 章で説明した分類法をもう一度参照してください。

45


ロードバランサメトリクス

ELBクライアント

ロードバランサメトリクス

バックエンドインスタンス

検討するべきメトリクスの最初のカテゴリは、ロードバランサに登録されるバックエンドインスタンスではなく、ロードバランサ自体に関連します。AWS CloudWatch では通常、これらすべての集計が使用できるため、各メトリクスについて、最も関連性が高く、監視するために有用な時間の集計（sum、avg、min、または max）をここに記載します。

名前説明メトリクスの種類

REQUESTCOUNT 選択された期間中に受信され、登録された EC2 インスタンスに送信された要求 ELB の数（SUM）

ワーク：スループット

SURGEQUEUELENGTH バックエンドインスタンスにより受け入れて処理されるのを待機している受信要求の数（max）

リソース：サチュレーション

SPILLOVERCOUNT 選択された期間中に完全なサージキューのために拒否されたという要求の数（SUM）

ワーク：エラー（リソースが飽和しているため）

HTTPCODE_ELB_4XX* 選択した期間にロードバランサによって返されたクライアントエラーの数（SUM）

ワーク：エラー

HTTPCODE_ELB_5XX* 選択した期間にロードバランサによって返されたサーバーエラーの数（SUM）


* Elastic Load Balancing では、1 つまたは複数のリスナーを構成する必要があります。リスナーとは、接続要求を確認する ELB のプロセスです。上記の HTTPCODE メトリクスは、リスナーがフロントエンド接続とバックエンド接続の両方の HTTP または HTTPS プロトコルで構成されている場合にのみ使用できます。

アラートをオンにするメトリクス－ RequestCount:このメトリクスは、ロードバランサが処理しているトラフィッ

ク量を測定します。この重要なメトリクスのピークとドロップを常に監視することで、インフラストラクチャの問題や DNS のような上流の問題を示している可能性がある大きな変化についてアラートを発行できます。Auto Scaling を使用していない場合は、要求数が大きく変化する時期を把握しておくと、ロードバランサを支援するインスタンス数を調整するべき時期を把握できるようになります。

46


－ SurgeQueueLength:バックエンドインスタンスがすべてロードされ、それ以上の要求を処理できなくなると、受信した要求はキューに入れられるため、レイテンシが増加し、ユーザーによるナビゲーションが遅くなったり、タイムアウトエラーが発生したりする可能性があります。そのため、このメトリクスはできるだけ低く、理想的にはゼロにしておく必要があります。「最大」統計は、このメトリクスで最も関連性の高いビューであり、キューにある最大の要求数が表示されます。これは技術的にはリソースメトリクスですが、キューが過度に長くなると処理エラーが発生するため、注意して監視する価値があります（下記の「SpilloverCount」を参照）。

－ SpilloverCount:SurgeQueueLength がキューに入れられた要求数の最大値 1,024 に達すると、新しい要求はドロップされ、ユーザーには 503 エラーが表示され、スピルオーバー回数のメトリクスが増分します。健全なシステムでは、このメトリクスは常にゼロにならなければなりません。

－ HTTPCode_ELB_5XX:このメトリクスは、正しく処理できなかった要求の数をカウントします。さまざまな根本原因があります。

－ 502 (Bad Gateway)：バックエンドインスタンスは応答を返しましたが、ロードバランサが正しく機能していなかったか、または応答が不正な形式であったため、ロードバランサは応答を解析できませんでした。

－ 503 (Service Unavailable)：このエラーは、バックエンドインスタンスまたはロードバランサから発生します。要求を処理するための十分なキャパシティがなかったために発生する場合があります。インスタンスが正常に動作しており、ロードバランサに登録されていることを確認します。

－ 504 (Gateway Timeout)：応答時間が ELB のアイドルタイムアウトの制限を超過しました。レイテンシ（下記のバックエンドメトリクスの表を参照）が高く、5xx エラーが ELB によって返されるかどうかを確認し、原因を確認できます。そのような場合は、バックエンドを拡張するかアイドルタイムアウトの制限値を増やして、ファイルのアップロードなどの低速な操作をサポートすることを検討します。インスタンスが ELB との接続を閉じている場合は、ELB アイドルのタイムアウト値よりも長いタイムアウト値を設定してキープアライブ設定を有効にする必要があります。

47


HTTPCODE_ELB_4XX についての注：このメトリクスは基本的には、ELB に送信されたエラーの要求数を測定するため、通常、4XX エラーについてはユーザーができることはほとんどありません。調査が必要な場合、ELB のアクセスログを確認して、どのコードが返されたのかを判断できます。

バックエンド関連のメトリクス

ELB

バックエンドメトリクス

クライアントバックエンドインスタンス

CloudWatch は、応答のレイテンシや ELB ヘルスチェックの結果など、バックエンドインスタンスのステータスとパフォーマンスに関するメトリクスも提供します。ヘルスチェックは、ELB が不健全なインスタンスを特定して、要求を他の健全なインスタンスにルーティングできるようにするメカニズムです。デフォルトのヘルスチェックを使用するか、AWS コンソールで異なるプロトコル、ポート、または正常 / 異常を示すしきい値を使用するように構成できます。ヘルスチェックの頻度はデフォルトで 30 秒ですが、この間隔は 5 〜 300 秒の間で任意に設定できます。


HEALTHYHOSTCOUNT* 各アベイラビリティゾーンにある健全なインスタンスの現在の数リソース：アベイラビリティ

UNHEALTHYHOSTCOUNT* 各アベイラビリティゾーンにおいてヘルスチェックでエラーになったインスタンスの現在の数

リソース：アベイラビリティ

LATENCY ロードバランサとバックエンド間におけるラウンドトリップ要求の処理時間

ワーク：パフォーマンス

HTTPCODE_BACKEND_2XX


選択した期間内に登録されたバックエンドインスタンスによって戻された HTTP 2XX（成功）/3XX（リダイレクト）コードの数

ワーク：成功



選択した期間内に登録されたバックエンドインスタンスによって戻された HTTP 4XX（クライアントエラー）/ 5XX（サーバーエラー）コードの数


BACKENDCONNECTION ERRORS

ロードバランサと健全と考えられるバックエンドインスタンス間で試行されたものの失敗した接続数

リソース：エラー

* これらの回数は、インフラストラクチャのインスタンス数と必ずしも一致しない場合があります。クロスゾーン負荷分散が ELB で有効な場合（さまざまなアベイラビリティゾーンでトラフィックを均等に分散させるため）、ロードバランサに接続しているすべてのインスタンスは、Cloudwatch によってすべてのアベイラビリティゾーンの一部としてみなされます。そのためあるアベイラビリティゾーンに 2 台の健全なインスタンスがあり、別のアベイラビリティゾーンに 3 つある場合、Cloudwatch はアベイラビリティゾーンにつき 5 台の健全なホストを表示します。

48


アラートをオンにするメトリクス－ Latency：このメトリクスは、ロードバランサ自体のレイテンシではなく、バッ

クエンドインスタンスによる要求の処理によるアプリケーションレイテンシーを測定します。バックエンドのレイテンシを追跡すると、アプリケーションパフォーマンスに関する有用な情報を取得できます。この値が高すぎる場合、タイムアウトによって要求がドロップされる恐れがあります。レイテンシが高くなるのは、ネットワークの問題、バックエンドホストの過負荷、または最適化されていない構成が原因である場合があります（たとえば、キープアライブを有効にするとレイテンシを減らすことができる場合があります）。

注目すべきメトリック－ BackendConnectionErrors：ELB とサーバー間の接続エラーは、ELB がバッ

クエンドへの接続に失敗したときに発生します。この種類のエラーは通常、ネットワークの問題かバックエンドインスタンスが正しく実行されていないことが原因です。ELB 要求のエラーとレイテンシについてすでにアラートを発行している場合は、ユーザーに直接影響しない接続エラーについてはアラートを出したくない場合もあるでしょう。

バックエンドとの接続に失敗した場合、ELB は再試行しますので、このカウントは要求率よりも高くなる可能性があります。

タイムアウトについて要求ごとに、クライアントとロードバランサの間に 1 つの接続、およびロードバランサとバックエンドの間に 1 つの接続があります。そして、各要求について、ELB は全体的なアイドルタイムアウトを設定しています（デフォルトで 60 秒）。この 60 秒以内に要求が完了しないと接続は閉じられます。必要に応じて、このアイドルタイムアウトを増大し、ファイル転送などの長い操作を確実に完了させることができます。

49


EC2 バックエンドインスタンスの設定でキープアライブを有効にし、ロードバランサがバックエンドホストとの接続を再利用するようにできますが、リソース使用率が低下する場合があります。キープアライブの時間が、ELB のアイドルタイムアウトよりも長く設定されていることを確認してください。そうすることで、ロードバランサが接続を閉じる前に、バックエンドインスタンスが接続を閉じることがなくなります。そうなっていないと、ELB は不健全なバックエンドホストとして間違ってフラグを立てます。

全体像を把握するためのホストメトリクスバックエンドインスタンスのヘルスとロードバランサのパフォーマンスは直接関係します。たとえば、バックエンドインスタンスの CPU 使用率が高いと、要求がキューに入れられる可能性があります。これらのキューは、最終的に設定されている最大の長さを超過し、要求をドロップし始める恐れがあります。そのため、バックエンドホストのリソースを監視することは非常に有用です。

さらに、バックエンドから返される HTTP コードに関する ELB メトリックスはサーバーのハイレベルのビューを提供しますが、EC2 インスタンスを直接監視することでサーバーに関するより詳細で有用な情報を得ることができます。

これらの理由から、ELB のパフォーマンスと健全性の全体像を把握するには、EC2 インスタンスのメトリクスも合わせて監視します。本章の次のセクションでは、ELB メトリクスと EC2 メトリクスを関連付けることで、インフラストラクチャをさらに明確に可視化する方法について詳しく説明します。

メトリクスのまとめ上記の表では、最も重要な Amazon ELB のパフォーマンスメトリクスについて概説しました。Elastic Load Balancing を使用し始めたばかりの場合は、以下のメトリクスを監視することで、ロードバランサやバックエンドサーバーの正常性とパフォーマンスに関する有用な情報が得られます。

－要求数

－サージキューの長さとスピルオーバー数

－ ELB 5xx エラー

－バックエンドインスタンスの健全性の状態

－バックエンドのレイテンシ

AWS マネジメントコンソールまたは AWS コマンドラインインターフェイスを使用してこれらのメトリクスの値を確認できます。両方のアプローチについての詳細は、次のブログ記事を参照してください。http://dtdg.co/collect-elb-metrics

インフラストラクチャを包括的に把握するには、ELB を動的ですべての機能を利用できる監視システムに接続します。次のセクションでは、Datadog を使用して、主要なすべての ELB メトリクスやその他のメトリクスを監視する方法を説明します。

http://dtdg.co/collect-elb-metrics

50


Datadog を使用した ELB の監視Datadog を使用すると、ELB のメトリクスを表示し、時間による推移を追跡し、プロパティまたはカスタムタグの任意の組み合わせを使用し、多次元な分析を行うことができます。さらに重要なのは、有用な情報を得るために、ELB のメトリクスをインフラストラクチャの他の部分のメトリクスと相関させることもできます。

Datadog は、ELB、EC2、ElastiCache、RDS、および他の AWS サービス、さらに 280 を以上の追加のテクノロジから監視データを収集します。一般的なコラボレーションおよびコミュニケーションツールがサポートされており、PagerDuty、Slack などを使用して詳細なアラートを作成してチームに送信できます。

この記事では、ELB インテグレーションを開始する方法、およびロードバランサのパフォーマンスメトリクスとバックエンドインスタンスのメトリクスを関連付ける方法について説明します。

Datadog と ELB の統合AWS CloudWatch とのインテグレーションを構成するだけで、ELB メトリクスの監視を開始できます。CloudWatch メトリクスに対して読み取り専用アクセスを Datadog に付与する場合、ここで説明されている手順に従ってください。http://docs.datadoghq.com/integrations/aws/

これらの認証情報を AWS で構成したら、Datadog アプリの AWS インテグレーションタイルで簡単な手順を実行して、ELB データの取得を開始します。

すべての主要な ELB メトリクスに注意するDatadog と ELB を統合したら、Datadog アプリのダッシュボードリストに「AWS ELB」という名前の構築済みのダッシュボードが表示されます。ELB ダッシュボードには、本章の前半で説明した、1 秒あたりの要求数、レイテンシ、サージキューの長さ、スピルオーバーの回数、健全および不健全なホスト数、返される HTTP コードなどの主要なメトリクスがすべて表示されます。

http://docs.datadoghq.com/integrations/aws/

http://docs.datadoghq.com/integrations/aws/

51


ダッシュボードのカスタマイズDatadog で Elastic Load Balancing からメトリクスを取得したら、テンプレートダッシュボードを基準にして、ELB やインフラストラクチャの他の部分のメトリクスを追加できます。ダッシュボードのカスタマイズを開始するには、ダッシュボードの右上にある歯車のアイコンをクリックしてテンプレートのクローンを作成します。

EC2 メトリクスと ELB の相関本章の前半で説明したように、CloudWatch の ELB 関連のメトリクスからロードバランサのヘルスとパフォーマンスを把握できます。また ELB は、バックエンドインスタンスのヘルスとパフォーマンスを反映するメトリクスも提供します。しかし、インフラストラクチャを包括的に監視するために、EC2 からメトリクスを収集することも検討してください。ELB メトリクスを EC2 メトリクスと相関することで、たとえば、ロードバランサによってキューに入れられている要求が多くある場合、その理由がバックエンドインスタンスのリソースの飽和（メモリ使用量、CPU 使用率など）によるものであるかどうかをすばやく調査できます。

CloudWatch とのインテグレーションと設定した権限によって、Datadog の EC2 メトリクスにアクセスできます。あらかじめ構築されている「AWS EC2」ダッシュボードは、EC2 リソースメトリクスを監視するための優れた出発点になります。

構築済の ELB Datadog のダッシュボード

52


カスタムダッシュボードにグラフを追加し、ELB と EC2 のメトリクスを並べて表示できます。これにより、さまざまなメトリクスの傾向を簡単に相関できます。

ELB ダッシュボードにホストマップ（本書の第 6 章に詳述）などのサマリーグラフを追加することもできます。たとえば、このホストマップを見ると、バックエンドインスタンスの CPU 使用率が過度に高い場合に一目で把握できます。

テンプレート EC2 Datadog のダッシュボード

53


さらに正確なネイティブメトリクスCloudWatch から EC2 メトリックスを取得するだけでなく、Datadog では、サーバーからネイティブメトリックスを直接取得し、EC2 インスタンスのパフォーマンスを監視できます。Datadog Agent はオープンソースソフトウェアで、各ホストからメトリクスを収集して報告し、Datadog アプリでメトリクスを表示、監視、および相関できるようにします。Agent を使用すると、バックエンドインスタンスのメトリクスをさらに細かい粒度で収集し、インスタンスのヘルスとパフォーマンスをより正確に表示できます。

Agent を設定し、EC2 インスタンスのネイティブメトリクスを ELB の CloudWatch メトリクスと相関すると、インフラストラクチャの全体と詳細を把握できます。

CPU、メモリなどのシステムレベルのメトリクスに加えて、Agent はアプリケーションメトリクスも収集しますので、アプリケーションパフォーマンスをコンピュートレイヤーのリソースメトリクスと相関することができます。Agent は、MySQL、NGINX、Redis などのテクノロジとシームレスに統合します。StatsD メトリクス収集プロトコルのタグ付けを有効にした拡張である DogStatsD を使用し、内部アプリケーションからカスタムメトリクスを収集することもできます。

Agent のインストール手順は、さまざまなオペレーティングシステム、および Chef、Puppet、Docker、Kubernetes などのプラットフォーム用の Datadog アプリで参照できます。

ELB 監視の基本本章では、ELB を適切に管理するために監視が必要な主なメトリクスについて説明しました。また、Elastic Load Balancing と Datadog を統合することで、インフラストラクチャをより包括的に把握できるビューを構築する方法についても説明しました。

Datadog を使用して監視することで、ロードバランサ、バックエンドのインスタンス、およびアプリケーションで何が起こっているのを的確に視覚化できます。インフラストラクチャと使用パターンに正確に合わせたトリガーを使用し、任意のメトリックに対してアラートを簡単に自動で発行できます。

Datadog アカウントを取得されていない場合は、www.datadog.com から無料トライアルにサインアップし、すべてのホスト、アプリケーション、およびサービスの監視を開始いただけます。

http://www.datadog.com

54

第 8 章あらゆる情報を一元化する：Docker の監視

第 8 章：あらゆる情報を一元化する：Docker の監視

Docker は最近登場したコンテナテクノロジの 1 つであり、非常に勢いがあります。コンテナはすばやく起動でき（通常は 1 秒以内）、簡単に構成できる軽量な仮想マシンのようなものです。コンテナは、マイクロサービスアーキテクチャ、またはすばやくスケーリングされたり頻繁にリリースされたりする環境にとって最適です。

本章では、Docker がどうして動的なインフラストラクチャの代表となっているのかについて、そして Docker で最新の監視アプローチが必要である理由について説明します。本章は、次の 3 つの部分から構成されます。

1. Docker を監視するときの課題

2. 主な Docker リソースメトリクス

3. iHeartRadio 社による Docker の監視方法

55


Docker を監視するときの課題コンテナは運用に関するいくつかの重要な問題を解決します。その能力こそが Docker がインフラストラクチャの世界を席巻している理由です。

しかし、問題もあります。コンテナ環境は動的であり、急速に変化するため、物理ホストや仮想ホストと比較すると、監視や管理が非常に困難になる恐れがあります。

コンテナとは？コンテナは軽量な仮想の実行環境（ランタイム）です。コンテナの主な目的はソフトウェアを分離することです。ソフトウェアを分離するために一般的に使用される環境には、次の 3 つがあります。

1. 物理マシン（重量級）

2. 仮想マシン（中程度）

3. コンテナ（軽量）

コンテナへとアーキテクチャが移行していますが、他のアーキテクチャへの移行と同じように、これは新たな運用に関する課題が生まれることを意味します。一般的な課題には、オーケストレーション、ネットワーキング、および構成があります。実際、これらの課題に対処するための多くのプロジェクトが現在登場しています。

しかし、コンテナを監視するという運用上の重大な課題は、あまりよく理解されていません。

Docker の監視は極めて重要監視せずに本番環境でソフトウェアを稼働させることは、視界ゼロの状態で車を運転するようなものです。衝突する寸前なのか、正しく走行しているかどうかも把握することはできません。

= アプリケーション

ハイパバイザー

モニター

モニター

56


監視する必要があることは十分に理解が進んでおり、次のような従来型の監視ソリューションが従来のスタックに対応します。

－アプリケーションパフォーマンス監視は、カスタムコードを計測し、ボトルネックやエラーを特定します

－インフラストラクチャ監視は、CPU の負荷や利用可能なメモリなど、ホストに関するメトリクスを収集します

= アプリケーション = オフザシェルフコンポーネント

ハイパバイザー

コンテナ

モニター

モニター

ギャップ

しかし、本章の後半で説明しますが、コンテナは、アプリケーションパフォーマンス監視や従来型のインフラストラクチャ監視を適用しても効果的ではない、ホストとアプリケーションの間のトワイライトゾーン（曖昧な領域）に存在します。これにより、監視戦略に死角が生まれることになりますが、これはコンテナにとって、そしてコンテナを利用する企業にとって大きな問題です。

57


コンテナの概要従来型の監視ツールにとってコンテナが大きな問題である理由を理解するために、コンテナの仕組みについてさらに掘り下げて見ていきましょう。

簡単に言うと、コンテナとは、ソフトウェアを分離して実行する方法を提供します。これはプロセスでもホストでもなく、プロセスとホストがつながる場所のどこかに存在します。

コンテナは、オーバーヘッドが少なく、セキュリティ上の利点もあります。しかし、コンテナを採用する重要な理由は他に 2 つあります。それらの理由とは、スケーリングのしやすさと複雑な依存関係からの脱却です。

スケーリングのしやすさDocker のようなコンテナテクノロジを使用すると、Kubernetes や ECS などのプロジェクト / サービスを使用してプログラムコードによって新しいコンテナを簡単に展開できます。他のシステムに影響を及ぼすことなくシステムのさまざまな部分をスワップアウトまたはスケールアップできるように、マイクロサービスアーキテクチャを使用してシステムを設計している場合、パターンを確立して容易にスケーリングできるようになります。このようなシステムは弾力性があり、負荷に応じて自動的に拡張または縮小でき、ダウンタイムなしでリリースを展開できます。

複雑な依存関係からの脱却

共有ライブラリパッケージオムニバス Dockera.out

58


コンテナの 2 つ目の利点は、恐らく１つ目の利点よりも重要ですが、エンジニアが極めて複雑な依存関係から脱却できることです。以前は、ライブラリは実行可能ファイルに直接コンパイルされていましたが、大規模なライブラリが希少な RAM をすべて枯渇させるようになるまでは問題ではありませんでした。最近では、共有ライブラリが一般的になり、実行時に必要なライブラリが利用できない場合や 2 つのプロセスが同じライブラリの異なるバージョンを必要とする場合、依存関係という新しい問題が発生するようになりました。

今日では、ソフトウェアエンジニアや運用担当のエンジニアはコンテナを利用して、同じホスト上で実行されている他のソフトウェアによる影響を受けない軽量で隔離された仮想の実行環境に小規模なホスト全体をパッケージ化でき、複雑な依存関係から脱却できるようになりました。この場合、Git（分散型バージョン管理システム）にチェックインし、コードのようにバージョン管理できるマニフェストが必ず使用されます。

コンテナの課題：大規模運用の複雑さコンテナは基本的には小規模なホストです。ホストの運用についてのベストプラクティスは確立されていますので、コンテナの運用についても基本的に同じであると思われるかもしれませんが、そうではありません。

ホストの増殖= アプリケーション = オフザシェルフコンポーネント

アプリケーションアプリアプリ

OSOS OSOS OS

オフザシェルフオフザシェルフ

コンテナ

オフザシェルフ

ハードウェアハードウェアハードウェア

ハイパバイザーハイパバイザー

59


上の図は、過去 15 年間で標準的なアプリケーションスタックがどのように進化したかを示しています。（「オフザシェルフ」は、J2EE ランタイムまたはデータベースである場合があります。）

－左図：15 年前

－中央図：約 7 年前、EC2 のようなサービスによる仮想化が広く採用されるようになりました。

－右図：今日、仮想化されたハードウェア上で動作するコンテナスタックが人気になっています。

Datadog が収集しているデータから、Docker を採用している平均的な企業は各ホストで同時に 8 台のコンテナを実行していることがわかりました。コンテナは従来のホストよりも寿命が短い傾向があることを考えると、平均的な VM はその寿命において 14 台のコンテナを実行します（その他の Docker データは dtdg.co/dckr-adopt を参照してください）。

メトリクスの爆発的な増加コンテナを使用すると、ホストあたりのメトリクス数が数倍に膨れ上がります。オペレーティングシステムと 1 つまたは 2 つのオフザシェルフコンポーネントを監視しているような状況ではありません。コンテナを使用している場合、オペレーティングシステム、ホスト上の各コンテナ、およびそれらのコンテナで実行されている各コンポーネントを監視することになります。インフラストラクチャの稼働部分のそれぞれが、5 または 6 つの稼働部分に置換され、それぞれが独自のメトリクスを報告するようなものです。

さらに、ホストの寿命はコンテナの寿命よりはるかに長く、平均で 6 倍です。平均的なアップタイムが日数、週数または月数で測定される短命または長命の EC2 インスタンスが混在する場合とは異なり、コンテナの平均的なアップタイムは分または時間で測定されます。

問題をさらに複雑にするのは、新しいバージョンのコンテナが作成され、git commit が可能になるとすぐにコンテナを展開できるようになることです。複数のコンテナを毎日のようにローテーションさせて自社で使用するようになります。

このような環境を管理するには、Kubernetes や AWS ECS を使用して手動の命令型のプロビジョニングから自律的で宣言型のプロビジョニングに移行することになります。たとえば、「各ゾーンのインスタンスごとに常にタイプ X のコンテナが 1 台必要である」と指定することができ、スケジューラはこの条件を常に満たすことができることを確認します。このような自動化は現在のコンテナアーキテクチャでは必須ですが、新たな混乱も生み出します。

要約すると、コンテナを使用すると、多くのことをはるかに速く実行できます。

60


ホストを中心とする監視

ホストを中心に監視する場合、お使いの環境は天動説の天文学のように複雑になります。この方法で惑星の動きを説明することは非常に困難です。ホストを中心とする監視ツールをコンテナ環境に合わせようとすると、次の 2 つの選択肢しか残されないことになります。

1. コンテナを数分ごとに追加または削除されるホストとして扱う。この場合、監視システムは常にインフラストラクチャの半分が緊急事態にあると捉えるため、監視担当のユーザーの人生は悲劇になります。

2. コンテナをまったく追跡しない。オペレーティングシステムとアプリで何が発生しているのかは把握できますが、前述したように、これらの間にあるものすべては監視の死角（ギャップ）となります。

これまでホストを監視していたのと同じ方法でコンテナを監視することを計画している場合は、非常に大きな痛みを伴うことになります。

ゴール：簡潔な監視

61


一方こちらは運用監視のモダンなアプローチであり、すべてをホストとして扱わない方法になります。

上の写真はコペルニクスの天文学を表しています。地球を宇宙の中心に置くことと比較して、コペルニクスの提案はとても簡明です。

ホストを中心にせずに、レイヤーやタグを中心とする新しい視点で監視することにより、複雑さは解消され、円滑かつ簡単な運用を実現できます。

レイヤー

= アプリケーション = オフザシェルフコンポーネント

OS OS

コンテナ

ハイパバイザー CloudWatch CPU/ ネットワーク /IO

インフラストラクチャの監視

ファイルシステムdocker メモリdocker CPU

db クエリWeb 要求数

APM アプリのスループット

ギャップなし視界ゼロの状態で走行しないようにするためにも、スタック全体をギャップなく上位レベルから下位レベルに監視することをお勧めします。EC2 を使用している場合は、おそらく CloudWatch を使用して VM を監視し、インフラストラクチャ監視ツールを中間部に使用し、アプリケーションパフォーマンス監視を上位レベルで使用してスループットを測定し、コード内の問題箇所を特定しているのではないでしょうか。

62


タイムラインは 1 つ

レイヤーの監視を成功させるには、レイヤー間で何が同時に起こっているのかを把握でき、スタックの一部の問題がスタックの他の部分にどのように波及するかを判断できるようにする必要があります。たとえば、アプリケーションの応答時間が遅いにもかかわらず、それが VM レイヤーにおける I/O の急上昇が原因であることを識別できないのであれば、その監視方法では問題を解決できません。

タグ

コンテナを効果的に監視するには、第 2 章で詳しく説明しているように、コンテナにタグを付ける（ラベルを付ける）必要もあります。幸い、すでに AWS やサーバー自動化ツールを通じてタグを使用している可能性があります。

63


タグを中心とした監視環境に移行することで、命令型から宣言型へと戦略を変更できます。これは、グループの自動スケーリングや Docker オーケストレーションが動作する仕組みに似ています。特定のホストやコンテナを監視するようにシステムに命令するのではなく、たとえば同じアベイラビリティゾーンにあるすべてのコンテナのように、共通のプロパティ（タグ）があるすべての要素を監視するようにシステムに命令できます。

タグを使用すると、次のような強力なクエリを使用してコンテナを監視できます（タグが使用される箇所は太字で示します）。

全アベイラビリティゾーンにわたるリージョン us-west-2 で c3.xlarge の平均メモリの 1.5 倍以上を使用する imageweb を実行しているすべての Docker コンテナを監視できます。

要点コンテナによりソフトウェアの複雑な依存関係から脱却できるようになり、スケーラブルなソフトウェアアーキテクチャの基盤が提供されるため、本番環境での普及が進んでいます。

ただし、通常使用されるコンテナ数は多く、その寿命は非常に短いため、運用の複雑さが容易に 1 ケタ増大する恐れがあります。このため、現在、コンテナを使用する多くのスタックは、コンテナそのものの監視ができていません。これにより大きな死角が生まれ、システムでダウンタイムが発生する可能性が高まります。

したがって、Docker を効果的に使用するためには、以下の対策が求められます。

1. スタックのすべてのレイヤーをまとめて監視し、ギャップを生み出すことなく、あらゆる場所で何が起こっているのかを同時に確認できるようにします。

2. コンテナにタグを付けて、個々のコンテナではなくクエリが可能なコンテナ群として監視できるようにします。

本章の次のセクションでは、Docker の監視で利用できる主なメトリクスについて説明します。

主な Docker リソースメトリクス覚えているかもしれませんが、Docker は小規模なホストのようなものです。通常のホストと同様に、常駐ソフトウェアの代わりに作業を実行し、その作業では、CPU、メモリ、I/O、およびネットワークリソースが使用されます。ただし、Docker コンテナは cgroup で実行されるため、ホストと同じようなメトリクスが報告されるわけではありません。

64


CPU


ユーザー CPU CPU がプロセスによって直接制御されている時間の割合リソース：利用率

システム CPU CPU がプロセスの代わりにシステムコールを実行している時間の割合リソース：利用率

ストロットリング（数）コンテナの CPU スロットリングの実施回数リソース：サチュレーション

ストロットリング（時間）コンテナの CPU 使用率がスロットリングされた合計時間リソース：サチュレーション

標準的なメトリクス従来のホストと同じように、Docker コンテナはシステムCPU とユーザーCPU の使用状況を報告します。もちろん、コンテナのパフォーマンスが低い場合には、最初に確認するリソースの 1 つは CPU です。

コンテナとホストとの 1 つの重要な相違点：従来のホストとは異なり、Docker は nice、idle、iowait、または irq の CPU 時間を報告しません。

ストロットリングDocker に十分な CPU キャパシティがあるが、それでもコンピュートキャパシティによる制約が問題と考えられる場合は、コンテナ固有のメトリクスである CPU スロットルを確認します。スケジューリングの優先度を指定しない場合、使用可能な CPU 時間は実行中のコンテナ間で均等に分割されます。割り当てられた CPU 時間のすべてを必要としないいくつかのコンテナがある場合、他のコンテナで利用できる CPU 時間は比例することになります。

CPU シェアを指定することで、同じ CPU を使用する他のコンテナに対する CPU 時間のシェアを各コンテナで任意に制御できます。

さらに、コンテナは積極的にスロットリングできます。場合によっては、コンテナのデフォルトまたは宣言された CPU シェアによって、必要以上に CPU 時間が付与される場合あります。そのような場合、コンテナが実際にその CPU 時間を使用しようとすると、CPU クォータ制限により、コンテナの CPU 使用率をストロットリングするタイミングが Docker に指示されます。CPU クォータと CPU 期間はどちらもマイクロ秒で表されます（ミリ秒やナノ秒ではありません）。つまり、0.1 秒の間に CPU 時間の半分以上を使用しようとする場合、100,000 マイクロ秒の期間と 50,000 マイクロ秒のクォータが設定されたコンテナがスロットリングされます。

Docker は、各コンテナについてスロットリングが強制された回数、および各コンテナがスロットリングされた合計時間をユーザーに通知します。

メモリDocker は、使用可能なメモリ量と使用しているメモリ量を報告できます。

65



メモリコンテナのメモリ使用リソース：利用率

RSS プロセス用の非キャッシュメモリ（スタック、ヒープ、その他）リソース：利用率

キャッシュメモリメモリにキャッシュされたディスクのデータリソース：利用率

SWAP 使用中のスワップスペースの量リソース：サチュレーション

使用されているメモリは、次のように細分化できます。

－ RSS（プロセスが確保している物理メモリサイズ）は、プロセスに属するデータ（スタック、ヒープなど）です。RSS はさらにアクティブメモリと非アクティブメモリ（active_anon と inactive_anon）に分解できます。非アクティブな RSS メモリは、必要に応じてディスクにスワッピングされます。

－キャッシュメモリは、ディスクに保存されているデータで、現在メモリにキャッシュされているメモリを反映します。キャッシュはさらにアクティブメモリと非アクティブメモリ（active_file、inactive_file）に分解できます。システムでメモリを必要となるときに、非アクティブメモリが最初に再利用されることがあります。

Docker は、現在使用中のスワップの量についても報告します。パフォーマンスや安定性の問題を調査するのに役立つ可能性があるその他のメトリクスに、ページフォールトがあります。ページフォールトは、セグメンテーションフォールトまたはメモリではなくディスクからのデータのフェッチを示します（それぞれ pgfault および pgmajfault というメトリクスになります）。

従来のホストと同じように、パフォーマンスの問題がある場合に最初に検討する必要があるメトリクスには、メモリの可用性とスワップの使用量があります。

I/Oブロックデバイスごとに、Docker は読み取りと書き込み、同期と非同期の I/O の 2 つのメトリクスを 4 つのカウンタに細分化してレポートします。


処理された I/O サイズに関係なく、実行された I/O 操作の回数リソース：利用率

I/O 処理バイト CGROUP により読み取りまたは書き込まれたバイト数リソース：利用率

ブロック I/O は共有されているので、上記のコンテナ固有の I/O メトリクスに加えて、ホストのキューと処理時間を追跡すると役立ちます。コンテナが使用するブロックデバイスでキューの長さや処理時間が増加していると、コンテナの I/O が影響を受けます。

66


ネットワーク通常のホストと同じように、Docker はさまざまなネットワークメトリクスを報告できます。各メトリクスはインバウンドとアウトバウンドのネットワークトラフィックの別々のメトリクスに分けられます。


バイト数ネットワークトラフィックボリューム（送信 / 受信）リソース：利用率

パケット数ネットワークパケット数（送信 / 受信）リソース：利用率

エラー（受信）エラーがある状態で受信したパケット数リソース：エラー

エラー（送信）パケット送信のエラー数リソース：エラー

ドロップドロップされたパケット（送信 / 受信）リソース：エラー

メトリクスのまとめDocker は、従来のホストと同じように、CPU、メモリ、I/O、およびネットワークのすべての基本的なリソースメトリクスを報告できます。ただし、従来のホストで取得できる特定のメトリクス（nice、idle、iowait、irq の CPU 時間など）は利用できません。また、CPU スロットリングなどコンテナ固有のメトリクスもあります。

次のセクションでは、大手のメディア企業のエンジニアリングチームと深く連携し、大規模な Docker 環境を監視するためにこれらのメトリクスをどのように利用しているかを調べます。

iHeartRadio 社による Docker の監視方法iHeartRadio 社は、iHeartMedia の音楽ストリーミングおよびデジタルラジオのプラットフォームであり、パーソナライズされたアーティストステーション、米国内の何千もの生放送のラジオ局、米国のあらゆる場所からアクセスできるオンデマンドポッドキャストを提供しています。Web、モバイル、タブレット、車載デバイス、スマートテレビ、ゲーム機器など、さまざまな多くのデバイスやプラットフォームで利用できます。

iHeartRadio 社が Docker を使用する理由iHeartRadio 社は巨大なユーザーベースを抱えており、確実にサービスを提供するためにインフラストラクチャを拡張すること自体が課題となっています。しかし、プラットフォームの課題もあります。10 を超えるモバイルプラットフォーム、すべての主要な Web ブラウザ、家庭用のコネクテッド製品、車載デバイス、さまざまなウェアラブルデバイスなど、60 以上のプラットフォームをサポートしています。同社は、数千のライブラジオ局をストリーミング配信し、多くの CMS やパートナーと統合しています。

iHeartRadio 社は、単一のモノリシックアプリケーションで全ユーザーと全データストリームをサポートすることはできないと判断しました。しかし、単一のプラットフォームを使用せずに、安全で安定しているサービスをどのように構築するかが課題となりました。

同社は、小規模なエンジニアグループでも、ロードバランサ、HTTP サーバー、ロギング

67


機能、データベース、監視など、標準的なインフラストラクチャサービスを再構築せずに、非常に特殊なアプリケーションを構築できる簡単な方法を必要としていました。そのため、HAProxy、MongoDB、Elasticsearch などの標準インフラストラクチャサービスを従来型のホストに配置し、それらを内部アプリケーションへのサービスとして利用できるようにしました。また、この企業は各アプリケーションをサイロ化する必要がありました。依存関係の問題を回避する必要があり、各アプリケーションで最低限のリソース（CPU、メモリ、I/O、ネットワーク）を利用できることを保証する必要がありました。そのため、Docker が依存関係とリソースの使用量を制御できるプラットフォームとして登場したときに、同社はすぐに利用することを決断しました。

iHeartRadio 社は、Docker を「宣伝通りの機能」と評価して非常に満足しています。

1 つの重要な欠点iHeartRadio 社は Docker について満足できない点が 1 つだけがありました。それらはコンテナレベルでリソースの使用状況を可視化できないことでした。同社は、従来型の監視ツールを使用していましたが、このツールではホストレベルでのリソースの使用状況しか確認できませんでした。iHeartRadio 社は各ホストで数十台のコンテナを実行しているため、このような可視化ではまったく十分ではありませんでした。

この問題をさらに複雑にしたのは、iHeartRadio 社は多くの企業と同様に、コンテナをペットではなく家畜として扱っており、個々のコンテナのステータスよりも、冗長化され地理的に分散したコンテナによって供給されるサービスのヘルスを重視していました。Docker イメージで集計し、サービスレベルのメトリクスを監視できるようになるため、iHeartRadio 社は、第 2 章で概説したタグを使用してメトリクスを集計する方法を必要としていました。

Datadog を使用した Docker パフォーマンス監視さまざまな監視プラットフォームを徹底的に調査した結果、iHeartRadio 社はインフラストラクチャの監視に Datadog を使用することに決定しました。Datadog 製品を導入するとすぐに、各 Docker コンテナから CPU、メモリ、I/O、およびネットワークメトリクスを収集し、任意のタグによってメトリクスを集計できました。これにより、同社は、コンテナレベル、サービスレベル、または他のタグで定義したレベルで、高精度のリソースメトリクスにアクセスできるようになりました。

優れた設計のマイクロサービスアーキテクチャでは、サービスは直接またはキューを介して通信します。この直接的な通信は監視が難しい場合があります。計測するための中央ロードバランサがなく、標準のホストレベルネットワークメトリクスは、ホスト上のすべてのサービスのトラフィックの測定値を集計します。この集約により問題が隠れてしまい、調査が困難になる恐れがあります。

iHeartRadio 社が Datadog を使用した理由の 1 つは、Datadog がネットワークトラ

68


フィックをイメージとコンテナ別に細分化でき、エンジニアはどのサービスが過負荷になっているのか、また過剰なトラフィック量を送信しているために他のサービスが失敗する原因になっているサービスをすぐに確認できるためです。また、エンジニアはこれらのサービスメトリクスをあらゆる数のホストで集計できます。

さらに、iHeartRadio は、Hadroxy、MongoDB、Elasticsearch などの Docker 以外のサービスの監視にも Datadog を使用しており、エンジニアは Docker パフォーマンスメトリクスをインフラストラクチャ全体のヘルスとパフォーマンスと相関できます。

アラートの発行と調査iHeartRadio 社にとって、内部ネットワークトラフィックの急激な変化は危険性を知らせる最も重要な警告となります。同社は、エンジニアがアラート疲れを起こすことがないように、この情報を使用して、精度の高いアラートを発行しています。前述のように、集計したサービスレベルトラフィックと分離したサービスレベルトラフィックの両方を可視化することが非常に重要なのはこのためです。さらに、Datadog は、測定値が危険とされるしきい値を超過する前でも、ネットワークトラフィックの急激な変化を警告できます。

iHeartRadio 社が Docker から収集するその他のリソースメトリクスは、主に発生した問題を調査するために使用されます（第 4 章を参照）。

iHeartRadio 社のように Docker のパフォーマンスを監視する方法本章の次のセクションに進むには、Datadog アカウントが必要となります。アカウントをお持ちでない場合は、www.datadog.com から無料でトライアルアカウントを取得できます。

Datadog Agent を使用して、Docker 監視環境を設定するためのいくつかのオプションについて説明します。コンテナで Agent を実行する、ホストでコンテナを実行する、サービスディスカバリを使用しあらゆる実行場所でコンテナ化されたサービスを継続的に監視する場合などについて説明します。

iHeartRadio 社が Docker パフォーマンスを監視するために使用している Datadog のダッシュボード


69


エージェントのインストールDocker は、各 Docker ホストのコンテナで実行される Agent を介して Datadog にメトリクスを報告します。

Agent は通常コンテナ内で実行されます。Agent コンテナをダウンロードして起動するには、次の docker run コマンドを実行します。http://dtdg.co/docker-run

オプションで、-e TAGS="simple-tag-0,tag-key-1:tag-value-1" を追加してホストにタグを追加できます。

これだけで、コンテナとそのホストからリソースメトリクスを収集し始めることができます。以下のような構築済みの Docker ダッシュボードをすぐに利用できるようになります。このダッシュボードには、本章の最初に説明した主要なメトリクスが含まれています。上記のように、iHeartRadio は docker.net.bytes_rcvd と docker.net.bytes_sent についてアラートを設定しています。これらのメトリクスはイメージ別に集計されますが、コンテナごとに表示されます。これらの重要なメトリクスは自動的に収集され提供されます。

特定のインテグレーションの有効化同じホスト（NGINX、MySQL など）で実行されているテクノロジからメトリクスを収集する必要がある場合は、適切な設定ファイルを Agent からホストにコピーし、必要に応じて編集して、以下の説明に従ってコンテナにマウントします。dtdg.co/docker-agent#enabling-integrations

http://dtdg.co/docker-agent#enabling-integrations

http://dtdg.co/docker-agent#enabling-integrations

70


これらのテクノロジを他の Docker コンテナ内で実行している場合は、これらのコンテナを Datadog Agent コンテナに接続する必要があります。1.9 より前のバージョンの Docker の場合、コンテナリンクを使用しますが、1.9 以降のコンテナネットワークを使用することを強くお勧めします。どちらの方法でも、同じコンテナにある他のコンテナと名前を使用して通信できるように、各コンテナの /etc/hosts にエントリが作成されます。

構成の検証すべてが正しく動作していることと、インテグレーションによってメトリクスが収集されていることを確認します。

docker exec dd-agent service datadog-agent info

その他のオプション自分の構成とインテグレーションを Datadog Agent のイメージに焼き付けることもできます。dtdg.co/docker-agent#build-an-image

ホストからコンテナのログにアクセスする場合、または Agent を使用せずに直接メトリクスを DogStatsD に送信する場合は、以下の手順に従ってください。dtdg.co/docker-agent#logs

ホストで Agent を直接実行するほとんどの企業は Datadog Agent をコンテナ内で実行しています。すべてがコンテナ化されていると、動的なインフラストラクチャを簡単にオーケストレーションできます。しかし、コンテナ内で Agent を実行する場合、いくつかの制限があります。

1. 他のコンテナのプロセスを表示することはできますが、ホスト自体のプロセスは表示されません。

2. ホストのネットワークメトリクスは報告されません。しかし、各コンテナのネットワークアクティビティを集計して概算できます。

3. API を介してメトリクスを報告しないテクノロジからはメトリクスを収集できません。これらのテクノロジからメトリクスを収集することが重要である場合、これらのテクノロジを Agent と一緒に（コンテナではなく）ホスト上で直接実行する必要があります。

コンテナを使用せずに Agent を直接ホストにインストールした場合でも、同じホストにある Docker コンテナ内からメトリクスを収集できます。Datadog アプリに記載されているお使いの OS でのインストール手順に従って、Docker インテグレーションを有効にします。

http://dtdg.co/docker-agent#build-an-image

http://dtdg.co/docker-agent#logs

http://dtdg.co/docker-agent#logs

71


サービスディスカバリKubernetes や Amazon Elastic Container Service などのプラットフォームを使用してコンテナをオーケストレーションしている場合、コンテナが実行されているホストさえ分からない場合があります。このように基盤が変化している場合、サービスの監視はさらに複雑になります。

Datadog のサービスディスカバリ機能を使用すると、コンテナと同じように監視も自動的にオーケストレーションされます。サービスディスカバリにより、Docker インフラストラクチャがホスト間で拡張、縮小、および変化しても、中断することなく継続的にインフラストラクチャを監視できます。

サービスディスカバリの仕組みサービスディスカバリが有効になっていると、Datadog は継続的に Docker イベントを監視します。コンテナが作成または開始されるたびに、Agent は新しいコンテナでどのサービスが実行されているかを識別し、監視のための構成を取り込んで、メトリクスの収集と報告を開始します。サービス用の構成が定義されていない場合、Agent は、Apache、Memcached、Redis など、比較的単純な設定を使用して、いくつかのサービスを自動的に構成するように試みます。

設定サービスディスカバリを使用するには、構成ストア（etcd または Consul）で監視するイメージの構成テンプレートを最初に定義する必要があります。構成テンプレートの基本構造は次のとおりです。

/datadog/

check_configs/

docker_image_0/

- check_names:["check_name_0"]

- init_configs:[{init_config}]

- instances:[{instance_config}]

docker_image_1/

- check_names:["check_name_1"]

- init_configs:[{init_config}]

- instances:[{instance_config}]

...

また、構成ストアをバックエンドとして使用して、サービスディスカバリを有効にするように Datadog Agent を設定する必要があります。そのためには、datadog.conf ファイルのサービスディスカバリのセクションを編集して、設定を反映させます。例：

service_discovery_backend:docker

sd_config_backend:etcd

sd_backend_host:127.0.0.1

72


sd_backend_port:4001

docker run パラメータとしてこれらの構成オプションをコンテナ化した Agent に渡すこともできます。

docker run -d --name dd-agent \

-v /var/run/docker.sock:/var/run/docker.sock \

-v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \

-e API_KEY=[YOUR_API_KEY] -e SD_CONFIG_BACKEND=etcd \

-e SD_BACKEND=docker -e SD_BACKEND_HOST=127.0.0.1 \

-e SD_BACKEND_PORT=4001 \

datadog/docker-dd-agent:kubernetes

サービスディスカバリの詳細Docker で動的な NGINX 監視を設定する方法の例など、サービスディスカバリの使用に関する詳細なガイドについては、次の URL にアクセスしてください。docs.datadoghq.com/guides/servicediscovery/

まとめiHeartRadio 社は Docker を使用し、複雑な依存関係を脱却し、アプリケーションによるリソース使用量を個別に把握できるようにしています。同社がサポートしているプラットフォームの数は拡大し続けているため、この方法は非常に有効ですが、本章の冒頭で説明したように Docker のパフォーマンスは監視するのが非常に難しいため、iHeartRadio 社は、コンテナ環境を含め、すべてのインフラストラクチャを監視するために Datadog を使用しています。Datadog を使用すると、ホストやコンテナ全体のメトリクスを集計および分解でき、サービスがどこで実行されていても、すべてのサービスのヘルスとパフォーマンスを把握できます。

謝辞本章を記載するために活用したブログ投稿について支援いただいた iHeartRadio 社、特にエンジニアディレクターの Trey Long 氏に深く感謝します。

http://docs.datadoghq.com/guides/servicediscovery/

http://docs.datadoghq.com/guides/servicediscovery/

73

第 9 章 Datadog は、動的でクラウドスケールの監視ソリューション

第 9 章： Datadog は、動的でクラウドスケールの監視ソリューション

これまでの章では、Datadog を使用して Amazon Elastic Load Balancing、Docker、およびそれらに関連するすべてのインフラストラクチャのヘルスとパフォーマンスを追跡する方法について説明しました。どのようなテクノロジを使用する場合でも、Datadog を使用すると、インフラストラクチャ全体のメトリクスやイベントを表示して分析できます。

Datadog は、モダンでクラウドスケールなインフラストラクチャの独特なニーズに対応するために構築されました。

－包括的な監視。Datadog 製品を導入するとすぐに 280 以上の人気の高いテクノロジから監視データを収集します。Datadog Agent には、事実上あらゆるアプリケーションからカスタムメトリクスを収集できる軽量なメトリクス集計サーバーも含まれています。

－柔軟な集計。Datadog ではタグ付けがネイティブにサポートされていますので、メトリクスとイベントをオンザフライで集計して、最も重要なビューを生成できます。タグ付けを使用すると、ホストではなくサービスを監視できるため、ユーザーやビジネスに直接影響するパフォーマンスメトリクスを中心に確認できます。

74

第 9 章 Datadog は、動的でクラウドスケールの監視ソリューション

－容易なスケーリング。ホストの台数が数十、数百、数千でも、Datadog はインフラストラクチャの規模に合わせて自動的に拡張されます。Datadog は新しいホストとコンテナがオンラインになると自動的に登録します。また、サービスディスカバリを使用すると、コンテナ化されたサービスがどこで実行されていても常に監視できます。

－高度なアラート作成。事実上あらゆるタイプの監視データを使用して、Datadog のアラートをトリガーできます。Datadog は、固定または動的なメトリクスのしきい値、外れ値、イベント、ステータスチェックなどについてアラートを発行できます。

－コラボレーションの強化。Datadog を使用すると、ダッシュボード、グラフ、および注釈付きのスナップショットを簡単に共有でき、チームは協力して作業に当たることができます。PagerDuty、Slack、HipChat などの業界最先端のコラボレーションツールとシームレスに統合されており、監視データについてスムーズにコミュニケーションを図ることができます。

本書で習得した監視と視覚化の手法を適用される場合、www.datadog.com からすべての機能を利用いただける Datadog のトライアル版にサインアップいただけます。

本書の情報が、皆様がインフラストラクチャの監視を開始するときや既存の監視方法を改善するときに役に立つことを願っています。本書で説明したフレームワークは、当社の動的なインフラストラクチャを監視および拡張する上で非常に有益であることが実証されています、皆様の環境でも同じように利用いただけることを願っています。本書や Datadog についてご質問やご意見がございましたら、電子メール（[email protected]）または Twitter（@datadoghq）でお問い合わせください。

皆様が有効な監視を実践できることを願っています。


mailto: [email protected]

mailto: [email protected]

datadog.com

Documents

モダンな Monitoring インフラストラクチャの ...€¦ · クラウドコンピューティングのインスタンスは、 わずか数時間や数日間実行されただけで破棄されることも多く、コンテナに至っては利用

モダンな Monitoring インフラストラクチャの ...€¦ · クラウドコンピューティングのインスタンスは、わずか数時間や数日間実行されただけで破棄されることも多く、コンテナに至っては利用