--- title: "Kubernetes をモニターするための次のステップ" description: "Datadog は、分散トレースにコンテナのメタデータで自動的にタグ付けし、OpenMetrics ヒストグラムをグローバルパーセンタイルとして簡単にモニターします。さらに、Watermark Pod Autoscaler や ExtendedDaemonSet プロジェクトを Kubernetes コミュニティに提供しています。" author: "Yair Cohen, David M. Lentz" date: 2019-11-19 tags: ["インフラストラクチャ モニタリング", "apm", "kubernetes", "オートスケーリング", "オープンソース"] blog_type_id: the-monitor locale: ja --- Datadog は Kubernetes に大きく依存しており、Kubernetes を使用しスケーリングや効率化の向上を図るための[課題](https://www.youtube.com/watch?v=2dsCwp_j0yQ) に直面しています。そのため、クラスターのスケーリングの制御に役立ち、Datadog Agent を簡単にデプロイし管理するソリューションに取り組んできました。今日、このソリューションを Kubernetes コミュニティに対し公開します。また、Datadog で Kubernetes をモニターする際に利用できる 2 つの機能も発表します。これにより、以下のことが可能になります。 - クラスター全体の[分散トレーシングの分析](#distributed-tracing-across-kubernetes-clusters)にタグを使用 - Datadogで Kubernetes からの OpenMetrics データを[ディストリビューションメトリクス](#distribution-metrics)として表示 Datadog とユーザーが実環境で Kubernetes を実行する際の課題に対処するよう、継続的な機能強化に務めています。ここでは、上記の新機能を詳しく見るとともに、開発中のオープンソースプロジェクトについても説明します。 ## Kubernetes クラスター全体の分散トレーシング Datadog が APM for Kubernetes を使用した分散トレーシングを[サポート[datadog-agent-kubernetes] することで、クラスターを横切る際のリクエストに対する可視性が増すため、コンテナ化されたワークロードでのエラーやボトルネックの原因を素早く特定できます。[Tracing without Limits™](https://www.datadoghq.com/blog/dash-2019-new-feature-roundup.md#tracing-without-limits) により、トレースをライブで照会したり、その後の分析のために保持するかどうかをビジネスの優先度に基づき選ぶことができます。個々のコンテナからデプロイやネームスペースレベルまで、すべてのトレースにコンテナのメタデータが自動的にタグ付けされます。 [App Analytics](https://www.datadoghq.com/blog/trace-search-high-cardinality-data.md) ビューでは、[ファセット](https://docs.datadoghq.com/tracing/advanced/search.md#facets)（例、下のようなポッド名）でトレースをフィルターでき、各コンテナやデプロイが処理したリクエストの詳細を見ることができます。またリクエストをクリックすれば、フレームグラフでリクエストの生存期間やリクエストに対するサービスのタイミングを確認できます。 ![Datadog のフレームグラフは実行されたリクエストのタイムラインを示します。1 つのスパンにカーソルを合わせると、リクエストを処理したホストに適用されたタグが確認できます。](https://web-assets.dd-static.net/42588/1776305467-whats-next-monitoring-kubernetes-datadog-kubernetes-flame-graph.png) アラートは簡単に作成でき、たとえば特定のデプロイメントにより処理されるリクエストの平均存続期間が指定した閾値を超えた場合に通知を受け取ることもできます。Slack、PagerDuty、または他の[コラボレーションツール](https://www.datadoghq.com/product/platform/integrations/#cat-collaboration)に通知が行くようにアラートを設定すれば、チームはすぐさまレイテンシーの原因解明に取りかかることができます。 トレースは、[ライブコンテナビュー](https://www.datadoghq.com/blog/introducing-live-container-monitoring.md)で直接確認できます。コンテナ名をクリックし実行したトレースを表示し、トレースをクリックすればフレームグラフが表示されます。 ![Kubernetes クラスターの一覧と、それぞれの CPU、メモリー、ネットワークメトリクスがコンテナビューに表示されている様子](https://web-assets.dd-static.net/42588/1776305472-whats-next-monitoring-kubernetes-datadog-kubernetes-containers-view1.png) ## ディストリビューションメトリクス [ディストリビューションメトリクス](https://docs.datadoghq.com/graphing/metrics/distributions.md)は、コンテナやポッズなどのソースからモニターデータを集約し、サービス全体のパフォーマンスを示すグローバルパーセンタイル値を計算するため、ユーザーエクスペリエンスを深く理解するのに役立ちます。ディストリビューションメトリクスを視覚化して警告を発し、ビジネスにとって必要な[サービスレベル目標（SLO）](https://www.datadoghq.com/blog/set-and-monitor-slas.md) に対するパフォーマンスを追跡するために利用できます。 [OpenMetrics](https://openmetrics.io/)データ形式は Kubernetes などのクラウドテクノロジーでネイティブに使用されています。Datadog は、[Prometheus エクスポジション形式](https://www.datadoghq.com/blog/monitor-prometheus-metrics.md)や[OpenMetrics](https://docs.datadoghq.com/getting_started/integrations/prometheus.md?tab=host)に対応しています。また、OpenMetrics ヒストグラムデータをディストリビューションメトリクスに変換できるので、Datadog で Kubernetes メトリクスをパーセンタイルとしてモニターできます。ディストリビューションメトリクスを使い、サービスのパフォーマンスをチームの SLO に照らし合わせることもできます。たとえば、SLO でリクエストの 95% を 200 ミリ秒以内に処理するよう設定されている場合、`http_response_time_seconds` を基に[ディストリビューションメトリクスを作成](https://docs.datadoghq.com/graphing/metrics/distributions.md)し、`p95` 値が閾値に近づいた際に警告が発せられるようにアラームを作成できます。 ![メトリクス http 応答時間の p-75、p-95、平均値を示す折れ線グラフ。](https://web-assets.dd-static.net/42588/1776305476-whats-next-monitoring-kubernetes-datadog-distribution-metrics.png) Datadog のディストリビューションメトリクスは最新の [DDSketch アルゴリズム](https://www.datadoghq.com/blog/engineering/computing-accurate-percentiles-with-ddsketch.md)に基づいています。DDSketch は、OpenMetrics ヒストグラムを集約してディストリビューションメトリクスに効率的に変換する方法を提供する、相対誤差のあるマージ可能なクォンタイルスケッチを定義します。 ## Kubernetes コミュニティへの還元 今日のインフラストラクチャにおいて Kubernetes は必要不可欠なものと考える Datadog は、Kubernetes コミュニティへの還元に取り組んでいます。今年は、インフラストラクチャの大規模運用に役立つ 2 つのオープンソースプロジェクトを始動させ、これを Kubernetes コミュニティと共有し、フィードバックを得ながらソリューションの強化を続けたいと考えております。当社の[Watermark Pod Autoscaler (WPA)](https://github.com/DataDog/watermarkpodautoscaler)プロジェクト（ベータ版）は、Horizontal Pod Autoscaler の機能強化を目標としています。アルファ版の [ExtendedDaemonSet (EDS)](https://github.com/DataDog/extendeddaemonset)は Kubernetes DaemonSet を強化し、カナリアリリースやローリングアップデートの機能で展開プロセスを改善します。 また、Kubernetes クラスターの可視性を高めるため、Datadog Agent の大規模展開および管理プロセスを簡素化することを目的に設計された Datadog Operator の開発（およびオープンソース）に務めています。 ### Watermark Pod Autoscaler を使用してクラスターをオートスケール Kubernetes の [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) は、拡大するユーザー数に合わせ Datadog プラットフォームをスケールするための重要な機能でした。それに[改善を加え](https://www.datadoghq.com/blog/autoscale-kubernetes-datadog.md)、コンテナ化されたアプリケーションの運営を簡単にしました。ここでは、HPA の機能を拡張し、クラスターのオートスケーリングをより細かく制御するためのオープンソースプロジェクト、Watermark Pod Autoscaler をご紹介します。 HPA は、クラスター内のポッドの CPU 平均使用率など、設定したメトリクス閾値を基にインフラストラクチャを調整しますが、HPA がスケールする度に、メトリクスの値が大幅に変化したり継続的なスケーリングイベントループが発生することがあります。たとえば、スケーリング閾値を全てのポッドの CPU 平均使用率の 40% に設定し、ワークロードが最初の 2 つのポッドで 45% になった場合、HPA はポッド数を増やすため平均使用率は 30%（または複数のポッドが追加された場合それ以下）に落ちます。使用率が落ちたことで今度は HPA はポッド数を減らすため、クラスターはポッド数の乱高下に振り回されます。 WPA はHPA のアルゴリズムを改良し、スケーリングのトリガーに HPA が使用する閾値を 1 つにするのではなく、メトリクスの許容値（上限と下限）を設定できるようにしました。たとえば、ポッド全体の CPU 平均使用率の上限を 40%、下限を 20% に設定した場合、CPU の平均使用率がその範囲内である限りスケーリングイベントは発生しません。WPA は CPU の平均使用率が 40% を超えた場合にのみ ReplicaSet にポッドを加え、メトリクスが 20% を下回った場合にのみポッドを減らし始めます。 下のグラフでは、WPA の上限と下限を水平線で示しています。メトリクスがその範囲内にある場合はスケーリングイベントは発生しません。メトリクスがこの範囲から外れた場合、クラスターは必要な調整をし、メトリクスを範囲内に戻します。 ![WPA で設定した境界線の上を移動する無名のメトリクスを示す時系列グラフ。その後メトリクスは境界線の下に移動し、また範囲内に戻ります。](https://web-assets.dd-static.net/42588/1776305480-whats-next-monitoring-kubernetes-datadog-wpa-bounds.png) さらに、WPA は 1 回のスケーリングイベントで調整するレプリカの数を（現在のクラスターのサイズの割合として）制限できるため、ワークロードをより効率的に調整できます。これにより、たとえば必要なレプリカの数を再計算する前にスケールアップしすぎることを防ぐことができます（希望のメトリクス値に戻すためにサイドスケールダウンし直す必要がなくなります）。また冷却期間を設定できるため、複数のスケーリングが矢継ぎ早にトリガーされることを防ぐことができます。このような WPA の機能により、1 回のスケーリングが ReplicaSet のサイズに与える影響をコントロールできるため、インフラストラクチャのサイズが突然大幅に変更されることを防ぐことができます。 [Datadog Agent](https://github.com/DataDog/datadog-agent) のように、WPA はオープンソースです。是非皆さんに[ご覧いただき](https://github.com/DataDog/watermarkpodautoscaler)、お試しいただき（ベータ版）、プロジェクトに参加していただきたいと思います。WPA の可能性を信じる Datadog は、このプロジェクトを盛り上げるために [Kubernetes 拡張プロポーサル](https://github.com/kubernetes/enhancements/pull/1372) (KEP)を提出しました。 ### ExtendedDaemonSet でノードベースのエージェントを使用 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) コントローラーは、Kubernetes クラスターでエージェントを展開し管理する一般的な方法です。DaemonSet コントローラーを使用してノードに共通の構成を設定すれば、必要なデーモン（保存やログインなどの処理）を全て実行することができます。当社は、ユーザーが Kubernetes クラスターに Datadog Agent を展開する際に DaemonSet コントローラーに任せており、現在その機能をさらに強化するオープンソースプロジェクト、[ExtendedDaemonSet](https://github.com/DataDog/extendeddaemonset) (EDS) に取り組んでいます。 大規模な Kubernetes クラスターへ変更を加えることは複雑でリスクを伴う場合があります。DaemonSet では展開プロセスでのきめ細やかな制御が望めないため、クラスター全体に問題が広がる前に対処することは不可能でした。EDS は展開プロセスを事細かく制御できます。具体的には、カナリアリリースに対応し、ローリングアップデートにもさまざまなオプションを用意します。 カナリアデプロイは、新しいリリースのインパクトを制限することでリスクを最小限に抑えることができます。たとえば EDS では、クラスター内のノードのサブセットに新しい構成をデプロイしたカナリアリリースを作成できます。カナリアリリースの期間、作成されるカナリアレプリカ数などを指定できます。カナリアデプロイがうまくいけば、EDS はローリングアップデートを実行し完全なデプロイメントを始め、残りのポッドに変更を加えます（その割合も設定可能）。 Datadog Agent の展開プロセスを向上させるために EDS を開発しましたが、Kubernetes クラスターにデプロイするエージェントの種類は問いません。[このプロジェクトはオープンソースであるため](https://github.com/DataDog/extendeddaemonset)、ぜひお試しください（現在アルファ版）。 ユーザーのため、そして Kubernetes コミュニティを盛り上げるための一翼をこのプロジェクトが担うことを願っています。 ### Datadog Operator を使用したエージェントの展開と管理 Kubernetes インフラストラクチャで Datadog Agents を簡単に展開し設定するために、[Datadog Operator](https://github.com/DataDog/datadog-operator)（アルファ版）を作りました。[Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/)（Kubernetes でアプリケーションを操作する際に必要なタスクを自動化する一般的な方法）パターンを基に、Datadog Operator は Datadog Agents の操作に役立つ機能を追加しています。 複数の種類の Agent を操作し（ノードベースの Datadog Agents と Cluster Agent など）、さらには Datadog がサポートする 1,000 以上のテクノロジーの組み合わせをモニターする Agent を構成する場合があります。規模が小さければ Agent のコンフィギュレーションのカスタマイズは簡単ですが、大規模かつ動的なインフラストラクチャではそうはいきません。 さらに、Kubernetes クラスターの展開や管理にさまざまなプラットフォームやメソッド（Terraform、Helm、ConfigMaps）を使用する場合もあります。Datadog Operator には Kubernetes [CustomResourceDefinition (CRD)](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) があるため、1 つの API リソースで Datadog Agents の展開と管理ができます。またデプロイの結果も CustomResource ステータス 1 つで確認できます。Datadog Operator を使えば、単一の API リソースで 1 か所でコンフィギュレーションを記述でき、クラスターで実行される Agent に簡単に適用できます。 記述するコンフィギュレーションを最小限に抑えるため、Datadog Operator には起動する Agent 用にデフォルトのコンフィギュレーションが用意されています。もちろん必要に応じて Agent のコンフィギュレーションはカスタマイズできます。Datadog Operator はユーザーのデプロイ要件と照らし合わせエラーがないかコンフィギュレーションを検証します。Agent のデプロイ後は、`kubectl` コマンド 1 つでデプロイメントのステータスを確認できます。 Datadog Operator はオープンソースプロジェクトです。皆さんの[参加](https://github.com/DataDog/datadog-operator)をお待ちしております。現在アルファ版ですので、お試しになる際はサンドボックス環境をご利用ください。プロジェクトに参加し、アイデアが浮かんだ場合はイシューやプルリクエストを作成してください。 ## コミュニティへのコミット Datadog で Kubernetes をモニターするための新機能をご紹介できたこと、Kubernetes エコシステムへ機能を還元できることを嬉しく思います。今回そして今後の開発に対するフィードバックを是非お寄せください。KubeCone の Datadog ブースにも足をお運びください。まだ Datadog をお使いでない場合、をご利用いただけます。