Zenn
🐶

Datadogの『クラウド時代のサーバー＆インフラ監視』を読んだ（後編）

2023/04/03に公開
datadog
#
monitoring
tech

はじめに

ポートのSREを担当している @taiki.noda です。

Datadogの『クラウド時代のサーバー＆インフラ監視』を読んだ（前編）の続きです。
前編では第4章まで見ていったので、5章からになります。

『クラウド時代のサーバー＆インフラ監視』はこちらからダウンロードできます。
https://www.datadoghq.com/ja/ebook/monitoring-modern-infrastructure/

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

以下の時系列グラフについて、機能、使用するケース、別のグラフの種類に切り替えるケースについて説明している章

  • 折れ線グラフ
  • 積み上げ面グラフ
  • 棒グラフ
  • ヒートマップ

空間を横断する集計

  • インフラストラクチャの単位で分類しても意味ない場合がある
  • 空間を横断して集計することにより、インフラストラクチャを多次元に分析し、最も重要なメトリクスを正確に切り分けることができる
    • メッセージングキュー、データベーステーブル、アプリケーション、またはホスト自体に関する任意の属性(オペレーティングシステム、アベイラビリティゾーン、ハードウェアプロファイルなど)
    • タグをつけることで、グラフ描画と同時にアドホックに簡単に実行できる

折れ線グラフ

  • メトリクスデータを視覚的に変換する最も簡単な方法



積み上げ面グラフ

  • 面グラフは折れ線グラフに似ているが、メトリクスの値が線ではなく 2 次元のバンドで表示される点が異なる


棒グラフ

  • 棒グラフの各棒は、特定の時間間隔におけるメトリクスの集計を表す
  • 棒グラフはカウント(回数)を表すのに最適
  • ある間隔と次の間隔における補間を必要としないため、スパース(疎)メトリクスを表す場合に特に役立つ


ヒートマップ

  • 時間とともに変化するメトリクスの値の分布を示す
    • 各列は特定のタイムスライスにおける値の分布を表す
  • 多数のエンティティのメトリクスを視覚化するように設計されており、 個々のホストやコンテナレベルでは集計されないメトリクスをグラフ化するために使用される

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

  • サマリーグラフとは、特定の期間を平坦化して視覚化し、インフラストラクチャの概要を確認できるようにしたもの

時間を横断する集計

  • メトリクスのサマリービューを表示するには、ビューの時間次元を圧縮して、時系列を単一値に平坦化する必要がある
    • 過去 60 分間で 各ホストによって報告された最大値を表示して、問題となる可能性がある急激な変化を把握できる

空間を横断する集計

  • ホストのいくつかのプロパティ(アベイラビリティゾーン、インスタンスタイプ、オペレーティングシステム)を基準として、あるいはメトリクスに適用したタグ(サービス名、メッセージングキュー、データベーステーブルなど)を基準として集計すること

単一値のサマリー

  • メトリクスクエリと条件を示す書式設定（緑/黄/赤）の背景などとともに表示され、値が範囲内かどうか示すもの

  • 単一値のサマリーが有用なケース

トップリスト

  • メトリック値でランク付けできる

  • わかりやすいため、高レベルのステータスボードで役にたつ

  • トップリストが有用なケース

推移グラフ

  • メトリクスの現在値と過去のある時点の値を比較できる
  • パラメータとして2 つの異なる時間枠がある
    • 評価期間（過去~時間）
    • ルックバック期間（昨日と同じ~時間）

  • 推移グラフが有用なケース


ホストマップ

  • インフラストラクチャ全体または一部を簡単に確認できる固有の方法
  • Datadog独自の視覚化の手法

  • ホストマップが有用なケース

分布

  • インフラストラクチャのあるセグメント全体におけるメトリクス値のヒストグラムを示す
  • ヒートマップは時間の経過による推移を示すのに対し、分布はある時間枠の要約を示す
  • ヒートマップのように、分布グラフでは特定のメトリクスを報告する多数のエンティティを簡単に視覚化でき、個々のホストまたはコンテナレベルでメトリクスをグラフ化する場合によく使用される

  • 分布グラフが有用なケース

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

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

  • 監視するELBパフォーマンスメトリクスには、次の２つの大きなカテゴリに分類される
    • ロードバランサメトリクス
    • バックエンド関連のメトリクス

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

  • CloudWatchでは通常、 これらすべての集計が使用できる
  • 各メトリクスについて、最も関連性が高く、監視するために有用な時間の集計は以下

