New Relic Advent Calendar 2022の23日目の記事です。
NTTドコモでRAFTELという名のサービス共通API基盤を開発・運用するチームに配属になった新入社員の田中と申します。
一部界隈で有名人の先輩が今年3月に「Observability Conference 2022」で発表した内容があり、本記事はその続きのエピソードになります。
先日、社内で大型イベントが行われ、RAFTELも関与することになりました。
そこで、イベントの運用監視にNew RelicのAPMダッシュボードが役に立ったというお話を書きたいと思います。
RAFTEL（サービス共通API基盤）とは
RAFTELについて既にご存知の方もいらっしゃるかと思いますが、簡単にご紹介します。
自社では金融・エンタメ等様々なサービスを展開しています。
昨今のビジネス環境の大きな変化に対応するためには、サービス開発をより早く安くすることが重要です。
そのために立ち上がったのがサービス共通API基盤であるRAFTELです。
今までは、
- 各関連部署への申請
- フォーマットが異なる仕様書
- 複数の基盤接続に比例して開発工程の増加
- 社内基盤がAPI更新をするたびに改修
をサービスごとに対応していたため、時間もコストもかかっていました。
まぁ......とにかくめんどくさい。
一方で、RAFTELが誕生してからは、
- 複数の社内基盤を利用しても申請が一本
- 仕様書の統一
- サービスが共通して利用する機能をマッシュアップAPIで提供
- 社内基盤のAPI更新はサービス共通API基盤が吸収
と、サービスの接続先が一つになったことで、社内基盤を効率よく活用できるようになりました！
一大イベントがあるってよ
先日、とあるサービスで大規模なイベントを開催するという話があり、イベントの一員としてRAFTELも参加してその準備から運用まで携わってきました。
イベントを成功させるためには、数多くある社内のシステムが協力しながらイベントを運営する必要があります。
ここで一旦昔話をしましょう。
数年前のイベント運用体制について社内で確認したところ、イベント中に関連部署が個別に連絡を取り合い、「今あなたのシステムは大丈夫？」と定性的な確認をしていたようです。
このようなアナログな方法では情報共有に時間を費やしてしまったり、解釈の違いが生じてしまったりするので、トラブル時の初動が遅れてしまう可能性があります。
近年オブザーバビリティの重要性が高まっていることもあり、今回はイベント管理者から「全システムの運用状況をまとめて監視できるようにしたい」との要望がありました。
RAFTELではNew Relicを導入していますので、作成したダッシュボードはURLを共有したり、無料のBasicユーザーを作成したりすると社内に公開できます。それにより異なる部署ともリアルタイムで情報共有が可能となっています。
今回はイベント専用のダッシュボードをささっと作成して提供しました！
まず、こちらが複数のサービスそれぞれに共有するために作成したダッシュボードです。
以下3つのNRQLを1つのグラフで表現した後、グラフのURLを直接サービス側に提供することでNew Relicのアカウントを発行しなくても参照できる仕組みを利用しました。
- １：サービスごとのトラヒックを表示するNRQL
- SELECT rate(count(*),1 second) from Transaction WHERE appName = [利用API名] and c.servicerinfo = [利用サービス] TIMESERIES MAX EXTRAPOLATE
- ２：閾値を表示するNRQL
- SELECT [閾値] as ‘閾値（tps）’ FROM Transaction TIMESERIES
- ３：閾値の8割線を表示するNRQL
- SELECT [閾値 * 0.8] as ‘閾値８割（tps）’ FROM Transaction TIMESERIES
次にRAFTEL担当用に作成したダッシュボードが以下のものです。
サービスごとに作成したダッシュボードを1つのダッシュボードで確認できるように視認性をアップさせています。
イベント当日
イベント当日は、各サービスや社内基盤が問題なく稼働しているのかをイベント管理者を中心に監視しました。
RAFTELが接続している社内基盤はオンプレミスのため、リクエストを処理できる上限値が決まっています。
したがって、リクエスト超過の予兆が見られる場合には一部の機能を抑止するなどの対処をし、社内基盤がダウンしないようにする必要があります。
RAFTELチームもダッシュボードを活用し、トラフィックの急増が予想される時間帯でも各サービスの状況をリアルタイムで比較しながら監視しました。
今回、リクエスト超過の予兆検知は上限値の8割を基準値に設定し、これに近づいているかどうかを5分周期で視認＆イベント管理者へ情報共有しました。
事前にRAFTELチームが見ているグラフと同じものをイベント管理者へ提供していたことで、認識齟齬もなくスムーズに情報を共有できました。
イベント自体は上限値の8割線に対しても余裕があり、無事終了を迎えることができホッとしました。
（すばらしい試合でした！
）
まとめ＆今後の改善
以前、先輩が発表した利用者へオブザーバビリティを提供する話は、利用者がAPI単位で現状を確認できるものでした。
今回再びNew Relicのダッシュボードを活用して利用者にオブザーバビリティを提供、ならびにイベント管理者とRAFTELチームが同じダッシュボードを見ながらリアルタイムで情報を共有できたことで、スムーズなイベント運営を実現できました！
上記のイベント専用ダッシュボードを作成したように、将来的には接続先のサービスごとにダッシュボードを提供することで、RAFTEL利用者達が自分のシステムに対する影響をひと目で確認できるようにし、RAFTEL利用者に対するオブザーバビリティをさらに向上させたいと思っています。
ただ…RAFTELを利用するサービスがますます多くなってきているので、サービスごとにダッシュボードを作成するのは骨が折れるなぁと悩んでいます。
理想としては、ダッシュボードを確認する人が各自でサービス名を選ぶ（NRQL変更ではなくフォーム入力やリストから選択みたいなものを想定）、というのができるようになるといいなぁなんて思っていますが、New Relicさん！いかがでしょうか？
New Relicの更なる進化を期待し、こちらで以上です！