階層型オブザーバビリティ：オブザーバビリティ機能を優先度に沿って成熟させる方法

意外に思われるかもしれませんが、オブザーバビリティとは段階的に実現していくものであり、すべてを一気に観測可能にするものではありません。つまり、プロアクティブな検出、迅速なトラブルシューティング、ビジネスの優先事項との整合といった成果を徐々に推進するための取り組みなのです。このブログシリーズの読者であれば、すでに以下を実践済みのことと思います。

• オブザーバビリティ戦略を一元化する。
• ツールを合理化および簡素化する。
• オブザーバビリティの運用を継続的に改善していくための評価方法を確立する。

ウィンストン・チャーチルの言葉どおり、「完璧主義は進歩の妨げ」となります。数多くのアプリケーションを管理しなくてはならない大企業にとって、オブザーバビリティ(略称：o11y)への投資は、優先順位を見極めて行う必要があります。アプリケーションオーナーであれば、自分のサービスが重要であると誰もが考えるでしょうが、ビジネスへの影響はアプリケーションごとに大きく異なります。そのような中で求められるアプローチが、体系的な階層型のオブザーバビリティです。一方、小規模または急成長中のスタートアップ企業であれば、まだオブザーバビリティを階層化する必要はないかもしれません。しかし、ビジネスの成長に合わせて、早い段階で階層型のアプローチを取り入れておけば、将来的な規模の拡大に備えることができます。

監視対象をむやみに広げてしまうと、アラートのノイズが増え、運用が非効率的になります。また、重要なアプリケーションの監視が不十分であれば、重大な見落としが生じることになるでしょう。では、どうすればよいのでしょうか。

階層型オブザーバビリティを実践することにより、ビジネスの優先事項に投資の照準を合わせ、重要なサービスを最大限に可視化すると同時に、リソースを最適化して最大の効果を実現できます。

階層型オブザーバビリティとは

階層型オブザーバビリティのアプローチでは、投資に優先順位を付け、複雑さを軽減し、最も重要な業務に注力することが可能になります。オブザーバビリティの戦略がビジネスの優先事項と整合することにより、組織はリソースを浪費することなく、アラートのノイズを減らし、運用効率を向上させることができます。

戦略を適切に実行することによって以下が可能になります。

• MTTRの短縮：重要なアプリケーションをより詳細に可視化して、短い時間で問題を解決します。
• コストの最適化：オブザーバビリティへの支出をビジネスへの影響度に応じて調整します。
• S/N (Signal-to-noise)比の向上：ノイズではなく重要度の高いアラートに優先的に対応できます。
• 拡張性と効率性：再利用可能な運用モデルを組織の成長に合わせて拡張できます。

オブザーバビリティの取り組みは、意図が明確で、拡張性があり、ビジネス目標と整合している必要があります。これを実現するには、まずアプリケーションを分類し、その重要度別にオブザーバビリティの期待値を設定して、ツールの合理化とオートメーションを進めます。

階層型のアプローチでオブザーバビリティ(略称：o11y)を推進していくメリットを理解するために、体系的なアプローチを持たずにo11yの取り組みを進めている多くの組織の現状を見てみましょう。

すべてを直ちに監視対象にすることで生じる課題

多くの組織は、すべてのシステムを完全に可視化すれば最良の結果につながると考え、「すべてを網羅するオブザーバビリティ」を目指してしまいがちです。しかし、このアプローチが大規模環境で実を結ぶことはめったにありません。オブザーバビリティを実現するには時間がかかる、というのが現実です。そして、時間は最も限られたリソースです。優先順位を付けずに始めると、以下のような運用上および財務上の課題にすぐに直面することになるでしょう。

• リソースが限られているため、すべてのシステムを対象にオブザーバビリティを運用したりサポートしたりできない。
• 規模の拡大に伴う課題：アラートが多すぎる、ノイズが多すぎる、コンテキストが少なすぎる。

