[事例ニュース]

PayPayカード、基幹システムのAWSへの移行が完了、COBOLをJavaにリライト

DBアクセスのレイテンシからシングルAZ構成を選択

2023年4月21日(金)日川 佳三(IT Leaders編集部)

クレジットカードサービス会社のPayPayカードは2023年4月5日、メインフレームとCOBOLで動いていたオンプレミス環境の基幹システムをJava言語でリライトし、パブリッククラウドのAmazon Web Services(AWS)で稼働させた。約6年半前にJava化プロジェクトが始まり、約3年前にAWSに移行するプロジェクトが始まった。今回、AWS上で新システムが稼働した。Amazon EC2とAmazon RDS for Oracleで構築している。AWSのシステム構成は、レイテンシ(遅延時間)を短くするため、マルチAZ構成ではなくシングルAZ構成とした。

写真1:PayPayカードで専務執行役員CTO、テクノロジー部門長兼VPoEを務める信太宏之氏
拡大画像表示

 クレジットカードサービス会社のPayPayカードは、メインフレームとCOBOLで動いていたオンプレミス環境の基幹システムをJava言語でリライトし、パブリッククラウドのAmazon Web Services(AWS)で稼働させた。

 約6年半前にCOBOLをJava化する構想がスタート。2020年10月にはAWSへの移行プロジェクトが始まった。今回、2023年4月5日付で、AWS上で新基幹システムが稼働した。Amazon EC2(仮想サーバー)とAmazon RDS for Oracle(データベース)で構築した。

 同社の基幹システムが抱えるデータ量は、約150億レコードで、データサイズは約10TBに及ぶ。バッチ処理は、日次処理が約1万8000本、月次処理が約3万4000本走っている。「今後の事業の成長を考えた時に、従来のシステムでは負荷に耐えられない」(PayPayカードの信太宏之CTO、写真1)と考え、AWSへの移行を決めた。

 AWSを採用した背景には、市況に合わせてシステムを柔軟に変化できるようにする狙いもあったと信太CTOは指摘する。例えば、オンプレミスのシステムでは、サーバーなどのリソースの調達に時間がかかる。一方、AWSならテスト環境を短期に立ち上げられる。キャンペーンなどのマーケティング施策に合わせてリソースを一時的に増強するといったことも容易である。

DBアクセスのレイテンシを考慮してシングルAZを選択

 AWSのシステム構成を考えるうえで意思決定が難しかったポイントは、AZ(アベイラビリティゾーン)の設計である。「一般的には、マルチAZ構成で可用性を担保する。しかし、PayPayカードでは、マルチAZの選択は取らなかった」(信太CTO)。

 マルチAZ構成にしてAZ間でデータベースをレプリケーションした場合、AZ同士の距離が離れることによる通信遅延(レイテンシ)が大きくなってしまう、というのが理由である。

 アプリケーションのインスタンスからデータベースにアクセスした際のレイテンシは、シングルAZ環境では0.19ms(ミリ秒)で済むのに対して、マルチAZ環境では2.6msになる。1件だけだと大したことはないが、1000万件だと0.5時間(シングルAZ)が7.2時間(マルチAZ)に増えてしまう。

 結局同社は、シングルAZ構成を選びつつ、スケールアップとアプリケーションの並列処理によって、性能要件を満たした。可用性については、AZの中でシステムを2重化し、アクティブスタンバイ構成をとった。こうして、障害発生時に切り替えられるようにした。

関連キーワード

PayPay / AWS / クラウド移行 / レガシーマイグレーション / Java

関連記事

トピックス

[Sponsored]

PayPayカード、基幹システムのAWSへの移行が完了、COBOLをJavaにリライトクレジットカードサービス会社のPayPayカードは2023年4月5日、メインフレームとCOBOLで動いていたオンプレミス環境の基幹システムをJava言語でリライトし、パブリッククラウドのAmazon Web Services(AWS)で稼働させた。約6年半前にJava化プロジェクトが始まり、約3年前にAWSに移行するプロジェクトが始まった。今回、AWS上で新システムが稼働した。Amazon EC2とAmazon RDS for Oracleで構築している。AWSのシステム構成は、レイテンシ(遅延時間)を短くするため、マルチAZ構成ではなくシングルAZ構成とした。

PAGE TOP