ハイブリッドおよびマルチクラウドのベストプラクティス

はじめに

マルチクラウドとは、複数のクラウドサービスプロバイダーを同時に使用して自社のワークロードを運用することを指します。一方、ハイブリッドとは、オンプレミス環境とクラウド環境の両方にワークロードを拡張することを意味します。ハイブリッドおよびマルチクラウド環境におけるオブザーバビリティは、ツールの多様性、レイテンシー、異種ワークロードにより、大きな複雑さを伴う可能性があります。それにもかかわらず、これは開発者とビジネスユーザーの両方にとって共通の目標であり続けています。この目標に対応する豊富な製品とサービスのエコシステムが存在します。

しかし、クラウドネイティブなワークロードに対するオブザーバビリティツールの有用性は大きく異なる場合があります。コンテナ化されたバッチ処理ワークロードと、サーバーレスフレームワークを使用するリアルタイムバンキングアプリケーションのモニタリング要件の違いを考えてみてください。両者にはログ、メトリクス、トレースがありますが、それらを観察するためのツールチェーンは異なり、クラウドネイティブ、オープンソース、ISV 製品など、多数の選択肢があります。Prometheus のようなオープンソースツールが一方に適している場合もあれば、マネージドサービスとして提供されるクラウドネイティブツールが要件をより適切に満たす場合もあります。

これにマルチクラウドとハイブリッドの複雑さが加わると、アプリケーションからの洞察を得ることはさらに困難になります。

これらの追加された次元に対処し、オブザーバビリティへのアプローチを容易にするために、顧客は統一されたインターフェースを持つ単一のツールチェーンに投資する傾向があります。結局のところ、シグナル対ノイズ比を減らすことは通常良いことです！しかし、単一のアプローチがすべてのユースケースに適用されるわけではなく、さまざまなプラットフォームの運用モデルが混乱を招く可能性があります。私たちの目標は、お客様のニーズを補完し、問題が発生した際の平均修復時間を短縮するための情報に基づいた決定を支援することです。以下は、あらゆる規模の顧客と、すべての業界での作業を通じて学んだベストプラクティスです。

ヒント

これらのベストプラクティスは、エンタープライズアーキテクト、開発者、DevOps など、幅広い役割を対象としています。組織のビジネスニーズと、分散環境におけるオブザーバビリティがどのように最大限の価値を提供できるかという観点から、これらを評価することをお勧めします。

ツールに決定を左右されないようにする

アプリケーション、ツール、プロセスは、売上や顧客満足度の向上などのビジネス成果を達成するために存在します。適切なテクノロジー戦略とは、これらのビジネス目標の達成を可能な限り支援するものです。しかし、目標達成に役立つものは単なるツールであり、戦略を支援するためのものであって、戦略そのものではありません。例えを挙げると、家を建てる必要がある場合、ツールに設計や建築方法を尋ねることはしません。むしろ、ツールは目的を達成するための手段です。

単一の同質な環境では、ツールに関する決定は比較的容易です。結局のところ、1 つの環境で単一のアプリケーションを実行する場合、ツールは全体で簡単に同じものを使用できます。しかし、ハイブリッドおよびマルチクラウド環境では状況はより複雑であり、ビジネス成果に注目し続けること、そしてこれらの環境全体でワークロードを観察することによって付加される価値に注目することが重要です。各クラウドサービスプロバイダー（CSP）には独自のネイティブなオブザーバビリティソリューションがあり、利用可能な豊富なパートナーや独立系ソフトウェアベンダー（ISV）のセットもあります。

複数の環境で運用しているからといって、すべてのワークロードに単一のツールを使用することが推奨されるわけではありません。これは、ワークロードを観察するために複数のサービス、フレームワーク、またはプロバイダーを使用する可能性があることを意味します。運用モデルがニーズを反映する必要がある方法の詳細については、以下の「単一の画面よりもワークロードのコンテキストの方が重要」を参照してください。いずれにせよ、ツールを実装する際は、将来オブザーバビリティソリューションを進化させることができるように「双方向のドア」を作成することを忘れないでください。

以下は、避けるべき「ツール優先」の結果の例です：

1. アップグレードや将来の新しいソリューションへの移行のための双方向のドアなしに単一のツールの実装に焦点を当てると、回避可能な技術的負債を生み出す可能性があります。これは、ツールがソリューションであり、いつの日か解決すべき問題になる可能性がある場合に起こります。