アラートをオンにするメトリクス

  • RequestCount
    • ロードバランサが処理しているトラフィック量を測定する
    • インフラストラクチャの問題や DNSのような上流の問題を示している可能性がある大きな変化についてアラートを発行できる
  • SurgeQueueLength
    • バックエンドインスタンスにより受け入れて処理されるのを待機している受信要求の数（max）
    • バックエンドインスタンスがすべてロードされ、それ以 上の要求を処理できなくなると、受信した要求はキューに入れられるため、レイテンシが増加し、ユーザーによるナビゲーションが遅くなったり、タイムアウトエラーが発生したりする可能性がある
    • そのため、このメトリクスはできるだけ低く、理想的にはゼロにしておく必要がある
  • SpilloverCount
    • 選択された期間中に完全なサージキューのために拒否されたという要求の数(SUM)
    • SurgeQueueLengthがキューに入れられた要求数の最大値 1024に達すると、新しい要求はドロップされ、ユーザーには 503 エラーが表示される
    • このメトリクスは常にゼロにならなければならない
  • HTTPCode_ELB_5XX
    • 正しく処理できなかった要求の数
      • 502 (Bad Gateway)
        • バックエンドインスタンスは応答を返したが、ロードバランサが正しく機能していなかったか、または応答が不正な形式であったため、ロードバランサは応答を解析できなかった
      • 503 (Service Unavailable)
        • 要求を処理するための十分なキャパシティがなかったために発生する場合がある
        • インスタンス が正常に動作しており、ロードバランサに登録されていることを確認する
      • 504 (Gateway Timeout)
        • 応答時間が ELB のアイドルタイムアウトの制限を超過
        • バックエンドを拡張するかアイドルタイムアウトの制限値を増やして、ファイルのアップロードなどの低速な操作をサポートすることを検討
        • インスタンスが ELB との接続を閉じている場合は、ELB アイドルのタイムアウト値よりも長いタイムアウト値を設定してキープアライブ設定を有効にする必要がある

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

  • 有用なメトリクスは以下

アラートをオンにするメトリクス

  • Latency
    • ロードバランサ自体のレイテンシではなく、バックエンドインスタンスによる要求の処理によるアプリケーションレイテンシーを測定する
    • 高すぎる場合、タイムアウトによって要求がドロップされる恐れがある
      • ネットワークの問題、バックエンドホストの過負荷、または最適化されていない構成が原因である場合がある

注目すべきメトリック

  • BackendConnectionErrors
    • ELB がバックエンドへの接続に失敗したときに発生する
    • 通常、ネットワークの問題かバックエンドインスタンスが正しく実行されていないことが原因

タイムアウトについて

  • リクエストごとに、クライアントとロードバランサー間に１接続、およびロードバランサーとバックエンドの間に１接続ある
  • 各リクエストについて、ELBはアイドルタイムアウトを設定している（デフォルト60秒）
  • このアイドルタイムアウトを増やすことで、ファイル転送などの長い処理を確実に完了できる
  • バックエンドインスタンスのKeepAliveがELBのアイドルタイムアウトよりも長く設定されていなければならない
    • 短い場合、ロードバランサーが接続を閉じる前にバックエンドインスタンスが接続を閉じることがある
    • つまり、ELBは不健全なバックエンドホストとして間違ったフラグを立ててしまう

全体像を把握するためのホストメトリクス

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

Datadogを使用したELBの監視

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

Datadog と ELB の統合

統合の手順について
http://docs.datadoghq.com/integrations/aws/

すべての主要な ELB メトリクスに注意する

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

EC2 メトリクスと ELB の相関

  • CloudWatch の ELB 関連のメトリクスからロードバランサのヘルスとパフォーマンスを把握できる
  • バックエンドインスタンス のヘルスとパフォーマンスを反映するメトリクスも提供する
  • バックエンドインスタンスからもメトリクスを収集すべき

さらに詳細なネイティブメトリクス

  • Datadog Agentによる細かいメトリクスの取得について
  • Agentで取得したメトリクスをELBのメトリクスと相関すると、インフラストラクチャの全体と詳細を把握できる
  • CPU、メモリなどのシステムレベルのメトリクスに加えて、Agent はアプリケーション メトリクスも収集しますので、アプリケーションパフォーマンスをコンピュートレイヤーのリソースメトリクスと相関することができる

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

