관련링크

はじめに

こんにちは、WhaTap Labsのベッキーです。25回目の月刊WhaTapでは、Kubernetesのためのオブザーバビリティをご紹介します。韓国最大のITカンファレンス、2022 AWS Summit Koreaが5月11日に終了しました。最新のIT技術トレンドを紹介するこの場で、WhaTab Labsもセッションを行ないました。今月のWhaTapでは、WhaTap LabsのキムソンジョCTOのKubernetesのためのオブザーバビリティをレビューします。

💡 より詳細な説明は、AWSサミットセッションの再表示で7月31日までご覧いただけます。(登録およびログイン必須)

過去のモニタリングは？

過去のモニタリングツールでは、地域固有のポイントソリューションを使用するのが一般的でした。サーバーとアプリケーションの関係がすでにオペレーティングシステムを構築する際に決定されたからでした。そのため、異なるツールで分析された内容であっても、関連づけて解釈が可能でした。ところが2010年代初頭、デジタルトランスフォーメーションが登場します。

デジタルトランスフォーメーションの登場がモニタリングの概念を変えたと?!

デジタルトランスフォーメーションの究極の目標は、デジタル技術に基づいてビジネス領域を革新するために、ITシステムがビジネスのスピードに合わせて急速に発展することです。今はITがビジネスの発展をリードしています。市場の変化に適応するためには、継続的に開発し、迅速に展開する必要が生き残ることができます。

継続的な開発と迅速な展開のために、軽量化された高速コンテナ技術により、複雑なマイクロサービスのためのシステム構築が可能になりました。 多くのコンテナを管理するためにKubernetesが登場するようになりました。

Kubernetesは、インフラとアプリケーション間のコンテナをオーケストレーションします。従来のシステムにKubernetesというやつが登場し、今やサーバーとアプリケーション、そしてデータベース間の物理的な関係をモニタリング時代のように同じように分析することができなくなるそうです。その結果、デジタルトランスフォーメーションがKubernetesを登場させた背景となり、デジタルトランスフォーメーションによってモニタリングの視点を完全に変えたわけです。

だからKubernetesを使うなら、モニタリングの観点も変わらなければなりません。静的な監視を超えてシステムを統合的にモニタリングする必要があります。サーバー、コンテナ、アプリケーション、データベースのパフォーマンスデータを単一のソリューションでモニタリングすることを強調しました。だから登場したモニタリングの観点がオブザーバビリティです。

制御工学から始まったオブザーバビリティ

オブザーバビリティは、外部出力で内部状態を測定する能力です。これをモニタリングに適用すると、適切なモニタリングツールを使用して内部パフォーマンスの状態を測定する能力にまとめることができます。したがって、モニタリングは静的システムに対する観察である場合、オブザーバビリティは動的システムに対する観察可能性と考えられます。

オブザーバビリティは、Metrics(パフォーマンス指標)、Traces(トランザクション連携追跡)、Logs(ログ)を使用してパフォーマンスを分析する必要があります。複雑なシステムでは、パフォーマンス指標だけでなくトランザクションプロファイルも一緒に追跡する必要があり、パフォーマンス分析が可能になります。Kubernetesベースのシステムでは、パフォーマンス指標とトランザクション追跡だけでなく、システムに残っているさまざまなログを確認して分析する必要があります。

Metrics (パフォーマンス指標)

Kubernetesではインフラとアプリケーションの関係が動的です。そのため、クラウドを含むインフラゾーンのパフォーマンス指標とアプリゾーンのパフォーマンス指標を一緒にモニタリングする必要があります。さらに、コンテナを自動的にスケールイン/アウトするため、オペレータがいなくてもパフォーマンスモニタリングが可能でなければなりません。

静的モニタリングでは、ゾーンごとの個々のソリューションにパフォーマンスデータがそれぞれ保存され、最小限の統合ビューのみを提供しました。一方、オブザーバビリティでは、ゾーン固有のパフォーマンスデータが統合ソリューションに保存され、統合ダッシュボードから連想分析と連携追跡を可能にする必要があります。

Traces（トランザクション連携追跡）

リアルタイムトランザクションモニタリングは、20年以上の間その必要性を証明し、Kubernetesでも必須ですが、これを超えるトレース機能が必要です。ユーザーの要求は複数のマイクロサービスで処理されるため、分散追跡は非常に重要になり、非常に困難になりました。

なぜ難しくなったのですか？

まず、コンテナ環境でアプリケーションを軽量化するための非同期技術の使用が増加し、非同期スレッドで追跡するトランザクションは難しいからです。

第二に、1つの単一トランザクションが複数に分割され、追跡するトランザクションの数が以前よりも数十倍増加しました。

第三に、より多くの複雑なオープンソースコンポーネントが使用されています。

第四に、場合によってはマイクロサービスを開発する際にそれぞれ異なる言語を使用するため、Kubernetesでは単一のトレースではトランザクション分析が難しくなりました。

Logs(ログ)

ログは、伝統的なシステムでは大きな比重を占めていませんでした。それでも、サーバーに残ったログをコンソールコマンドで簡単に見つけることができたそうです。ところがKubernetesではコンテナが終了し、ログが消えて確認できなくなったそうです。

そして開発者が運用に参加するDevOpsが登場し、ログへの依存度が高まったのです。さまざまなオープンソースコンポーネントを使用することで、ログをもう少し積極的にモニタリングする必要があります。トランザクションビューやコンテナのパフォーマンスを分析しながら関連ログを参照する必要があり、ログの重要性が高まりました。そのため、統合ログモニタリングはオブザーバビリティにとって必須となりました。

おわりに

モニタリングは、ゾーンごとのポイントソリューションで統合されたソリューションが必須であり、さまざまなシステムコンポーネントから発生するパフォーマンスデータをMetrics(パフォーマンス指標)、Traces(トランザクション連携追跡)、Logs(ログ)の観点から統合収集して分析できる オブザーバビリティを実装する必要があります。

以前より膨大で複雑になった統合収集データを分析するには、まずトランザクションの観点またはコンテナの観点からデータを表示し、その後に関連するメトリクスまたはログを分析してパフォーマンスの問題を解釈できる必要があります。Kubernetesを導入計画中またはすでに導入している場合は、オブザーバビリティツールをお勧めします。😊😊