LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

オブザーバビリティとは——従来の死活監視と何が異なるのか

オブザーバビリティ（Observability、可観測性）とは、システムの外部出力を観察することで、内部状態を理解できる能力を指します。OpenTelemetryの公式ドキュメントでは、”外部から質問することで、内部の仕組みを知らなくてもシステムを理解できること”と定義されています^*1。

死活監視・ログ監視との違い——「正常か異常か」から「なぜ起きたか」への転換

従来の監視は、サーバーやプロセスの死活確認・CPU/メモリ使用率の閾値超えアラートが中心でした。「何かが壊れたこと」は検知できますが、「なぜ壊れたか」の因果関係を追うには手作業でのログ調査が必要です。

オブザーバビリティは、メトリクス・ログ・トレースを連携させることで、障害発生時に「どのサービスのどの処理で・何が原因で・どのリクエストが影響を受けたか」を一連の文脈として把握できます。事前に想定したアラートルールに頼らず、未知の障害にも対応できる点が大きな違いです。

分散システム・マイクロサービスが可観測性を必要とする理由

モノリシックなシステム（単一のアプリケーションとして動作する構成）では、ログを1か所で確認すれば問題の追跡がある程度完結していました。しかし、マイクロサービス（Microservices）アーキテクチャでは、1件のユーザーリクエストが10〜100以上のサービスをまたいで処理されます。

このとき、特定のサービスでエラーが発生しても、その原因が上流サービスの応答遅延なのか、依存するデータベースの問題なのか、ネットワーク経路の障害なのかを、従来の死活監視だけで特定することは困難です。オブザーバビリティの分散トレースが、こうした複雑な因果関係の追跡を可能にします。

メトリクス・ログ・トレース——3本柱の役割と連携

オブザーバビリティの3本柱とは、メトリクス（Metrics）・ログ（Logs）・トレース（Traces）の3種類のテレメトリデータを指します。OpenTelemetryの公式ドキュメントでは、これらを”シグナル（Signals）”と呼び、それぞれ異なる視点からシステムの状態を表現するものとして定義しています^*2。

メトリクス——CPU・レイテンシ・エラー率を時系列で集約

メトリクスとは、インフラストラクチャやアプリケーションの実行状態を数値として一定期間ごとに集約したデータです^*3。代表的な指標としては、CPU使用率・メモリ使用率・リクエスト応答時間（レイテンシ）・エラー率・スループットなどが挙げられます。

メトリクスは、時系列グラフでの可視化・閾値アラート・SLO（後述）の計算基盤として使われます。ログやトレースと比べてデータ量が少なく、長期保存・集計処理に向いています。Prometheus（プロメテウス、CNCFのオープンソース監視システム）との連携で活用されることが多い領域です。

ログ——タイムスタンプ付きイベントで障害の痕跡を残す

ログとは、サービスが出力するタイムスタンプ付きのテキストメッセージです^*3。エラーメッセージ・ユーザー操作の記録・処理の開始・終了などが含まれます。障害発生後の原因調査（ポストモーテム）において、最も詳細な痕跡を提供します。

課題となるのは、マイクロサービス環境では複数のサービスがそれぞれログを出力するため、ログが分散・大量化することです。ログ集約基盤（OpenSearch、Elasticsearch、Grafana Lokiなど）の設計と運用が別途必要になります。

分散トレース——マイクロサービス間のリクエスト経路を追跡

分散トレース（Distributed Trace）とは、1件のリクエストが複数のサービスをまたいで処理される経路を記録したデータです^*3。トレースは複数のスパン（Span）で構成され、各スパンは個々のサービスの処理時間・成否・属性情報を保持します。

分散トレースを使うと、「Aサービス→Bサービス→DBの順に処理が進んだが、Bサービスの処理で平均より200ms多くかかっていた」という粒度の分析が可能になります。Jaeger（ジェガー）・Zipkin（ジップキン）・Grafana Tempoなどのバックエンドが利用されます。

3本柱は独立した技術ではなく、連携して使うことで真価を発揮します。アラートメトリクスが閾値を超えたとき、同タイムスタンプのログを参照し、問題リクエストのトレースで根本原因を特定するという流れが、オブザーバビリティ基盤の標準的な調査パターンです。

OpenTelemetryとSLO/SLI——監視基盤の標準と品質指標

監視基盤を構築する際には、どのツールや標準を選ぶかが長期的な運用コストを左右します。現在、業界標準として普及しているのがOpenTelemetry（OTel）であり、品質管理の指標体系としてSLI/SLOが広く採用されています。

