Kubernetesと障害調査
どんなに手を尽くしても本番で運用をしていれば障害はつきものです。ここでは障害が起きることを前提として、障害調査のための準備や障害調査の仕方について説明します。
障害調査のための準備
これまで物理／仮想マシンでアプリケーションを立ち上げて運用した経験のある方は、コンテナを利用した障害調査がこれまでと違うことに驚くかもしれません。
Kubernetesでは自動でPod（コンテナ）が増減したり、利用しているNodeが変化したりします。運用に便利なさまざまな自動化が、障害調査を行う障壁になり得ます。こうした障壁に備えるために、コンテナを利用したアプリケーション開発・運用では、あらゆることを観測可能にしておくことが大事になってきます。この観測可能である状態を可観測性（Observability）といい、可観測性があるシステムの実現に向けて
ログ、メトリクス、トレーシングの3つの要素が重要だとされています。
ログ
ログを見ることで「何がおこったか」を探す手がかりができます。アプリケーション開発者にとってログを出力することは馴染み深いことでしょう。ここではアプリケーションのログをKubernetesがどのように扱うかを説明します。
Kubernetesではコンテナが自動で再起動したり、マニフェストの設定ミスでOut Of Memory（メモリ不足）が発生したりするなど、アプリケーションが正常に稼働しない状況が当たり前に発生します。コンテナが稼働しない状況でコンテナにログインしてログを調査するわけにはいきませんよね。
そこで、Kubernetesではデフォルトでログを収集する仕組みがあります。コンテナの標準出力内容をコンテナのログとして収集します。kubectl logsで収集したログの内容を参照することができます。
しかし、このデフォルトの仕組みを利用したログはPodがNodeから削除されると消えてしまいます。そのため、本番運用を行うにあたってログを保存する仕組みを入れる必要があります。
ログを保存する仕組みはいくつかありますが、パブリッククラウドを利用している場合、クラウドベンダーが提供しているログ収集サービスをそのまま利用することもできます。他の方法については公式ドキュメントなどを参考にしてください。
メトリクス
メトリクスは測定値の集合です。測定値を利用した統計的な処理をしたり、傾向を見たりしたい場合に活用できます。また、測定値に閾値を設定することでアラートに利用することもできます（例：ストレージ容量が残り20％になったらアラートを発報）。メトリクスもログ同様クラウドベンダー標準機能を利用することもできますが、さらなる高機能を求めて外部クラウドサービス（例：Datadog）を利用するケースも多くみられます。
メトリクスをさらに活用するためのダッシュボード
先ほど、メトリクスは統計的な処理を行い、傾向を見たい場合に活用できると書きましたが、この活用の役割を担っているのがダッシュボードです。メトリクスは測定値の集合、と書きましたが、多くの場合「何が正常値か」がわからないことも多いでしょう。例えばある瞬間にAPサーバーが100回ステータスコード404を返したとします。これは正常でしょうか？ 異常でしょうか？ ステータスコード404はユーザーの操作次第ではサービスが正常な状態でも発生します。しかし同じ日の同じ時間帯でも昨日は10回、今日が100回だとしたら、何かいつもと違ったことがあったかもしれないと思いますよね。
このように、メトリクスとはある一定の期間で値を取り続け、その値を連続的なグラフとして見れることが大事です。そしてその連続性を観測しやすくしてくれるのが、ダッシュボードになります。
トレーシング
トレーシング（分散トレーシング）はユーザーないしアプリケーションの通信を追跡するための概念です。また、トレースは複数のSpan（操作の集合）から成ります。コンテナを複数稼働させている環境障害が発生したとき、ユーザーからのリクエストがどのコンテナを経由したかを正確に辿る必要が出てきたときに利用します。また、リクエストのボトルネックを特定するためにも利用されます。しかし、これまでのログやメトリクスと違って、どこかのコンポーネント／インフラだけがトレーシングを実現しているのでは意味がありません。正確にアクセスを追跡するためには、リクエストが通る経路上全てでトレース／Spanが導入できている必要があります。そのため、ログやメトリクスに比べて導入のハードルは高いかもしれません。
ログ、メトリクス、トレーシング、これら3つの要素はお互いが連携していることが大事です。いきなり全てを導入することは難しいかもしれませんが、今後発生する障害に備えて少しずつ導入してみましょう！
