Powered by

PGマルチペイメントサービスのこれまでとこれから(前半)【DevelopersNight #24】

article-037_top.jpg

2021年6月15日に開催しました 「Developers Night #24 キャッシュレス決済サービス 開発者が語るサービスの裏側」のSession1「PGマルチペイメントサービスのこれまでとこれから(前半)」をお届けします。

動画はこちららかご覧いただけます:https://youtu.be/zaxuGVz0NnY

マルチペイメントサービス部 部長 鈴木
2012年GMO-PG入社
2012年7月から1年及び2016年10月から現在まで、「PGマルチペイメントサービス」を担当

article-037_thumb01.jpg

今回サービスの裏側ということで、なるべくお見せできる範囲でお話できればと思っています。
まず、「PGマルチペイメントサービス」についてです。ご覧頂いている方の中には、実際に接続された方もいらっしゃると思いますが、簡単にサービスの説明をさせていただきます。

article-037_thumb02.jpg

社内では通称「マルペイ」と呼んでいます。10年以上前からマルペイ、マルペイと呼んでいます。
社内では一般用語なのですが、私が10年前に入社して初めて聞いた時は、NTTデータさんの「マルチペイメントネットワーク」の話だと勘違いしていました。Googleで検索してみてもほとんどが、「マルチペイメントネットワーク」「MPN」の話ばかり出てきます。Googleの候補で「GMO」と出てくるので、それを付けて検索すると、私たちの「PGマルチペイメントサービス」の紹介ページがでます。そちらをご覧いただければと思います。

article-037_thumb03.jpg

弊社の「マルペイ」の詳細はこちらのURLの紹介ムービーを見ていただくと、概要が分かると思います。
既にマルペイを使われているお客様については、下段のほうに最近リニューアルしてより使いやすくなった「FAQサイト」がありますのでご覧ください。

article-037_thumb04.jpg

ここからサービスの概要ですが、「PGマルチペイメントサービス」を使うと、こんな良いことがありますよ、という内容です。
皆さんがオンラインショッピングのお店を開こうと思ったときに、当然クレジットカード払いや、コンビニ払いをできるようにしたいとお考えになると思いますが、その際、クレジットカード会社と直接契約される方はほとんどおらず、我々のような決済代行サービスを使うと思います。そのような時、我々を使うと便利ですよ。こんな良いことがありますよ。という内容になっています。

article-037_thumb05.jpg

実際の規模感などをお話します。
まず我々のサービス、「PGマルチペイメントサービス」で今稼働しているショップさんの数は「約15万店舗」と公開されています(2021年3月末時点)。これが多いのか少ないのか、よくわからないと思いますが、少なくとも私が入社した10年ほど前は、数万~3万(店舗)でした。10年間でここまで増えました。

article-037_thumb06.jpg

流通金額です。 1日あたり、我々の「PGマルチペイメントサービス」を通過するお金の量は約100億円。(2021年1-3月分より算出)
これも大きすぎてピンと来ないと思うのですが、参考までに、直近の楽天市場さんの決算の数字を見ると、大体この数字より少々多いぐらいでした。
なので、楽天市場よりすこし少ないぐらいの感覚でご理解いただければと思います。

article-037_thumb07.jpg

決済件数。これも多いか少ないかは置いておいて、オンラインや、リアルタイムでの決済件数というより、バッチでの一括処理のようなものを含んだ件数になっています。先程の金額100億円と比べると、最近の傾向としては、決済の単価が結構下がっていることもあり、金額の伸びより決済件数の伸びというのが顕著です。

article-037_thumb08.jpg

続いて、これは我々のシステムで受けるオンライン・WEBのリクエスト数です。1日で3,000万件です(2021年6月実績)。我々も毎月統計を取っていますが、基本的には毎月伸び続けています。前月比でも、常に増え続けているというのは特徴かなと思います。

article-037_thumb09.jpg

続いて、我々のサービスの特徴の1つである、決済手段の話をさせていただきます。「PGマルチペイメントサービス」の売りの1つとして、決済手段のラインアップの豊富さというのがあります。現在約50のラインアップになっています。この50というのが、システム、アプリケーション内で採番しているコードの数です。
お恥ずかしながら、開始当初はここまで増えるとは思っていなかったので、「1バイト」で定義していました。そのため1からはじまり数字は使い切り、大文字アルファベットも全部使い切って、現在小文字のアルファベットの、「O」まで来ています。もう少しで無くなってしまうというところが最近の悩みです。
当然ここまで増えると思っていなかったので、様々なシステムの手当てをしています。

article-037_thumb10.jpg

更に、こちらの数字については、外部に公開しているAPIのエンドポイントの数です。実際使われていないものも含まれていますし、重複しているものも含めていますが、ざっと計算してみたところ、このぐらいでした。

ここからはもう少し裏側の話をさせていただきます。

article-037_thumb11.jpg

エンジニアの方が多く参加されていると思うので、まずシステム構成のお話です。

現状、我々のサービスは右側にあるように、モノリシックなアプリケーションと、マイクロがあり、移行期間中です。
こちらについては、GMO Developers Night #17で、弊社の佐久間から細かく話がありましたので、当時の動画アーカイブ書き起こしを見ていただければと思います。
現状、決済手段50というのをお伝えしましたけれど、その内15ぐらいがマイクロに移行済みというところです。まだ移行中です。

article-037_thumb12.jpg

