Kubernetes の可観測性が生産性を向上させ、コストを削減する 10 の方法

エンジニアリング チームは、Kubernetes 管理およびオーケストレーション レイヤーと統合されたクラウド ネイティブの可観測性プラットフォームを使用して、ビジネス目標をより早く達成できます。

「Kubernetes の可観測性が生産性を高め、コストを削減する 10 の方法」からの翻訳です。著者の Eric Sc​​habell は Chronosphere の伝道ディレクターです。彼は開発コミュニティにおける講演者、講師、作家、そして野球の専門家として知られています。

クラウド ネイティブは急速にデジタル変革の好ましい方法となりましたが、複雑さとコストが増大しないわけではありません。仮想マシン (VM) ベースのインフラストラクチャとは異なり、Kubernetes を活用したクラウドネイティブ環境は常に変化しています。これらは数千のコンテナとマイクロサービスで構成され、より多くのデータを生成し、より大きな相互依存性を持ちます。

これらの課題に対処するために、エンジニアリング チームは、Kubernetes 管理およびオーケストレーション レイヤーと統合されたクラウド ネイティブの可観測性プラットフォームを使用して、デジタル ビジネス目標をより迅速に達成し、収益を保護し、イノベーションをサポートできます。

組織がクラウドネイティブの可観測性と Kubernetes 管理ソリューションの実行を検討している場合、Kubernetes の可観測性に関して従うべき 10 のベスト プラクティスを以下に示します。

次の 10 の簡単な手順に従うことで、観測データの制御、または制御の回復が可能になります。

1. 目標を明確にする

まず、デジタル変革プログラムのビジョンを確立し、それを達成するための目標を設定します。たとえば、ハイブリッドな作業モードで顧客と接続できるアプリケーションの場合、サービス レベル目標 (SLO) はどうすればよいでしょうか。

逆に、目標とする平均修復時間 (MTTR) はどれくらいでしょうか。つまり、組織が許容できるダウンタイムはどれくらいでしょうか。どのようなリソースのピークを許容し、どれだけの資金を投資できるかを最初から決定する必要があります。これから逆算して、目標を達成するために必要な平均検出時間 (MTTD) を決定できます。

2. 最適な可観測性ソリューションを選択する

すべてのデジタル変革プロジェクトと同様に、チームはユースケースと目標に応じて、可能な限り最善のソリューションまたはソリューションの組み合わせを探す必要があります。 Kubernetes の監視やクラウド ネイティブ化には、万能のアプローチはありません。それは、人材、組織、ビジネス目標、既存のテクノロジー スタックによって異なります。

組織に最適な可観測性ソリューションを選択する際に考慮すべきツールの種類は次のとおりです。

• オープンソース メトリクス ツール: Prometheus は、Kubernetes メトリクスの事実上の標準です。スケーラビリティの制限があるため、長期保存には Thanos、Cortex、M3DB などの時系列データベースを追加することを選択することがよくあります。
• オープンソースのログ記録ツール: クラウド ネイティブ環境では、さまざまなバックエンドにデータを送信できるデータ コレクターとして機能する Cloud Native Computing Foundation (CNCF) プロジェクトの Fluentd などのログ集約ツールが多くの人に利用されています。
• オープンソース トレース ツール: Jaeger は、最も人気のあるオープンソース トレース ツールの 1 つとしてスタートしました。その後、OpenTelemetry に置き換えられました。OpenTelemetry は現在、Kubernetes に次いで CNCF で 2 番目にアクティブなプロジェクトであり、データ追跡の事実上の標準となっています。
• オープンソースのコスト最適化ツール: これらのツールは、クラスターとリソースに関するコスト情報を報告し、対処できるようにします。このカテゴリで最も人気のあるものは Kubecost と OpenCost です。
• 非オープンソース ツール: 多くのベンダーが観測可能性ツールを提供しています。ここで最も重要なのは、観測データのエンコード、転送、取り込み、クエリにオープン スタンダードを使用しているかどうかを評価することです。これらの可観測性プロバイダーが Chronosphere などの CNCF プロジェクトと統合してコミュニティ標準に準拠することを期待します。

