Kubernetes障害で泣かないための羅針盤、Observabilityを活用したトラブルシューティングフロー大公開：Cloud Nativeチートシート（14）
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Observabilityを活用したトラブルシューティングフローを紹介する。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
※岡本、正野、宇都宮はNTTデータ所属
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。前回から複数回に分けて「Observability（オブザーバビリティ）」「可観測性」にフォーカスして解説しています。
Kubernetesを使っていてトラブルが発生したけど、原因究明をどう進めればいいか分からない……ということはありませんか？
コンテナを利用したシステムでは、マイクロサービス化が容易なので、コンポーネントやサービスの数が従来のシステムに比べて非常に多くなります。そのため、障害が発生した場合の原因の究明も大変になります。
そこで今回は、「Observabilityでいろいろとデータが取れるのは分かったけど、何からどう見ていけばいいのか分からない」という方向けに、Kubernetesで実装されるクラウドネイティブなアーキテクチャに対するトラブルシューティングの羅針盤となる「トラブルシューティングフロー」を紹介します。
トラブルシューティングフローの中では前回の記事で紹介したObservabilityの3シグナル（メトリクス、ログ、トレース）を活用します。
目次
※前回記事では、Observability、可観測性とは何か？ と、その構成要素として3シグナル（メトリクス、ログ、トレース）や考慮点を説明したので、併せてご参照ください。
クラウドネイティブとKubernetesにおけるトラブルシューティングの難しさ
クラウドネイティブなシステムといえど発生する障害自体は、次のような性能問題やHTTPエラーやコンポーネントの障害など、従来と同じ問題です。
- 性能問題
- サービスの遅延
- サーバ障害（HTTPエラー503や504）
- コンポーネントの障害
- PodやNodeの障害やデプロイエラー
- 各種ミドルウェア、アプリエラー
ただし、これらの問題が分散したシステムのどこで発生しているのか、根本原因は何かを正しく迅速に突き止める「トラブルシューティング」については、従来と異なるアプローチが必要となります。
従来はサーバの絞り込みが簡単（メトリクスやログを見れば一発）だったので、「サーバ上で何が起こっているのか」の解析が注力分野となることが多かったと思います。例えば、「DB（データベース）のスロークエリの状況を見ながらAPサーバかDBサーバどちらに原因があるかを切り分ける」「AP（アプリケーション）サーバが怪しいとなればCPUネックかどうかを切り分けて、プロファイリングやGC（Garbage Collection）の分析に注力する」という流れです。
しかし、クラウドネイティブアーキテクチャでは大量のコンポーネントが分散かつ自律的に動作するので、コンポーネントやサービス数が従来のシステムに比べて多くなり、単一のメトリクスやログを見るだけでは問題のコンポーネントにたどり着くこと自体が難しくなります。
加えて、コンポーネントのライフサイクルが短くなったことで、メトリクスやログなどの情報の永続化にも気を配る必要があります。例えば、大量にPodがある中からサービスの遅延に関係性のあるPodを迅速に特定するのは難しいです。問題のあるPodを発見しても再起動を繰り返してログが残っていないこともよくあります。
ここで、前回紹介したObservabilityを利用することで、トラブルシューティングに必要な情報を保持しながら、コンポーネントと事象を正しく特定することができます。
クラウドネイティブトラブルシューティングフローの全体像
クラウドネイティブ向けのトラブルシューティングフローを見ていきましょう。
こちらがフローの全体像です。このフロー自体は、外形監視やサービス監視から取得するレスポンスタイムやエラー率（いわゆるREDメトリクス）から、問題を検知したところを起点として作成しております。全体像がかなり大きいので、3つのレイヤーに分けて説明します。本稿を読み終わった際に、もう一度この図を振り返ってもらえれば、全体像がつかみやすいと思います。
今回作成したフローでは、上図で色分けしている3レイヤー（ぼんやり特定レイヤー、しっかり特定レイヤー、かっちり判明レイヤー）に分けてトラブルシューティングをするように整理しています。理由としては、問題発生の被疑個所を徐々に絞ることで、詳細な情報を確認する範囲を狭めることができ、迅速に原因にたどり着けるからです。
それぞれのレイヤーでどのように切り分けるかの概要を紹介します。
ぼんやり特定レイヤー
最初の「ぼんやり特定レイヤー」では、ぼんやりとダッシュボードを見て、問題個所を「ぼんやりと把握」します。発生している問題について、まだ発生個所や事象自体を把握できていない段階から、KubernetesのNamespaceより細かい粒度まで絞り込みます。
このフェーズでは、あまり個別の事象を深追いせず、おおよそどの辺りが怪しそうか“あたり”を付ける程度にして、短時間で済ませましょう。
しっかり特定レイヤー
「しっかり特定レイヤー」では、前のレイヤーでぼんやりと特定された被疑個所から、さらに「しっかりと絞り込み」ます。より詳細なコンポーネントレベルの問題発生個所（PodやNodeのどの設定やCPUやメモリなどのリソースに問題があるか）に絞り込み、問題事象全容の正確な把握を目指します。
このフェーズでは、Observabilityの3つのシグナルをフル活用します。3つのシグナルをどう活用して切り分けるかが肝になります。
かっちり判明レイヤー
最後に、「かっちり判明レイヤー」では、特定された問題発生個所で発生している問題に対して「根本原因の深掘り」をします。問題発生コンポーネント上の細かな情報（リソース定義、デバッグ、プロファイルなど）を分析しながら根本原因を特定します。
このフェーズでは、それぞれのトラブルに応じて細かな確認すべき情報を見ていきます。具体的に、どのような情報を確認すべきかが重要です。
ここからは、それぞれのレイヤーでの具体的な切り分けフローや確認する情報、Tipsを紹介します。
関連記事
New Relicがアプリの問題解決で開発者を助ける新機能、「開発者は本来の仕事に集中できる」
New Relicの日本法人が可観測性プラットフォームで新機能「New Relic CodeStream」を発表した。 開発ツールを離れることなくソースコードの問題箇所を特定し、チーム内で情報を共有して迅速に解決できるという。
AWS、障害注入試験に向くフルマネージドサービス「AWS Fault Injection Simulator」を正式リリース
AWSはシステムに意図的に障害を発生させる障害注入試験に向いたフルマネージドサービス「AWS Fault Injection Simulator」の一般提供を開始した。CPUやメモリの使用量の急増といった破壊的なイベントを発生させてアプリケーションに負荷をかけ、システムの反応を監視して、改善できる。
ユーザーの幸福度を定量化――SLI、SLO実践の4ステップ
SREは計測、自動化など取り組むことが多く、求められる知識量も少なくない。また周囲の理解が得られなければ、組織でSLI、SLOを定義してSREを実践するのも容易ではない。組織でSREに取り組む最初の一歩をどう踏み出せばいいのか。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。