ハイブリッドおよびマルチクラウド環境におけるクラウド監視の課題トップ6

ハイブリッドクラウドとマルチクラウドは、一部のワークロードをパブリッククラウドで実行し、一部をオンプレミスで維持し、それらをすべて接続する、というシンプルなように聞こえます。しかし実際には、チームやシステム間の依存関係、コンテキストを共有しないツール、そして一元化できないインシデントを管理する必要があります。

多くの資産では、オンプレミスと1つ以上のクラウドにまたがるVM、コンテナ、マネージドサービス、SaaS依存関係が混在しています。それぞれの障害は異なる方法で発生し、所有者も異なる場合が多くあります。

古いシステムと新しいクラウドおよびSaaSサービスでは、ルールやチームが異なるため、アクセス、保持、所有権の確保が難しくなります。そして、インシデントも珍しくありません。 アップタイム研究所の年間停止分析 停止の傾向を追跡し、チームが可視性を失ったときに実際のコストと混乱を伴う障害が依然として発生することを示します。

監視が追いつかないと、重大なインシデント、定期的なリリース、誰もが納得できる判断を下せるほどデータを信頼していない計画会話などで時間が失われます。

クラウド監視における6つの課題は、どこにでも存在します。もしこれらのうちいくつかに遭遇したことがあるなら、あなたはすでに多くの課題を抱えていると言えるでしょう。

1) 分散した監視データ

ハイブリッドクラウドやマルチクラウド環境では、規模が拡大するにつれて監視ツールが集約されます。多くのチームは、複数の可視性プラットフォームに可視性を分散させてしまうため、現状を把握し、共有ビューを維持することが困難になります。

まず、AWS、Azure、Google Cloud、Oracle Cloud Infrastructureといった大手クラウドプロバイダーがあり、それらにはAmazon CloudWatch、Azure Monitor、Google Cloud Monitoring、Oracle Cloud Infrastructure Monitoringといったネイティブ監視ツールが付属しています。PrometheusはKubernetesクラスタ上で動作します。アプリケーションチームはAPMツールを活用していますが、ネットワークチームは依然として独自のシステムを維持しています。それぞれのツールは、導入時にその重要性を実感しました。

また、権限と保持を管理する場所が増えることも意味します。監視対象がプロバイダー、Kubernetes、SaaS、オンプレミスにまたがり、複数のチームがそれぞれ異なる部分を所有している場合、管理はすぐに複雑になります。問題は何かが故障したときに表面化し、それらがどのように関連しているかを把握する必要が生じます。

混合環境でオンコール対応を経験したことがあるなら、こんな状況に遭遇したことがあるでしょう。アプリケーションログには10:14からエラーが発生しているのに、データベースチームのダッシュボードには10:11に急上昇が見られます。ネットワークグラフでも10:09に急上昇が見られます。3つの異なるコンソールを切り替えながらタイムスタンプを並べ、どの急上昇がどの症状を引き起こしたのかを突き止め、10:00に実行されたデプロイメントに関連するものがあるかどうかを判断しようとしています。

誰かが自分の画面のスクリーンショットを撮ってSlackに貼り付ける。別の誰かが「それは私が見ているものと違う」と言う。インシデント発生から20分経っても、修正をテストするどころか、タイムラインの作成に追われている。なぜなら、すべてのインシデントは同じ調整作業から始まるからだ。タイムスタンプの一致、用語の翻訳、そしてそもそも繋がるように設計されていない断片的な情報から物語をつなぎ合わせる作業だ。そして、あるシステムがデータを7日間保存しているのに、別のシステムが30日間保存していると、正しいタイムラインを見つけた後でも、話の筋道を見失ってしまう可能性がある。

時間の浪費は予測可能です。つまり、障害の調査ではなく、インシデントの最初の部分をデータの相関分析に費やします。

分散環境で監視がうまく機能すれば、こうした負担はほぼ解消されます。5つのタブを開くことなく、何が関連しているかを確認できます。タイムラインは、あなたが現場に到着した時点で既に構築されています。アプリケーションエラー、データベースのレイテンシ、ネットワークの輻輳などがすべて同じビューに同じ時刻で表示されるため、相関分析ではなく調査に時間を費やすことができます。ここでも多少の自動化は役立ちますが、真のメリットはコンテキストの共有です。