必要なソリューションを特定したら、それをどのように活用するかを決定します。オープンソースは、Kubernetes に依存するクラウド ネイティブ エコシステム コレクターにとって重要な機能です。

可観測性を展開してアクセスするための主な方法は次のとおりです。

• オープンソースの自己管理 (別名 DIY) : これは、ベンダーのタイムラインやロックインに左右されることなく、独自のデータと可観測性のイノベーションを制御したいと考えているほとんどの組織にとってのエントリ ポイントです。環境を急速または大規模に拡張する必要がない場合は、内部の観測性が適切な選択肢となります。ただし、アプリケーションの運用環境が実行されているアベイラビリティーゾーンとは異なるアベイラビリティーゾーンでソリューションを実行、ホスト、運用、監視するためのリソース、経験、規模が必要です。
• 独自の SaaS ソリューション: DevOps およびサイト信頼性エンジニアリング (SRE) 組織の健全性と成長は、多くの場合、SaaS を選択する際の大きな要素となります。非コンテナ化環境向けの既存の SaaS (Software-as-a-Service) 監視ベンダーがある場合は、それを拡張して Kubernetes を監視できる可能性がありますが、注意すべき落とし穴がいくつかあります。価格設定は VM 指向の環境向けに設定されているため、ライセンス コストが高くなります。ダッシュボードが遅いデータ量が多いことと、Kubernetes クラスター内の主要なメトリックの可視性が不足していることが原因で、アラートが遅れることがあります。
• オープンソース互換の SaaS ソリューション: この「ゴールデン パス」は、データ制御の利点をすべて備え、ベンダー ロックインのない、スタック全体にわたる包括的でスケーラブルな可視性を提供することで実装を簡素化します。 Prometheus および OpenTelemetry と完全に互換性のあるソリューションにより、両方の長所を活用できます。その結果、組織はオープンソース ソリューションのメリットだけでなく、コミュニティ、エコシステム、チュートリアルのサポートも享受できるようになります。オープンソース サービスは、目標が変わった場合にセルフホスティングに戻る出口パスも提供します。

ソリューションを選択する最後のステップは、クラウド プロバイダー ツールを選択することです。単一のクラウド環境の場合、既存のクラウド インフラストラクチャとの緊密な統合により価格上の利点と可視性が得られるため、クラウド プロバイダーの分析および監視ツールを使用するのが合理的です。単一のクラウドを使用する場合でも、複数のクラウドを使用する場合でも、顧客エクスペリエンスに対する責任はあなたにあります。

3. コードインストルメンテーション

使用するツールを最大限に活用し、分散トレースを実装するには (ポイント 7 を参照)、コードをインストルメント化する必要があります。実際には、コードをインストルメント化するということは、データを収集し、それを任意の場所に送信することを意味します。アプリケーション パフォーマンス モニタリング (APM) またはインフラストラクチャ モニタリング プロバイダーを使用する場合のようなベンダー ロックインはありません。多くのソリューションは、特別な作業をしなくてもすぐに使用できますが、コードをインストルメント化することで、利用可能な最良のデータを取得して、最善の行動を取ることができます。

オープンソースの世界では、Prometheus は Kubernetes クラスターの健全性を把握するための標準です。ただし、実際には出力されるすべてのデータが必要になるわけではないので、注意して進めてください。データがあなたや組織にとって役に立たない場合、それは負担になります。特定のユースケースやビジネス ニーズに合わせて調整された監視エクスペリエンスは、常に、万能のアプローチよりも優れています。 Prometheus ダッシュボードを使用して学習する場合は、この点に注意してください。

4. ダッシュボードを使用して観測データを収集し、視覚化する

エンジニアは、データの視覚化を実現するダッシュボードの作成を担当します。こうすることで、システム内で何が起こっているかをすぐに理解できます。多くのソリューションにはダッシュボード システムが含まれています。たとえば、Chronosphere は、Query Accelerator テクノロジーを通じて、より高速なダッシュボードを実現するのに役立ちます。システム全体で、手動での最適化を必要とせずに、迅速かつ効率的に実行されます。

