New Relicの具体的な活用例
具体的にNew Relicのどの機能を活用し、先の目標の達成を目指したのか。マルペイの第一の課題は「APIのレスポンス遅延をリアルタイムで把握すること」と中川氏。この課題を解決するために活用したのが、New Relic APM（以下、APM）だ。
APMはアプリケーションの性能を可視化してモニタリングする機能である。APMの第一の特徴は導入が非常に簡単なこと。「当社ではJavaで開発しているが、一般的なフレームワークを利用していれば、仮想マシン（VM）引数にAPM Agentのパスを指定するだけで、すぐモニタリングを開始することができます」（中川氏）
第二の特徴は、アプリケーションへの性能影響を感じないこと。例えば、メモリの枯渇などによりアプリケーションの性能に影響が出た場合など、万が一の時はサーキットブレーカーの機能を搭載しており、自動的に機能が停止される。現在、決済事業者への通信はAPMを使って稼働状況を監視している。「アプリ単位でエラー率や原因がわかるため、障害調査の時間短縮が実現しました」（中川氏）
また、APMは開発時にも効果を発揮しているという。性能試験を実施したところ、他のAPIよりレスポンスが速いはずのAPIの処理に時間がかかっていることがあった。そこで細かい処理時間をAPMで見ると、新規テーブルのセレクトに時間がかかっており、インデックスの追加が漏れていることが判明した。
「今まで原因究明しようとすると、ログの確認やインフラ担当に詳細を確認してもらうなど時間がかかっていましたが、今はAPMにより可視化されたので、数分で解決することができます」（中川氏）
また、APMならエンドポイント単位でレイテンシ、エラー率、スループットなどが分かることに加え、JavaやDBアクセス、外部通信などがレイテンシに占める割合も見られるのだ。
第二の課題は、アプリケーション到達までのネットワークの監視をすること。この課題については、New Relic Synthetics（以下、Synthetics）を活用して解決。Syntheticsは、外部ネットワークからモニタリングする外形監視機能である。世界の複数のロケーションからモニタリング可能で、pingを使った単純な監視であれば追加料金もなし、スクリプトベースの複雑な監視も可能な特徴を持つ。「APMとSyntheticsを組み合わせてモニタリングすることで、問題発生時の調査スピードが向上しました」（中川氏）
第三の課題は、運用に沿って可視化すること。この課題への対応は、New Relic Dashboard（以下、Dashboard）を活用して実現した。DashboardはAPMやSyntheticsなどで取得したテレメトリーデータを可視化するための機能である。「当社では主要なAPIのレイテンシ、スループット、エラーレートなどをDashboardで可視化しています」と中川氏は言う。Dashboardは無料のベーシックユーザーでも利用可能。「ライセンスの都合でAPMを使えないエンジニアや営業担当はDashboardを見てもらっている」と中川氏は続ける。
第四の課題は、検知したものを通知すること。この課題についてはNew Relic Alert（以下、Alert）で対応。Alertは名前からも分かるとおり、APMやSyntheticsなどで取得したテレメトリーデータをもとにアラート設定するための機能だ。特徴は柔軟なアラート設定が可能なこと。エラーだけではなく、遅延の検知もできる。特定APIで○○秒以上の遅延が何分続いたら通知など、閾値オーバーの状態がある程度継続したら、通知することも可能。
さらにAPMでは、特定APIで何件以上のエラーが何分続いたら通知、Syntheticsでは外形監視でエラーが発生したら通知するなどの設定ができる。「できるだけノイズを除いた形で必要なアラートだけ通知することができるので非常に便利です」と中川氏は説明する。その上、アラート先も複数用意。「当社ではWebhookを使ってMicrosoft TeamsやOpsGenie（オンコール管理）に連携しています」（中川氏）
中川氏はさらなる具体的な活用事例も紹介。その一つが加盟店との稼働状況の即時共有である。障害を検知した場合、GMOペイメントゲートウェイのほうである程度調査を行い、加盟店にメールで連絡するという方法を採用しているが、ある程度時間がかかっていたという。またレイテンシの悪化など、サービス提供できているケースについては、連絡しないようにしていた。
その一方で加盟店からは、「何か起きているかだけでもリアルタイムに知りたい」という要望があった。そこでAlertをお客さまにわかりやすい形で提供する方法を検討した。その結果、New Relic、AWS、Statuspageを組み合わせることでリアルタイムでの通知を実現した。ちなみにStatuspageは、アトラシアンが提供するインシデントコミュニケーションツールである。「New Relicの柔軟なアラート設定やWebhook通知により、約1カ月という短期間で構築することができました」（中川氏）
もう一つの事例が、トランザクションの細分化である。外部通信処理の状況を確認する場合、ドメインごとであればAPMの外部サービス呼び出し処理で確認できるが、より詳細に同一ドメイン宛ての外部通信については、どのAPIから呼ばれているのか、リクエストパラメータの重要キー別の状況をモニタリングしたいという要望もあった。
そこでNew Relic Javaエージェントの外部APIを使用し、追加情報をレポートするUtilクラスに1行追加し、通知するようにした。「このような仕組みのため、どの組み合わせが遅いのかなどが一目でわかるようになり、障害発生時の原因特定はもちろん、キャパシティ計画時にも役立っている」と中川氏は話す。
New Relicの導入により、マルペイの稼働率は99.99％を達成、遅延に関する問題解決時間は70％以上短縮、性能関連のインシデントゼロもほぼゼロに近い状況に改善できたという。
「New Relicを導入しただけでも便利に活用できるが、機能活用をしたり、カスタマイズしたりすることでさらに利便性が上がると思います」（中川氏）
最後に梅津氏は次のようにまとめ、セッションを締めた。「New Relicは問題箇所の把握や原因特定するという単純な監視だけではなく、システムの継続的な改善や攻めのシステム運用にも活用できるので、ぜひ活用して、システムの信頼性を向上に役立ててほしいですね」
