複雑化するシステムの監視に欠かせないオブザーバビリティ
「複雑に連携したシステムが把握しきれず、課題感を持っている」「さまざまなツールを導入しているものの、個別に確認せねばならず調査に時間がかかっている」「システムの監視は十分にできているが、改善できるポイントを知りたい」と思っている方には「ぜひ、聞いてほしい」と前置きし、梅津氏のセッションは始まった。
ようやく収まりつつあるものの、新型コロナウイルス感染症の拡大は、私たちの生活スタイルを大きく変えた。買い物もその一つ。コロナ禍では、リアル店舗に足を運ぶことは少なくなり、多くの人がECサイトを活用して買い物をしていた。需要が増したECサイトでは、ユーザーの満足度向上を図るため、多様な決済方法への対応を進めている。そこで多くのECサイトが活用しているのが決済代行サービスである。決済代行サービスを活用するとセキュリティも担保され、情報漏えいのリスクも大幅に軽減できるからだ。
その一方で、障害が発生した場合は、自社サービス側の問題なのか、連携先の一つである決済サービス側の問題なのか、切り分けが必要になる。「ECサイトの停止は大きな機会損失になる。そのため決済代行システムでトラブルが発生した際には、利用しているECサイト側でその状況を把握できる仕組みが必要になります」（梅津氏）
しかもECサイト側の社内のシステムがマイクロサービス化し、さまざまな外部サービスと連携するなど複雑化していると、通知されたアラートがユーザーにどんな影響を与えているか、正確に把握するのは難しい。
「こういう状況だと監視している意味が薄れます。では、どうすれば解決するのか。システムの全容をリアルタイムに把握し、改善できる状況にすること。つまりオブザーバビリティが必要です」と梅津氏は話す。
New Relicは本社のある米国を中心に、オブサービリティプラットフォームを提供しているITベンダーである。日本法人では日本のお客さま向けに営業および技術サポートを提供。梅津氏は前職のインフラエンジニアの経験をもとに、New Relicではリテール系を中心に、さまざまなお客さま向けに技術的な導入支援を担当している。「国内では600社以上の企業がNew Relicを活用しています」（梅津氏）
導入企業ではNew Relicを活用し、どのようにオブザーバビリティを実現しているのか。その事例として登壇したのが、日々膨大な決済処理システムを品質高く運用しているGMOペイメントゲートウェイの中川氏である。
年間決済処理金額13兆円超のGMOペイメントゲートウェイが抱えていた課題
GMOペイメントゲートウェイは、加盟店と各決済会社との契約、決済情報、お金のやり取りをつなぐプラットフォームとしての役割を担っている。「GMOペイメントゲートウェイや連結会社で提供しているサービスは、EC事業者や自治体など2023年3月現在約16万の加盟店で利用されています」と中川氏。
そのため、同社連結の2022年4月から2023年3月までの年間処理件数は55.3億件、年間決済処理金額にすると13兆円にも上るという。ちなみに同社連結の10年前の年間決済処理金額は約1兆円。したがってGMOペイメントゲートウェイはこの10年間で約13倍に急成長した企業なのだ。
中川氏はGMOペイメントゲートウェイに2016年に新卒で入社した。以来、オンライン総合決済サービス「PGマルチペイメントサービス」の開発・運用を担当。昨年、子どもを出産。今年5月に産前産後休業、育児休業を経て復帰してからは、QAエンジニアとして品質改善業務に取り組んでいる。
「決済サービスはますます品質が求められるようになっている。私たちはそれに応えるため、より迅速かつ効率的にモニタリングできる仕組みを構築する必要がありました」と中川氏は語る。そこで2019年6月、PGマルチペイメントサービス（以下、マルペイ）の大規模な更改をすることになった。
現在、マルペイはクレジットカード決済はもちろん、コンビニ決済やスマホ決済など30種類以上の決済手段を提供している。加盟店がマルペイを活用するメリットは、決済事業者ごとにシステムを構築したり、入金サイクルや売上金額などを把握したりする必要がなくなること。決済部分をすべて一元管理できるようになることに加え、契約も一本化され決済の締め日や入金日の統一、入出金管理の手間も削減されるからだ。
「従来、マルペイのシステムは1つのアプリにさまざまな決済手段の機能を集約していたため、一つの不具合が全体に波及したり、開発に時間がかかったりなど、課題がありました。2019年6月に行ったシステム更改において、5年後の取引量に耐えられることやこれらの課題を解決する事を目標に、決済手段ごとに細分化してマイクロサービス化を実施しました。」（中川氏）
この更改によりオンラインサーバーは3台から26台、オンラインアプリは3個から60個に急増した。これまで自力でモニタリングしていたが、マイクロサービスごとに性能面でよりプロアクティブに監視をすることが必要不可欠になった。
そこで2019年9月、マルペイを構成するマイクロサービス全体の稼働状況を可視化するため、New Relicを導入した。「稼働率99.999％以上、性能に関する問題解決時間50％以上短縮、性能関連のインシデントゼロの目標達成を目指し、運用を開始しました」（中川氏）
さらに2023年からはマルペイ以外のサービスにも順次展開しており、「結果的に当社全体のサービスレベルの維持につながっている」と中川氏は満足そうに話す。
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は問題箇所の把握や原因特定するという単純な監視だけではなく、システムの継続的な改善や攻めのシステム運用にも活用できるので、ぜひ活用して、システムの信頼性を向上に役立ててほしいですね」
