前回でKubernetesアプリケーションのリリースまで出来るようになりました。アプリケーション開発者としての仕事はここまで……としたいところですが、リリース後にパフォーマンスが落ちた、不具合が発見された、となると、対応に当たるのは開発者であるあなたです。そこで今回と次回は、Kubernetesアプリケーションの最低限のモニタリングとロギングの仕組みと手法、さらに一歩進んでオブザーバビリティの概念と導入について解説します。
アプリケーションを運用する上でモニタリングが必要だということは、今さら言うまでもないでしょう。Kubernetesアプリケーションでも同様です。非コンテナアプリケーションを動かす場合と同じように、負荷やアクセス量、エラーレートなどのメトリクスは計測する必要がありますし、また過負荷やソフトウェア障害、通信障害、物理障害も当然発生するので、対応が必要な場合にはアラートを発報します。リリース後に大量のアラートが、だとかダッシュボードを見たらCPU利用率がものすごい値に、といった経験は多くの人がしていますね。
近年ではモニタリングに加えて、アプリケーションの内部動作に踏み込んで可視化する「オブザーバビリティ」に取り組む必要がある、と言われています。モニタリングとはすなわち、アプリケーションの状態を可視化し通知するものです。モニタリングにより異常が発生したことはわかりますが、実際に異常を解決するためには調査して問題を切り分けして、原因箇所を特定して……という作業が必要です。この調査が問題で、調査するべきログが複数行、あるいは複数ファイルに渡ってしまって突合が大変だったり、ノードやワークロードのオートスケールを導入しているとそもそも目的のログがどこにあるのかを見つけるのも一苦労だったりします。なんとか該当のログを見つけることができても、そこで手詰まりになってしまったのでログの出力を変えて再現待ち…とかいうのはよくある話です。特にマイクロサービスアーキテクチャを採用する場合には、この調査がチームの境界をまたぐ必要がありスムーズに進まない、というのもまたある話です。
オブザーバビリティとは、アプリケーションのメトリクスやログを単にモニタリングするのに留まらず、アプリケーションの動作まで踏み込んで何が起こっているのかを知るための取り組みです。なにか問題が起こったとして、もしアプリケーション内部の問題箇所の切り分けがあらかじめ出来ていれば、対処もいくらか容易ですよね。例えばリクエストを受けてからレスポンスを返すWebサービスのようなアプリケーションなら、リクエスト全体でのステータスコードやレスポンスタイムのみならず、処理の中で各サービス、関数がどう動作したのかというところまで記録、可視化して問題箇所の特定と解決を支援するようなことを目指します。Kubernetesなどのクラウドネイティブなアーキテクチャの導入でリリースが迅速化する一方でオートスケールやサービスの分割による複雑化が進んだ昨今、発生するトラブルにも迅速かつスマートに対処するべくオブザーバビリティの確保が求められてきている、というわけです。
さて、今回はKubernetesアプリケーションのモニタリングの話をします。そして次回は、オブザーバビリティを実現すべくアプリケーションにトレーシングを導入し、マイクロサービスの処理の流れを追いかけてみましょう。なお、詳細なモニタリングツールの導入や設定値の解説については最小限に留め、アプリケーション開発者として知っておくべき話題を中心に扱います。
まずは、Kubernetesでメトリクスを可視化するところから始めましょう。KubernetesにはPod、Nodeのメトリクスを取得するための標準の方法としてMetrics APIが定められています。Metrics APIはプラグインにより実装されるものなので、本連載のようにkubeadmを使用してクラスタを構築した場合は、そのままでは使えません。Metrics APIを利用するための最もメジャーな方法はMetrics Serverをクラスタにインストールすることです。Metrics Serverはkubeletを通してcontainerdなどのコンテナランタイムからメトリクスを取得し、kube-apiserverを通して取得できるようにします。
それでは、さっそくクラスタにインストールしてみましょう。今まで見てきたコンポーネント同様にコマンドひとつで完了します。
本来はこれで完了ですが、第2回のような手順でクラスタを構築している場合はもうひと手間必要です。metrics-serverはkubeletにアクセスしてmetricsを取得しますが、今回のようにkubeadmで構築したクラスタだと、そのままではkubeletの証明書エラーが発生します。kubeletの証明書を正しくkubernetesのCAで署名するように作り直すか、あるいは証明書エラーを無視するように設定します。今回は後者を採用します。
インストールが完了するとMetrics APIが有効になります。実際にkubectl top コマンドを利用して、Node、PodのCPU使用率、メモリ使用量を表示できます。反映までに少し時間がかかります。
kubernetes-dashboardなどのダッシュボードツールを利用すると、Metrics APIから取得したデータをWebUI上で可視化できます。また、このMetrics APIはKubernetesのオートスケールの仕組みであるHorizontal Pod AutoscalerやVertical Pod Autoscalerでも利用されます。Metrics Serverを導入することで、CPU利用率とメモリ使用量の2つのメトリクスを利用してPodをオートスケールできます。この連載ではこれ以上触れませんので、公式ドキュメントを参照してください。ちなみに、Metrics Server以外のプラグインを利用することで、より多くのメトリクスをMetrics APIで取得できます。実際にリクエスト数などアプリケーション固有のメトリクスでオートスケールするために、後述するPrometheusでMetrics APIを拡張することも多いです。
ただし、Metrics APIはあくまでPod、Nodeのメトリクスを取得するための仕組みです。PodをまたいだDeployment、Service単位でモニタリングする機能もなければ、アプリケーション固有のメトリクスをモニタリングするのにも適していません。Metrics APIはあくまでオートスケールのために利用し、運用のためのモニタリングには外部のモニタリングツールを並行して利用することをおすすめします。
では、アプリケーション固有のメトリクスをモニタリングするにはどうするべきでしょうか。非Kubernetesのシステムでも利用されていたモニタリングツール群の多くがKubernetesに対応しているので、引き続きこうしたツールを利用するのが良い方針です。ここでは、その中でも最もメジャーなPrometheusをKubernetesで使ってみたいと思います。ElasticsearchやDatadogなど、他の多くのツールもKubernetesで利用できますので、既に動かしているものがあれば調べてみてください。
実際に、Prometheusを利用したKubernetesのモニタリングを試してみましょう。Prometheus Server自体はKubernetesクラスタの内外で動作しますが、今回はHelmを利用してクラスタ内部に構築します。また簡単のため、persistentVolumeをオフにしてインストールしています。データが失われてしまうので実際に運用する場合はpersistentVolumeを用意しておきましょう。
Prometheusサーバが用意できたら、アプリケーションのメトリクスを公開しましょう。アプリケーションを修正し、Spring FrameworkとNuxt.jsのPrometheus Exporter Moduleを導入してイメージをビルドします。変更内容の詳細を見てみたいという方は、GitLab.comのコミットログを参照してください。
exporterが用意ができたら、Prometheus側でこれらのExporterからメトリクスを収集する設定が必要となります。PrometheusにはKubernetesクラスタのためのkubernetes_sd_configという設定値があるので、多くの場合ではこちらを利用すると便利です。この設定により、PodやServiceのAnnotationに特定の値を記述することで、Prometheusが自動的に値を収集してくれます。
これらは、アプリケーション側でメトリクスを公開する設定でした。今度はPod、Nodeなど、Kubernetesリソース自体のメトリクスも見てみましょう。Metrics APIを利用したモニタリングはKubernetes固有の仕組みでPrometheusに直接対応するものではないため、PrometheusでPod、Nodeのメトリクスを収集するにはmetrics-serverではなく、別途exporterをインストールする必要があります。Nodeについてはnode-exporter、Podや他Kubernetesリソースについてはkube-state-metricsが最も広く利用されています。HelmでKubernetesクラスタにPrometheusをインストールした場合には、これらのexporterも同時にインストールされています。
こうして、アプリケーション固有のメトリクスとKubernetesリソースのメトリクスを同時にPrometheusで扱えるようになりました。特にオートスケールするようなアプリケーションの場合、Deploymentリソースのレプリカ数やPodのステータスなどはアプリケーションメトリクスと合わせて表示しておきたいところです。ということで、可視化ツールのGrafanaを利用してダッシュボードで表示してみましょう。図ではDeploymentリソースのレプリカ数、Podのコンディション、リクエストのDurationとガベージコレクションの所要時間を1枚のダッシュボードにサマリしています。ちなみに、このGrafanaもHelmでインストールできます。
メトリクスがモニタリングできるようになったところで、ログのモニタリングにも触れておきます。Kubernetesを含めて、コンテナアプリケーションではアプリケーションログの書き込み先をログファイルではなく、標準出力にするのがベストプラクティスです。Kubernetesでは、各コンテナの標準出力から出力されたログをAPIから閲覧できるようになっています。kubectl logs コマンドを実行して、実際に確認してみましょう。またtailコマンドのように、-f オプションで出力をリアルタイムに確認することもできます。
Deploymentリソースなどを利用して複数のPodを並列稼働している場合には、kubectl logs コマンドに –selector オプションを指定することで同一のラベルを持つPodのログをまとめて表示することができます。ただ少し見づらいので、sternのようなツールを利用するとPodごとに色分け表示してくれるので便利です。kubernetesのあらゆる操作は単なるkube-apiserverへのリクエストなので、こうした拡張ツールが盛んに開発されています。Krewは、こうしたkubectlコマンドのプラグインを管理する仕組みです。多くのプラグインが登録されているので、目を通しておくと使いたいものがあるかもしれません(＊2021年10月現在、sternはKrewのレポジトリに登録されていません)。
ログにも非Kubenetesのシステムで利用されていたツール群を利用できます。代表的なログ収集ツールはfluentdやpromtail、logstash、ログサーバはElasticSearchやLoki、S3等のオブジェクトストレージなどがよく利用されます。先ほどはGrafanaを利用してメトリクスを可視化しましたので、同じくGrafana Labsが開発しているPromtailとLokiを利用してみましょう。
先ほどと同様にPromtail、LokiをHelmでデプロイします。Promtailの転送先がLokiになるように設定値を変更しています。PromtailはDaemonSetで各ノードに配置され、各コンテナが標準出力したログを自動で収集してくれるようになっています。ちなみに、各コンテナのログはノードの/var/log/pods/以下に書き込まれています。
GrafanaのデータソースにLokiを設定すると、アプリケーションのログが表示できるようになっていますね。ログのラベルにはNamespaceやNode、PodのLabelが設定されています。図ではNamespaceを指定することで、アプリケーションのログに限定して表示しています。Podのラベルを適切に設定しておくことで、アプリケーション内の一部のサブシステムのみ抜き出してログを確認するなどの細かいフィルタリングがしやすくなります。
また、アプリケーションによっては、コンテナの標準出力ではなくファイルにログを書き込むものがあります。その場合は、同一Podのサイドカーコンテナとしてpromtailを動かしてLokiにログを転送するようにPodを構成しましょう。コンテナ間でVolumeを共有することで、アプリケーションコンテナが書き込んだログをpromtailコンテナで読み出して転送できます。マニフェストファイルのサンプルを抜粋して載せておきます。
今回は、Kubernetes環境でのアプリケーションのモニタリングについて解説しました。非Kubernetesのアプリケーション同様に、メトリクスとログがモニタリングできることをお分かりいただけたかと思います。次回は、モニタリングから一歩進んだオブザーバビリティについて、実例をお見せしながら紹介します。お楽しみに。
Think ITメルマガ会員のサービス内容を見る
「OSSfm」は“オープンソース技術の実践活用メディア”であるThink ITがお届けするポッドキャストです。