すべてのアプリケーションが、同じ重要度を想定して設計または保守されているわけではありません。同様にサービスに関しても、重要度の低い階層のサービスであれば、24時間365日のオブザーバビリティは必要ないでしょう。以下のような場合が考えられます。

• 本番環境のデータベースでディスク領域不足のアラートが発生した場合、緊急の対応が求められます。
• 同様の問題がサンドボックス環境の開発サーバーで発生しても、直ちに対処する必要はないかもしれません。

優先度に関する体系的なアプローチがなければ、どのイベントも同じ緊急度で対応しなければならず、無駄な作業が発生したりアラート疲れにおちいったりします。

優先順位付けを怠ることで招く影響

優先順位を付けずにすべてを監視しようとすると、技術的負債が発生するだけでなく、ビジネスの成果にも影響が生じます。最も重要なサービスに優先的に取り組むことができなければ、以下のような問題に直面することになるでしょう。

• アラートの信頼性の低下
• 非効率なリソース使用
• ツールの分散
• エンジニアの燃え尽き症候群

明確な優先順位付けがないと、インシデントの解決が遅れ、MTTRが長期化し、カスタマーエクスペリエンスに悪影響を与える可能性があります。

優先順位がないことは、エンジニアの不満にもつながります。不満が募れば、チームは標準化されたオブザーバビリティスタック以外の代替ソリューションを求めるようになるため、シャドーITが増加するおそれがあります。このようにばらばらのツールを使うと、以下のような事態を招くことになります。

• 一貫性のある可視化ができない
• コストが上昇する
• 作業がチーム間で重複する

階層型オブザーバビリティによる監視と分析の両立

オブザーバビリティは、システムの問題を検出できる十分な監視のカバー範囲と、ミッションクリティカルなアプリケーションのトラブルシューティングに役立つ十分に深掘りした分析を両立させる必要があります。アジャイル開発と同様、まずは最も重要な領域に注力する必要があり、すべてのサービスをカバーするのはその後です。

私の経験から言えば、まずはすべてのサービスにオブザーバビリティの基盤となるレイヤーを適用する必要があります(以下の「階層型オブザーバビリティの導入例」の表を参照)。この基盤レイヤーにより、メトリクス、ログ、アラートの基本的なインストルメンテーションが実現します。

初期の段階では、より高度なオブザーバビリティ機能をTier 0とTier 1のアプリケーションに割り当てる必要があります(これについては次のセクションで説明します)。このアプローチにより、APM、RUM、分散トレーシング、プロファイリングなどによる詳細なインストルメンテーションが可能になり、きめ細かなテレメトリを取得して、最大のビジネス価値を提供できる体制が整います。

重要度の低い階層のサービスについては、オブザーバビリティの取り組みが前進し、ビジネスニーズが変化したり、障害によって課題が浮き彫りになったりする過程で、徐々に改善していくことをお勧めします。階層化は、分類作業を一度行ったら終わりではなく、組織にとっての継続的な戦略と考えるべきものです(以下の「階層別オブザーバビリティ機能：期待値および透明性」セクションを参照)。

階層化の一般的なアプローチ

大規模な企業や組織では、以下の基準でアプリケーションを分類するのが一般的です。

• ビジネスへの影響
• 業務における重要度
• リスクの許容度

この分類により、アプリケーションをどのように管理、保護、サポートするかについての方針が明確になり、リソースを効率的に割り当てることができます。

きわめて重要なアプリケーション(収益を生み出すサービス、顧客向けプラットフォーム、生命や安全に関わるシステムなど)では、レジリエンス、オブザーバビリティ、パフォーマンス管理により多くの投資が必要です。一方、優先度の低いアプリケーションでは、同じレベルの冗長性、24時間365日のサポート、詳細なオブザーバビリティなどは必要ないかもしれません。社内ツール、非本番環境、重要性の低いバックグラウンドサービスなどがこれに該当します。

ヒント：小規模な組織における階層化の考慮事項