Dockerを監視するときの問題

  • コンテナを監視するという運用上の重大な課題は、あまりよく理解されていない
  • コンテナは、アプリケーションパフォーマンス監視 や従来型のインフラストラクチャ監視を適用しても効果的ではない、ホストとアプリケー ションの間のトワイライトゾーン(曖昧な領域)に存在する
  • これにより、監視戦略に死角が生まれることになる
    • これはコンテナにとって、そしてコンテナを利用する企業にとって大きな問題

コンテナの概要

  • コンテナとは、ソフトウェアを分離して実行する方法を提供する
  • これはプロセスでもホストでもなく、プロセスとホストがつながる場所のどこかに存在する
  • コンテナは、オーバーヘッドが少なく、セキュリティ上の利点もある
  • コンテナを採用する重要な理由
    • スケーリングのしやすさ
    • 複雑な依存関係からの脱却

スケーリングのしやすさ

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

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

  • 最近では、共有ライブラリが一般的になり、 実行時に必要なライブラリが利用できない場合や 2 つのプロセスが同じライブラリの異なるバージョンを必要とする場合、依存関係という新しい問題が発生するようになった
  • コンテナを利用して、同じホスト上で実行されている他のソフトウェアによる影響を受けない軽量で隔離された仮想の実行環境に小規模なホスト全体をパッケージ化でき、複雑な依存関係から脱却できるようになった

ホストの増殖

  • 過去 15 年間で標準的なアプリケーションスタックがどのように進化したかを示した図
  • オフザシェルフとはバイナリやライブラリのこと？

メトリクスの爆発的な増加

  • コンテナを使用すると、ホストあたりのメトリクス数が数倍に膨れ上がる
    • オペレーティングシステム、ホスト上の各コンテナ、およびそれらのコンテナで実行されている各コンポーネントを監視することになる
    • インフラストラクチャの稼働部分のそれぞれが、5または 6つの稼働部分に置換され、それぞれが独自のメトリクスを報告するようなもの
  • ホストの寿命はコンテナの寿命よりはるかに長く、平均で6倍
    • コンテナの平均的なアップタイムは分または時間で測定され
  • 新しいバージョンのコンテナが作成され、git commitが可能になるとすぐにコンテナを展開できるようになる
    • 複数のコンテナを毎日のようにローテーションさせて自社で使用するようになる

ホストを中心とする監視

  • ホストを中心に監視する場合、次の2つの選択肢しか残されない
    • コンテナを数分ごとに追加または削除されるホストとして扱う
      • 監視システムは常にインフラストラクチャの半分が緊急事態にあると捉えるため、 監視担当のユーザーの人生は悲劇になる
    • コンテナをまったく追跡しない
      • 監視の死角(ギャップ)となる

ゴール:簡潔な監視

  • 運用監視のモダンなアプローチであり、すべてをホストとして扱わない方法
  • レイヤーやタグを中心とする新しい視点で監視する

レイヤー

ギャップなし

  • スタック全体をギャップなく上位レベルから下位レベルに監視する

タイムラインは 1 つ

  • レイヤーの監視を成功させるには、レイヤー間で何が同時に起こっているのかを把握でき、 スタックの一部の問題がスタックの他の部分にどのように波及するかを判断できるように する必要がある

タグ

  • 特定のホストやコンテナを監視するようにシステムに命令するのではなく、たとえば同じアベイラビリティゾーンにあるすべてのコンテナのように、共通のプロパティ(タグ)があるすべての要素を監視するようにシステムに命令できる

要点

Dockerを効果的位使用するためには、以下の対策が求められる

  1. スタックのすべてのレイヤーをまとめて監視し、ギャップを生み出すことなく、あらゆる場所で何が起こっているのかを同時に確認できるようにする
  2. コンテナにタグを付けて、個々のコンテナではなくクエリが可能なコンテナ群として監視できるようにする

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

CPU

標準的なメトリクス

  • コンテナは従来のホストと同じようにシステムCPUとユーザーCPU報告する
  • 相違点は、nice, idle, iowait, irqのCPU時間を報告しない

