Azure監視シリーズの第2弾です。今回は、Azureのスケールアウト時に何が問題になるのか、そして従来の監視では対応できない理由について考察します。アラートストームからデータコストの急増まで、何に注意すべきか、可視性が損なわれるのはどこか、そしてサービスアウェアな可観測性によってチームが混乱を先取りする方法をご紹介します。 全シリーズを読む.
多くのチームは、Azure導入を少数の仮想マシンと基本的なダッシュボードから始めます。しかし、クラウドの複雑さは直線的に増大するのではなく、複合的に増大します。突如、複数のリージョン、クラウド、ツールにまたがる数百もの相互接続されたサービスを管理する必要に迫られるのです。そして、かつてはシンプルだった監視設定が、プレッシャーに耐えきれなくなり始めます。
もう指標だけを追いかけるのではなく、1つのコンポーネントの障害がどのようにサービス全体に波及し、ユーザーに影響を与え、コストを押し上げるかを理解しようとしています。問題はデータの不足ではなく、コンテキストの不足です。
従来のツールは、このようなレベルの複雑さに対応できるようには設計されていません。一時的なワークロードを追跡できず、サービス間の依存関係も把握できません。また、どのインシデントが収益に最も大きな影響を与えるかを正確に把握することもできません。
ここで、最新の可観測性が役立ちます。
もはやサーバーを監視するだけではありません。サービスを監視すること、そしてメトリクス、イベント、ログ、トレースを、稼働時間、パフォーマンス、コスト効率といった重要な成果に結び付けることが重要です。
TL; DR
MicrosoftのAzure Monitorは、戦略を変えない限り大規模に機能しなくなる
-
サービスの無秩序な拡大は可視性を損ないます。追跡できないものはトラブルシューティングできません。個々のコンポーネントの監視をやめ、それらが稼働するサービス全体の監視を始めましょう。
-
アラートの数が増えても、アラートの質は向上しません。複数の地域にまたがるノイズは、実際のインシデントをかき消してしまう可能性があります。コンテキストアウェアなアラートが、混乱を切り抜けます。
-
一時的なワークロードは、捕捉する前に消えてしまいます。クラウドネイティブの監視機能は、コンテナが消えた後も追跡を続けます。
-
データ量＝コスト爆発。必要なのはすべてのデータではなく、必要なデータだけです。スマートな集約により、Coinbaseのような65万ドルのサプライズを回避できます。
-
クラウドのコストはコンピューティングだけではありません。監視ツールはすぐに費用がかさみます。コストとパフォーマンスの相関関係がわからないと、何も見えなくなってしまいます。
-
解決策：事後対応型の監視はやめましょう。クラウドとビジネスに合わせて拡張できるサービスベースの可観測性に移行しましょう。
1. Azure サービスは監視が追いつかないほど急速に増加しています
Azureには200を超えるサービスがあり、それぞれが複雑さを増しています。すべてが相互に接続されています。単一のアプリケーションリクエストがXNUMXもの異なるサービスにアクセスする可能性があり、監視システムがそれらのパスを自動的に統合できなければ、状況を把握できていないことになります。
さらに厄介なことに、 89%の組織が現在マルチクラウド環境で運用されているつまり、Azure だけを監視しているのではなく、SaaS プラットフォーム、API、オンプレミスのシステムといった複雑なシステム群を網羅しているということです。新たな統合を行うたびに、潜在的な障害ポイントが生まれます。そして、あらゆる障害はユーザーエクスペリエンス、SLA、そして収益にリスクをもたらします。
典型的な電子商取引の取引を見てみましょう。
フロントドア → App Service → Service Bus → Functions → SQL Database → ストレージ → API 管理 → CDN
つまり、複数の地域やベンダーにまたがる8つの異なるサービスがすべて同期して動作しているということです。これらのリンクの1つでも見落とせば、本来はすぐに解決できるはずのものが、何時間もかかる原因究明になってしまいます。
監視が機能しない箇所：環境間の可視性
問題はデータ不足ではなく、コンテキスト不足です。Azureネイティブツールは個々のコンポーネントをサイロ化した状態で可視化しますが、サービスが複数のサブスクリプションやハイブリッド環境にまたがっている場合、そのコンテキストを統合するにはダッシュボード間を移動したり、カスタムクエリを作成したり、あるいは既存の知識に頼ったりすることになります。
障害が発生すると、クラウドとオンプレミス、アプリとAPI、データ層とサービスバスといった境界面で障害が発生することがよくあります。Azure SQLがボトルネックになっているにもかかわらず、APIのレイテンシしか目に見えない場合、ユーザーからの苦情や収益への打撃が発生するまで、接続が復旧しない可能性があります。
サービス間の明確なコンテキストがなければ、運用チームは効果的に優先順位を付けることができません。どのインシデントがインフラ上の単発的な障害で、どのインシデントが重要なビジネスサービスを脅かすのかを把握できず、推測に頼る、問題解決に追われる、そしてSLAの未達につながります。
修正方法: 完全なサービス認識型の可視性が重要な理由
最新のオブザーバビリティは、テクノロジースタック全体のメトリクス、イベント、ログ、トレースを自動的に関連付け、障害の背後にある全体像を明らかにします。しかし、重要なのは、コンポーネントだけでなく、サービスという観点から考えることです。
現実世界では、単一のVMが過負荷状態にあるかどうかは誰も気にしません。むしろ、それがログインサービスの一部であり、顧客がアカウントにアクセスできない状態にあるかどうかの方が問題です。
監視がサービスに関連付けられている場合:
- どのアラートが優先度の高いビジネス機能に影響するかを即座に確認できます
- サービスパスのすべてのホップにわたって失敗したリクエストを追跡できます
- 症状を追いかけるのをやめて、重要なことを解決し始めましょう
例えば、ユーザーに表示される500エラーは、バックエンドAPIのタイムアウト、キューの過負荷、チェックアウトボリュームの急増などによって引き起こされる可能性があります。完全なサービスレベルの可観測性があれば、そのチェーン全体を可視化し、対処することが可能になります。
これが、私たちがサービスを監視する理由です。お客様のビジネスはサービスによって運営されているからです。LogicMonitorでは、サービスコンテキストは後付けではなく、最初から組み込まれています。
2. 複数地域への展開 = 頭痛の種がXNUMX倍
複数のAzureリージョンを立ち上げることで高可用性が実現されるはずですが、実際には、適切な方法で監視しない限り、テレメトリのノイズが2倍に増加します。
マルチリージョン環境では以下が導入されます。
- 地域によって変動するレイテンシのばらつき
- フェイルオーバーの動作を混乱させるレプリケーション遅延
- 何が本当に壊れているのかを教えてくれない重複したアラート
従来のリージョンベースの監視では、ここで問題が生じます。米国東部と米国西部を別々の環境として監視しているにもかかわらず、ユーザーはリージョンごとにアプリを体験しているわけではありません。ユーザーはサービスそのものを体験しているのです。アラートがそのサービスに紐付けられていない場合、それは「幽霊」を追っているようなものです。
プロヒント： Azure Monitorはリージョン固有のアラートをサポートしていますが、インテリジェントなコンテキスト情報が欠けています。LM Envisionを使えば、サービスがどこで実行されているかに関係なく、包括的に監視できます。リージョン間でアラートを相関させ、動的なしきい値を適用することで、ノイズに埋もれることなく、実際のインシデントを可視化します。
監視が機能不全に陥る場所：アラート疲労と信号過負荷
地域が増えると、アラートも増え、誤検知も増えます。チームはノイズを気にしなくなり、真の問題を見逃してしまいます。静的な閾値では、地域間で変化するベースラインに対応できません。また、地域間の相関関係がなければ、問題が個別のものかシステム全体のものかが不明瞭になります。
修正方法: 地域ではなくサービスを考える
この移行はシンプルですが、強力です。インフラの地域ごとの監視をやめ、重要なサービスだけを監視するようにしましょう。そうすれば、グローバルなチェックアウトフローに問題が発生した場合でも、西ヨーロッパのレイテンシだけでなく、エンドツーエンドのパスを把握できるようになります。
ちなみに、LM Envision の動的アラートとトポロジーを考慮した相関関係により、27 つのリージョンと XNUMX つのツールからの XNUMX 件の切断されたアラートではなく、XNUMX つの意味のあるインシデントが提供されます。
3. 自動スケーリングと一時的なリソースが従来の監視を破る
クラウドでは、すべてが一時的なものです。VM、コンテナ、サーバーレス関数など、すべてが消え去ります。そして、監視が固定されたインフラストラクチャや手動のインストルメンテーションに依存している場合、それらのワークロードは跡形もなく消えてしまいます。
例えば、Azure Monitor がイベントをログに記録する前に、関数がトリガーされ、失敗して消えてしまうことがあります。これは実際の問題であり、目に見えないものです。
監視が機能しない箇所：移行後の可視性ギャップ
オンプレミスからクラウドに移行するチームは、既存の監視ツールが対応できると想定しがちです。しかし、従来のプラットフォームの多くは、短期的なワークロードではなく、静的サーバー向けに構築されています。そのため、可視性にギャップが生じ、適切なサイジングの取り組みが不十分になり、事後対応的なトラブルシューティングが必要になります。
修正方法: インフラストラクチャだけでなくサービスも監視する
重要なのは、すべてのコンテナや関数を追跡することではありません。それらのコンポーネントがサポートするサービスを追跡することです。LM Envision はこれを自動的に実行し、一時的なリソースが起動したり停止したりしてもサービスレベルの継続性を維持します。
ワークロード間でテレメトリを相関させ、サービスの履歴パフォーマンス ベースラインを保持し、トリガーしたコンテナーが存在しなくなった場合でも、発生した事象のトレースを保持します。
サービスという観点から考えると、ノードがダウンしたりポッドが消滅したりしても問題ありません。サービスがどのように動作し、どこで障害が発生したかという全体像を把握できます。
10,000つのAKSクラスターで50以上のメトリクスを生成できます。クラウドへの移行後、ログの量は2日あたりXNUMXGBからXNUMXTBに急増します。すると突然、ダッシュボードの速度低下やクエリのタイムアウトが発生し、監視ツールがボトルネックになります。
データが増えても、必ずしも洞察力が高まるわけではありません。規模が大きくなると、すべてのデータを保持するにはコストがかかりすぎ、膨大なテレメトリをクエリすることで根本原因分析（RCA）の速度が著しく低下します。
Azure Monitor のデフォルトの保存期間は 30 ～ 60 日ですが、大容量データの場合はこれを延長するでしょうか？すぐにコストがかさみます。そして、その価値はほとんどないでしょう。ほとんどのチームにとって、今朝発生したサービスの問題を解決するために 90 日前の生のログが必要なわけではありません。
検討 Coinbaseの悪名高いDatadogからの65万ドルの監視請求この法案の大きな原因は、膨大な量の観測データをフィルタリングせずに取り込み、保持していたことです。これは、賢明なデータ戦略がなければ、監視コストがインフラストラクチャよりも急速に上昇する可能性があることを改めて示しています。
修正：スマートに集約し、重要なものを保持する
必要ない よ データが必要です より意味のある LM Envisionは、インテリジェントな集約機能により、関連性の高い情報（特にサービスに影響を与えるインシデントに関する情報）を保持しながら、ノイズをフィルタリングします。これにより、迅速なトラブルシューティングとコスト削減が可能になります。
5. クラウドコストがブラックホールになる
あらゆるAPI呼び出し、あらゆるログデータ、あらゆる過剰プロビジョニングされたコンピューティングリソースの1分1分、これらすべてが積み重なって、あっという間に大きなコストとなります。しかし、ここで問題なのは、クラウドリソースのコストだけではありません。それらのリソースを監視するコストもかかるということです。
監視が機能しない箇所: 所有権の断片化とパフォーマンスコンテキストの欠如
ほとんどのツールは、支出を個別に監視しています。利用率の低いVMやアイドル状態のサービスにはフラグを立てますが、なぜそのようにプロビジョニングされているのかは考慮しません。もし、その利用率の低いVMが、厳格なレイテンシSLAが設定されたミッションクリティカルな決済システムの一部だったとしたらどうでしょうか？
コレクターベースのアプローチはAPI呼び出しを大幅に削減し、コストを増やすことなくより詳細な可視性を実現します。しかし、さらに重要なのは、コストとサービスパフォーマンスを相関させることができる可観測性プラットフォームを見つけることです。そうすることで、最適化によってサービス停止に陥る事態を防ぐことができます。
LM Envision のようなプラットフォームは、次の方法でコストの最適化を簡素化します。
Azure の大規模な監視を修正する方法
Azureはすぐに複雑になります。サービス、リージョン、データが増えれば増えるほど。しかし、可観測性戦略が重圧に耐え切れず、崩壊してしまう必要はありません。
制御する方法は次のとおりです。
- サイロではなくサービスごとに監視します。 インフラストラクチャ中心のダッシュボードからサービス指向の可視性に移行します。
- MELT全体でテレメトリを相関させる メトリック、イベント、ログ、トレースは、個別に動作するのではなく、連携して動作する必要があります。
- コストとパフォーマンスを一致させます。 信頼性を損なうことなく、スマートな最適化の決定を下します。
- 問題に先手を打つ。 動的アラート、異常検出、履歴コンテキストにより、ユーザーが気付く前に対処できます。
最新の可観測性は、稼働時間だけではありません。スピード、回復力、そして透明性を大規模に実現することです。LM Envision を活用すれば、Azure を実際の運用状況（サービスファースト、クラウドスマート、そしてスケーラブルな設計）に合わせて監視するための可視性とインテリジェンスが得られます。
このシリーズの次の記事： 実際に重要なAzureの重要なメトリック数千もの指標を徹底的に分析し、ビジネスに真に効果的な指標を厳選します。どの指標が実用的な洞察をもたらし、それらを活用することで、常に問題解決に追われるのではなく、問題を先取りする方法を学びます。
Azure を圧倒的なものから制御可能なものへと変えましょう。
無料体験 よくある質問
1. 大規模に実際に重要な Azure メトリックをどのように確認すればよいですか?
関連する指標に焦点を当てる サービスパフォーマンス最も重要なサービスパスにおけるエラー率、レイテンシ、スループットなど、インフラストラクチャの指標にこだわる必要はありません。ユーザーエクスペリエンスに直接影響しない限り、インフラストラクチャの指標にこだわる必要はありません。
2. 可視性を損なうことなく Azure 監視コストを削減できますか?
はい。まずは大量のテレメトリ（ログやトレースなど）を集約し、実際のデータに紐づくものだけを残します。 サービスに影響を与えるインシデントLM Envision のようなプラットフォームは、重要な信号を保持しながらノイズをフィルタリングするのに役立ちます。
3. マルチリージョン展開を監視する最適な方法は何ですか?
地域を個別に追跡するのではなく、ユーザーに提供する機能に基づいてリソースをグループ化したビジネスサービスごとに監視します。これにより誤検知が減り、 Azureの監視 はるかに実用的になります。
4. サービス認識型の可観測性と従来の監視の違いは何ですか?
従来の監視はコンポーネント（VM、ストレージなど）を監視しますが、 サービス認識型可観測性 これらのコンポーネントがどのように連携して、実際のユーザー向けサービスを提供するかを監視します。このアプローチにより、より詳細なコンテキスト情報、より迅速な根本原因分析、そしてよりスマートなアラート通知が可能になります。
5. Azure で有効期間の短いコンテナーと関数の可視性を維持するにはどうすればよいですか?
で クラウドネイティブ環境従来の監視では、起動とシャットダウンが速いコンテナやサーバーレス関数を見逃してしまうことがよくあります。 サービスレベルのトレース コンテキストも保持されるため、インスタンスがなくなった後でも障害を調査できます。
結果重視で細部にこだわる技術プロフェッショナル。製品管理、IT コンサルティング、ソフトウェア開発、フィールド イネーブルメント、戦略計画、ソリューション アーキテクチャの経験を持ち、20 年以上にわたって顧客中心のソリューションを提供しています。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2025 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
