ENECHANGE Developer Blog

ENECHANGE開発者ブログ

Application SignalsとOpenTelemetryで構築するSLO基盤

目次

はじめに

ENECHANGE株式会社でSREを担当している杉田(@Mnbvc124)です。

ENECHANGEでは、複数のプロダクトをAWS上で運用しています。

プロダクトの信頼性を継続的に改善するため、SLO導入に向けた基盤整備を進めており、その中で Amazon CloudWatch Application Signals と OpenTelemetry を利用したSLO基盤の検証・構築を行いました。

本記事では、その構成や実装内容について紹介します。

なぜSLO基盤が必要なのか

ENECHANGEでは、以下のような課題がありました。

  • 本番状況が十分に可視化できていない
  • アラートの重要度判断に時間がかかる
  • 運用改善が感覚ベースになっている
  • チーム間で問題認識が揃わない
  • 改善優先度の判断が属人的になっている

そのため、

  • OpenTelemetry によるシステム内部の可観測化
  • SLI/SLO による信頼性の定量化

を組み合わせて改善を進めることにしました。

技術選定理由

Datadog や New Relic などのSaaSも候補に挙がりましたが、複数プロダクトに展開する前提だとコストが大きな負担になります。

また、現時点では社内でSLOの有効性をまだ十分に見出せていない段階のため、まずは安価に構築できる方法で小さく始め、有効性を確かめながら進めたいと考えていました。

ちょうどその検証時期に Amazon CloudWatch Application Signalsに新しいSLO機能が追加 されたため、AWS Nativeな構成でSLO基盤を構築することにしました。

また、将来的にDatadogやNew Relicなど他SaaSへ移行する場合でも計装を再利用しやすい構成にするため、計装には OpenTelemetry を採用することにしています。

アーキテクチャ全体像

全体構成

今回の構成では、RailsアプリケーションにOpenTelemetryを導入し、収集したトレースデータを AWS Distro for OpenTelemetry (ADOT) Collector 経由で CloudWatch Application Signals へ送信しています。

主な役割は以下の通りです。

  • Railsアプリケーション
    • OpenTelemetry SDK による計装
  • ADOT Collector
    • テレメトリデータの収集・転送
  • CloudWatch Application Signals
    • SLI/SLOの可視化
    • アプリケーションマップ・トレース分析

Ruby on Railsでの計装

Ruby on Railsでは opentelemetry-instrumentation-all を利用して自動計装しています。

OpenTelemetry::SDK.configure do |c|
  c.use_all
end

これにより、以下の情報を自動で収集できます。

  • HTTPリクエスト
  • ActiveRecord
  • 外部HTTP通信
  • Redis

収集したトレースデータは ADOT Collector へ送信しています。

opentelemetry.io

Application Signalsで実現できること

Application Signals を導入したことで、SLOの可視化から障害分析までをAWS上で一貫して行えるようになりました。

特に、SLO運用とトレース分析を同じ画面群で確認できる点が便利でした。

SLOダッシュボード

SLOダッシュボードでは、SLO達成状況やエラーバジェット残量を確認できます。

SLOダッシュボード

これにより、

  • サービスが現在どれくらい安定しているのか
  • 今どれくらいユーザー影響があるのか
  • SLO違反リスクが高まっていないか

を数値ベースで判断できるようになりました。

また、バーンレートアラームと組み合わせることで、SLOを割りそうな状態を早めに検知できるようになっています。

アプリケーションマップ

アプリケーションマップでは、サービス間の依存関係を可視化できます。

アプリケーションマップ
障害発生時に、

  • どのサービスでエラーが発生しているか
  • どこまで影響が広がっているか

を把握しやすくなりました。

特に、複数サービスへまたがる障害調査で役立っています。

スパンの可視化(分散トレース)

Application Signals では、リクエスト単位でトレース情報も確認できます。

Railsアプリケーションでは、

  • ActiveRecord
  • 外部API
  • Redis

などの処理時間を追跡できます。

これにより、レイテンシ悪化時に「どこがボトルネックになっているのか」を分析しやすくなりました。

その他

このほかにも、

  • サービスダッシュボード
  • スパン横断検索

など、障害分析を支援する機能が提供されています。

詳細はAWS公式ドキュメントを参照してください。

docs.aws.amazon.com

今後の展望

今後は、

  • SLO基盤の複数プロダクト展開
  • SLO違反時の調査・一次対応の効率化

を進めていく予定です。

現在は一部プロダクトで検証を進めていますが、2026年上半期を目標に段階的に展開していきます。

また、SLO違反時には AWS DevOps Agent を活用し、一次調査の自動化などを行い、障害対応の効率化も進めていく予定です。