大量にあるKubernetesクラスタをどのように監視するか　ヤフーのクラスタ監視システムの仕組み

クラスタ監視の概要

勝田広樹氏（以下、勝田）：では、ここからクラスタ監視についてお話しします。まず自分たちKubernetes as a Service（KaaS）チームがどういったことを監視したいかという点についてです。前半でもお話ししましたが、このKaaSチームは、すごくいろいろな領域を担当しています。

ここでは「machine」「KaaS」「Kubernetes Cluster」「container」、それから一部アプリケーションもデフォルトのアドオンとして提供しています。こちらで提供しているアドオン部分に関しては動作をしっかり担保して、サービス開発者はサービスの開発に注力できるような状態をつくりたいと思っています。

ということで、KaaSチームとしては、このKubernetes Clusterを払い出して終わりではありません。その払い出したクラスタがしっかり正常に稼働していて、かつ自分たちが提供しているデフォルトのアドオンたちが正常稼働していること、この両方をしっかりと担保できるように監視をしようとしています。

今回のイベントは「Kubernetes導入検討している方にもわかりやすく」ということでした。まず入り口の部分、このクラウドネイティブな監視に関しまして、3本の柱、オブザーバビリティの3本柱として「メトリクス」「トレース」「ログ」があります。

今回主に話すのはメトリクスの部分です。定量的な状態把握と、アラーティングに伝える部分・つなげる部分としてかなり有用に使える部分かなと思っています。内容としては、リソースの利用状況だったり、e2e監視によってサービスの健全性確認などに使われています。

このメトリクス監視によるアラーティングから何か異常を察知して、そこから他の2つの柱の部分、「トレース」でアプリケーション間の通信だったり、どこで何が、どこで問題が起きているかというようなのを検知して調べて、そして該当箇所のログを見ることによって問題を解決するような流れになるかなと思います。

メトリクス管理の利点

繰り返しですが、KaaSチームとしては、全体として正常に動いているか、何か起きていたら知りたいので、このアラーティングに主に使える部分、メトリクスについて集約して監視をしています。すでにKubernetesを使っている方はご存じな方が多いのかなと思うのですが、Prometheusを使ってメトリクス監視を行なっています。

そういった利用用途としてもメトリクス監視がアラートにつなげられるという点で有用なのですが、ほかにも主に数値データを使いますので、保存データが少量で済むのが利点となっています。

このデータ量が少量で済むというのは、言い換えれば一定になるまで保存できる期間が長くなるということです。長期間のデータを溜め込むことによって過去の状態遷移が確認可能となります。

何かアラートが来たときにそのメトリクスの推移を確認することによって、「このタイミングから何かを起きてそうだぞ」というような過去の何がどのタイミングで発生したかというのも探る上でデータ量が少量で済むのは、かなり大きな利点かなと思っています。

残りの2本の柱は、先ほどお話ししたように、詳細調査の際に使用しています。

単体クラスタの監視

KaaSチームとしてはクラスタ全体を監視しているのですが、まずは単体のクラスタについてお話しします。Prometheusを使った監視としまして、まずすごく簡単にお話ししますと、主に2つのコンポーネントで成り立っています。

主にexporterとPrometheus自身に分かれておりまして、このexporter側で先ほどから話していますメトリクスの収集を行なっています。

いろいろな種類のexporterがありまして、実際にヤフーでもよく使っているexporterとして、ここでは「node_exporter」「blackbox_exporter」といったものがあります。

node_exporterによってノードの情報を収集したり、blackbox_exporterによってブラックボックスなアプリケーションの疎通確認したり、動作のリクエストに対するレスポンスの確認だったりをできます。そこでメトリクスを収集し、実際にPrometheusがそのメトリクスを見て何かあればアラートにつながるようになっています。

これによって、先ほどKaaSチームが行ないたいと言っていたクラスタの正常稼働、クラスタリソース、ノードの状態、etcdのメンバーとかリーダーがコロコロ切り替わっていないかとか、何か異常が起きていれば検知できるようになり、アドオンの正常稼働、これはアプリケーションとしての対象のPodの稼働状態を見たり、Ingressと疎通がちゃんとできていて利用者からしっかりアクセス可能かどうかをチェックするようにしています。

大量クラスタ監視の集約

こうして簡単ですがクラスタの監視はできるようになりましたということで、これを大量クラスタの監視につなげます。ということで、今度はこの680以上の数百クラスタを監視することを考えます。

個別のクラスタは、利用者目線ではこういったPrometheusのメトリックス監視によって何か起きていないかと状況感知・検知できるようになったのですが、KaaSチームから目線ではなかなかこの数百クラスタを個別に見るのは大変です。