2) サービスコンテキストのないコンポーネント監視

顧客対応サービスは、ほとんどの場合、単一の機能で完結するものではありません。ログインやチェックアウトのフローを例に挙げてみましょう。IDプロバイダー（多くの場合、別のクラウドやSaaS）を呼び出し、データベースにアクセスし、キューに書き込み、サーバーレス関数をトリガーし、サードパーティAPIを利用するといった処理が行われます。これらの処理のうち、どれか1つが静かに劣化している一方で、残りの部分はリアルタイムダッシュボードでは正常に動作しているように見える可能性があります。

しかし、ほとんどの監視はインフラストラクチャ層（サーバー、コンテナ、データベース、ネットワーク）ごとに体系化されており、顧客が利用しようとしているサービスごとに体系化されていません。インシデント発生時に唯一重要な質問、つまり「どの顧客向けサービスが影響を受け、どの程度深刻な影響を受けているのか」に答えようとすると、このギャップが最も顕著になります。

アラートが発動し始めると、3つのノードでCPU使用率が高く、データベースのクエリ時間が増加し、APIゲートウェイのエラー率が上昇しているといったリストが表示されます。これらはすべて実際のシグナルですが、ユーザーが実際にログインしたり購入を完了したりできるかどうかは、どれもわかりません。

すると、インシデントチャネルは優先順位付けの議論に変わります。CPU使用率の急上昇がデータベースの速度低下を引き起こしているのか、それとも遅いクエリがCPUを圧迫しているのか？ノードをスケールさせるのか、それともクエリを調整するのか？サードパーティAPIを確認することを提案する人もいますが、それが監視されているかどうかは誰も確信していません。たとえ監視されていたとしても、どこか別の場所にあるはずです。ここでも、シンプルな外部からのチェックが役立ちます。基本的なログインやチェックアウトのパスが失敗しているなら、10番目のインフラストラクチャアラートを読む前に気付くでしょう。

顧客への影響を確認する頃には、顧客もすでにそれを確認してしまっているはずです。

混乱は根深いものです。コンポーネントアラートは症状を説明していますが、何がリスクにさらされているかを確実に伝えるものではありません。サービス対応型モニタリングは、この流れを逆転させます。まず、サービスの健全性（レイテンシ、エラー、そして対象とするターゲットに対する可用性）を示す少数のシグナルから始め、それらのシグナルをサービスが依存する依存関係に結び付けます。チェックアウトが遅くなれば、顧客への影響を即座に把握できるだけでなく、原因がID、データベースのレイテンシ、キューのバックログ、あるいはサードパーティ製APIのいずれにあるかを特定できます。

監視がサービス対応型になると、出発点が変わります。「チェックアウトのレイテンシが上昇している」ことや、どの依存関係が関係しているかを把握できるため、チームは優先順位を明確にし、根本原因への最短経路を確保できます。コンポーネント監視は依然として重要ですが、すべてのインシデントを調査作業から始めるのではなく、サービス視点をサポートします。

3) 警報音とトリアージの遅れ

環境間インシデントは複数のチームを迅速に巻き込みます。アプリケーションチームはエラーを確認し、プラットフォームチームはポッドの再起動を確認します。データベースチームは接続プールの枯渇に気づきます。ネットワークチームは断続的なパケットロスを捕捉します。ポケベルは数分間隔で鳴り響き、プロバイダー、クラスター、オンプレミスをまたいだ影響範囲はまだ明確ではありません。

Slackチャンネルには8人が参加しています。3人は同じ症状を、気づかずに異なる角度から調査しています。2人は、これが自分の問題かどうか誰かに確認してもらいたいと思っています。1人は昨日のデプロイと関係があるかどうかを尋ねています。アラートは次々と届き、何が既知の問題で何が単なるノイズなのかという認識が共有されていないため、会話は行き詰まってしまいます。複数の監視ツールが同じシグナルを収集したり、監視が行き過ぎて定型的な問題がバックグラウンドの雑音に変わってしまったりすると、状況はさらに悪化します。

