死活監視、ロギング、メトリクス――Kubernetesと監視の話：マネージドサービスで始めるKubernetes入門（5）（1/2 ページ）

AWSが提供するマネージドKubernetesサービスの「EKS」を用いてアプリケーションを公開する方法を紹介する本連載。最終回は、Kubernetesでアプリケーションを公開後に必要となる「監視」について。

[上野一義，株式会社PIVOT]

　第1回〜第4回で、Amazon Web Services（AWS）が提供するマネージドKubernetesサービス「Amazon Elastic Kubernetes Service（EKS）」を用いた「Kubernetes」環境の構築や、Kubernetesを利用したアプリケーションの公開までを解説しました。この2つの能力があれば、ITサービスを通じてユーザーに価値を提供することができます。パン屋さんで例えるとパン（アプリケーション）を店頭で並べられるようになった（公開）といったところでしょうか。

　パンを焼いて店頭に並べる一連の作業は、もちろん1回で終わるものではなく、毎日繰り返すものです。毎日繰り返すには、パンを焼くための道具や機械に不具合がないように定期的に点検して、機械が不調になったときはすぐに修理したり、一時的に代用できるものをあらかじめ準備しておいたりするなどの対策が必要です。

　Kubernetesというプラットフォームを利用する際にも同様のことが言えます。Kubernetes環境で不具合が起きないよう、毎日点検したり、不具合が発生したときに対策したりすることは必要不可欠です。

アプリケーションにおける「点検」とは

　では、アプリケーションにおける点検（監視）とは具体的に何をすればよいでしょうか。

　代表的な手法の一つとして「死活監視」があります。例えば、CPUやメモリの使用率を定期的に確認し一定の数値（率）を超えたときやアプリケーションの応答がない場合にアラートを出す仕組みです。アラートが来たら、アラートの原因を突き止めプログラム修正などを行います。

　一見すると問題のない監視方法です。しかし、私たち開発者や運用管理者はSaaS（Software as a service）で提供される外部APIやAWSのようなパブリッククラウドで提供される仕組みやサービス、データベースなどのミドルウェアを組み合わせて利用していることがほとんどです。また昨今、機能別に開発したアプリケーションを組み合わせるマイクロサービスアーキテクチャを採用する事例もあります。

　「死活監視」という単純なアプリケーションのアップ／ダウン監視の観点のみに絞っても対象となるものが複数上がるためアラートがより複雑になってしまうのです。

　このような状況でアラートを受け取った場合、「アプリケーションのどこに関連した問題なのか？」「問題はアプリケーションのみなのか、それともネットワークなのか？」を見極めるために、大量の「ログ」を調査する必要が出てきてしまいます。

　またひと言でログといっても、Webサーバ、データベース（DB）サーバ、開発したアプリケーションやフレームワークに標準で設定されている仕様で出力されるものや、「記録しておいた方がよいだろう」と開発チームで決めたカスタム文字列データなどがあります。

　障害発生時に、大量のログデータから障害原因の目星を付けて分析し、それが的外れだった場合、再び別の目星を付けるということを繰り返す。やっとの思いで可能性の高いと思われる原因の対処方法を決めて修正を進める。こうした進め方は遠回りではないでしょうか。

監視で本当に知りたいのは「障害発生」の理由

　アプリケーションを監視するための情報源は、死活監視によるアップ／ダウンという2つの情報とアプリケーションやサーバがあるルールに沿って出力するログ、そしてメトリクス（「メモリやCPUの使用率」などある瞬間の状況における数値情報）などが、アプリケーションやリソースごとにそれぞれ存在します。

　これらを用いてアプリケーションを監視する上で知りたいのは「状態の情報」ではなく、なぜそのような状態や数値になってしまったのかという「理由」です。

　例えば、状態の一つとして「障害が起きている」ことを知るためには、その前提条件として「何を障害とするのか？」を決めておく必要があります。死活監視はアップ／ダウンの2つしかありません。またメトリクスをアラートに利用するためには、閾値（しきい値）を検討する必要があるでしょう。

　しかし、閾値を決めただけでは「理由」を知ることができません。例えば、HTTPステータスコードを基に「HTTPステータスコードが200以外で返ってくるときは障害」と判断する監視をしていて、HTTPステータスコードが正常を示す「200」で返ってきたとします。監視としては正常ですが、ブラウザで表示すると真っ白な画面が表示されるという問題が起きていた場合、問題が発生していることを監視で見抜くことができず、またなぜ真っ白な画面が表示されているのか理由を知ることができません。

　さらに、ユーザーによってはシステムが通常の振る舞いだったとしても障害と判断する例もあるかもしれません。例えばWebサイトの表示完了に要する時間が、2〜10秒だった場合、ユーザーは「サービスにつながりにくいのは障害が起きているからだ」と感じるかもしれません。

　このようにサービスダウンや障害の基準を決めるときは「ユーザーがハッピーなのか？」を指標にして、複数の手法を組み合わせながら監視手法や設計をしていく必要があると考えています。

監視対象や障害の定義は「ユーザーがハッピーか」で決める

　先述したHTTPステータスコードのように、死活監視で分かることはシステムの外部から見える挙動の観察のみです。「システム内部で何が起きているか？」に対しては、踏み込むことができません。抽象的に表現すると「予想可能な障害」しか検知できず、障害検知のタイミングは、「その障害が起きた後」になってしまいます。

　その結果で私たちが分かることは「何が壊れているのか？」のみであり、本当に知りたい「なぜ壊れたのか？」という理由を知ることはできません。

　ログに関しても同じような性質があります。ログは、冒頭で書いたように基本的にプログラマー（またはサービス提供者側）が「何をログとして記録するか？」を決めます。言い換えると、「予想できるもの」に対して「記録しておいた方がよいだろう」という判断なので、予想以外のことに適応できません。そこで「さまざまな予想」を組み立てようとすると、ログの量が多くなり、目的のログを探すことが大変になってしまいます。

　さらに、ログのためにストレージも多く使用することにつながり、コストが大きくなる可能性もあります。そして、それを理由にログの量を減らそうとすると、今度はログが断片的になってしまい、収集の意味がなくなってしまう恐れがあります。

　このように「予想可能な障害」に対して単体情報を利用すれば適応することは可能ですが、不具合が発生した理由を得られません。この「なぜ起きてしまったのか？」という理由を得るために、メトリクスが力を発揮します。