クラウドの可観測性における5つの主要な新たなトレンド

[[431137]]

Red Hat の主席ソフトウェア エンジニアである Bartłomiej Płotka 氏は、現代のクラウドの可観測性における 5 つの主要な新たなトレンドを特定しています。

高度に抽象化され、仮想化され、多くの場合は一時的であり、常に動的なクラウド コンピューティング リソースの世界では、継続的な可観測性を実現する必要性が重要です。しかし、企業の中には、社内システムの可観測性を考慮せずにクラウド コンピューティング サービスを作成するところもあります。当初は、リソースの柔軟性とコスト管理性を通じて IT の俊敏性を高めるための重要な手段として販売されていました。

クラウドの導入が拡大している今、一歩下がって観測可能性の機能を評価する必要があります。さらに、クラウド ネイティブ実装はパブリック、プライベート、ハイブリッド、マルチクラウド (複数のベンダー) インスタンスにまたがるため、アプリケーションとデータ サービスのワークロードのさまざまな部分が異なるクラウド コンピューティング サービス プロバイダー間で分離されるマルチクラウドについて検討し始めることができます。

制御理論に基づくと、現代のクラウド コンピューティング時代における可観測性はさまざまな形で現れますが、企業がより優れた可視性を得るためにクラウドに移行する方法に影響を与えている主な要因は何でしょうか。

APMはどこにでもある

クラウドの可観測性と APM (アプリケーション パフォーマンス監視) の違いを知りたい人はたくさんいます。かつては「単に」仮想マシンを所有していたため、コンピューティング ブロックまたはインスタンスを比較的簡単に監視対象に公開できました。

私たちは現在、ネストされた仮想化、ソフトウェア定義インフラストラクチャ (SDI)、クラウド コンピューティング サービスの世界に生きています。企業のアプリケーション ワークロードは通常、オペレーティング システム、エージェント、オーケストレーション ソフトウェア、コンテナー エンジン、仮想マシン、外部サービスなどのソフトウェア レイヤー (「アプリケーション」とも呼ばれます) に囲まれています。

APM は可観測性とほぼ同義語となり、現在では IT スタック全体のあらゆるレイヤーと構造に拡大しています。明らかに、アプリケーション用の APM が必要ですが、インフラストラクチャ APM (iAPM) も必要であり、現在使用されている仮想化デバイスをターゲットにできる必要があります。

APM と非アプリケーション監視を区別する必要がなくなる段階に達している可能性があります。業界では、同様の方法でクラウド内のさまざまなソフトウェアを監視および観察するためのツールがすでに提供されています。

フェデレーション集中オーケストレーションビュー

複数の異なるクラウド プロバイダーと多数のクラウド インスタンスが存在する世界では、制御を維持するために、集中化されたビューと、複数のクラスター内の複数のクラウドにわたってフィルタリングおよび集約する機能を備えた、調整されたレベルのフェデレーションされた監視可能性が必要です。

観測可能性データを一元化された場所に統合することは、今日では一般的なテクノロジーとプロセスです。これは、クラウドの過負荷、不適切な構成、インスタンスがアイドル状態になっている「ゾンビ」クラウドの無駄を見つけるための最良の方法であることが証明されています。これらすべてを組み合わせることで、より効率的なクラウド コンピューティング リソースを活用してコンテンツ配信ネットワークにサービスを提供し、全体的によりスマートなレベルで作業できるようになります。

内部依存関係を考慮する

現在消費および生成されるデータの量により、観測可能性の要件に応じて追跡する信号をさらに取得できるようになります。 IoT によってデータ ポイントが飛躍的に増加しているという事実を考慮すると、膨大なデータ量によって、データ ストリームの観点からの観測可能性がはるかに困難になります。

この課題に対処するには、相関関係を考慮する必要があります。システム メトリック、ログ、トレースを分析しようとする場合、これらのプログラムとタスク間をすばやく切り替えて、IT スタックのさまざまな部分で動的に作業できる必要があります。観察すべきことがたくさんあるため、接続された関連性は、IT 機能の運用に実際に不可欠なデータ ソース間の重要なリンクを提供するのに役立ちます。

継続的な分析

可観測性の目標により、パフォーマンス効率を向上できる最適化が求められます。これは、さまざまな観測信号を見つけ、追跡し、分析することを意味します。これを行う最良の方法の 1 つは分析です。この技術により、プロセスのリソース使用量を調べるときに推測することなく、アプリケーションのどの部分がどれだけのコンピューティング リソース (CPU 時間、メモリ、ディスク、またはネットワーク IO) を使用しているかを知ることができます。

継続的な分析により、アプリケーションを確認し、興味があれば過去のパフォーマンス特性を確認することができます。メモリが不足してノード全体がクラッシュする可能性がある場合に特に役立ちます。アプリケーション プロファイルを 60 秒ごとに (またはそれよりも頻繁に) 表示できれば、アプリケーション ソース コード内の関数を最適化または拡張する必要がある場所を確認できます。これは、特定の関数呼び出しに逆方向にマップできるようにするデバッグ シンボルが埋め込まれているため、コンパイルされた (解釈されたのではなく) アプリケーションの場合でも遡及的に実行できます。

eBPF のアクティビティが豊富

最後に、eBPF、つまり完全な名前で言うところの Extended Berkeley Packet Filter があります。これは、Linux カーネル内で追加のコードを実行できるようにするメカニズムです。この「特別な機械」技術を使用してカーネルの特定の関数の内部を調べることができる場合、観測可能性に対する新しい制御が可能になります。追加の利点として、eBPF ではメトリックのキャプチャを開始するためにアプリケーション レベルのインストルメンテーションを必要としないことも注目に値します。

もともとセキュリティのために設計されましたが、現在ではアプリケーションに関するメトリックを公開するために、より積極的に使用できるようになりました。アプリケーションの周囲にプロキシを配置する方法としてサービス メッシュの使用が検討されていますが、サービス メッシュはオーバーヘッドが少なく機能が豊富な eBPF に置き換えることができます。

「カナリア デプロイメント」では依然としてサービス メッシュが必要になる場合があり、カナリア デプロイメント (トラフィックの厳密な制御) や認証 (相互 TLS 経由) など、非可観測性のためのサービス メッシュの使用例がまだあることに注意する必要があります。 eBPF を使用してこのレベルでトラフィックを形成する試みはまだ行われておらず、現在のところ eBPF の使用例はセキュリティと監視可能性のみです。

最新の IT スタックに可観測性を実装する際にこれらの要素と機能を考慮すると、クラウドに何が期待できるかがわかります。