こうした状況の多くは、アラートの到着方法に起因しています。つまり、独立した通知が単調な流れとして流れてくるのです。複数のシステムにまたがる数十ページにも及ぶアラートが、すべて一つの根本的な問題によって引き起こされ、グループ化も優先順位付けもされていないまま届くこともあります。インシデントの最初の段階は、手作業によるトリアージ、つまり仕分け、重複排除、そして誰が部屋に居るべきかの判断にかかっています。

だからこそ、「単純な」障害でさえも遅く感じることがあります。何かを修正する前に、状況を整理する必要があります。

この遅延は、あらゆる面で問題を引き起こします。サービス復旧までの時間延長、顧客への影響拡大、そしてチームが原因究明ではなくノイズの整理に時間を費やしたためにSLAを遵守できない可能性の高まりなど、あらゆる面で影響を及ぼします。また、遅延はスタッフの疲弊にもつながります。ポケベルが鳴り続け、アラートの半分が重要でない場合、エンジニアはたとえ次のポケベルが本物であっても、その信号を信頼しなくなります。

問題は、それらを取り巻く構造の欠如です。アラートがコンポーネントのしきい値だけでなく顧客への影響も反映されていれば、チームの生産性も向上します。そのため、一見恐ろしい問題で8人もの担当者を呼び出してしまうような事態は避けられます。アラートが適切に機能すると、大量の通知ではなく、インシデントフィードのような動作をします。関連する症状は1つのインシデントにまとめられます。新しいシグナルは、新たなノイズを生み出すのではなく、同じスレッドを更新します。チームは、何が壊れているのか、何が影響を受けているのか、そして何が既にチェック済みなのかを把握できます。責任の所在も明確になります。アラートは、最も大きな問題を引き起こしているインフラストラクチャだけでなく、劣化したサービスに基づいてルーティングされます。まさにこの点で自動化がすぐに効果を発揮します。

4) コストの急上昇と弱いフィードバックループ

クラウドコストは運用上のシグナルです。従量課金制の世界では（オンプレミスのキャパシティ制約がある場合でも）、小さなミスがあっという間に積み重なります。スケーリングポリシーは更新されたまま、ロールバックされることがありません。ログ記録量は一夜にして倍増します。テスト環境は、誰もシャットダウンしないため稼働し続けます。ワークロードが非効率的に動作し始め、ひっそりとコンピューティングリソースを消費します。コストの急上昇は、監視自体、つまり大量のログ、重複したエージェント、あるいはプロバイダーや環境間で時間の経過とともにひっそりと増加していくデータ収集に起因する場合もあります。

問題は、コストとパフォーマンスがしばしば異なる領域に存在していることです。エンジニアリング部門はダッシュボードとアラートを監視し、財務部門は請求を監視します。この2つが連携されていないと、フィードバックループが機能しなくなります。

よくあるパターンはこうです。数週間後に、重大なコスト増加が明らかになります。課金コンソールに、あるリージョンでのコンピューティング費用の急増が表示されます。誰かが、その原因を探るため、デプロイメント履歴と構成変更を徹底的に調べ始めます。変更を行ったエンジニアを追跡するのは困難で、変更の理由はチケットの中に埋もれており、システムは長期間にわたって過大な規模で稼働しているため、既に費用は回収されています。特に、急増の原因がエグレス、インターコネクト、またはリージョン間トラフィックである場合、つまり、コストが急増を引き起こしたサービスから遠く離れた場所で発生する場合はなおさらです。

もう一つのパターンは「万が一に備えた」キャパシティです。削減しても安全だと誰も証明できないため、チームはより大きなインスタンスと余裕を持った余裕を保持します。古い環境は、もはや誰もそれらに依存していないという証拠がなければ、廃止するのはリスクが高いと感じられるため、そのまま残されます。時間が経つにつれて、コストは不確実性のデフォルトの結果になります。

