ハイブリッドおよびマルチクラウドのベストプラクティス
はじめに
マルチクラウドとは、複数のクラウドサービスプロバイダーを同時に使用して自社のワークロードを運用することを指します。一方、ハイブリッドとは、オンプレミス環境とクラウド環境の両方にワークロードを拡張することを意味します。ハイブリッドおよびマルチクラウド環境におけるオブザーバビリティは、ツールの多様性、レイテンシー、異種ワークロードにより、大きな複雑さを伴う可能性があります。それにもかかわらず、これは開発者とビジネスユーザーの両方にとって共通の目標であり続けています。この目標に対応する豊富な製品とサービスのエコシステムが存在します。
しかし、クラウドネイティブなワークロードに対するオブザーバビリティツールの有用性は大きく異なる場合があります。コンテナ化さ れたバッチ処理ワークロードと、サーバーレスフレームワークを使用するリアルタイムバンキングアプリケーションのモニタリング要件の違いを考えてみてください。両者にはログ、メトリクス、トレースがありますが、それらを観察するためのツールチェーンは異なり、クラウドネイティブ、オープンソース、ISV 製品など、多数の選択肢があります。Prometheus のようなオープンソースツールが一方に適している場合もあれば、マネージドサービスとして提供されるクラウドネイティブツールが要件をより適切に満たす場合もあります。
これにマルチクラウドとハイブリッドの複雑さが加わると、アプリケーションからの洞察を得ることはさらに困難になります。
これらの追加された次元に対処し、オブザーバビリティへのアプローチを容易にするために、顧客は統一されたインターフェースを持つ単一のツールチェーンに投資する傾向があります。結局のところ、シグナル対ノイズ比を減らすことは通常良いことです!しかし、単一のアプローチがすべてのユースケースに適用されるわけではなく、さまざまなプラットフォームの運用モデルが混乱を招く可能性があります。私たちの目標は、お客様のニーズを補完し、問題が発生した際の平均修復時間を短縮するための情報に基づいた決定を支援することです。以下は、あらゆる規模の顧客と、すべての業界での作業を通じて学んだベストプラクティスです。
これらのベストプラクティスは、エンタープライズアーキテクト、開発者、DevOps など、幅広い役割を対象としています。組織のビジネスニーズと、分散環境におけるオブザーバビリティがどのように最大限の価値を提供できるかという観点から、これらを評価することをお勧めします。
ツールに決定を左右されないようにする
アプリケーション、ツール、プロセスは、売上や顧客満足度の向上などのビジネス成果を達成するために存在します。適切なテクノロジー戦略とは、これらのビジネス目標の達成を可能な限り支援するものです。しかし、目標達成に役立つものは単なるツールであり、戦略を支援するためのものであって、戦略そのものではありません。例えを挙げると、家を建てる必要がある場合、ツールに設計や建築方法を尋ねることはしません。むしろ、ツールは目的を達成するための手段です。
単一の同質な環境では、ツールに関する決定は比 較的容易です。結局のところ、1 つの環境で単一のアプリケーションを実行する場合、ツールは全体で簡単に同じものを使用できます。しかし、ハイブリッドおよびマルチクラウド環境では状況はより複雑であり、ビジネス成果に注目し続けること、そしてこれらの環境全体でワークロードを観察することによって付加される価値に注目することが重要です。各クラウドサービスプロバイダー(CSP)には独自のネイティブなオブザーバビリティソリューションがあり、利用可能な豊富なパートナーや独立系ソフトウェアベンダー(ISV)のセットもあります。
複数の環境で運用しているからといって、すべてのワークロードに単一のツールを使用することが推奨されるわけではありません。これは、ワークロードを観察するために複数のサービス、フレームワーク、またはプロバイダーを使用する可能性があることを意味します。運用モデルがニーズを反映する必要がある方法の詳細については、以下の「単一の画面よりもワークロードのコンテキストの方が重要」を参照してください。いずれにせよ、ツールを実装する際は、将来オブザーバビリティソリューションを進化させることができるように「双方向のドア」を作成することを忘れないでください。
以下は、避けるべき「ツール優先」の結果の例です:
-
アップグレードや将来の新しいソリューションへの移行のための双方向のドアなしに単一のツールの実装に焦点を当てると、回避可能な技術的負債を生み出す可能性があります。これは、ツールがソリューションであり、いつの日か解決すべき問題になる可能性がある場合に起こります。
-
ボリュームディスカウントのために単一のツールを使用する会社標準は、恩恵を受けられる機能がない状態になる可能性があります。これは「品質よりもコスト」となり、意図せずにモノリシックなアンチパターンを生み出す可能性があります。これにより、ボリューム閾値以下に留まるためにテレメトリの収集が抑制され、結果としてオブザーバビリティツールの使用が阻害される可能性があります。
-
既存のトレース収集インフラストラクチャがないが、豊富なログとメトリクスコレクターがある場合に、特定のタイプのテレメトリ(通常はトレース)を全く収集しないことは、不完全なオブザーバビリティソリューションにつながる可能性があります。
-
労働力と訓練コストを削減したいという願望から、サポートスタッフが単一のツールチェーンのみのトレーニングを受けることで、他のオブザーバビリティパターンの潜在的な価値が減少する可能性があります。