スロットリング

  • 十分なCPUキャパシティがあるが、コンピュートキャパシティによる制約が問題と考えられる場合は、コンテナ固有のメトリクスであるCPUスロットルを確認する

  • スケジューリングの優先度を指定しない場合、使用可能な CPU 時間は実行中のコンテナ間で均等に分割される

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

  • コンテナは積極的にスロットリングできる

  • コンテナのデフォルトまたは宣言されたCPU シェアによって、必要以上に CPU 時間が付与される場合がある

    • コンテナが実際にその CPU 時間を使用しようとすると、 CPUクォータ制限により、コンテナの CPU 使用率をストロットリングするタイミング が Docker に指示される
    • CPU クォータと CPU 期間はどちらもマイクロ秒で表される

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

メモリ

使用されているメモリ

  • RSS（プロセスが確保している物理メモリサイズ）

    • プロセスに属するデータ (スタック、ヒープなど)
    • アクティブメモリと非アクティブ メモリ(active_anon と inactive_anon)に分解できる
    • 必要に応じてディスクにスワッピングされる

  • キャッシュメモリ

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

  • Docker は、現在使用中のスワップの量についても報告する

  • パフォーマンスや安定性 の問題を調査するのに役立つ可能性があるその他のメトリクスに、ページフォールトがある

    • ページフォールトは、セグメンテーションフォールトまたはメモリではなくディスクからのデータのフェッチを示します(それぞれ pgfault および pgmajfaultという メトリクスになる）

  • パフォーマンスの問題がある場合に最初に検討する必要があ るメトリクスには、メモリの可用性とスワップの使用量

I/O

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

ネットワーク

iHeartRadio 社による Docker の監視方法

  • iiHeartRadio社は、巨大なユーザーベースを抱え、複数のプラットフォームに対応しているため、単一のモノリシックアプリケーションでは安定したサービスを提供できないと判断した
  • HAProxy、MongoDB、Elasticsearchなどの標準インフラストラクチャサービスを使用し、Dockerを採用してアプリケーションをサイロ化し、依存関係とリソースの問題を解決した

1 つの重要な欠点

  • iHeartRadioはDockerのリソース監視に課題があった
  • 伝統的な監視ツールではホストレベルでしか監視できなかったため、コンテナレベルでの監視が不十分であった

Datadog を使用した Docker パフォーマンス監視

  • iHeartRadioはDatadogを導入し、CPU、メモリ、I/O、およびネットワークメトリクスを収集できるようになった
  • Datadogはネットワークトラフィックをイメージとコンテナ別に細分化でき、エンジニアは過負荷のサービスや過剰なトラフィックを送信する原因をすぐに確認できる
  • iHeartRadioはDocker以外のサービスの監視にもDatadogを使用しており、インフラストラクチャ全体のヘルスとパフォーマンスを相関できる

アラートの発行と調査

  • iHeartRadio社は内部ネットワークトラフィックの急激な変化を警告として利用して、精度の高いアラートを発行している
  • サービスレベルトラフィックの集計と分離の両方を可視化することが重要
  • Datadogはしきい値を超過する前にネットワークトラフィックの急激な変化を警告できる
  • iHeartRadio社はDockerから収集するリソースメトリクスを問題の調査に使用する

iHeartRadio 社のように Docker のパフォーマンスを監視する方法

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

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

  • Datadogは、モダンでクラウドスケールなインフラストラクチャのニーズに対応するために設計された監視ツールです
  • Datadogには、280以上のテクノロジからデータを収集する機能があり、カスタムメトリクスを収集できる軽量なメトリクス集計サーバーも含まれている
  • タグ付けがネイティブにサポートされているため、メトリクスとイベントをオンザフライで集計して、最も重要なビューを生成できる
  • Datadogは自動的にスケールアップし、サービスディスカバリを使用すると、コンテナ化されたサービスがどこで実行されていても常に監視できる
  • Datadogのアラートは、固定または動的なメトリクスのしきい値、外れ値、イベント、ステータスチェックなどについてトリガーできる
  • Datadogを使用すると、ダッシュボード、グラフ、および注釈付きのスナップショットを簡単に共有でき、PagerDuty、Slack、HipChatなどの業界最先端のコラボレーションツールとシームレスに統合されている
  • 本書で説明したフレームワークは、動的なインフラストラクチャを監視および拡張する上で非常に有益であることが実証されている

引用

引用元: Datadog. (2021). クラウド時代のサーバー＆インフラ監視. Monitoring Modern Infrastructure. https://www.datadoghq.com/ja/ebook/monitoring-modern-infrastructure/

Discussion