PayPayカード、メインフレームの基幹システムをAWSに移行–業界で前例なき規模

PayPayカード、メインフレームの基幹システムをAWSに移行–業界で前例なき規模

PayPayカードは4月21日、メインフレームで運用していた基幹システムのインフラをAmazon Web Services(AWS)に移行して4月に本格稼働を開始したと同日開催の「AWS Summit Tokyo」で発表した。国内クレジットカード業界では前例のない規模といい、専務執行役員 最高技術責任者(CTO)の信太宏之氏がその舞台裏を語ってくれた。

同社は、1963年設立の国内信販を源流として楽天KC、KCカードと変遷し、現在はPayPayの完全子会社として「PayPayカード」ブランドのクレジットカード事業などを手掛ける。2022年3月に1000万会員を突破し、5500万の決済ユーザーを抱えるPayPayとの連携推進など事業拡大を図り、会員数の倍増を目指している。

PayPayカード 専務執行役員 最高技術責任者(CTO)の信太宏之氏
PayPayカード 専務執行役員 最高技術責任者(CTO)の信太宏之氏

2015年にソフトバンクグループとなってからビジネスが大きく変わり、「『ネット屋の金融を目指す』というトップのビジョンの基でIT戦略も大きく変化した。あまり表明していないが、ITを大手ベンダーに丸投げせず自社でコントロールできるようにし、『ネット屋の金融』らしいプロダクトファーストな新しい金融サービスを目指すようになった。社内エンジニアでもシステム内部はベンダーにしか分からない状態で、エンジニアがものづくりに取り組むためにもシステム内部を理解していることが必要だった」(信太氏)という。

上述の経緯から同社の基幹システムは長年メインフレームで運用されてきたが、ビジネスが変わったことでモダナイズ(最新化)の必要性が高まり、まず2016年頃からアプリケーションを「COBOL」から「Java」に書き換える(リライト)改修を行った。このリライト作業は容易ではなく、「当時の担当者が既におらずドキュメントなどもない状況。変換ツールも使用したがうまくいかず、大部分をスクラッチ(手作業)に近い形でJavaに書き換えた」(信太氏)と苦労した。

システムインフラのクラウド化は、親会社のPayPayやヤフーが先行してAWSを採用していたこともあったが、大きな契機となったのは、2019年12月にPayPayが実施した「100億円あげちゃうキャンペーン」でのシステム障害だった。PayPayがモバイル決済サービスの参入に際して行ったキャンペーンは当時大きな話題を集めたが、利用者の殺到ぶりにシステムの処理能力が追い付かず、何度もシステムの緊急メンテナンスを行うなど、キャンペーンの中断が相次いだ。

「表向きはPayPay側の障害だったが、実はPayPayカード側のシステムもダウンして加盟店でのカード決済が全てできなくなり、多方面にご迷惑をおかけしてしまった。PayPay側はAWS活用の再発防止策を打ち出したが、オンプレミス環境の当社はそれができず、リソース拡張も図ったが、システム障害での反省や事業スピードが求められていることからもパブリッククラウドのIaaSを使うと覚悟を決めた」と信太氏は明かす。

インフラ選定でのポイント
インフラ選定でのポイント

 基幹システムのインフラをAWSに移行するプロジェクトは2020年10月にスタートした。信太氏によれば、従前のアプリケーションのリライト時も含めレガシーなIT資産の全てをモダナイズするには膨大な費用や工数、リソースを必要とするため事実上不可能であり、事業の整理を余儀なくされた。

「大きな意思決定を何度もしなければならなかったが、『PayPay』ブランドで勝負する、クレジットカードと後払いのビジネスに集中していくと決め、それ以外のビジネスは整理しAWSに移行しない選択をした」(信太氏)

基幹システムはデータベースが約10TB、レコード数が約150億件、バッジ処理が1日当たり約1万8000本という規模で、国内大手クレジットカード会社がこの規模の基幹システムのインフラをAWS環境へ移行させた前例がないという。同社は、AWSに構築する基幹システムの構成をシングルリージョン・アベイラビリティーゾーン(AZ)によるシンプルなものにした。

システム構成における課題
システム構成における課題

一般的には、システムの可用性を重視して複数のリージョン(例えば東京と大阪など)を組み合わせるマルチリージョンや、複数のAZを組み合わせるマルチAZの構成を採用するが、信太氏によれば、同社では特に可用性と決済処理における遅延とのバランスをどう両立させるかが課題になり、慎重に検討した結果、シングルAZを採用した。同社の検証では、シングル構成の場合にインスタンスからデータベース(Amazon Relational Database Service)への処理時間が0.19ミリ秒なのに対し、マルチAZでは2.6ミリ秒だったとのこと。仮に1000万レコードを処理すると、前者では30分程度だが、後者では7.2時間になり、マルチAZでは10倍近く遅延が大きくなることが懸念された。

シングルAZ採用に伴う課題の対処
シングルAZ採用に伴う課題の対処

「結果として基幹システムではバッチ処理がメインになることから、性能面はスケールアップと並列処理によって対応し、可用性はアクティブ-スタンバイの構成で瞬時に切り替えることにより対応できるようにしている」(信太氏)

約3年に及ぶ基幹システムのクラウド移行は、こうしたさまざまな課題と対応への意思決定を繰り返しながら慎重に進められた。移行プロジェクト自体は、2023年4月に無事完了したが、信太氏はむしろこれからが本題だとも述べる。

「ビジネスが拡大し、データ量もますます増えていくため、クラウドを活用して柔軟に対応していくには正確にキャパシティーを予測して計画したり、運用コストを常に最適化したりしなければならず、システム構成のさらなる最適化や、マイクロサービス化などのモダナイズも推進しなければならない」(信太氏)

今後は、PayPayグループ全体でのビジネスの変化に合わせたIT環境の最適化もテーマになるとのこと。「グループ各社ごとではいろいろな意思決定が別々の方向に動いてしまう。現状ではアーキテクチャー面でもユーザーインターフェース/体験(UI/UX)面でも各社が取り組んでしまうところが大いにあるので、各社の技術、UI/UXの責任者が集まり足並みをそろえていく動きをまさに始めたばかりだ。今後はグループ各社が足並みをそろえていけるようになるだろう」(信太氏)という。

今後のテーマ
今後のテーマ

ZDNet より

事例カテゴリの最新記事