ここからは質問形式で進めます。まず、「いつからこのマルチペイメントやっていますか?」という話ですが、今回資料を探し調べてみたところ、2002年ぐらいからは、すでに原型があり、約20年前に誕生していました。
当時は、今のようなインターネット上で幅広く皆さんに使っていただくようなWebサービスというよりかは、クレジットカード会社様と組んで、カード会社様が加盟店様に展開するサービスをOEMで提供するということが多かったようです。
その後、2006年ぐらいからは、今の「PGマルチペイメントサービス」の前身のサービスが誕生し始めています。「PGカード」と言われているものです。こちらは、昨年無事サンセット(サービス終了)し約15年の幕を閉じました。

ちょっと大きなイベントがあったところだけオレンジ色にしているので、そこだけ簡単に紹介します。まず2008年に初めて登場しました。初めて「PGマルチペイメントサービス」という名前で、プレスリリース等も出されており実際動き出しています。当時はシステム的には、PGカードと相乗りだったという話も聞いております。
2013年、5年後に初めて大型の更改をしました。その後、2014年、16年、18年、この矢印を上向きにしているのは、取扱量が増えているのをイメージしているんですけれども、本当に爆発的に利用者が増え始めました。

2016年、これは本当に大変申し訳ない話で、私が着任してすぐに、大規模な障害があったので2時間ぐらい停止してしまいました。非常に苦い思い出で、ここからいろいろ対策や改善を繰り返しながら2019年、2年前ようやく大型更改2回目をやりまして、先ほどのマイクロ化とか増強っていうのをしています。

昨年にコロナが起きたわけなんですけれども、皆さんご存じの様に、巣ごもり需要で非常にインターネット上でのお買い物が増えたということがありましたが、「PGマルチペイメントサービス」自体は、それに負けず、処理をさばくことができました。一部ネットワークまわりで、ご迷惑をおかけしたことはありましたが、「PGマルチペイメントサービス」のアプリケーションそのものは、全く問題なく動いていました。

article-037_thumb13.jpg

参考までに2002年、誕生当時のAPIの仕様書があったので、ちょっと見てみたのですけれども、こちらが当時のURLになっていますね。SSLじゃなかったり、謎な「ohayou」っていうのが入っていたり、時代を感じさせるものですし、逆に「EntryTran」って、今もご存じの方はご存じだと思うんですけれども、「PGマルチペイメントサービス」のすごく一般的な取引登録のAPIなんですけれども、当時からこのまま使われていたということになっています。

ちなみに、現状は「EntryTran.idPass」という拡張子のAPIを用意、展開しているのですけれども、このidPassという拡張子については、ごめんなさい、私もよく分からない。社内で聞いても、IDとパスワードが使われるのでそれじゃないかという感じでしたね。われわれの造語です。一般用語じゃなくて、完全にGMOペイメントゲートウェイがつくった、付けたもの、となっています。

article-037_thumb14.jpg

ここからはもうちょっと踏み込んだ話ができればなと思って、「実際何人ぐらいで運用しているんですか」という話です。大体これが「PGマルチペイメントサービス」の開発運用に関わるメンバーの構成比率ですね。
マネージャー職がいて、開発も運用もする人、それから開発を協力いただいている企業様の方、それからQA担当の方、運用される方、インフラの方という感じの割り振りになっています。30人強で全部ですね。主に運用も含めて関わって頂けている方。更に、開発だけに限ると27人くらい。更に、主に社員でやっているのは18人ぐらい。ここが、内製でやっている人数ですね。大体このぐらいの人数で回しているというところになります。これが多いか少ないかというと、私もここではコメントできないんですけれども、少なくとも私が入った10年前は5人でしたが今は18人に増えてきたところですね。

article-037_thumb15.jpg

実際この18人でどういった見守り方をしているかというところについてご紹介したいと思います。いろんな観点から、監視の仕組み、検知の仕組みは仕込んでいまして、大きく4つです。上から順に説明すると、「Sql to Mail」というもの、それから2段目が「Log File Monitor」。一般用語っぽく書いていますが、実は完全に我々の自社で独自につくったものでして、独自の名前です。ここは完全にオリジナルのものを作りこんで動かしています。

それから、2年前ぐらいから「APMツール」として、New Relicさんの、性能の部分を見られるツールを導入しています。
最後「SIEM」として、ログを分析するようなプラットフォームも準備して、各々からメール、WEBフック、電話も含めて、何らかの異常検知をして、あらゆる観点で見て、あらゆるところから通知がくるような仕組みをつくっております。

article-037_thumb16.jpg

私の個人的な思いもあるのですけれども、決済手段数50・1日あたり100億円飛ぶシステムなので、当然、見逃しちゃいけないものとか、きちんと見なきゃいけないものっていうのは多いです。その中でも、うまく回すための仕組みとして、特定の人にアラーム対応が偏らないように、なるべく当番制をして回すこと。あとは、きちんとナレッジを蓄積して、場合によっては、アラートのメールそのものに対応手順のコンフルエンス(ワークスペースツール)のURLが付いたものを送ってしまうとか、という形で、誰でも対応できるような形をとっていければといいかなと思っています。

最後はやっぱり結局何か障害につながるときは、本当に細部の部分がきれいにすり抜けていったときに、最終的にご迷惑をおかけしてしまうという。こういう細かいところを見逃すと、1カ月後2カ月後に何かが起きてしまう、というのは経験上あるので、精神論にはなってしまうんですが、細部までこだわって検知の仕組みであったり、検知後の対応というのはしていくというところに気を付けております。

ということでいったん私のほうから、前半部分のお話は以上とさせて頂きます。

ありがとうございました。

後半はこちら

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。

SSL GMOグローバルサインのサイトシール