コスト管理は、運用と同じサイクルで実行することでより効果的に機能します。支出は変化が起きた直後に可視化され、その変化を具体的な事象（デプ​​ロイメント、スケーリングイベント、ログの調整、シャットダウンされなかった環境など）に簡単に結び付けられる必要があります。環境別の予算管理、支出パターンが崩れた場合のアラート、そして適切なチームが迅速に対応できるよう、コストをサービスまたはオーナーにマッピングするタグ付けなど、いくつかのシンプルなガードレールが大きな違いを生み出します。

トレンドを把握することで、チームは次の予期せぬ事態に先手を打つことができます。支出の傾向、そして現状維持の場合の見通しを大まかに把握するだけで、予算編成の対応が後手に回りにくくなり、月末の慌ただしさを軽減できます。

適正化とは、支払うべきリソースとワークロードの実際のニーズを一致させることを意味します。実際には、これは定期的なループです。常に使用率の低いリソースを特定し、アイドル状態または孤立した環境にフラグを立て、ロールバックプランを使用して安全な変更（ダウンサイズ、非本番環境のスケジュール調整、または完全に使用されていないもののシャットダウン）を実施します。これは監視と連携することで最も効果的です。使用率とサービスの健全性から、削減しても安全なものと変更するとリスクの高いものを判断できるからです。適切に実施すれば、信頼性を犠牲にすることなくコストを最適化できるだけでなく、「万が一」のためのキャパシティをあらゆる場所に持ち運ぶ必要がなくなるため、スケーラビリティも向上します。

コストの可視性を、利用率やサービスの健全性と並べて表示することで、異常の発生をより早期に検知し、具体的な変更と関連付けることができます。適正化を検討する際には、直感に頼るのではなく、実際のサービス動作と比較して影響を検証できます。これにより、コスト管理は定期的なクリーンアッププロジェクトから、運用の通常の一部へと変化します。

5) インターネットスタックの盲点

ビジネスが直面する最も深刻なインシデントの中には、クラウド環境やオンプレミス環境の外部で発生するものがあります。DNS、CDNの動作、ISPルーティング、SASEポリシー、プライベートリンク、サードパーティAPIの突然のタイムアウトなど、ユーザーとサービス間のルートのどこかで発生します。

インシデント発生中、内部指標は一見クリーンに見えるかもしれません。データベースの応答時間は正常で、CPUとメモリは安定しており、プライマリリージョンのエラー率は急上昇していません。一方、英国のユーザーから読み込み速度の低下が報告されており、米国では再現できません。
そこでチームは、チームとしてやるべきことを始めます。つまり、まずは可能性を洗い出します。ロードバランサーは正常です。アプリ層は問題なさそうです。データベースには明らかな負荷は見られません。その後、議論は「DNSかもしれない」「CDNかもしれない」といった方向に進みます。なぜなら、これらのレイヤーを直接可視化できないからです。現実世界では、パブリックDNSリゾルバーの障害は、スタック全体が正常であっても、サービスがダウンしているように見えることがあります。 Cloudflareの1.1.1.1インシデント、誤った構成によりグローバル ルートの撤回がトリガーされ、その影響は突然の到達不能という形で現れました。これは、「お客様の」サービスの内部ダッシュボードだけでは必ずしも説明できません。

サービスが少数のサードパーティエンドポイントに依存している場合は、インシデントが発生する前に基本的なヘルスチェックとエスカレーションパスを用意しておくことが重要です。

数時間後、プロバイダーから「異常は見られない」という返答が来るかもしれません。場合によっては、問題が自然に解決し、何が起こったのか誰も証明できないため、事後検証は漠然とした「外部」というラベルで終わります。顧客が注文できず、原因が全く分からない場合と、たとえ答えが組織の外にあったとしても、どこで障害が発生したのかが分かる場合の違いです。 

インターネット スタックの可視性が少しでもあれば、プロバイダーや顧客と共有できる具体的な情報が得られ、やり取りが短縮され、インシデントの停滞を防ぐことができます。

自社環境外、つまりインターネットスタック全体にわたるユーザーエクスペリエンスを測定できれば、どこでパフォーマンス低下が発生し、誰に影響が及んでいるかを把握できます。ロンドンではレイテンシが上昇しているのにフランクフルトでは正常であることや、特定のISP周辺で障害が集中していることなどが分かります。また、重要なサードパーティエンドポイントを監視し、チェックアウトの失敗やサポートチケット発行につながる前にパフォーマンス低下を検知することも可能です。たとえ修正が自社で対応できない場合でも、調査範囲をより迅速に絞り込み、プロバイダーや社内チーム全体への影響を自信を持って伝えることができます。

