はじめに
こんにちは、ぐるなびの APM(Application Performance Monitoring)分科会 です。
私たちは、全社的なシステム品質の向上を目指し、組織横断でオブザーバビリティ（可観測性）の導入・活用を推進しています。
昨今、「オブザーバビリティ」という言葉は広く浸透しましたが、多くの現場では依然として「リリース後の監視」や「障害調査」といった運用フェーズでの利用に留まっているのが実情ではないでしょうか。
私たちも以前はそうでした。
しかし、システムが複雑化する中、リリース後に問題に気づくスタイルでは手戻りコストが増大し、ユーザー体験を守りきることが難しくなっています。
そこで私たちが推進しているのが、「Observability Shift Left（オブザーバビリティ・シフトレフト）」 です。
コードを書く前の「設計」や開発中の「実装」フェーズから観測を組み込む。「何を守るべきか」を定義し、開発段階から計測を行うことで、リリース時には高い信頼性を担保できている状態を目指すアプローチです。
本記事では、New Relicを用い、「設計・開発・運用」の3フェーズにおいてどのようにオブザーバビリティを活用しているか、各プロダクト（FineOrder, Pro Platform, UMAME!）の実例を交えて紹介します。
目次
- はじめに
- 目次
- 第1章: 設計フェーズにおける Observability Shift Left
- 第2章: 開発フェーズにおける Observability Shift Left
- 第3章: 運用フェーズにおける Observability Shift Left
- 最後に
第1章: 設計フェーズにおける Observability Shift Left
オブザーバビリティの導入は、コードを書き始める前の「設計フェーズ」から始まります。 設計段階でサービスレベルや運用を定義することは、手戻りを最小限に抑え、堅牢なシステムを構築する上で極めて重要です。 私たちは以下の3ステップで設計を行っています。
1. CUJ (クリティカルユーザジャーニー)の定義
単にサーバやプロセスが動いていることを監視するのではなく、「ユーザーが目的を達成できているか」を起点に監視項目を設定します。
CUJとは
ユーザーがサービスを利用する上で、絶対に成功しなければならない一連のフローのことです（例：ECサイトでの商品検索→カート追加→決済完了）。
なぜ最初に決めるのか
すべてのAPIを同じ重要度で監視するのは不可能です。CUJを定義することで、メリハリのある設計が可能になります。
New Relicでの実装
Synthetic Monitoring (外形監視)を用いて実装し、ユーザー体験が損なわれていないかを常時監視します。
2. 外部依存を見越した責任分界点と防衛策
CUJが決まったら、そのジャーニーを構成するシステム要素を洗い出し、リスクヘッジを設計します。
- 依存先のパフォーマンスを前提とした設計: New Relicの External services 機能を活用し、「呼び出し元」と「呼び出し先」のパフォーマンスを分離して計測
- 現実的なタイムアウトとFail Fast: 外部サービスの応答が悪い場合は即座に切り離す (Fail Fast) 判断基準を設け過去の傾向データから、安全なタイムアウト値やサーキットブレイカーの閾値を決定
3. 非機能要件の具体化 (SLO/SLIの策定)
定義したCUJに対し、具体的な数値目標 (SLI)を設定します。Googleが提唱する「4 Golden Signals」を活用して指標を具体化します。
- レイテンシ (Latency): 平均応答時間に加え、体験の悪いユーザーを減らすために「99パーセンタイル値」も監視対象
- トラフィック (Traffic): アクセス集中 (RPS)を把握し、スパイク時の挙動を予測
- エラー (Errors): CUJの失敗率 (エラーレート)を監視し、信頼性を担保
- サチュレーション (Saturation): システムリソース（CPU、メモリ、ディスクI/Oなど）の飽和度
第2章: 開発フェーズにおける Observability Shift Left
実際にコードを書く「開発フェーズ」において、どのようにオブザーバビリティを活用しているかをご紹介します。
「Observability Shift Left」の考え方を取り入れたことで、「開発中 (インナーループ)から計測し、リリース前に問題を早期に潰す」という文化が定着しつつあります。
1. 実装フェーズ: New Relic CodeStream でボトルネックを早期に検知
IDEに「New Relic CodeStream」を導入することで、パフォーマンスを可視化しながら実装することが可能です。
導入手順
VS Code 拡張機能のインストール VS Code の拡張機能マーケットプレイスで「New Relic CodeStream」を検索しインストールします。
New Relic との連携 インストール後、サイドバーのアイコンをタップし、画面の指示に沿って New Relic のアカウントでログインします。
使用例
セットアップが完了すると、サイドバーにレスポンスタイムやエラー率が表示され、NRQLを実行することで、以下のように VS Code 上でサービス全体のメトリクスを確認することが可能です。
また、エディタ上のメソッド定義の上に、CodeLens 機能として実際のパフォーマンスデータ（平均応答時間やエラー率）がオーバーレイ表示されます。
これにより、ブラウザ上でAPMを確認する必要がなく、実装段階でボトルネックを早期に検知、修正が可能になりました。
2. 試験フェーズ: 負荷試験
実装後の試験フェーズ、特に負荷試験においては、単に「テストシナリオが通ったか」だけでなく、「システムがどこで限界を迎えるか」「高負荷時にどこがボトルネックになるか」 を正確に把握する必要があります。
私たちは以下の 3 ステップで New Relic を活用し、リリース前のパフォーマンスチューニングを実施しています。
- New Relic Dashboard の作成
負荷試験を実施する前に、まずはアプリケーションとインフラの状態をリアルタイムに俯瞰できるダッシュボードを作成します。
- アプリケーション指標: レスポンスタイム、スループット、エラー率
インフラ指標: CPU・メモリ使用率、サーバー台数（オートスケールの挙動確認）
限界性能やボトルネックの観測 準備ができたら API に実際に負荷をかけ、先ほどのダッシュボードの波形を監視します。 ここで注目するのは、「パフォーマンス劣化の予兆」 と 「最大性能（限界点）」 です。 例えば、リクエスト数（負荷）を上げていった際に、「スループットが頭打ちになったタイミング」や「エラー率が急上昇したポイント」をグラフ上で特定します。同時に CPU やメモリの推移を見ることで、「アプリのロジックが詰まっているのか、リソース不足なのか」などの切り分けが瞬時に可能になります。
Transaction Details による原因特定・修正 ダッシュボード上でパフォーマンスに問題があることが確認できたら、次は根本原因を深掘りします。New Relic の [APM] > [Transactions] > [Transaction Details] 機能を使うと、時間がかかっているトランザクションの処理内容をウォーターフォール形式で確認できるため、瞬時に問題を特定することが可能です。
このように、開発フェーズから「観測」を行うことで、既知の問題を可能な限り排除した状態で本番環境へリリースすることができます。 では、実際にリリースされた後の運用フェーズについての New Relic の活用事例を次の章で紹介します。
第3章: 運用フェーズにおける Observability Shift Left
運用フェーズにおけるオブザーバビリティの活用は、障害対応といった受動的な利用から、継続的なアプリケーションパフォーマンス最適化や自らアプリケーションの状態を知るなどの能動的な利用へとその役割を進化させます。各アプリケーションの担当者は、New Relicを「システムの健康診断ツール」として日常的に活用し、継続的な信頼性の向上を目指しています。 ここでは、運用事例を3つご紹介します。
ぐるなびFineOrderにおける運用事例
私たちは「ぐるなびFineOrder」において、New Relicを日々の予兆検知と、ユーザー体験に直結するクリティカルなパフォーマンス監視に活用しています。継続的な安定稼働を確保するため、以下の活動をルーティン化しています。
1. 予兆検知のための「日次ダッシュボードレビュー」
私たちは、障害を未然に防ぐ「予兆検知」を重視し、毎日実施する朝会でNew Relicのダッシュボードを確認しています。
- 日次モニタリング: AWS上のDBのCPU利用率や、Lambda、ECSなどのアプリケーションリソースの稼働状況を示すダッシュボードを毎朝確認
- 傾向分析: モニタリング期間を過去2週間程度のデータとして設定し、日々のリソース利用に十分な余裕があるか、また普段の傾向と異なる突発的な変動がないかをチェック
- 対応アクション: CPU利用率の継続的な上昇など、通常と異なる動きを検知した場合は、それが将来的な障害やパフォーマンス低下につながらないよう、即座に原因調査と対策を実施する体制の確立
2. リリース直後のユーザー体験を保証するパフォーマンス監視
新機能リリースや改修後の本番環境において、ユーザーに直接影響するパフォーマンス低下が発生していないかを、データに基づいて厳密に確認しています。
- SLO（サービスレベル目標）に基づく監視: ユーザーのアクセス頻度が最も高い主要なAPIに焦点を当てたSLOダッシュボード作成
- リリース後の確認: デプロイ完了後、このSLOダッシュボードを即座に確認し、SLOの値が低下していないかを検証
- 迅速な是正措置: もしSLOの達成度が基準を下回っている場合は、ユーザー体験への影響を最小限に抑えるため、原因を調査し、直ちに対策
APMを用いた原因特定と性能改善
エラー発生時や、リリース後の詳細な性能向上施策を実行する際には、APMを深く活用しています。
- エラー原因の深堀り: APMのトランザクション追跡機能を使用し、特定のエラーが発生した際のボトルネックとなっているコードや外部サービスへの呼び出しを特定し、迅速なバグ修正
- 性能改善の検証: パフォーマンス向上を目的とした施策（例：DBクエリの改善、非同期処理の導入）を実施する際、APMを使って改善前後のレスポンス時間やスループットを比較し、施策の効果を数値で検証
これらの活動により、FineOrderでは、リソースの逼迫を未然に防ぎ、リリースサイクルの健全性を保ちながら、サービス全体の信頼性の維持しています。
ぐるなびPro Platformにおける運用事例
1. 日次定例にてAWSリソースの監視およびパフォーマンス改善
アプリケーションのパフォーマンスだけではなくAWSリソースのパフォーマンス低下や高負荷の状態をすぐに特定するために活用しています。
- 日次定例で、あらかじめ作成したNew Relicのダッシュボードをチームメンバーで確認し、アラートを出すほどではないが、改善すべき箇所の特定に使用しています。
- Salesforceとのデータ連携などで高負荷がかかる時間にダッシュボードを見てLambdaがタイムアウトしないかなどを監視しています。
- 一定の閾値を超えるとSlack通知するように設定しているので、日常的な監視と緊急時の対応を両立しています。
2. デプロイ前後のパフォーマンス監視
本番へのリリース前後でのパフォーマンスを計測し重大なシステム影響が起きる前に気づけるように日々確認を行っています。
- Change Trackingを使用し、デプロイのタイミングがAPMダッシュボードに出るように設定し、リリースの前後でパフォーマンスに違いがあるかを確認
- 日次定例で、APMダッシュボードを日々確認し、デプロイとは関係なくアプリケーションパフォーマンスが低下していないかを毎日確認
これらの活動を通じて、ぐるなびPro Platformはサービスの信頼性を高めると同時に、継続的な運用効率の向上を実現しています。
UMAME!における運用事例
私たちは現在、AIを活用した飲食店検索アプリ「UMAME!（プレビュー版）」を運用しており、機能改善やバグ修正を含むリリースを週1回というペースで実施しています。 運用フェーズにおけるオブザーバビリティの役割は、単なる「監視（Monitoring）」ではありません。「現状を正しく把握し、次のアクション（開発・設計）へフィードバックするサイクルを回すこと」です。私たちは以下の3つのアプローチでこれを実践しています。
1. 全チーム参加の「週次ダッシュボードレビュー」
週に一度、エンジニアだけでなく、PMやデザイナーを含むアプリに関わる全チームで New Relic のダッシュボードを見る時間を設けています。 「なんとなく重い気がする」といった感覚的な話ではなく、データに基づいて現状を把握するためです。
このレビュー会では、主に以下の観点でディスカッションを行います。
ボトルネックの特定と要件の再確認
「どこの処理で時間がかかっているか」を特定します。 重要なのは「その遅延は許容範囲内か？」という視点です。例えば、AIの回答生成に時間がかかっている場合、それが技術的なボトルネックなのか、それともUXとして許容できる（機能要件を満たしている）範囲なのかを議論します。 もし許容できない場合は、「処理を高速化する」のか、それとも「UIで待機体験を向上させる」のか、あるいは「機能を削る」のか、具体的な対策を決定します。
外部依存と内部処理の切り分け
遅延やエラーの原因が「自社APIの内部処理」なのか、それとも「外部API（AIモデルや地図情報など）」に起因するものなのかを明確にします。これにより、自分たちで修正すべきか、プロバイダのステータスを確認すべきかが即座に判断できます。
2. 未知のエラー検知と PagerDuty 連携による即応体制
リリース直後のプレビュー版や新機能には、「未知のエラー」がつきものです。これらを早期に発見し解決するために、New Relic の Errors Inbox を活用しています。
未知のエラーの検知
ログを漁るのではなく、Errors Inbox でグルーピングされたエラー詳細を確認することで、どのユーザーに、どの頻度で、どのようなスタックトレースのエラーが発生しているかを一目で把握できます。 また、発生している 5xx エラーや 4xx エラーをそれぞれ確認できるので、本当に正しい意味で返されているかも検討できます。例えば、5xxのエラーが出ているが、元来APIでは入力として想定されていないものであったなら、それは4xxのエラーとして捌き、アプリ側でのハンドリングで対応というようにできます。
PagerDuty との連携
第1章で定義した CUJ（クリティカルユーザジャーニー）に関わる致命的なエラーが発生した場合は、PagerDuty と連携して開発担当者に即座に通知が飛びます。 逆に言えば、CUJに影響しない軽微なエラーで深夜に叩き起こされることはありません。これにより、開発者は燃え尽きることなく、健全な精神状態で運用を続けることができます。
3. 設計（SLI/SLO）へのフィードバックループ
運用フェーズで最も重要なのが、「設計へのフィードバック」です。 第1章で設計した SLI/SLO（サービスレベル目標）の設定値が妥当だったかを、実運用データと照らし合わせて検証します。
エラーバジェットに基づく意思決定
SLOを達成しエラーバジェット（許容できるエラーの余裕）が残っているなら、「新機能の追加（Go）」に舵を切ります。 逆にエラーバジェットを使い果たしているなら、新規開発を止め、「信頼性向上やリファクタリング（Stop）」に注力します。
このように、「Observability Shift Left」の考えに基づき、設計段階から CUJ や SLI/SLO を定義していたからこそ、運用フェーズにおいて「感覚」ではなく「数値」に基づいた、ビジネスインパクトのある意思決定が可能になりました。
最後に
監視から「文化」へ
本記事では、設計から運用まで一貫してオブザーバビリティを活用する「Observability Shift Left」の取り組みをご紹介しました。
- 設計フェーズ： CUJとSLOを定義し、「何を守るか」を明確にする
- 開発フェーズ： IDEや負荷試験で計測し、リリース前にボトルネックを潰す
- 運用フェーズ： データを基に次のアクション（開発・設計）へフィードバックする
このサイクルを回すことで、オブザーバビリティは単なる「健康診断ツール」から、エンジニアが自信を持ってリリースし、ビジネス価値を最大化するための「羅針盤」へと進化します。
ツールを導入するだけではなく、「数値に基づいて会話する」「設計段階から計測を意識する」というエンジニアリング文化を定着させることこそが、Shift Leftの本質です。
この記事が、皆様のチームにおけるオブザーバビリティ活用のヒントとなり、より堅牢でユーザー体験の優れたサービス作り一助となれば幸いです。
