2021年6月15日に開催しました 「Developers Night #24 キャッシュレス決済サービス 開発者が語るサービスの裏側」のSession２「年間3,000億円超送金するシステムをサービス停止なしでシステム更改した話」をお届けします。
▶動画はこちららかご覧いただけます：https://youtu.be/o3Tm4aBbu68
話者紹介
GMOペイメントゲートウェイ 送金サービス室 担当課長 数矢
入社約7年。内5年ほど送金システムを、加盟店様が増え始めたあたりから担当。
GMOペイメントゲートウェイ 送金サービス室 主任 長沢
新卒入社5年目。エンジニアとして自社の送金サービスパッケージの開発や保守を担当して2年目。
アジェンダ
長沢 皆様はじめまして。GMOペイメントゲートウェイの長沢と申します。私からは準備期間1年ほどかけまして今年の2月にリリースを実施しました送金システム更改について、お話させていただきます。
アジェンダは、大きく2つとなります。まずは送金サービスについてということで、どのような背景でリリースされたのか、また中身はどういったものなのかを、ご説明させていただきます。2つ目はシステムについて、旧システム構成の課題、それに対しての現システム構成、また没構成案であったり、システム更改時の工夫などについてお話できればと思っております。
サービスについて
送金サービスとは
長沢 ではまずサービスについてご説明します。まず送金サービスとはどういったものか。こちら言葉そのままとなってしまいますが、サービスの利用者様に対して返金、送金などの業務を代行する仕組みになります。メジャーなご利用ケースとしてはこちらに絵を貼っておりますが、 ECサイトでの返金、フリマアプリ出品者への送金、チケットの払い戻し、クラウドソーシングの報酬支払い、あとはキャンペーンでのキャシュバック等になります。
特にコロナ発生当初は、世間ではイベント・ライブの中止や延期で各企業様がチケットの払い戻しの対応をされていたことが印象にあるかと思いますが、そういった送金・返金のケースで、「GMO-PG送金サービス」をご利用いただけます。
GMO-PG送金サービスの特徴
長沢 続きまして、「GMO-PG送金サービス」の特徴についてご紹介させていただきます。
このサービスの生い立ちは、もともとセッション1で登場していた「PGマルチペイメントサービス」の返金機能として誕生し、そこから「PGマルチペイメントサービス」を利用していない企業様にもご活用いただけるよう1つのパッケージとなったと聞いております。
そんなGMO-PG送金サービスの特徴ですが、
1点目、ニーズの高い送金手段をご用意しております。口座振り込みの送金はもちろん、コンビニのセブン-イレブンに設置されているATMからお金を受け取れる方法であったり、Amazonアカウントに対する形で受け取る方法もご用意しております。ですので、若年層で銀行口座を持っていない方々に対しての返金・送金も可能になっております。
2点目ですが、サービス提供会社様が送金先の口座情報を保持する必要がございません。一度口座情報を弊社サービスにご登録いただけば、その口座情報に紐づくIDを発行することで、以降はIDでの送金依頼を出すことができます。また送金先である利用者様に我々が提供している専用画面がありますので、そこから利用者様に口座情報をご入力いただき送金依頼を出すといった方法もあります。
3点目としては、入金依頼をしたその日中に口座への入金が可能となっております。
どんなサービス？
長沢 少し回りくどい説明になってしまいましたが、絵にするとこのような形のシンプルなサービスとなっております。左上が送金を実施したい企業様、右上が金融機関、右下に送金先のユーザー様がいます。送金を実施したい企業様と金融機関との間に弊社のサービスがあるといったような形になっております。
サービスの利用の流れとしましては、まず左の企業様より原資のお振り込みを実施いただきます。その後、原資の金額の中で送金依頼を実施いただきます。リクエストの方法としてはSFTPでのファイル連携、あとはAPI/管理画面を用意しております。いただいた送金依頼を弊社サービスでとりまとめて、各金融機関へ入金いたします。
また前のページで少しお話した、企業様にて送金先の口座情報を保持せずユーザー様に専用画面からご登録いただく場合は、左の企業様から依頼をいただくときにユーザー様のメールアドレスをご連携いただき、弊社サービスから右下のユーザー様へメールで専用画面へのURLをご案内するといった形になります。
ユーザー様にはメール記載のURLからアクセスいただいて、口座情報などの送金情報をご入力いただきます。入力完了しましたら先ほど同様、弊社サービスで送金依頼を取りまとめ、各金融機関へ連携いたします。メール以外にも企業様画面ページから専用画面へ遷移するといったような方法もございます。
サービスの効果
長沢 サービスの効果につきましては、ユーザー様としては生活スタイルに合わせてお金の受け取り方法を選択することができます。例えば口座を持っている・持っていないですとか、すぐに手元にお金が欲しいですとか、外出の予定がある、コンビニが近い・遠いなど、自分の環境や生活に合った方法でお金を受け取ることができます。
また企業様としては、コストダウンとリードタイムの短縮という効果が見込めます。コストダウンの仕組みとしては 同行間の送金は手数料が安くなるという仕組みを利用しております。同行間というのは、送金元口座と送金先口座の金融機関が同じということです。銀行Aの口座から銀行Bの口座へ送金するよりも、銀行Aの口座から銀行Aの別の口座へ送金する方が手数料が安くなるということです。
弊社は複数の銀行と直接接続しており、送金先の口座に応じて送金元口座を使い分けておりますので、同行間によるコストダウンを実現しております。
以上がサービスの説明となります。
システムについて
長沢 続いてシステムについてご説明いたします。
全体の構成（更改前）
こちらが以前のシステム構成になります。オンプレで稼働しております。前方にロードバランサ、リバースプロキシがあって、その後ろにいろいろアプリがいる、一般的な構成になるかと思います。DBはOracleです。ハードウェアの保守期間の終了を迎えることから、新サーバーへ移行を実施することは決まっていたのですが、この構成には他にもいくつか課題があり併せて解決しようということになりました。
なぜ更改？
長沢 課題についてお話します。
先ほど申し上げた通りハードウェア更改は必須でしたが、その他の改善点としまして、
まず1点目。ゲストにアプリが集中しすぎているということがありました。管理画面、バッチ、ユーザー用の専用画面、一部APIが同じゲストに密集しており、まとまりがありませんでした。名称としては「管理画面ゲスト」なのですが、管理画面以外のアプリも複数入っておりプロジェクト新規参入者は少し戸惑うといったような場面もありました。
2点目としては、バッチのジョブをcronで管理しているということで、ジョブのつながりやリランなどの運用保守性を考えると、cron管理にはちょっと限界を感じていました。
3点目ですが、送金手段ごとにアプリを分離できていないということで、当時はまだ口座振り込み以外の送金手段がセブン銀行の「ATM受取」しかなかったのでが、それぞれ銀行APIと、その他送金手段APIという形で構成していて、新しい送金手段追加があった場合はその他送金手段APIの方にどんどん追加していくようなイメージの構成にしていました。
ですが、例えば何らかの障害で送金手段Aが使えなくなってしまった場合に、使えるはずの送金手段Bまで使えなくなってしまうと、障害発生時の影響範囲が大きくなってしまう可能性がありました。
以上が課題になります。
全体の構成（更改後）
長沢 それに対し、こちらが現在のシステム構成になります。変わらずオンプレで稼動していて、ロードバランサ―、リバースプロキシの後ろにアプリ群がいて、DBがOracleというところも変わっておりません。
1つずつ課題への対応をご紹介したいと思います。ゲストについては「銀行振り込み用」、「その他送金手段用」、「管理画面用」、「ユーザーアクセス画面用」、「内部用」というふうに、直感的に分かりやすいような、用途によって分けました。
ジョブ管理についてはcronをやめて、ジョブ管理システムのソフトウェアを利用することに変更しました。改めて運用が変わって、実行状況のステータスが把握しやすい点でしたり、リランがしやすいといった点で、素晴らしいと感じております。
アプリのモダン化につきましては送金手段単位でマイクロサービス化し、障害発生時の影響範囲を限定化できるような構成にしております。また同じ処理が各アプリ、各メソッドに点在していたりしたので、1メソッドに共通化したり役割が大きい処理についてはそれ自体を1つの機能として切り出してしまい、httpsリクエストで呼び出すようなつくりに変えております。
さらにユーザー様がアクセスする画面については、同時間帯にユーザーアクセスが集中し、一気にネットワーク帯域が枯渇するという可能性もありました。そのため静的コンテンツはCDNを活用し、負荷削減できるような構成にしました。具体的にはAWSのクラウドフロント経由でS3上に配置した静的コンテンツにアクセスするようにしております。
ただ同様の仕組みで障害が発生したというニュースもありますので、そこについては監視含めどのように対応するのがよいかというところは検討中です。
以上が更改後の構成の話になります。
全体の構成（並行稼働期間）
長沢 続いてシステム更改時の工夫の話になります。
オンラインについては更改時にいきなりすべての処理を新アプリで処理するのではなく、1週間ほど旧アプリと新アプリの並行稼働期間を設けておりました。一度新アプリでリクエストを受け取るのですけれども、旧アプリで処理するか新アプリで処理するかを振り分けられる仕組みを実装し、旧アプリで処理する場合は新アプリからそのまま旧アプリへリクエストを流して処理するという仕組みにしました。
その結果、少しずつ取引を新アプリの方で処理することができましたので、リスクを抑えながらのリリースができたとは思っております。
またテスト時の話になりますが、業務シナリオを作成し、社内テスト環境で実際のスケジュール通り2カ月回していたことが品質をあげる上でよかったと思います。
切り替え作業について付け加えますと、ハードウェア更改がありましたので内部のVIPの付け替えだけで切り替わるため、特にシステム利用停止もなく基本影響なしでの実施が可能でした。
うらばなし
長沢 最後になりますが、以前も現在もオンプレで稼働しておりますが、実はAWS化も検討しておりました。最終的にAWSでなくオンプレになった理由のご紹介となります。
まず送金サービスシステムはOracle DBで動いてますが、AmazonだとMySQLとなるため、アプリはAWSでDBはオンプレのハイブリット構成を考えました。アプリとDBはAWSのダイレクトコネクトでつなぐ想定です。
ですが、既存のダイレクトコネクトではクラウドサービス用途を想定した設計になっていないため、別のネットワークラインでの構築し直しが必要であるということと、レイテンシーの懸念からハイブリッドの可能性はなくなりました。AWSかオンプレかについては、性能面についてレイテンシーの懸念があり、またわざわざ高い初期コストをかけてMySQLへのマイグレーションをするほどの合理性があるのかというところで、コスト面での懸念もありました。
こちらまだ実現できていないのですが、保守性などの面ではAWSに軍配が上がるものの、オンプレでもDockerなどを活用すればAWSライクな運用も可能であるという意見もありました。
以上の理由から、最終的にオンプレという形になりました。
以上で送金更改の話は終わりますが、送金プロの数矢がこの場にいますので、いくつか質問しようと思います。
送金サービス開発時に苦労した点
長沢 送金サービス開発時に苦労した点、何かございますか。
数矢 開発時、実は私はあんまり絡んでなかったのですけれども、先ほど話があった通り、複数銀行に接続しているので、各銀行の差異や、特徴的なところを吸収するのに苦労したと聞いています。
やはり銀行の機能になりますのでどうしても吸収できない部分があって、例えば弊社から銀行にリクエストを投げてから着金するまでの期間や、通帳に印字される受け取り名義人がどのように表示されるかなど、そういうところはさすがに吸収しきれず、そういう差異があって苦労したということになります。
長沢 ありがとうございます。続きまして、日々送金サービスの機能追加・改善に取り組んでいるかと思うのですけれども、直近だとどういったものがあったのか、ご紹介いただけますでしょうか。
数矢 まず、先ほど話がありました、エンドユーザー様が受け取り口座を指定するという機能があるのですが、弊社からそのエンドユーザー様にメールを飛ばすという機能になっています。そのメールの文面に送金の目的などを記したいという加盟店様のニーズが結構多く、加盟店様単位でテンプレ化をするとか、控え文字を置いておいてそこに商品名などを表示する、あとはテンプレートを複数持つなど、メール送金の機能を拡充しております。
他には、全銀協（全国銀行協会）が提供する銀行支店マスタというのがあり、それを取り込んで弊社の中で入力チェックをする仕組みがあるのですが、そのデータが全銀協から月1でCD-ROMで送られてきていました。月1だったのであまりタイムリーに反映できませんでした。
しかし、全銀協が週1、月曜日に先週までの情報をダウンロードできる仕組みを用意してくれたので、それを弊社で取り込んで、最短2週間前の情報しか取れなかったものが、今は前週時点の情報が取れるようになっています。それにあわせ、新しく追加された支店の情報でも、口座情報として受け取れるように改善をしております。
長沢 ありがとうございます。
以上となります。ご清聴ありがとうございました。
※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。
