複雑化するサービスでの、機能単位での SLO 分割による運用改善
2026-01-05 | Author : 高山さやか (クラシル株式会社)
はじめに
クラシル株式会社 SRE チームリーダーの高山です。
私たちの運営するレシート買い取りアプリ・クラシルリワード (現レシチャレ) は、サービスの拡大とともにモノリシックな Ruby on Rails (Rails) アプリケーション上に多様な機能が積み重なり、「サービス全体で単一の Service Level Objective (SLO) ではサービスの実態にあっていない」という課題に直面しました。
本記事では、Rails で作成されたモノリスなサービスを Amazon Elastic Container Service の AWS Fargate (ECS Fargate) で動かすという一般的な構成の中で、サービスの複雑化に合わせて SLO を機能単位へ分割し、Service Level Indicator (SLI) の定義と SLO の計測方法を再構築していったプロセスと実装を紹介します。また、AWS や New Relic のログ活用によって現実に即した SLI / SLO を運用できるようになるまでの具体的なステップと学びをお伝えします。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
概要
レシート買い取りアプリ・クラシルリワード (現レシチャレ) のシステム構成は以下のとおりです。
- インフラ：ECS Fargate
- ログ基盤：Firelens x Fluent Bit (アプリケーションログの収集と送信)
- APM：New Relic Logs / ServiceLevels / Dashboard / New Relic Alert
SLO 計測で New Relic を選定した理由は以下のとおりです。
- New Relic のデータ injection 料金の安さ・APM が優れているためオブザーバビリティツールに選定
- アプリケーション関連のオブザーバビリティを New Relic に寄せているため、SLO の計測も New Relic に寄せている
- 簡潔な UI でビジネスサイドのメンバーも閲覧しやすい
このサービスはモノリシックな Rails アプリケーションであり、独立性の高い複数の機能 (レシチャレ、アフィリエイト、アンケート、チラシ、歩数など) が存在します。
本記事では以下の流れで説明します。
① サービス価値に基づくSLI の設計
② 単一 SLO のまま運用をはじめた際に発生した課題
③ New Relic を活用した機能ごとの SLO 計測手法
④ その結果として得られた運用改善
サービスインフラ構成
① サービス価値に基づく SLI の設計
SLI / SLO 運用を始めるにあたり、「サービスの価値」をチームで整理しました。
まだこの段階では、サービスの複雑性を深く意識しておらず、プロダクト全体としてひとつの SLO を定義する前提で議論を進めていました。
ワークショップ形式で付箋を使いながら、「ユーザーにとって欠かせない価値」を洗い出していくと、次のような項目に集約されました。
- コインなど売上に直結する情報が正しく更新・表示されること
- ユーザーがサービスに来た目的を快適に達成できること
こうした議論の結果や、指標がシンプルでないと運用しきれないという判断もあり、サービス全体として共通の SLI を「レイテンシ」と「5xx エラー率」の 2 軸で管理するという、シンプルな構成が初期の答えとなりました。
この時点ですでに各機能の重要度や要件が異なり始めていましたが、まだ「サービス全体でひとつの SLO で管理する」という前提でした。
② 単一 SLO のまま運用をはじめた際に発生した課題
サービス全体を対象とした単一の SLO を設定し、SLO の計測を開始したところいくつかの課題が発生しました。
課題 1. サービスの実態と SLO の乖離
まずは、SLO のアラートが発火していてもユーザー影響が限定的であるなど、単一 SLO がサービスの実態を適切に表現できていないという状況になりました。
主な要因は、サービスの拡張に伴い機能ごとに重要度・可用性要件が異なる構造へと変化していたことにあります。
具体的には、いくつかの機能には下記のような固有の事情が存在していました。
- 外部通信の影響などにより、一定のレイテンシを許容することを意思決定した機能
- 廃止予定で改善を継続しない意思決定がされた機能
このように、機能ごとに求められる可用性やレイテンシの許容範囲は一様ではありませんでした。単一の SLO 運用では、こうした “意図的であったり一時的に許容した低パフォーマンス” もすべて同じ目標に集約されるため、SLO の値に対して、抵触したらすぐに修正する必要がある指標として有効に機能していませんでした。
課題 2. アラート調査の複雑性とオーナーシップの持ちづらさ
情報が単一 SLO に集約されているが、上記のような過去に行われた意思決定の暗黙知によって本当に対応するべきなのかわからず、特に新規メンバーがアラートの重要度を判断しづらいという課題がありました。
また、SLO に抵触した際、このような多機能なサービスの調査では「どの機能が原因か」を特定する必要がありますが、全機能が一括で集計されているため原因切り分けに工数が発生します。
チーム体制が 1 チームから複数チームへと拡大したことで、単一 SLO が発火した際に「どのチームがトリアージすべきか」が曖昧になり、SLO アラートに対するオーナーシップを持ちづらくなる可能性がありました。
③ New Relic を利用した機能ごとの SLO 計測
上記の課題を解決するために、SLO を機能単位で分け、機能ごとに SLO の値を調整可能にするというアプローチを取りました。
以下では、New Relicを利用した機能ごとの SLO 計測と監視方法について紹介します。
対応内容は下記です。
- New Relic Logs に ECS からアプリケーションログを送信
- New Relic の SLI / SLO 機能を利用した機能ごとの SLO 計測
- ダッシュボード化 / 監視設定
New Relic に ECS Fargate からアプリケーションログを送信
FireLens / Fluent Bit と Amazon Data Firehose を利用し、ECS のコンテナ経由で New Relic Logs にアプリケーションログを送信しています。SLO を計測するときはなるべくユーザーに近いレイヤーでデータを取得することがベストですが、コストの関係上アプリケーションログで計測しています。Rails からのログは、https://github.com/roidrage/lograge を利用してリクエスト情報をjson形式に構造化して送信しています。 ECS のロギング設定を FireLens / Fluent Bit と Data Firehose に切り替えるのはとても簡単で、Amazon Data Firehose の Firehose ストリームを用意したうえで、ECS の Task に下記のように定義します。
本構成の運用上の注意点
こちらの構成の運用上の注意点としては、Amazon Data Firehose にはクオータがあるので、運用に乗せる前に
- 事前にクオータの上限緩和申請しておく
- 上限に近づいた際のアラートを設定しておく
などの対策をすることでログ配信の遅延を防ぐことができます。
また、Data Firehose ではログの送信先を複数設定できるので、同時に Amazon S3 にアプリケーションログを送信し、より長いスパンでのログを保持するようにしています。
New Relic の SLI / SLO 機能の利用
New Relic では、New Relic 上の様々なデータを SLI / SLO のソースに設定することができます。
今回は、Rails のモノリシックなアプリケーションを機能ごとに分割するために、New Relic Logs に送信したアプリケーションログの PATH を軸に分割して SLO を設定しています。
アプリケーションのエンドポイントの設計として、同じ機能はある程度まとまった同一の Prefix がついた PATH で統一されていることを前提としています。
こちらが、実際の New Relic の ServiceLevels の画面になります。
NRQL という DSL を利用して図のように対象の PATH を絞り込み、SLO を設定します。
New Relic ServiceLevels の設定はとてもシンプルで、かなり扱いやすく運用負荷は最低限にできています。
また、新しい関連PATHが追加されたときに PATH を手動で SLO の設定に追加しなくてもいいよう、Devin の Playbook を利用してアプリケーションの変更に対して自動で SLO の設定変更の PR を出す仕組みをチームメンバーが構築してくれました。
そのことにより、アプリケーションの実態と PATH 指定の自動化ができ運用が更に効率化できています。
(図 2. New Relic の ServiceLevels の設定)
ダッシュボード化と監視
ダッシュボード化
New Relic の ServiceLevels に SLO を設定したあとに、New Relic Dashboard にダッシュボード化を行いました。このことで、下記のようなメリットがあります。
- New Relic の Basic ユーザー (無料) でも SLO を閲覧可能
- 機能ごとの SLO が 1 ページで閲覧可能
図のように、タブ化することで各機能の SLO の状況を見やすくしています。
(図 3. New Relic Dashboard)
監視
New Relic にはアラート機能があり、SLO のエラーバジェットをベースにアラートを通知するしくみがあります。
それを各機能ごとに設定した SLO に適用して、notice / warn の 2 段階のしきい値でアラート通知を行っています。
(図 4. アラートメトリクス)
アラートはこのように、Slack のアラートチャンネルに通知されるようになっています。
また、New Relic の ServiceLevels / Dashboards / Alerts を Terraform の module として管理し、PATH の指定と目標値を設定するだけで機能ごとの SLO を作成できるようにしています。このことで、新機能が増えたときの運用を簡略化しています。
(図 5. Slack 通知)
④ 結果どうなったか
この改善を実施した結果、以下の運用改善に繋がりました。
- SLO がサービスの実態に即したことで、SLI / SLO の変動が「実装に課題がある」「アラートがきた = 修正が必要」という共通認識を生み出し、この 2 年間で SLO 抵触に対するパフォーマンス改善を継続的に実施することができています。
- トリアージの責任チームが明確になったことで、SLO 抵触時のパフォーマンス改善に対する心理的ハードルが下がり、オーナーシップを持って改善に取り組みやすくなり、組織への SLO の浸透が促進されました。
まとめ
クラシルリワード (現レシチャレ) はサービス拡大に伴い、複数の機能が混在するモノリシックな Rails アプリケーションとなり、単一 SLO では実態を正しく捉えられない課題が生じました。これを解消するために、SLO を機能単位へ分割し、New Relic Logs と ServiceLevels を活用して PATH ベースでの SLI / SLO 計測を実現しました。また、ダッシュボード化、SLO アラートの構築などを行い、運用負荷を抑えた監視体制を整えました。
この取り組みにより、SLO がサービスの実態に即した状態となり、SLO 抵触は「修正が必要な実装課題」としてチーム間で明確に認識されるようになりました。また、機能ごとに責任範囲が定まったことでトリアージの混乱が減り、SLO 改善への心理的ハードルの低下につながりました。
結果として、この 2 年間で継続的なパフォーマンス改善が可能となり、SLO 文化の組織的な浸透が促進することができました。
筆者プロフィール
高山さやか
クラシル株式会社 開発 BU バックエンドチームリーダー
2018 年に クラシル株式会社 に入社し、バックエンドエンジニアや SRE を経験。
2022 年よりクラシルリワード (現レシチャレ) の開発・DevOps・SRE チーム立ち上げなどを担当。
