ハイブリッドクラウドとマルチクラウドのベストプラクティス
はじめに
マルチクラウドとは、複数のクラウドサービスプロバイダーを同時に使用してワークロードを運用することを指し、ハイブリッドとは、オンプレミスとクラウド環境の両方にワークロードを拡張することを指します。 ハイブリッドおよびマルチクラウド環境におけるオブザーバビリティは、ツールの多様性、レイテンシー、異種ワークロードにより、大きな複雑さを伴う可能性があります。 それにもかかわらず、これは開発者とビジネスユーザーの両方にとって共通の目標であり続けています。 この目標を達成するために、豊富な製品とサービスのエコシステムが存在します。
しかし、クラウドネイティブなワークロードに対するオブザーバビリティツールの有用性は、大きく異なる場合があり ます。 コンテナ化されたバッチ処理ワークロードと、サーバーレスフレームワークを使用するリアルタイムバンキングアプリケーションのモニタリング要件の違いを考えてみましょう。 両者ともログ、メトリクス、トレースを持っていますが、それらを観察するためのツールチェーンは、クラウドネイティブ、オープンソース、ISV 製品など、さまざまな選択肢があります。 Prometheus のようなオープンソースツールが一方に適している一方で、マネージドサービスとして提供されるクラウドネイティブツールが要件をより良く満たす場合もあります。
これにマルチクラウドとハイブリッドの複雑さが加わると、アプリケーションからの洞察を得ることはさらに困難になります。
これらの追加された次元に対処し、オブザーバビリティへのアプローチを容易にするため、お客様は統一されたインターフェースを持つ単一のツールチェーンに投資する傾向があります。 結局のところ、シグナルとノイズの比率を下げることは通常良いことです！ しかし、単一のアプローチがすべてのユースケースに適用できるわけではなく、さまざまなプラットフォームの運用モデルが混乱を招く可能性があります。 私たちの目標は、お客様のニーズを補完し、問題が発生した際の平均修復時間を短縮するための情報に基づいた決定を支援することです。 以下は、あらゆる規模、すべての業界のお客様との協業を通じて学んだベストプラクティスです。
これらのベストプラクティスは、エンタープライズアーキテクト、開発者、DevOps など、幅広い役割を対象としています。 組織のビジネスニーズと、分散環境におけるオブザーバビリティがどれだけの価値を提供できるかという観点から、これらを評価することをお勧めします。
ツールに判断を左右されないようにする
アプリケーション、ツール、プロセスは、売上や顧客満足度の向上などのビジネス成果を達成するために存在します。 適切な技術戦略とは、これらのビジネス目標の達成を可能な限り支援するものです。 しかし、目標達成を支援するものは単なるツールであり、戦略を支援するためのものであって、戦略そのものではありません。 たとえば、家を建てる必要がある場合、ツールに設計や建築方法を尋ねることはしません。 むしろ、ツールは目的を達成するための手段なのです。
単一の同質な環境では、ツールに関する判 断は比較的容易です。 結局のところ、1 つの環境で単一のアプリケーションを実行する場合、ツールは全体で同じものを簡単に使用できます。 しかし、ハイブリッドおよびマルチクラウド環境では状況はより複雑になり、ビジネス成果と、これらの環境全体でワークロードを監視することによって得られる価値に注目することが重要です。 各クラウドサービスプロバイダー (CSP) には独自のネイティブなオブザーバビリティソリューションがあり、利用可能なパートナーや独立系ソフトウェアベンダー (ISV) も豊富に存在します。
複数の環境で運用しているからといって、すべてのワークロードに単一のツールを使用することが推奨されるわけではありません。 これは、ワークロードを監視するために複数のサービス、フレームワーク、またはプロバイダーを使用する可能性があることを意味します。 運用モデルがニーズを反映する必要がある方法の詳細については、以下の「ワークロードのコンテキストの方が単一の管理画面よりも重要」を参照してください。 いずれにせよ、ツールを実装する際は、将来オブザーバビリティソリューションを進化させることができるように「Two-way doors」を作成することを忘れないでください。
以下は、避けるべき「ツール優先」の結果の例です：
- 将来のアップグレードや新しいソリューションへの移行のた めの Two-way door なしに単一のツールの実装に焦点を当てると、回避可能な技術的負債が生じる可能性があります。 これは、ツールがソリューションとなり、いつの日か解決が必要な問題となる可能性があるときに発生します。
- ボリュームディスカウントにより単一のツールを使用する企業標準は、有益な機能を得られない可能性があります。 これは「品質よりもコスト」となり、意図せずモノリシックなアンチパターンを生み出す可能性があります。 ボリュームしきい値以下を維持するためにテレメトリの収集を抑制し、結果としてオブザーバビリティツールの使用を妨げる可能性があります。
- ログとメトリクスのコレクターは充実しているものの、既存のトレース収集インフラストラクチャがないためにテレメトリの種類全体（通常はトレース）を収集しないことは、不完全なオブザーバビリティソリューションにつながる可能性があります。
- 労働コストとトレーニングコストを削減したいという理由で、サポートスタッフが単一のツールチェーンのみのトレーニングを受けることで、他のオブザーバビリティパターンの潜在的な価値が低下する可能性があります。
ツールがオブザーバビリティ戦略を決定している場合は、アプローチを逆転 させる必要があります。 ツールはオブザーバビリティを実現し、強化するためのものであり、選択肢を制限するものではありません。
ツールの乱立は企業が苦労している実際の問題ですが、単一のツールチェーンへの急激な移行も同様にオブザーバビリティソリューションの有用性を低下させる可能性があります。 ハイブリッドおよびマルチクラウドのワークロードには、各プラットフォーム固有のテクノロジーがあり、各 CSP の高度なサービスは有用です。 ただし、単一ソース製品を使用することのトレードオフには、価値に基づく分析が必要です。 これらのリスクの一部を軽減するアプローチについては、「OpenTelemetry への投資」を参照してください。
オブザーバビリティデータには重力がある
すべてのデータには重力があります。つまり、ワークロード、ソリューション、ツール、人、プロセス、プロジェクトを引き寄せ る力があるということです。 例えば、顧客の取引データを含むデータベースは、コンピューティングや分析ワークロードを引き寄せる引力となります。 これは、ワークロードをどこに配置するか、どの環境で実行するか、そしてどのように運用していくかに直接的な影響を与えます。 同様のことがオブザーバビリティのシグナルにも当てはまりますが、このデータが生み出す重力は、ワークロードと組織のコンテキストに結びついています（「シングルペインオブグラスはワークロードのコンテキストほど重要ではない」を参照）。
オブザーバビリティのテレメトリのコンテキストを、その基盤となるワークロードやデータから完全に切り離すことはできません。 同じルールがここでも適用されます。テレメトリはデータであり、重力を持っています。 これは、テレメトリエージェント、コレクター、またはシグナルを集約・分析するシステムをどこに配置するかに影響を与えるべきです。
オブ ザーバビリティデータの時間経過に伴う価値は、他のほとんどのデータタイプと比べてかなり低くなります。 これをオブザーバビリティデータの「半減期」と呼ぶこともできます。 テレメトリを別の環境に中継する際の追加レイテンシーを、データ使用前の強制的な価値低下と考え、問題発生時のアラート要件と比較検討してください。
ベストプラクティスは、データの集約によってビジネス価値が得られる場合にのみ、環境間でデータを送信することです。 データクエリのための単一のソースを持つことだけでは、多くのビジネスニーズを解決することはできず、より高価なソリューションや障害点の増加を招く可能性があります。
シングルペインオブグラスよりもワークロードのコンテキストが重要
「シングルペインオブグラス」でワークロード を全て監視したいという要望は一般的です。これは、できるだけシンプルな方法で可能な限り多くのデータを表示し、混乱やフラストレーション、診断時間を減らしたいという自然な欲求から生まれます。オブザーバビリティソリューション全体を一度に見るためのインターフェースを作成することは有用ですが、テレメトリーデータをそのコンテキストから切り離してしまうというトレードオフが生じる可能性があります。
例えば、100 台のサーバーの CPU 使用率を表示するダッシュボードは、消費量の異常なスパイクを示すかもしれませんが、なぜこれが発生したのか、またはこの動作に寄与する要因が何であるかを説明することはできません。また、このメトリクスの重要性が即座には明確にならない可能性があります。
時として、お客様がシングルペインオブグラスを過度に追求するあまり、ビジネスのコンテキストが失われ、1 つのツールで全てを見ようとすることで、データの価値が実際には希薄化してしまうケースを見てきました。ダッシュボードとツールはストーリーを語る必要があります。そしてこのストーリーには、ワークロードのイベントによって影響を受けるビジネスメトリクスと成果を含める必要があります。
さらに、ツールは運用モデルに合わせる必要があります。シングルペインオブグラスは、サポートチームがグローバルで全ての環境にアクセスできる場合に価値を付加できますが、単一のワークロード、単一の CSP またはハイブリッド環境にのみアクセスが制限されている場合、このアプローチによる付加価値はあり ません。このような場合、チームが各環境でネイティブにダッシュボードを作成できるようにすることで、価値実現までの時間を短縮し、将来の変更にも柔軟に対応できる可能性があります。
オブザーバビリティデータの価値は、それが生成されたアプリケーションと深く統合されています。テレメトリーデータには、その環境から得られるコンテキストの認識が必要です。ハイブリッドおよびマルチクラウド環境では、技術の違いによってコンテキストの必要性がさらに高まります（ただし、Kubernetes のようなシステムは、異なるクラウドプロバイダーやオンプレミス間で類似している場合があります）。
分散システム用のシングルペインオブグラスを構築する際は、ビジネスメトリクスと Service Level Objectives (SLOs) を、これらの SLOs に寄与する他のデータ（インフラストラクチャメトリクスなど）と同じビューに表示 してください。これにより、他の方法では欠けているかもしれないコンテキストが提供されます。
シングルペインオブグラスは、テレメトリーデータの意味を保持できる場合に限り、問題の迅速な診断と検知時間（MTTD）、そして平均解決時間（MTTR）の短縮に役立ちます。これがなければ、シングルペインオブグラスアプローチは価値実現までの時間を増加させ、運用チームにとってマイナスの効果をもたらす可能性があります。
シングルペインオブグラスの価値が判断できない場合、またはワークロードが完全に単一の CSP やオンプレミス環境に限定されている場合は、トップレベルのビジネスメトリク スのみをシングルペインオブグラスにロールアップし、生のメトリクスや他の寄与要因は元の環境に残すことを検討してください。
OpenTelemetry への投資
オブザーバビリティベンダーの世界において、OpenTelemetry (OTel) は事実上の標準となっています。 OTel は、各種のテレメトリーデータを 1 つまたは複数のコレクターにマーシャリングできます。 これには、クラウドネイティブサービスや、さまざまな SaaS および ISV 製品が含まれます。 OTel エージェントとコレクターは OpenTelemetry Protocol (OTLP) を使用して通信を行い、シグナルを多様なデプロイパターンを可能にする形式にカプセル化します。
最も価値のあるトランザクショントレースを、ビジネスとインフラストラクチャのコンテキストとともに収集するには、アプリケーションにトレース収集を統合する必要があります。 一部の自動計装エージェントは、ほとんど労力をかけずにこれを実行できます。 ただし、より高度なユースケースでは、トランザクショントレースをサポートするためにコードの変更が必要です。 これにより技術的負債が生まれ、ワークロードが特定の技術に縛られることになります。
OTel は、スパンという概念を使用してログ、メトリクス、トレースを収集します。 スパンには、単一のトランザクションからグループ化されたこれらのシグナルが含まれ、コンテキスト化された検索可能なオブジェクトにパッケージ化 されます。 これにより、単一のアプリケーションイベントからのシグナルを 1 つのシンプルなエンティティとして表示できます。 たとえば、ユーザーが Web サイトにログインする際に、それが統合されているすべてのダウンストリームサービスへのリクエストを生成する場合、それらを単一のスパンとして表示できます。
OTel はアプリケーショントレースに限定されず、ログやメトリクスにも広く使用されています。また、多くの ISV 製品が現在 OTLP を直接受け入れています。
OTel を使用してアプリケーションを計装することで、将来別のオブザーバビリティプラットフォームに移行する場合でも、アプリケーション層での計装を置き換える必要がなくなります。これにより、オブザーバビリティソリューションの一部が Two-way Door となります。
OTel は将来性があり、スケーラブルで、アプリケーションコードを変更することなく収集および分析システムを将来変更することを容易にします。これにより効率的な シフトレフト が可能になります。