個人の能力を上げるだけでは、自分もちょっと腕立てとかではなかなか対応しきれなかったので、システム化しました。やっぱり人間では限界がありますのでシステムで集約して、それを人間が簡単に見られるようにしましょうということです。

集約システムとして何をやっているかというと、KaaS側にクラスタのリストを取りに行って、そのリストによって各クラスタのメトリクスを収集します。

この集約システム自身も実体としてはPrometheusとなっておりまして、Prometheusの機能であるfederateを使うことによって、メトリクスのデータを収集して、かつ個別に……先ほどメトリクスデータを長期間保存することが大切という話をしたのですが、個別のメトリクスデータ保存よりは、この集約したシステムによって保存できるような状態を作りました。

これによって、KaaSメンバーは自身のトレーニングを頑張らずに、集約システムだけ見れば大丈夫というようになっています。

ここでポイントとなるお話を少ししますと、メトリクスといえどもこの数百クラスタですべてのデータを保存するのはかなり大変でした。その保存量がやはり多くなってしまいますと期間が短くなってしまいますので、そうすると過去の何がどのタイミングで起きたというのがわかりづらくなってしまいます。

なので、現在では何か起きたよというタイミングで生まれるメトリクスであるアラートメトリクスのみを基本的に収集することによって、何か起きたタイミングというものがいつから発生していたのかを確認できるようにしています。

そしてプラスで運用改善に必要データを書いています。ただ何か正常に動いているかという監視だけではなくて、自分たちKaaSチームがよりユーザー側のクラスタの改善に使えるように、そういったデータを収集しています。

それは何かというと、すごく簡単な紹介ですが、例えばクラスタのCPUとかメモリとかの使用量のデータです。こういった表にすることによって、どこのクラスタでどれだけリソースが使われているかをパッと見ることが可能になります。

あまりにも少ない使用量ですと、どこかもっと必要としているクラスタに割り当てることが可能になったり、逆にかなり使いすぎているクラスタがあれば、アップデートすることによってもっとアプリケーションを動かせるようにするというような全体最適化にも使えるようにしています。

このように集約したメリットとしては、全クラスタをKaaSチームで見られるようになっただけではなくて、この永続化ストレージも1箇所にすることによって、リソースを効率よく使えるようになりました。

そして、全体の情報収集をできるようにすることで、全体のクラスタのアップデートだったり、自分たちが提供するアプリケーションによって何か起きていないかというようなチェックだったりも可能になりました。これによってユーザー側としては安定したクラスタを使って開発に集中できるようになります。

まとめ

まとめです。前半ではKaaSを使って運用自動化をすることをお話ししました。イベントも紹介しましたので、詳しく知りたい方はぜひそちらをご参照ください。

また一般的な監視に関しまして、メトリクス・ログ・トレースを使って可観測性を高めるお話をしました。

そしてヤフーの仕組みとして、このメトリクスをすべてのクラスタ……数百クラスタのメトリクスを集約し、最小限のコストで全クラスタの稼働状態を担保するというようなシステムのお話をしました。

そして、これによって管理者が全体をしっかり把握することによって、リソースの最適化だったり提供するアプリケーションのより改善につなげたりと、全体最適化を図れるようにしました。

すみません、少し時間がオーバーしてしまいましたが、この発表は以上です。ありがとうございました。

質疑応答

司会者：発表ありがとうございました。質問が来ていますね。

相良幸範氏（以下、相良）：はい。1つ目の質問ですね。「デプロイ作業をCIOpsで行なっている箇所もあるでしょうか？」という話ですが、ちょっとすみません、もう少し具体的に質問していただければ答えられたかもしれないですけど、ちょっとわからない感じです。ただ、厳密な意味のCIOpsだと、ちょっと違うかもしれないです。CI/CDと連携してデプロイしていますよ、というふうに捉えてもらえるといいと思います。

2つ目は勝田さんお願いします。

勝田：はい。「集約システム側では、全サービスのメトリクス値が見えてしまう気がするのですが、社内セキュリティルールとしては許容していらっしゃるのでしょうか？」という質問ですね。

メトリクス値として取得するものは限られたもの、今回ですとアラートメトリクスだったり自分たちで払い出したクラスタの自分たちのアプリケーションによる影響部分ということで、サービスの各開発者が持っているような他のチームに見せてはいけないようなデータは収集しないようにしています。という回答で大丈夫そうでしょうか？

司会者：はい。スピーカーのみなさん、ありがとうございました。

相良・勝田：ありがとうございました。