特殊な力業ではない、先進的な「当たり前」で1,000TPS達成
その後、これまでの取り組みを一層強化しながら微調整を続けてきた平川氏たちは、2020年9月に毎秒1,000決済を達成。大規模なユーザー数であっても安定した処理を実現できる状態になった。
「今まで朝見つけた問題を夜にはリリースできるレベルでスピーディに対応してきたし、そのためのインフラ整備も整えた。、また、全てのリリースはプレ本番環境で動作確認する作業を挟むようにしている。加えて、本番環境では1%からカナリアリリースするように設計した。QAや自動負荷試験で綿密な品質チェックを実施しているが、認識も理解もしていない問題を最小限に抑えるためにも、カナリアリリースは重要と考える」。そう述べた平川氏に、大谷氏は「特別なプラクティスではないが、きちんと正しく進化した施策を実践できている印象」と感心する。

そんな矢先に3つ目の試練がやってきた。2020年10月22日のAWS障害だ。
「11時40分頃だった。今でもはっきり覚えている」と述べる平川氏。AWS東京リージョンのアベイラビリティゾーンでネットワーク障害が起こり、それを受けてPayPayの決済関連データベースでフェイルオーバーが発生。決済ができなくなった。
AWSのフェイルオーバーが始まってから5分後、決済は再開した。AWSのフェイルオーバー自体は1分半から2分で完了しており、PayPay側のアプリケーションの再起動などを含めて約5分。その程度であれば問題ないと考える人も多いだろうが、平川氏たちの目は厳しい。
「私たちが提供するのは決済サービス。昼時の混み合うコンビニで、レジ前には行列ができている。そんな中で決済サービスが5分でもダウンすることは大きなこと。非常に重く受け止めている」(平川氏)
AWSは、意図的にクラウドサービスを落としてアプリケーションの挙動を検証するための「AWS Fault Injection Simulator」提供を発表。平川氏は、これを使いながらAWSフェイルオーバー完了後のタイムラグをどれだけ短縮できるか調整していくと述べた。
講演後の質疑応答で、リモート環境でのトラブル対応は難しいかという質問が挙がった。これに対して平川氏は、PayPayでは2020年9月より新しい働き方「Work From Anywhere at Anytime(WFA)」制度を導入し、新型コロナウイルス感染症の蔓延が終息してオフィス出社ができるようになってもリモートワークは継続する方針であることを説明。障害発生時には、Zoomなどのオンライン会議システムを活用し、ホワイトボード機能やダッシュボードなどで情報共有しながら対処する流れを、みんなで知恵を出し合いながら整理していると話す。
「PayPayの一番のライバルは、現金。コロナ禍のニューノーマル期に『決済のニューノーマル』という価値を創り、いかに提供できるか。今後もチャレンジしていきたい」(平川氏)