OpenTelemetry（CNCFグレデュエーテッドプロジェクト）が標準になった背景

OpenTelemetryとは、テレメトリデータ（メトリクス・ログ・トレース）の生成・収集・エクスポートを行うオープンソースのオブザーバビリティフレームワークです^*1。CNCF（Cloud Native Computing Foundation）のグレデュエーテッドプロジェクト（Graduated、CNCFの上位成熟度ステータス）として認定されており、12以上のプログラミング言語に対応し、100以上のベンダーがサポートしています^*4。

OpenTelemetry以前は、ベンダーごとに独自エージェント・独自SDK・独自プロトコルが乱立していました。Datadogのエージェント、New Relicのエージェント、AWS X-Rayのエージェントをそれぞれ組み込む必要があり、監視ツールを切り替えるたびにアプリケーションコードの修正が必要でした。

OpenTelemetryはベンダー非依存の計装（インストルメンテーション）を提供します。一度OTelのSDKで計装しておけば、バックエンドをDatadogからGrafanaに変更する際もアプリケーション側の変更は不要です。この”ベンダーロックインの排除”が普及した主因です。

OpenTelemetry Collectorは、テレメトリデータを受信・処理・エクスポートするベンダー中立のコンポーネントです^*5。リトライ・バッチ処理・センシティブデータのフィルタリングといった共通処理を集約でき、本番環境での導入が推奨されています。

SLI（サービスレベル指標）とSLO（サービスレベル目標）の設計

SLI（Service Level Indicator、サービスレベル指標）とは、ユーザー視点でのサービス品質を測定する指標です^*3。可用性（稼働率）・レイテンシ（応答時間）・エラー率・スループット（処理量）などが代表的なSLIです。

SLO（Service Level Objective、サービスレベル目標）は、SLIに対して設定する数値目標です^*3。「99.9%の月間可用性を維持する」「p95レイテンシを200ms以下に保つ」のような形で定義します。SLOを設定することで、エラーバジェット（許容できる障害量の上限）が計算でき、信頼性投資の判断基準になります。

SLAとの違いも整理しておくと実務で役立ちます。SLA（Service Level Agreement）は顧客との契約に記載する数値であり、SLOはそれを達成するための内部目標です。SLOをSLAより厳しく設定することで、SLA違反を事前に防ぐバッファを確保します。

監視基盤を内製構築する難易度——必要スキルと工数の実態

オブザーバビリティ監視基盤の内製構築は、単に監視ツールを導入するだけでは完結しません。計装・データ収集・バックエンド構築・ダッシュボード設計・アラートルール策定・継続運用まで、複数の専門技術領域が絡み合います。

内製に必要な技術領域——計装・Collector設計・バックエンド・ダッシュボード

監視基盤の内製構築には、主に以下の4つの技術領域のスキルが必要です。

• 計装（インストルメンテーション）：アプリケーションコードにOpenTelemetry SDKを組み込み、メトリクス・ログ・トレースを出力する作業。自動計装と手動計装の使い分けが必要です。
• Collector設計・運用：OpenTelemetry Collectorのパイプライン設定（レシーバー・プロセッサー・エクスポーターの構成）と、スケーラビリティ確保のための冗長化設計が必要です。
• バックエンド構築：メトリクス用（Prometheus＋Thanos等）・ログ用（OpenSearch、Grafana Loki等）・トレース用（Jaeger、Grafana Tempo等）のそれぞれのストレージとクエリエンジンを別々に設計・運用する必要があります。
• ダッシュボード・アラート設計：Grafana等を用いたダッシュボード作成と、SLOベースのアラートルール（PromQL、LogQLの習熟が必要）の策定です。

これらを内製で担うには、SRE（Site Reliability Engineering）またはプラットフォームエンジニアリングの知識を持つエンジニアが複数名必要です。初期構築は数名×3〜6か月程度の工数になるケースが多く、構築後も専任またはそれに準じる体制での継続運用が求められます（参考値・一次資料ではありません）。

分散環境での計装で発生しやすい課題

内製で監視基盤を構築する際、特につまずきやすい点が計装の複雑さです。マイクロサービスが多言語で書かれている場合、Java・Go・Python・Node.jsなどそれぞれの言語のOpenTelemetry SDKを別々に導入・設定する必要があります。

また、計装を誤るとテレメトリデータが過多になり、ストレージコストとクエリレイテンシが急増するリスクがあります。サンプリング戦略（全リクエストの何%を記録するか）の設計が不適切だと、問題発生時に必要なトレースが欠損することもあります。