6) 構成のドリフトと監視の劣化

分散環境は、長く同じ形を維持することはありません。アカウント、サブスクリプション、プロジェクトが追加され、クラスターがロールオーバーされ、サービスがリファクタリングされ、チームの再編に伴い所有権が移行します。監視機能も同じペースで進化しなければ、実際に実行されているものを反映しなくなります。ハイブリッドクラウドやマルチクラウド環境では、レガシーシステムが必ずしも最新の検出規則や命名規則に適合せず、元のチームが異動すると所有権が曖昧になる可能性があるため、これはさらに困難です。

この不一致は、インシデント発生時に表面化する傾向があります。チームが「いつも使っている」ダッシュボードを開いてみると、それが古くなっていることに気づきます。新しい依存関係が欠落していたり​​、廃止されるはずだったシステムがまだ表示されていたり、シグナルとノイズを区別するのにほとんど役に立たなかったりするのです。

ドリフトはバックグラウンドにも現れます。基盤システムがなくなっても、古いアラートが鳴り続けます。新しいサービスは、何を設定する必要があるのか​​、誰が設定を担当するのか、誰も把握していなかったため、ベースラインがないまま稼働します。数週間後、何かが故障しても、チームには比較対象となる履歴も、正常な動作を反映するしきい値もありません。ここでも保持が重要です。変更前の「正常」状態を確認できるだけの十分な履歴を保持しておかないと、ロールバックの判断時に最も役立つツールの一つを失うことになります。

監視の精度を維持するには、継続的な注意が必要です。手作業が増えるほど、特にリリースが頻繁に行われ、クラウドインフラストラクチャが絶えず入れ替わる環境では、監視の精度が低下しやすくなります。

検出とオンボーディングがワークフローに組み込まれていると、監視はより安定します。新しいリソースは自動的に検出され、適切なデフォルト設定でオンラインになります。トラフィックパターンの変化に合わせてベースラインが調整されます。廃止されたシステムはダッシュボードとアラートから削除され、時間の無駄を省きます。「監視」の意味を明確に規定することで、システムのリリースごとにプロセスを見直す必要がなくなり、大きな効果が得られます。自動化は、環境の拡大に伴うワークフローの崩壊を防ぐ上で重要な役割を果たします。

包み込む

ハイブリッドクラウドおよびマルチクラウド環境は、新しいアカウント、新しいクラスター、新しい依存関係、新しいオーナーなど、急速に変化します。監視は、こうした変化に対応し、何か問題が発生した際にチームに共通のコンテキストを提供することで、その機能を維持します。これには、サービスレイヤー、環境外の依存関係、そして運用の基本（所有権、保持、ガードレール）が含まれ、これらは長期にわたって監視の信頼性を維持します。

そうなれば、タイムラインを一から作り直す必要がないため、インシデントへの対応が迅速化されます。影響を早期に把握できるため、リリースのリスクは軽減されます。データの一貫性が信頼できるレベルに達するため、コスト、パフォーマンス、信頼性に関する意思決定が容易になります。

良いテストとは、最後の大きなインシデントです。最初の 30 分がデータの調整と範囲の議論に費やされていた場合、それが次に何を修正すべきかを示す最も明確なシグナルとなります。

よくあるご質問

ソフィア・バートン

シニアコンテンツマーケティングマネージャー

ソフィアは、複雑なテクノロジーとリアルな人間が交差する領域におけるコンテンツ戦略と制作をリードしています。オブザーバビリティ、AI、デジタルオペレーション、インテリジェントインフラストラクチャの分野で10年以上の経験を持つ彼女は、難解なテーマを、明確で有用、そして実際に読んで楽しいコンテンツへと昇華させることに情熱を注いでいます。彼女は健全な懐疑心と、何が真実で何が有用で何が単なるノイズなのかを見抜く鋭い目を持つ、AIのハイプウーマンとして誇り高く知られています。

免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。