提供するサービスの数が少ない小規模な組織(たとえば、アプリケーション数が3つ程度で、チーム規模も数人程度)であれば、厳密な階層化は必ずしも必要ありません。すべてのアプリケーションを対象に一律にオブザーバビリティを適用する方が現実的でしょう。

しかし、ビジネスの規模が拡大するにつれ、階層化を行って、注力する業務やオブザーバビリティへの投資とビジネスの優先事項を整合させていくことが不可欠になります。

アプリケーションの階層化がIT戦略に与える影響

こうしたアプリケーションの分類は多くの場合、IT戦略と意思決定を支える判断材料として活用され、以下のような重要な領域に影響を与えます。

• セキュリティポリシー
• アーキテクチャの標準化
• パフォーマンスおよびテスト戦略
• サービス管理要件

オブザーバビリティもこの例外ではありません。同様の分類ロジックを活用し、オブザーバビリティ戦略を推進したりニーズを満たしたりする必要があります。つまり、アプリケーションの重要度に応じた、オブザーバビリティのカバー範囲、アラート、トラブルシューティングのワークフローを整備します。

一般的な階層モデル

アプリケーションの分類には、以下の2種類のうちのいずれかを使用するのが一般的です。

• 数値による階層化：Tier 0〜3
• メタルクラス：プラチナ、ゴールド、シルバー、ブロンズ階層

ヒント：オブザーバビリティスタックの階層化

オブザーバビリティツールが効果を発揮するかどうかは、その可用性と信頼性にかかっています。オブザーバビリティプラットフォームがダウンしていたり信頼性が低かったりした場合、何も問題が発生していないと誤解するどころか、信頼できない大量のアラートでチームが忙殺されるという事態も生じかねません。

オブザーバビリティスタックの信頼性を確保するには、監視対象アプリケーションの各階層で求められる要件を満たすか、それを上回る必要があります。

階層型オブザーバビリティでの主な考慮事項

階層型オブザーバビリティの導入アプローチは、アプリケーションの分類だけで終わりではありません。ビジネスへの影響を踏まえて、オブザーバビリティのインストルメンテーション、アラート、対応の戦略を整備する必要があります。以下に、オブザーバビリティへの投資に効果的に優先順位を付け、有意義なインサイトを引き出すための重要な考慮事項について説明します。

アプリケーション環境全体のオブザーバビリティ

オブザーバビリティのカバー範囲は本番環境以外にも広げるべきですが、すべての非本番環境を完全にカバーする必要はありません。たとえば、きわめて重要なアプリケーションの本番移行前のセイフティーネットとして「ステージング」環境を用意すれば、本番リリース前にオブザーバビリティのカバー範囲を検証できます。

その際のベストプラクティスとして、本番環境でのアプリケーションの重要度のTierを1段階下げたものを非本番環境でのオブザーバビリティレベルにすることをお勧めします。たとえば、Tier 0のアプリケーションであれば、非本番環境での同一アプリケーションはTier 1に分類します。これにより、オブザーバビリティの盲点によって優先度の高いプロジェクトの開発の中断を防ぎながら、コストとアラートのノイズを抑制できます。

本番移行前の環境を効果的に監視することで、以下のことが実現します。

• オブザーバビリティの効果を検証：非本番環境で、しきい値、異常検出のベースライン、KPIをテストすることによって、アラートが期待どおりに機能することを確認し、デプロイ後の予期しない問題の発生を回避できます。
• デプロイ関連のダウンタイムを検出：本番リリース前にレイテンシーの急増、エラー率、リソースの制約などを監視します。
• オブザーバビリティのカバー範囲を検証：カオスエンジニアリングと負荷テストの一環として検証を行い、実際に負荷の高い状況でもアラートとダッシュボードに障害が正確に反映されているかどうかを確認します。
• 機能、パフォーマンス、使用状況の変化を本番環境移行前に事前に把握：プロアクティブな真のオブザーバビリティこそが究極の目標ではありますが、本番リリース直前に影響範囲の大きい変更を検出できるだけでも、十分にプロアクティブと言えるのではないでしょうか。

