オブザーバビリティ製品移行の実現可能性の検証（PoC）の事例

技術選定 監視

オブザーバビリティ製品移行の実現可能性の検証（PoC）の事例

はじめに

こんにちは、EC基盤開発本部SRE部の杉山です。普段はSRE部のテックリードを務めています。

本記事では、2024年10月〜2025年4月に実施した、オブザーバビリティ製品移行の実現可能性を検証するPoC（Proof of Concept）について、その検証観点や分かったことを紹介します。

目次

前提

※本記事の内容は、2024年10月〜2025年4月に実施したPoCの検証結果に基づいています。記載している機能や挙動は当時のバージョンでの確認内容であり、今後のアップデートにより変更される可能性があります。

背景

当社では、監視・ログ収集・トレースなどのオブザーバビリティを実現するために、特定のオブザーバビリティ製品を利用しています。しかし、技術の進化や要件の変化に伴い、他製品への移行を検討する際に「現実的に移行は可能なのか？」という問いに対して、確信をもって答えづらい場面がありました。そこで、実際に移行が可能かどうかを確認するPoCを実施し、その知見を本記事にまとめました。

目的

PoCの目的は以下の通りです。

  1. 移行に伴う技術的課題の洗い出し
  2. 移行ができない機能の代替案の技術検討と仮実装
  3. 移行後の運用影響の調査

PoCチーム

  • PM/テックリード：杉山（筆者）
  • メンバー：各マイクロサービス担当SREより合計10名

フェーズ/スケジュール

  • Ph.1：機能移行の検証（2024/10〜2025/01）
  • Ph.2：運用影響の検証（2025/02〜2025/04）

Ph.1 機能検証について

現状利用している全機能を対象に、移行可否を検証しました。以下に検証対象の機能一覧を示します。対象は多岐にわたり主要な機能はすべて網羅しています。

検証対象の機能一覧

  • Integrations
    • AWS Integrations
      • CloudWatch Metrics (Standard)
      • CloudWatch Custom Metrics
      • CloudWatch Metric Streams
      • PrivateLink経由での接続
    • Slack Integration
    • Webhook Integration
    • PagerDuty Integration
    • Elasticsearch Integration
    • Kubernetes Integrations
    • Sentry Integration
    • GCP Integrations
  • Infrastructure Monitoring
    • Hosts
    • Containers
    • Kubernetes
    • Processes
    • Serverless
    • Network
  • APM
    • Service Catalog
    • Traces
    • Profiles
    • DBM（Database Monitoring）
    • DSM（Data Streams Monitoring）
  • APM Instrumentation
    • Auto instrumentation
      • Java
      • Go
      • Istio
    • Manual instrumentation
      • Java
      • Go
      • Istio
      • Custom spans
      • Custom metrics
    • Istio
      • Ingress Gatewayのトレース取得
      • サービス間通信のトレース取得
      • Progressive Delivery対応
    • レガシーシステム (VBScript)
      • VBScript環境のTrace
  • Monitor
    • Threshold Alert
    • 発報条件
      • 複合モニター
      • 条件の種類
      • Anomaly Detection（異常検知）
    • Downtime設定（任意時間のアラートミュート）
      • ワンショットダウンタイム
      • スケジュールダウンタイム
    • Traceメトリクスの利用可否
  • Metrics
    • System Metrics
      • CPU
      • メモリ
      • ディスク
      • ネットワーク
    • Runtime Metrics
      • GC
      • Heap
      • Non-heap
      • Thread
    • Custom Metrics
      • CloudWatch LogsのMetricsFilterで生成したカスタムメトリクス送信
      • CronJobなどから送信しているカスタムメトリクス
    • Argo Workflowのメトリクス送信（Custom Metricsと同様に取得可能か）
  • Dashboard
    • Service Dashboard
    • SLO Dashboard
  • Logs
    • Filter機能
    • AWS S3 Archive機能
    • 任意の場所やSaaSへのフォワード
    • レガシー環境の独自ライブラリからのログ送信
  • Synthetics
    • API Test
    • Browser Test
    • Private Locations
  • IaC対応
    • Terraform対応
  • SSO対応
    • Azure AD連携
    • ORG分割（プロダクト別）

課題と対応

検証対象の機能を網羅的に確認し、各機能の移行可否を評価しました。多くは移行可能でしたが、一部は移行先で同等機能が存在しない、あるいはOSS仕様上の制約があるなどの理由で、難易度が高いものもありました。

