Kubernetesのオブザーバビリティーを実現する方法： 原則とベスト・プラクティス
Kubernetes（K8s）コンテナと環境は、コンテナ化されたアプリケーションを大規模にパッケージ化し、導入・管理するための主要なアプローチです。Kubernetesの動的かつオープンソースのマイクロサービス・ベースの構成は、インフラの俊敏性を最大限に高めたいと考えている企業に最適です。ただし、Kubernetesの魅力である分散型の柔軟性により、Kubernetesの監視とオブザーバビリティー・プラクティスの実装が困難になることもあります。
オブザーバビリティーは、チームがシステムのアウトプットを調べることによってシステムの内部状態について実行可能な洞察を得るのに役立つ一連のプロセスとメトリクスで構成されます。これは、ITインフラを維持するために不可欠な部分です。ただし、Kubernetes環境を構成する膨大な量のデータやノード、ポッド、サービス、エンドポイントを管理するには、そのジョブに適したオブザーバビリティー・プラクティスが必要です。
このブログでは、Kubernetesのオブザーバビリティーがどのように機能するのか、および組織がそれを使用してクラウドネイティブのITアーキテクチャーを最適化する方法について説明します。
オブザーバビリティーとは、大まかに言うと、外部アウトプットから内部システムの状態をどの程度適切に推測できるかを表します。システムが特定の動作をする理由を診断して理解する能力は、トラブルシューティングやパフォーマンスの問題の解読、システム設計の改善に不可欠です。
DevOpsでは、オブザーバビリティーの概念は進化し、テレメトリー・データによって決定されるシステム状態のエンドツーエンドの可視性を指すようになりました。使用される主なデータ・クラスは、ログ、メトリクス、トレースで、これはオブザーバビリティーの3本の柱として知られています。
ログには、ステータスやエラー・メッセージ、トランザクションの詳細など、システムで何かが発生するたびに記録される個別のイベントが含まれます。Kubernetesのログは、構造化テキストと非構造化テキストの両方で書き込むことができます。
メトリクスは、CPU使用率、メモリー消費量、ネットワークI/O、リクエスト・レイテンシー、または任意の企業独自の指標です。Kubernetesメトリクスは、多くの場合、チームが傾向を見つけてパターンを特定するのに役立つ時系列のオブザーバビリティー・データを作成するために集約されます。
トレースは、チームが分散システムのさまざまなサービスとコンポーネントを通じてリクエストまたはトランザクションを追跡できるようにします。また、インフラストラクチャーのさまざまなコンポーネント間の依存関係をチームが可視化することで、遅延やエラーを迅速に特定できるようになります。
良好なオブザーバビリティーの実現には、適切なKubernetes監視ツールの導入と、3つの主要なアウトプットを収集・保管・分析するための効果的なプロセスの実装が必要です。これには、監視システムやアプリケーション・ログ・アグリゲーター、アプリケーション・パフォーマンス管理（APM）ツール、その他のオブザーバビリティー・プラットフォームの設定と保守が含まれる場合があります。
ただし、Kubernetes環境では、標準メトリクスをより徹底的に調査することも必要です。Kubernetesシステムは、相互接続されたコンテナやマイクロサービスその他のコンポーネントの広大な環境で構成されており、それらはすべて大量のデータを生成します。Kubernetesは、アプリケーションのライフサイクル全体を通じて、次のようなコンテナ関連のタスクをスケジュール設定し、自動化します。
デプロイメント
Kubernetesは、指定された数のコンテナを指定されたホストにデプロイし、それらを望ましい状態で実行し続けます。
ロールアウト
ロールアウトとは、Kubernetesのデプロイメントを修正することです。Kubernetesを使用すると、チームはロールアウトを開始・一時停止・再開・ロールバックできるようになります。
サービスの発見
Kubernetesは、DNS名やIPアドレスを使用して、コンテナをインターネットや他のコンテナに自動的に公開できます。
オートスケーリング
トラフィックが急増すると、Kubernetesは追加のワークロードを処理するために新しいクラスターを自動的に起動できます。
ストレージのプロビジョニング
チームは Kubernetesをセットアップして、コンテナ用の永続的なローカルまたはクラウド・ストレージをマウントできます。
ロード・バランシング
Kubernetesのロード・バランシング機能は、CPU使用率またはカスタム・メトリクスに基づいて、ネットワーク全体にワークロードを分散し、パフォーマンスと安定性を維持できます。
自己修復により高可用性を実現
Kubernetesは、ダウンタイムを防ぐために、障害が発生したコンテナを自動的にデバッグや再起動または置き換えができます。また、ヘルスチェック要件を満たさないコンテナの廃止も可能です。
非常に多くのコンポーネントがシフトし、相互作用し、階層化されているため、多くの潜在的な問題や障害点が発生し、そのためリアルタイムの監視が必要となる領域が数多くあります。これは、ログ、メトリクス、トレースを監視する従来のアプローチでは、Kubernetes環境でのオブザーバビリティーが不十分であることが判明することがあることも意味します。
Kubernetesアーキテクチャーのすべてのコンポーネントは他のコンポーネントと相互依存しているため、オブザーバビリティーにはより総合的なアプローチが必要です。
Kubernetesのオブザーバビリティーを実現するには、組織がログ、トレース、メトリクスからクラスター・レベルのデータを収集して分析するばかりではなく、データ・」ポイントを接続して、Kubernetesクラスター内の関係やイベントをより深く理解することがプロセスの中心となります。これは、組織がカスタマイズされたクラウドネイティブのオブザーバビリティー戦略に依存し、システム内で利用可能なすべてのデータソースを精査する必要があることを意味します。
K8s環境でのオブザーバビリティーには、次のものが含まれます。
1. メトリクス、ログ、アプリを超えた移行。仮想マシン（VM）の監視と同様に、Kubernetesのオブザーバビリティーでは、すべてのログ・データ（コンテナ、マスター・ノード、ワーカー・ノード、基盤となるインフラから取得）とアプリ・レベルのメトリクスを考慮する必要があります。ただし、VMとは異なり、Kubernetesはアプリやクラスターを超えたコンテナの相互作用を調整します。そのため、Kubernetes環境には、ネットワーク・クラスターやアプリの内外で、膨大な量の貴重なデータが保管されています。これには、CI/CDパイプライン（K8sクラスターに供給される）とGitOpsワークフロー（K8sクラスターを動かす）のデータが含まれます。
また、Kubernetesは、従来のアプリやVMとは異なり、メトリクス、ログ、トレース・データを公開しません。Kubernetesはデータの「スナップショット」、つまりライフサイクルの特定の時点でキャプチャされた情報をキャプチャする傾向があります。各クラスター内の各コンポーネントが異なるタイプのデータを異なる形式で異なる速度で記録するシステムでは、離散的なデータポイントを分析するだけではオブザーバビリティーを確立することは困難または不可能な場合があります。
さらに、Kubernetesはアプリ・レベルでもクラスター・レベルでもマスター・ログ・ファイルを作成しません。すべてのアプリとクラスターはそれぞれの環境でデータを記録するため、すべてを1か所で確認するには、ユーザーがデータを手動で集約してエクスポートする必要があります。また、コンテナは数秒以内にスピンアップ、スピンダウン、または完全に消滅する可能性があるため、手動で集計されたデータであっても、適切なコンテキストがなければ不完全な全体像が得られる可能性があります。
2. コンテキストとデータの相関関係を優先。監視とオブザーバビリティーは両方とも、効率的なKubernetesインフラストラクチャーを維持するための重要な部分です。それらを区別するのは目的の問題です。監視がシステム内で何が起こっているのかを明確にするのに役立つのに対し、オブザーバビリティーは、システムがなぜそのように動作しているのかを明確にすることを目的としています。そのために、Kubernetesの効果的なオブザーバビリティーでは、データ・ポイント間の点と点を結び付けて、パフォーマンスのボトルネックや機能の問題の根本原因を特定することが優先されます。
Kubernetesクラスターの動作を理解するには、他のすべてのクラスター・イベント、クラスターの一般的な動作、および問題のイベントにつながるイベントのコンテキスト内でクラスター内の個々のイベントを理解する必要があります。
例えば、ポッドがあるワーカー・ノードで起動し、別のワーカー・ノードで終了する場合、その変更やその根本原因および潜在的な結果を明確に理解するには、他のKubernetesノードで同時に発生しているすべてのイベントならびに他のKubernetes ServiceやAPIサーバー、名前空間で発生しているすべてのイベントを理解する必要があります。
言い換えれば、Kubernetes環境では、単にタスクを監視するだけでは不十分な場合が多いのです。Kubernetesのオブザーバビリティーを実現し、関連するシステムの洞察を取得し、正確な根本原因分析を行うには、ITチームがネットワーク全体からデータを集約し、コンテキスト化できる必要があります。
3. Kubernetesのオブザーバビリティー・ツールの使用。Kubernetesのオブザーバビリティーの実装と維持は、大規模で複雑な作業です。ただし、適切なフレームワークとツールを使用すると、プロセスが簡素化され、全体的なデータの可視化と透明性が向上します。
企業は、メトリクスの集計と分析を自動化するプログラム（PrometheusやGrafanaなど）、ロギングを自動化するプログラム（ELK、Fluentd、Elasticsearchなど）、トレースの可視性を促進するプログラム（Jaeger など）といった幅広いオブザーバビリティー・ソリューションから選択できます。OpenTelemetryなどの統合ソリューションは、3つの主要なオブザーバビリティー・プラクティスをすべて管理できます。また、Google Cloud OperationsやAWS X-Ray、Azure Monitor、IBM Instana Observabilityなどのカスタマイズされたクラウドネイティブ・ソリューションは、インフラ上で実行されているクラスターに最適化された観測ツールとKubernetesダッシュボードを提供します。
• KPIの定義。アプリの性能やシステムの健全性、リソースの使用状況など、インフラストラクチャーの動作に関する最も有用な洞察を提供する主要な性能指標を把握します。必要に応じてこれらを修正しましょう。
• ロギングの一元化。K8s環境では、大量のデータが生成されます。一元化されたロギング・ソリューションを使用してそれを集約し、保管することは、データ管理に不可欠です。
• リソースの使用状況の監視。メモリー、CPU、ネットワークの使用状況をリアルタイムで収集し、必要に応じてリソースを積極的に拡張できるようにしましょう。
• アラートとアラームの設定。確立されたKPIのしきい値を使用して、アラートとアラームを構成します。これにより、問題が発生したときにチームがタイムリーに通知を受け取れるようになります。
Kubernetesは業界標準のコンテナ・オーケストレーション・プラットフォームであり、コンテナ化されたワークロードを驚異的な効率で管理します。ただし、Kubernetesの分散型多層マイクロサービス・アーキテクチャーには、IBM Instana Observabilityのような堅牢なオブザーバビリティー・メカニズムと高度なソリューションが必要です。
Instana Observabilityは、あらゆるKubernetesディストリビューションに対応し、ノードやポッドからコンテナやアプリケーションに至るまで、Kubernetesアプリケーション・スタック全体を自動で監視するよう設計されたKubernetesのオブザーバビリティーとAPM（アプリケーション・パフォーマンス管理）機能を実現します。
Kubernetesのオブザーバビリティーは単なる技術的な実装ではありません。これは、綿密な計画とデータの透明性を重視する組織文化を必要とする戦略的アプローチです。
Instana Observabilityにより、チームはKubernetes環境を包括的に理解し、クラウドベース化が進む世界で堅牢で高性能のアプリケーションを提供できるようになります。