2. ボリュームディスカウントのために単一のツールを使用する会社標準は、恩恵を受けられる機能がない状態になる可能性があります。これは「品質よりもコスト」となり、意図せずにモノリシックなアンチパターンを生み出す可能性があります。これにより、ボリューム閾値以下に留まるためにテレメトリの収集が抑制され、結果としてオブザーバビリティツールの使用が阻害される可能性があります。

3. 既存のトレース収集インフラストラクチャがないが、豊富なログとメトリクスコレクターがある場合に、特定のタイプのテレメトリ（通常はトレース）を全く収集しないことは、不完全なオブザーバビリティソリューションにつながる可能性があります。

4. 労働力と訓練コストを削減したいという願望から、サポートスタッフが単一のツールチェーンのみのトレーニングを受けることで、他のオブザーバビリティパターンの潜在的な価値が減少する可能性があります。

備考

ツールがオブザーバビリティ戦略を決定している場合、アプローチを逆転させる必要があります。ツールはオブザーバビリティを可能にし、強化するためのものであり、選択肢を制限するものではありません。

備考

ツールの乱立は企業が苦心している非常に現実的な問題ですが、単一のツールチェーンへの急激な移行も同様にオブザーバビリティソリューションの有用性を低下させる可能性があります。ハイブリッドおよびマルチクラウドワークロードには、各プラットフォーム固有のテクノロジーがあり、各 CSP の高レベルサービスは有用です。ただし、単一ソース製品を使用することのトレードオフには価値ベースの分析が必要です。これらのリスクの一部を軽減するアプローチについては、「OpenTelemetry に投資する」を参照してください。

(オブザーバビリティ) データには重力がある

すべてのデータには重力があります。つまり、ワークロード、ソリューション、ツール、人、プロセス、プロジェクトを引き寄せるということです。 例えば、顧客の取引データを含むデータベースは、コンピューティングや分析ワークロードを引き寄せる引力となります。 これは、ワークロードをどこに配置するか、どの環境に配置するか、そしてそれらをどのように運用していくかに直接的な影響を与えます。 同じことがオブザーバビリティのシグナルにも当てはまりますが、このデータが生み出す重力は、ワークロードと組織のコンテキストに結びついています（「単一のペインは、ワークロードのコンテキストほど重要ではありません」を参照）。

オブザーバビリティのテレメトリのコンテキストを、それに関連する基盤となるワークロードやデータから完全に切り離すことはできません。 ここでも同じルールが適用されます：テレメトリはデータであり、それには重力があります。 これは、テレメトリエージェント、コレクター、またはシグナルを集約・分析するシステムをどこに配置するかに影響を与えるべきです。

ヒント

時間の経過とともに、オブザーバビリティデータの価値は他のほとんどのデータタイプよりもかなり低くなります。 これをオブザーバビリティデータの「半減期」と呼ぶこともできます。 テレメトリを別の環境に中継する際の追加レイテンシーを、使用前のこのデータの強制的な価値低下と考え、問題が発生したときのアラート要件と比較検討してください。

備考

ベストプラクティスは、環境間でデータを発信する際、この集約からビジネス価値が得られる場合にのみ行うことです。 データクエリのための単一のソースを持つことだけでは、多くのビジネスニーズを解決することはできません。 また、望ましい以上に高価なソリューションとなり、障害点が増える可能性があります。

単一のダッシュボードよりもワークロードのコンテキストが重要

すべてのワークロードを観察するための「単一のダッシュボード」がよく求められます。これは、できるだけ多くのデータを可能な限りシンプルな方法で表示し、混乱、フラストレーション、診断時間を減らしたいという自然な欲求から生まれます。このような観察性ソリューション全体を一度に見るためのインターフェースを作成することは有用ですが、テレメトリをそのコンテキストから切り離してしまうというトレードオフが生じる可能性があります。

例えば、100 台のサーバーの CPU 使用率を表示するダッシュボードは、消費量の異常なスパイクを示すかもしれません。しかし、これだけではなぜそれが起こったのか、またはこの動作の要因が何であるかを説明することはできません。そして、このメトリクスの重要性が即座に明確にならない可能性があります。