Kubernetesクラスター上でOpenTelemetry Operatorを用いて自動計装する構成では、Kubernetes運用知識も別途必要になります。監視基盤の構築が、インフラエンジニアとアプリケーションエンジニアの両方の専門領域にまたがる点が、内製難易度を高める主要因の一つです。

オブザーバビリティ監視基盤を外注するメリットと費用感

内製構築の難易度と専門人材の確保コストを踏まえると、外注・委託が有力な選択肢になります。外注によって立ち上げ速度の向上・専門知識の即時活用・継続運用体制の安定化が期待できます。

外注が有効な3つのケース——立ち上げ・人材不足・スケール対応

以下の3つのケースでは、特に外注の効果が出やすい傾向があります。

• 新規サービス・マイクロサービス移行の立ち上げ時：初期構築に3〜6か月の工数が必要な監視基盤を、早期に本番品質で稼働させたい場合に効果的です（工数目安は参考値・一次資料ではありません）。
• SRE・プラットフォームエンジニアの採用が難しい場合：オブザーバビリティ領域の専門人材は採用難度が高く、採用まで半年〜1年以上のリードタイムを要するケースも少なくありません。外注で即戦力の専門知識を活用できます。
• サービス規模拡大や複数チームへのオブザーバビリティ展開：プラットフォームエンジニアリング的に複数サービスへ横断展開する際の設計・教育・移行支援を外部に委ねることで、内部リソースをプロダクト開発に集中できます。

委託費用の市場参考値と費用を左右する要素

監視基盤の構築・外注費用は、対象サービス数・マイクロサービスの複雑さ・クラウド環境・既存ツールの状況によって大きく異なります。以下はあくまで市場参考値であり、一次資料に基づく数値ではありません。

費用を左右する主な要素は、対象マイクロサービス数・使用言語の多様性・既存監視ツールとの統合要否・バックエンドに使うSaaS（Datadog等）かOSS自前構築かの選択、そして継続運用体制の規模です。

SaaSを利用する場合はツールライセンス費用（データ量・ホスト数に比例）が別途かかります。OSS自前構築の場合は人件費・インフラコストが主となります。どちらが有利かは自社のデータ量・スケールアウト計画・運用体制によって異なります。

委託先の選定チェックリスト——技術・体制・運用設計の3軸

委託先を選ぶ際は、技術・体制・運用設計の3軸で評価することをお勧めします。

技術軸では、OpenTelemetryを用いた計装実績・Kubernetes/コンテナ環境での構築経験・採用するバックエンドツール（Prometheus、Grafana、Jaeger等）の習熟度を確認します。特に、自社のシステム構成（言語・FW・インフラ）に対応した計装実績があるかが重要です。

体制軸では、SREまたはプラットフォームエンジニアリング専門のチームを持つかどうかを確認します。元請（プライムベンダー）として窓口を一本化できるかも、複数ベンダーにまたがる調整コストを抑える観点から重要です。

運用設計軸では、SLO/SLIの設計支援能力・アラートノイズ低減の実績・障害発生時の対応手順（ランブック作成支援）まで含めた運用設計の経験を確認します。監視基盤は構築後の継続改善が品質を左右するため、単なる初期構築だけでなく運用フェーズまで見据えたパートナー選定が求められます。

まとめ——外注判断の3つの軸

本稿では、オブザーバビリティの定義・3本柱（メトリクス・ログ・トレース）・OpenTelemetry標準・SLO/SLI設計・内製の難易度・外注の費用感と選び方を整理しました。要点を3つに集約すると次の通りです。

第一に、オブザーバビリティは「なぜ起きたか」を追跡する能力であり、分散システム・マイクロサービス環境では従来の死活監視の代替ではなく補完として位置づけます。

第二に、OpenTelemetryはCNCFグレデュエーテッドプロジェクトとして業界標準となっており、ベンダーロックインを排除できる計装標準として採用メリットが高い選択肢です。

第三に、内製構築は計装・Collector設計・バックエンド・ダッシュボードの複数専門領域にまたがるため、SRE/プラットフォームエンジニアの確保が難しい場合は外注が現実的な選択肢になります。委託先選定は技術・体制・運用設計の3軸で評価することで、初期構築だけでなく継続運用まで見据えたパートナー選定ができます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OpenTelemetry「What is OpenTelemetry?」（2024年）
2. *2　出典：OpenTelemetry「Signals」（2024年）
3. *3　出典：OpenTelemetry「Observability Primer」（2024年）
4. *4　出典：OpenTelemetry公式サイト「OpenTelemetry — a CNCF graduated project」（2024年）
5. *5　出典：OpenTelemetry「Collector」（2024年）

Tweet