連載
» 2022年04月14日 05時00分 公開

Kubernetes障害で泣かないための羅針盤、Observabilityを活用したトラブルシューティングフロー大公開Cloud Nativeチートシート(14)

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Observabilityを活用したトラブルシューティングフローを紹介する。

[堀内保大, 正野勇嗣, 岡本隆史, 宇都宮雅彦,@IT]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

※岡本、正野、宇都宮は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を紹介します。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。