時として、顧客が単一のダッシュボードを追求するあまり、すべてのビジネスコンテキストが失われ、1 つのツールですべてを見ようとすることで、実際にそのデータの価値が薄められてしまうことがあります。ダッシュボードやツールはストーリーを語る必要があります。そして、このストーリーには、ワークロードのイベントによって影響を受けるビジネスメトリクスや成果を含める必要があります。

さらに、ツールはあなたの運用モデルに合わせる必要があります。単一のダッシュボードは、サポートチームがグローバルで、すべての環境にアクセスできる場合に価値を追加できますが、単一のワークロード、単一の CSP またはハイブリッド環境にのみアクセスが限定されている場合、このアプローチで付加価値は生まれません。このような場合、各環境内でネイティブにダッシュボードを作成できるようにすることで、価値実現までの時間を短縮し、将来の変更にも柔軟に対応できる可能性があります。

備考

観察性データの価値は、それが生成されたアプリケーションに深く統合されています。テレメトリには、その環境から得られるコンテキストの認識が必要です。ハイブリッドおよびマルチクラウド環境では、技術間の違いによりコンテキストの必要性がさらに高まります（ただし、Kubernetes のようなシステムは、異なるクラウドプロバイダーやオンプレミス間で類似している場合があります）。

備考

分散システムの単一のダッシュボードを構築する際は、ビジネスメトリクスとサービスレベル目標（SLO）を、これらの SLO に寄与する他のデータ（インフラストラクチャメトリクスなど）と同じビューに表示します。これにより、他の方法では欠けている可能性のあるコンテキストが提供されます。

ヒント

単一のダッシュボードは、問題の迅速な診断に役立ち、検出時間（MTTD）、ひいては平均解決時間（MTTR）を短縮できますが、これはテレメトリデータの意味を保持できる場合に限ります。これがなければ、単一のダッシュボードアプローチは価値実現までの時間を増加させたり、運用チームにとってマイナスになる可能性があります。

備考

単一のダッシュボードの価値が判断できない場合、またはワークロードが完全に単一の CSP またはオンプレミス環境に限定されている場合は、トップレベルのビジネスメトリクスのみを単一のダッシュボードにロールアップし、生のメトリクスやその他の寄与要因を元の環境に残すことを検討してください。

OpenTelemetry への投資

オブザーバビリティベンダーの領域全体で、OpenTelemetry (OTel) は事実上の標準となっています。OTel は、各種のテレメトリーを 1 つまたは複数のコレクターにマーシャリングできます。これには、クラウドネイティブサービスや、さまざまな SaaS および ISV 製品が含まれます。OTel エージェントとコレクターは、OpenTelemetry プロトコル (OTLP) を使用して通信します。OTLP は、シグナルを幅広いデプロイメントパターンを可能にする形式にカプセル化します。

最も価値のあるトランザクショントレースを、ビジネスやインフラストラクチャのコンテキストとともに収集するには、アプリケーションにトレース収集を統合する必要があります。一部の自動計装エージェントは、ほとんど労力をかけずにこれを実行できます。しかし、最も高度なユースケースでは、トランザクショントレースをサポートするためにコードの変更が必要です。これにより技術的負債が生じ、ワークロードが特定の技術に縛られることになります。

OTel は、スパンという概念を使用してログ、メトリクス、トレースを取得します。スパンには、単一のトランザクションからグループ化されたこれらのシグナルが含まれ、コンテキスト化され検索可能なオブジェクトにパッケージ化されます。つまり、単一のアプリケーションイベントからのシグナルを 1 つのシンプルなエンティティで表示できます。例えば、ユーザーがウェブサイトにログインし、それが統合されているすべてのダウンストリームサービスへのリクエストを作成する場合、これを単一のスパンとして表示できます。

ヒント

OTel はアプリケーショントレースに限定されず、ログやメトリクスにも広く使用されています。また、多くの ISV 製品が今日 OTLP を直接受け入れています。

備考

OTel を使用してアプリケーションを計装することで、将来別のオブザーバビリティプラットフォームに移行する場合に、アプリケーション層でこの計装を置き換える必要がなくなります。これにより、オブザーバビリティソリューションの一部が 双方向のドア になります。

備考

OTel は将来性があり、スケーラブルで、アプリケーションコードを変更せずに収集および分析システムを将来変更しやすくします。これにより、効率的な 左シフト が可能になります。