オブザーバビリティの責任者として最も恐れているのは、IT部門の幹部から「一体なぜ本番前の環境でこの問題を見つけられなかったのか？」と問い詰められることです。オブザーバビリティの事前検証の結果に基づいて、Tier 0とTier 1でのリリース可否を決定すれば、このような気まずいやり取りをせずに済みます。

階層別オブザーバビリティ機能：期待値および透明性

透明性の高い階層モデルを用意すると、アプリケーションのTierごとに必要なオブザーバビリティのカバー範囲を把握できます。

オブザーバビリティのカバー範囲と階層ごとに分類したワークロードを適切に整合させることで、オブザーバビリティ戦略の総所有コスト(TCO)をより正確に把握し、テクノロジーに闇雲に投資するのではなく、ビジネスへの影響を見極めながら投資を拡大することが可能です。透明性の高いオブザーバビリティの階層化戦略が策定されていれば、低い階層のアプリケーションを優先的に対応しない理由について説得力のある説明ができるだけでなく、エンジニアがオブザーバビリティツールに振り回されずに、価値の高い作業に集中できます。

階層型オブザーバビリティの導入例：階層型オブザーバビリティへの取り組みの基本から始めましょう。

階層化の成熟度を段階的に高める取り組みの例：オブザーバビリティの階層化戦略の成熟度に応じて、アクティビティを追加したり、組織のその他のアクティビティを活用したりすることで、ビジネス価値をさらに向上させることを検討してください。

ツールの有効活用：一元的な可視化と継続的な改善

オブザーバビリティは、ツール導入のみで完結するわけではありません。そのツールをどのように活用するかが重要です。アプリケーションのオブザーバビリティを網羅するために複数のツールが必要な場合は、ツールを頻繁に切り替えなくても済むように、統合的なエクスペリエンスを実現することも必要です。

オブザーバビリティにおける推奨事項：

• ツールを相互に接続してチーム間の連携を図ることで、作業の分断や重複を回避します。
• 推奨ツールセットの活用を進めながら、オブザーバビリティの目標達成を目指します。
• オブザーバビリティ/プラットフォームエンジニアリングチームと、効果的な問題の検出、調査、解決のためにこれらのツールを利用しているエンジニア(SRE、IT運用担当者、アプリケーション開発者など)との間の コラボレーションを促進 します。
• オブザーバビリティツールを最大限に活用できるよう、ツールの学習、トレーニング、「as-code」アプローチなどを通じた 継続的なスキルアップをチームに奨励 します。
• 定期的な情報共有の機会を設けることで、社内チームとオブザーバビリティベンダーの連携を維持します。これにより、ツールの定着と有効活用が促進され、オブザーバビリティの成果をより多く得られます。

オブザーバビリティのメタデータ戦略にも階層化モデルを取り入れる

メタデータとタグ付けの戦略を明確に定義することは、オブザーバビリティを実現する上での重要な鍵となります。適切にタグ付けをしなければ、高度なインストルメンテーション環境であっても、雑然としたデータやノイズが増え、効果的に運用できなくなります。

オブザーバビリティのメタデータとは、ピボットテーブルの「分割」機能のようなものと考えるとよいでしょう。適切に体系化されていれば、データを効率的に分割、フィルタリング、相関付けし、有意義なインサイトを引き出すことができます。

タグ付け戦略に階層化のためのメタデータを取り入れることには、以下のような大きなメリットがあります。

• オブザーバビリティの自動適用：アプリケーションの重要度に合わせて、オブザーバビリティのポリシー、アラート設定、データ保持設定を適用します。
• コスト最適化に関する詳細なインサイトの取得：オブザーバビリティの支出をアプリケーションの階層と関連付けて把握できるため、コストに見合ったビジネス価値を得られます。
• ツールをまたいだ相関付け機能の改善：複数のオブザーバビリティプラットフォーム間で、アプリケーション、サービス、インフラを正確にグループ化、フィルタリング、分析できます。