このアプローチは、エンジニアが PromQL などのクエリ言語、環境のアーキテクチャとスケール、可観測性ソリューションの基盤となるデータ モデル、またはテスト対象のクエリが本番環境でどのように実行されるかについて深い専門知識を持つ必要がないため、よりシンプルです。

5. リソースの使用状況を追跡する

リソース使用率の大幅な変化は、顧客ベースの急増や停止など、良いニュースにも悪いニュースにもなり得ます。どちらの場合でも、既存の APM またはインフラストラクチャ監視ツールを使用して、使用されているリソースの量、使用されているリソースの種類、使用されているアプリケーション、リソースが過剰に使用されているかどうかを把握することは困難です。

Chronosphere の観測データ最適化サイクルは、分析、改良、および実行のプロセスを通じて観測データのコストをより深く理解し、制御するためのアクションを実行することで、組織がこれらの課題を克服するのに役立ちます。

6. ログ記録とログの集約

クラウド ネイティブの世界では、ログ記録はチームがシステム イベントをキャプチャ、集約、理解するのに役立つため重要です。クラウドネイティブ アーキテクチャでは、イベントの数が増えますが、独立したシステム内の無関係なログの数も増えます。これにより、必要なデータを見つけて問題をトラブルシューティングすることが難しくなります。メトリックは問題の症状を診断するための重要なツールですが、問題を特定するにはトレースを使用する必要があります。また、ログは問題の根本原因を発見するのに最適です。

Kubernetes 環境でログを制御するには、データを集約してフィルタリングし、無駄を減らしてコストを節約し、必要なデータをタイムリーに簡単に見つけられるようにする必要があります。

7. 分散トレース

コードを適切にインストルメント化しないと (ポイント 2 を参照)、分散トレースをサポートすることはできません。ただし、分散トレースを使用すると、システム全体でリクエストがどのように実行されるかを確認できます。これにより、実行に時間がかかりすぎる単一の機能を特定し、顧客エクスペリエンスに影響を与える前にその理由を詳しく理解することができます。

8. アラートと通知

手順 1 ～ 7 を完了したら、自分自身またはチームへのアラートと通知を設定することをお勧めします。こうすることで、問題が発生した場合でも、タイムリーに整理して修正することができます。

9. ベストプラクティスとアップデートに従う

このステップは常識です。ほぼ毎日新しいアップデートが登場するため、将来に備えるのは簡単ではありません。ソリューション パッチと観測可能性のベスト プラクティスを最新の状態に保ちます。可能な場合は自動化を追加して、時間がかかり、エラーが発生しやすい手動プロセスを排除します。

10. コストを管理する

最高の可観測性プラットフォームは、クラウド コストと可観測性支出の管理に役立ちます。 Chronosphere とそのコントロール プレーンなどのソリューションを選択すると、可観測性ファネルに沿ったさまざまなツールが提供され、組織は次のことが可能になります。

• 保有するデータを理解する
• 何が有益で何が無駄かを分析する
• 誰かが指標に関してアラートを発したかどうかを知る
• どのタグが最も多くのカーディナリティを引き起こしているかを確認します。最もコストがかかりますが、最も使用頻度が低いタグです。

この透明性により、貴重で才能のあるエンジニアは、ビジネスにさらに大きな影響を与えるプロジェクトに集中できるようになります。コスト管理を実施したら、データの有用性を把握するためにデータを微調整し始めることができます。可観測性の支出に基づいてチームの割り当てを設定し、独立したマイクロサービスを実行しているチーム全体でコストの傾向分析を実行します。

クラウドネイティブ入門

クラウド ネイティブ環境は、デジタル変革の力を活用したいと考えている企業にとって不可欠ですが、連携してベスト プラクティスを採用できる適切なツールを備えている必要があります。 Chronosphere とそのパートナーは、クラウド ネイティブ環境の複雑さを抽象化し、データを最適化し、エンジニアの作業負荷を軽減するためにゼロから構築されました。