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