QRオーダー&決済の監視に New Relic を導入した
遊撃サーバーチームでサーバーサイドエンジニアの濱口です。QRオーダー & 決済チームでしたが、今月からチームが変わりました。遊撃サーバーチームでは、主に開発基盤やデータ分析基盤の整備、機能の改修、サービス運用・保守等に関わっています。とはいえ、やっていることはチームを移る以前とほとんど変わらず、やっていることに対して適切なチーム名を添えたというのが実態です。
少し前からQRオーダー&決済では New Relic を導入し、アプリケーションを監視するようになりました。今回は主に自分が担当したQRオーダー&決済の決済部分(以下、決済機能)について、導入してみてどう変わったかについてまとめようと思います。
QRオーダー&決済の決済部分の概要
決済機能は、ざっくり大きい要素だけ洗い出すと以下の図のような感じになっています。
色々なサーバーがデータをやり取りしていて、結構複雑な(実際もうちょっと複雑な)構成になっています。
もちろんゆくゆくはシステム構成自体の整理も必要ですが、とりあえず直近の課題としては、いくつものサーバーをまたぐ処理をどうやって監視するかという部分でした。網羅してシステムを精通しているスーパーマンであれば対応できなくもないのですが、全員(特に自分も含めた新しく入ったメンバーなど)が全員そういうわけにはいきませんでした。
どのシステムで何が起こって周囲のシステムにどんな影響を及ぼしているのかを可視化する必要がありました。
New Relic を導入する
導入自体はそれほど難しくありませんでした。決済機能は Ruby on Rails で作られているので、ドキュメントの手順に従って gem をインストールし、設定ファイルを追加するだけです。
ステージング、本番環境でアカウントを分けていたので、ライセンスキーの設定のみ、それぞれの環境変数に登録し参照するようにしました。インストール手順の詳細は以下で確認できます。
Ruby on Rails においては、最新バージョンのエージェントでは、ワーカーの監視や Logs in Context によるログ転送、分散トレーシングがデフォルトで有効になっています。
ただし例外はあって New Relic のデコレーションと互換性のない gem を利用していると、ログのデコレーションが行われなかったりするので注意が必要です。
決済機能では semantic_logger を利用しており、今回のケースでは New Relic での Logs in Context によるログ転送を実現する方がメリットが大きいと判断し、 semantic_logger の利用をやめました。
導入後
導入後、簡単なアラートやダッシュボードを追加することで最低限の監視を行えるようになりました。
以前までだと、システムに詳しいスーパーマンが原因を調査して、原因特定にもある程度時間がかかっていました。現在は New Relic に設定しているアラート通知やトレーシングの詳細を確認するだけで、どこでどんなエラーが発生していて周囲にどんな影響を与えているかが誰でも簡単に把握できるようになりました。またトレースと関連するログを同時に確認できるので、原因の特定も容易になりました。
まとめ
今回は New Relic を導入し、エラー検知や障害対応における運用を改善した話でした。他にも New Relic の機能を活用できるところがまだまだあると思います。今後は守りの保守・運用だけでなく、攻めの保守・運用にも活かせるように整備を進めていきたいなと思います。