対応策

OSSはコントリビュートによる機能追加の可否まで踏み込みました。また、レガシー環境向けの独自ライブラリについては、筆者が作者であったこともあり、移行先製品が対応するOpenTelemetryを利用したライブラリを新規作成しました。以下は一部の対応例です。

  • Java Auto Instrumentation

    • 自動計装では、一部のSpan情報やResource属性が不足しており、十分なトレースデータを取得できないケースがある。
      • 必要な情報を補完するため、該当箇所ではマニュアル計装を追加して対応。
    • 一部のJVMメトリクスは自動計装のみでは取得できない。
      • javaagentを起動オプションで手動起動することで、取得範囲が拡張されることを確認。

  • Flagger

    • Istio上でProgressive Delivery（Canaryリリースなど）を制御するために利用しているFlaggerについて、移行先候補のProviderがなく利用できない。
      • OSSにコントリビュートして機能追加を行い、マージ後に利用可能であることを確認。

  • Istio Auto Instrumentation

    • Istioでは、Tracerを有効化する際に、複数の監視バックエンドへネイティブ形式のトレースデータ（テレメトリ）を同時に送信できない。
      • OpenTelemetry Collectorの設定をカスタマイズし、複数の宛先にOTLP形式でトレースを送信する構成で対応。
        • 既存のネイティブ形式は利用できないため、トレース情報の差分を確認。
        • 多少の違いは、Collectorの設定ファイルでカスタムProcessorを定義して対応。
        • この構成により、複数のバックエンドに同一トレースデータを分岐して送信できるようにした。

  • Log Forwarding

    • オブザーバビリティ製品と、Amazon S3の両方にログを送信したい。
      • 複数の宛先へのログ送信は、OpenTelemetry Collectorのカスタムビルド（Linux/Windows）で対応。
        • 必要な設定とExporterを追加し、AWS S3など複数の出力先へ送信できるようにした。

  • Legacy Tracer Library

    • リプレイス未完のレガシー環境はTraceに非対応。
      • 移行先に対応したOtelTracerCOM Library（Windows向け）を作成。
      • 手動計装でDLLを適宜利用し、複数の監視バックエンドへトレースデータを送信できるようにした。

「無いものは作る！」という方針のもと、チームで積極的に課題解決に取り組みました。 その結果、製品の仕様によらない課題については概ね対応の見通しを立てることができました。

機能検証まとめ

  • 検証対象の多くは移行可能であることを確認。
  • 一部はOSSへのコントリビュートや独自ライブラリで補完可能。
  • 検証の結果、現時点の要件では一部機能が満たせないため、継続利用を含めた複数の選択肢を検討することにした。
  • なお、製品側の進化により状況が変わる可能性もあるため、継続的な情報収集が重要。
    • 例：DBMはPoC時点では移行不可能だったが、2025年12月時点では利用可能になっていることを確認（機能の詳細は未確認）。

Ph.2 運用検証について

運用検証は下記観点で評価しました。

  • 運用フローの変更とその影響
  • Traceの見え方（トラブルシュートの容易さ）
  • IaC化（Infrastructure as Code）に関する移行コスト
  • ダッシュボード構成などの運用要素
  • 移行作業全体のコストとドキュメント整備

以下に、特に注目すべき検証内容を記載します。ダッシュボード構成および移行コストに関する内容は、後述の「運用検証まとめ」で整理しています。

運用フローの変更

移行先製品の推奨運用フローと現行フローを比較したところ、オブザーバビリティの思想やトラブルシュート手法に大きなギャップがありました。現場では、開発環境で実際に変更後のフローを試してもらい、フィードバックを収集しました。

その結果、運用ドキュメントの大幅な改定が必要であることに加え、ドキュメント整備や教育にかかるコストも想定以上に大きいことが分かりました。特にトラブルシュートに関しては、Traceを起点とする現行の調査方法と大きく異なるため、現場の混乱が見られました。現場からは「運用方法をどう適応させるか」といった懸念もあり、チームで新しい運用スタイルに合わせる必要性が明確になりました。

このように、机上では問題なさそうに見える変更でも、運用検証を通じて現場の意見を集めることの重要性を再認識しました。

Traceの見え方

移行先製品のTrace画面（UI、情報量、表示形式）は、現在利用している製品とは設計思想が異なり、構成や操作感にも違いがありました。その結果、トラブルシュートの手順や情報の見せ方にも変化が生じています。