モノリシックアーキテクチャと最新アーキテクチャそれぞれに求められるオブザーバビリティ

階層型オブザーバビリティ戦略は、異なるアプリケーションアーキテクチャをまたいで実践した際に初めて真価を発揮します。従来型のレガシーワークロードと次世代のワークロードの両方でオブザーバビリティのニーズを満たすことが、価値を生み出すための鍵です。

モノリシックアプリケーションのオブザーバビリティ要件を満たす

多くの企業では、今でもモノリシックアプリケーションが利用されていますが、これらは最新のオブザーバビリティ製品で利用できる作りにはなっていません。モノリシックアプリケーションには、ERP、CRM、基幹業務プラットフォームなどがあり、その多くがきわめてビジネスクリティカルなシステムです。

レガシーアプリケーションのオブザーバビリティに関する考慮事項：

• 必ず調査を行ってください。最新のオブザーバビリティツールがすべてレガシーシステムと互換性があるわけではありません。
• Splunk AppDynamicsのような優れたAPMソリューションを活用しましょう。
• オブザーバビリティの導入前に、インストルメンテーションのリスクと制約を理解しておく必要があります。

次世代アプリケーション：導入段階からオブザーバビリティを自動化

クラウドネイティブ、マイクロサービスベース、サーバーレスの最新アーキテクチャでは、開発プロセスにオブザーバビリティを組み込む必要があります。以下に次世代アプリケーションのオブザーバビリティに関するベストプラクティスを挙げます。

• 基本的なオブザーバビリティをデフォルトで有効にします。基本的なオブザーバビリティ(基本ログ、メトリクス、アップタイムチェック)は、すべてのアプリケーションの導入時に組み込む必要があります。そこからスタートし、階層に応じてオブザーバビリティを強化します。
• Observability-as-Code (OaC)によるツール連携や自動化をオブザーバビリティツールで活用します。
• OpenTelemetry (OTel)を積極的に採用し、ベンダーに依存しない自動インストルメンテーション機能を活用します。

スケーラブルなオブザーバビリティモデルの構築

オブザーバビリティでは、ただ監視対象を可視化するだけではなく、最も注目すべき箇所を優先的に監視することが重要です。階層型のオブザーバビリティ戦略を採用することにより、最も重要度の高いアプリケーションにはそれに相応しいレベルの監視、アラート、対応を行い、重要度の低い階層のサービスにはそれなりの規模のオブザーバビリティ機能を割り当てることが可能になります。

まず、特に重要度の高いアプリケーションを特定し、それぞれにおいてオブザーバビリティのカバー範囲が適正かどうかを評価しましょう。インストルメンテーションやアラート設定が適切に行われ、パフォーマンスや信頼性が可視化されていますか？もし不十分な箇所があれば、そこに最優先で対応してください。オブザーバビリティのカバー範囲を他の領域に拡大するのはその後です。

長期的な成功につなげるためには、階層への分類作業を1回限りでは終わらせず、オブザーバビリティの不可欠な作業として戦略に組み入れる必要があります。ビジネスの優先事項の変化に合わせてアプリケーション階層を定期的に見直し、最も重要なワークロードに最高レベルのオブザーバビリティを導入してください。オブザーバビリティプラクティスは、それをビジネスへの影響と整合させ、不要なノイズを取り除き、オブザーバビリティを強化すべき場所についてデータに基づいた判断を重ねることで洗練していきます。階層モデルを中核に据えてオブザーバビリティへの投資戦略を策定することで、MTTRの短縮、コストの最適化、効率の向上が実現し、エンジニアリングチームがビジネス価値の創出に注力し続けることができます。

実践的なオブザーバビリティ運用

このブログ記事のようなo11Yコンテンツに興味をお持ちであれば、他のブログもぜひご覧ください。今後も新しいコンテンツが追加されますのでお楽しみに。

• オブザーバビリティに関するブログ