Webサービスを開発・運用する上で、開発チームと運用チームの連携は、サービスの品質と安定性を保つために不可欠です。しかし、実際には「開発チームは機能追加に注力し、運用チームは日々の運用や障害対応に追われている」といった状況に陥り、両チーム間の情報共有や認識のずれが生じ、連携がスムーズにいかないケースも少なくありません。
もし、開発チームと運用チームが同じ指標を見て、同じ認識を持ってサービスの状態を議論できたらどうでしょうか？今回は、まさにそれを実現するREDメソッドという共通言語と、それがもたらす開発・運用体験の変革についてご紹介します。
共通言語の欠如による開発と運用のコミュニケーションギャップ
従来の監視では、開発チームがログやアプリケーション固有のメトリックに注目する一方、運用チームはサーバのリソース使用率（CPU、メモリ、ディスクI/Oなど）やネットワークの状態といったインフラ寄りの指標を重視する傾向がありました。
もちろん、これらの情報はそれぞれ重要ですが、開発と運用が異なる指標でサービスを評価しているため、ユーザー体験に関する共通認識が生まれにくいという問題があります。例えば「CPU使用率は正常範囲なのに、なぜかユーザーからレスポンス遅延の報告がある」「アプリケーションログにエラーは記録されていないが、一部の機能が利用できないという問題報告がある」といった状況では、両チームの間で認識のギャップが生じ、問題解決が遅れがちになります。
Request, Error, Durationという共通言語としてのREDメソッド
そこで登場するのがREDメソッドです。REDメソッドは、サービスにおける主要な3つの側面をモニタリングすることで、サービス全体の挙動を把握し、ユーザー体験のための優れた指標となります。これにより、開発チームと運用チームが共通の認識を持つための強力なツールが手に入ります。
| 指標 | 説明 |
|---|---|
| Request（リクエスト数） | サービスが受けたリクエストの数です。特定の期間におけるトラフィックの量や、ユーザーの利用状況を把握するのに役立ちます。 |
| Error（エラー数） | サービス内で発生したエラーの数です。エラーレートを監視することで、サービスの安定性を評価できます。 |
| Duration（レイテンシー/処理時間） | リクエストを処理するのにかかった時間です。ユーザーがサービスを利用する際の体感速度に直結するため、パフォーマンスの指標として非常に重要です。 |
開発チームは新機能リリース後のリクエスト数の変化やエラーの発生状況、処理時間のパフォーマンスを把握し、コードの改善に役立てられます。一方、運用チームはこれらの指標の異常を早期に検知し、障害の予兆を捉えたり、パフォーマンス劣化の原因を特定したりすることができます。
MackerelのAPMではサマリータブでリクエスト数、エラー数、レイテンシーを一目で確認できるため、REDメソッドを実践するための強力なツールとなります。
REDメソッドがもたらす具体的なメリットとMackerelの活用法
Mackerel APMではトレースをもとに HTTPサーバーのレイテンシー・エラー率・アクセス数、およびデータベースクエリのレイテンシー・実行回数が可視化されるため、REDメソッドの指標とあわせて分析することで、システム全体のボトルネックやパフォーマンスの問題を特定しやすくなります。
パフォーマンス目標設定と改善活動における共通認識
サービス全体のパフォーマンス目標をREDメソッドの指標に基づいて設定することで、両チームが同じ方向を向いて改善活動に取り組むことができます。「レイテンシーの平均を〇〇ミリ秒以内に」「エラーレートを〇〇%以下に」といった具体的な目標を共有することで、議論がスムーズに進み、効果的な改善策を実行できます。レイテンシーの平均やエラーレートはAPMのサマリータブで確認できます。
また、SLI（Service Level Indicator）やSLO（Service Level Objective）をREDメトリックの指標に基づいて設定することで、サービスの品質を定量的に評価し、改善活動の効果を測定することもできるでしょう。
問題発生時の迅速な状況把握と原因究明
サービスで問題が発生した際、両チームがREDメソッドの指標を共有することで、状況の全体像を素早く把握できます。「リクエスト数は減っていないのにエラー数が増加している」「特定のエンドポイントのレイテンシーだけが異常に長い」といった具体的な情報に基づいて、迅速な原因特定と対応が可能になります。リクエスト数の推移やエンドポイント全体のレイテンシーの平均・最大・最小・99, 95, 90パーセンタイル値はAPMのサマリータブで、特定のエンドポイントのレイテンシーはHTTPサーバータブでそれぞれ確認できます。
コミュニケーションコストの削減と効率化
これまで、異なる指標に基づいて行われていたコミュニケーションが、REDメソッドという共通の土台の上で行われるようになります。「昨日の夜からこのサービスのエラーが増えているようです」「〇〇サービスのリクエスト数が想定より少ないですね」といった会話が、具体的な数値データに基づいて行われるため、認識のずれが減り、無駄なやり取りを削減できます。
特に、データベースに起因するパフォーマンス問題は開発・運用間で議論になりがちです。Duration（レイテンシー/処理時間）に注目しデータベースタブやトレースを組み合わせることで、「特定のエンドポイントのレイテンシ悪化はデータベースクエリが原因」あるいは「クエリが遅いのではなく、アプリケーションの処理に時間がかかっている」といった事実を客観的に特定できます。
Mackerel APMでどのようにしてREDメソッドを実践するのか？
Mackerel APMでは、アプリケーションのトレースを収集し、REDメソッドの指標を自動的に計測・可視化しています。具体的には、以下のような流れとなります。
- アプリケーションからトレースを投稿する
- Mackerelのトレーシング機能やトレース投稿の概要はMackerelトレーシング機能ガイドを、各言語でのトレースの投稿方法は、インストールや実装方法を記載したヘルプを参照してください。
- トレーススパンが自動的に集計され、リクエスト数、エラー数、レイテンシーが計測される
- HTTPサーバーのリクエスト数、エラー数、レイテンシーをサマリータブのグラフやHTTPサーバータブで可視化。どのような情報が可視化されるかは、HTTPサーバーのパフォーマンスを調査するというヘルプページで解説しています。
- データベースクエリの実行回数、レイテンシーをデータベースタブで可視化。どのような情報が可視化されるかは、データベースのパフォーマンスを調査するというヘルプページで解説しています。
REDメソッドでよりよいサービスを
REDメソッドの指標は、単なる監視指標の集まりではありません。それは、開発チームと運用チームが共通の「言葉」でサービスの状態を理解し、協力してよりよいサービスを提供するための強力な基盤となります。
もし、あなたのチームで開発と運用の連携に課題を感じているなら、ぜひREDメソッドの導入を検討してみてください。Mackerelではアプリケーションのトレースを投稿していただくだけで、REDメソッドの指標を自動的に可視化することができます。開発と運用の共通言語を獲得し、よりスムーズな連携を実現しましょう。