検証時に挙がった主な意見は以下の通りです。

  • 画面遷移の構成が異なり、エラーの発生箇所を特定するまでの流れが変わる。
  • サービス間の呼び出し関係やトレースの関連付けの表現が異なり、把握までに慣れが必要。
  • Span情報の扱いや付加できるメタデータの形式が異なるため、一部で追加計装が必要。
  • Trace、メトリクス、ログの紐づけ方が製品によって異なり、調査の進め方も変わる。

このような違いは、単なるUIの差ではなく、オブザーバビリティ製品がもつデータモデルや設計思想の違いによるものと考えられます。どちらが優れているという話ではなく、各製品が重視する観測軸や分析のアプローチが異なるため、運用チームとしてはそれに合わせたワークフローを再設計する必要があると感じました。

検証を通じて、トラブルシュートのUXはツールの機能だけでなく、チームの習熟度や運用文化にも大きく影響されることを改めて実感しました。

IaC化についての移行コスト

現行はTerraformによるIaC化が進んでおり、コード管理はMUST事項です。
移行先でTerraform化を進める場合は、手順が複雑になることが分かりました。
概算では、IaC化におおよそ半年超の工数が見込まれ、大きな負荷になると判断しました。

運用検証まとめ

ドキュメント上の機能比較だけでは見えない、ツールの設計やチームの慣れなど複数の要素が、障害対応の速度や品質に影響することが分かりました。ダッシュボード構成の表現も変わります。慣れの問題もありますが、これらの学習コストも見逃せません。現場運用者の声は重要な判断材料です。IaC管理においては、既存コードの変換は難しく、新たにコード化する必要があります。TerraformのImport/Exportなど、コード化を支援する機能が備わっている点も、製品選定において非常に重要なポイントだといえます。

まとめ

本記事では「オブザーバビリティ製品移行の実現可能性を検証したPoCの事例」を紹介しました。PoCを通じて、機能や性能の違いだけでなく、観測データの扱い方や運用文化の違いも、移行における重要な検討要素であることが明確になりました。

今回のPoCで得られた主な知見は以下の通りです。

  • 機能面では、多くの要件を移行先でも再現可能であり、実装による対応範囲の広さを確認できた。
  • 一部の機能は、OSSへのコントリビュートや独自ライブラリの追加によって補完可能であることが分かった。
  • SaaSやOSSなど、提供方式やデータモデルの違いによって実現方法が変わるため、機能単位ではなく構成単位で検討する必要がある。
  • 運用面では、チームの慣れやトラブルシュートの流れ、可視化の思想が変わることで、ドキュメント整備や教育コストが発生する。
  • これらの変化は単なるツールの使い勝手の違いではなく、組織の運用プロセスや役割分担にも影響するため、早期に検証環境を用意し、現場の意見を反映しながら調整を進めることが重要。
  • IaC化の検証では、コード管理の方式やツール連携の違いが運用負荷に直結することが分かり、Terraformの取り込み方は各社の製品方針に左右されることを確認した。

これらの結果から、オブザーバビリティ製品の移行は技術的には十分に実現可能であると判断しました。 一方で、「どのように運用に組み込むか」「どのようにチームに浸透させるか」という非機能面での設計と準備が重要であることが分かりました。 移行を進める際は、プロダクトやインフラ単位での影響評価に加え、SREや開発チームの運用習熟度を考慮した段階的な移行計画が求められます。

また、PoCを通じて改めて感じたのは、オブザーバビリティは単にデータを「見る」ための仕組みではなく、障害検知・改善・意思決定の精度を高める「文化や習慣」として根付かせることが大切だという点です。ツールの差はそれを支える手段の1つにすぎず、自社の運用スタイルや目指す可観測性のレベルに合った形を選ぶことが最も重要だと感じました。

最終的に、今回のPoCからは次のような結論を得ました。

  • 移行は技術的に可能。ただし、運用・教育・IaC化などの非機能領域にかかるコストは小さくない。
  • 検証を通じて得られた知見は、今後の製品評価や設計方針の議論にも活用できる。
  • 移行はゴールではなく、組織としてオブザーバビリティをどう進化させていくかを考える起点。

本PoCが、同様の課題を検討している方々にとって、計画立案や検証設計の参考になれば幸いです。

ZOZOでは、システムの信頼性や可観測性を高めながら、より良い開発体験を追求できるエンジニアを募集しています。ご興味のある方は、以下のリンクからぜひご応募ください。

hrmos.co

カテゴリー