こんにちは、MSPセクションの秋山です。

東京で開催された「AWS Summit Japan 2025」の1日目（6/25(水)）に参加してきました。
初めてのSummit参加となりましたが、とても良い刺激になりました。

その中で、以下のセッションの内容について紹介させていただきます。

セッションタイトル

パナソニック エオリア アプリにおける、ユーザージャーニーを起点としたサービスレベルマネジメントの導入と実践

皆様のシステムは外部からのクレームや SNS の反応に惑わされていませんか？障害対応は属人的になっていませんか？
国内で多数のユーザーが利用するエオリアアプリ。クラウドネイティブなアーキテクチャのもと、システム安定性向上と運用体制スリム化の両立を実現した鍵はオブザーバビリティの実践でした。
利用者の満足度を追求したクリティカルユーザージャーニーに基づく、サービスレベルマネジメントの導入と実践に向けて、パナソニック、AWS、New Relic の三位一体で取り組んだ軌跡と今後の展望をお伝えします。

セッションの内容に入る前に、セッションのテーマとなっている以下の用語について簡単に解説します。

オブザーバビリティとは

オブザーバビリティは可観測性と言われ、システムが現在どのような状態にあるか、内部の情報（メトリクス、ログ、トレースなど）を収集し観測することです。

現代の複雑な分散システムやマイクロサービスアーキテクチャでは、予期せぬ問題や未知の障害が発生しやすく、従来の監視（モニタリング）だけでは対応が困難になっています。
そこで、オブザーバビリティを導入し、プロアクティブに対応していくことが求められています。

以下のブログでとてもわかりやすく解説されています。
【次世代MSP】オブザーバビリティってなあに？

サービスレベルマネジメントとは

サービスレベルマネジメントとは、サービス提供者と利用者の間で、提供するサービスレベルを明確に合意し、その合意したサービスレベルを継続的に維持・改善していくためのプロセスのことです。

関連用語として、SLAやSLO、SLIなどがあります。
SLAはサービスレベルについての合意、SLOは目標、そしてSLIはサービスレベルを達成するために監視・測定する具体的な指標です。

本記事のテーマにもなっているサービスレベルマネジメント等の定義方法については、以下のブログでも詳しく解説しているので、ぜひご参照ください。

【次世代MSP】SLI / SLO を定義してみた ～ New Relic でサービスの見える化に挑戦！
【Google Cloud The Art of SLO ワークショップ】サイト信頼性エンジニアリング（SRE）とは？　SLO、SLIとは？

セッションの内容

クラウドネイティブなアーキテクチャで動作するエオリア アプリは、ユーザー数や機能の増加に伴い、コストや品質面で様々なことが課題となっていました。
こうした状況の中、顧客満足度の向上とシステムの運用コスト最適化のため、New Relicを活用してサービスレベルマネジメントの導入を進めました。（参考：NewRelicサービスレベルを始めましょう）

オブザーバビリティ導入のステップ

以下の流れでオブザーバビリティ導入に取り組んだとのことです。

  1. ユーザージャーニーの整理
  2. 主要なユーザージャーニー（Critical User Journey）の特定
  3. SLI/SLO仮決め
  4. 指標に必要なメトリクス設計
  5. 指標実装
  6. 手順改善
  7. SLI/SLO計測・見直し

主要なユーザージャーニー（Critical User Journey）、SLI/SLOの検討

ユーザージャーニーを洗い出し、それぞれの「頻度」と「重要度」から優先順位を定め、主要なユーザージャーニー（Critical User Journey）を特定。そして、特定した主要なユーザージャーニー（Critical User Journey）に対してSLI/SLOを仮定義・調整を繰り返す。

このステップは、AWSとNew Relicとワークショップを開催して検討を進めたようですが、このワークショップを通して、ユーザーが真に求めていることに気づけたとのことです。この点からも、ユーザージャーニーを丁寧に整理していくことがとても重要であると感じました。

なお、SLI（Service Level Indicator）は、SLOを達成するために監視・測定する具体的な指標で、例えば以下のようなものが挙げられます。

  • 可用性：有効なリクエストのうち正常に処理された割合
  • レイテンシー：有効なリクエストのうち閾値よりも早く処理された割合
  • 品質：品質を劣化させることなく処理された有効なリクエストの割合
  • 鮮度：しきい値よりも新しく更新された有効なデータの割合
  • カバレージ：処理に成功した有効なデータの割合
  • 正確性：正確な出力を生成する有効なデータの割合
  • スループット：データ処理レートがしきい値よりも速い時間の割合

今回のスライドには、「成功率」や「応答時間」といったワードがSLIの仮定義に含まれているため、上記のうち、「可用性」と「レイテンシー」をSLIの指標にしているようです。



SLI/SLO計測・見直し

New Relicで主要なユーザージャーニー（Critical User Journey）毎のダッシュボードを作成し、ユーザー影響や障害時の原因特定に活用しています。また、定義したSLOの一覧を可視化できるようにしています。
こうしたリアルタイムで計測した情報を週次でまとめて、以下の通り「計測したSLI/SLOの値とユーザー満足度の相関関係」を判断基準として、SLI/SLOの見直しを行っているようです。

SLI/SLOの見直し

  • 設定している内容を満たしてもユーザー満足度につながっていない場合
  • 違反が発生してもユーザー影響が認められない場合

SLOを定義することの重要性を説いているGoogleの「SRE Books」でも、SLI/SLOを定期的に見直して改善していくことが好ましいとされています。


導入効果

SLOの導入を進めることで以下のような効果があったとのことです。

  • エラーとサービス影響（ユーザー満足度）の関係性を把握しやすくなった
  • 開発者(Dev)と運用者(Ops)の間に共有言語が生まれ、コミュニケーションが円滑になった

Googleの「SRE Books」では、SLOを定義してSREを実践する効果の一つとして「開発者と運用者の関係改善」が挙げられています。今回のケースでは実際にその通りの効果が得られたということが、個人的には印象的でした。

まとめ

今回のセッションから、サービスレベルマネジメントでは、ユーザージャーニーを丁寧に整理して適切なSLI/SLOを定義すること、そして計測したSLI/SLOとユーザー満足度との関係性を定期的に確認し必要に応じて見直す、という取り組みを継続していくことが大切だと改めて感じました。

私もこれまでサービスレベルマネジメントの定義について学んできましたが、実際の導入プロセスとその効果を聞くことで腑に落ちることが多く、とても有意義なセッションでした。