3カ月でユーザー1,000万人増、次々現れるボトルネック
システム上では、いつ、なぜ発生するのか分からない、発生の原因を調べても理由がはっきりしないちょっとした異常が起こる。こうしたよく分からないものを、システムのメトリクスやログ情報、監視などを通じて可視化し、原因を特定して対処しながら安定稼働につなげるのが「オブザーバビリティ（可観測性）」の基本的な考え方だ。
このオブザーバビリティを継続的に実践しながら、「3つの試練」を乗り越えて決済システムの強化を続けてきたのが、PayPayだ。
1回目の試練は、創業から約3カ月後にサービスをリリースした直後、マーケティング部から「100億円あげちゃうキャンペーンを打つ」と言われたときだ。システムのモニタリング体制は準備してあったが未知数のアクセス数を受け入れなければならないという状況に、社内では戦々恐々だったと、PayPayの平川宗則氏は明かす。
負荷試験は当然実施した。しかし、運営側の未熟さも手伝い、負荷試験で問題ないと確認した構成や設定が本番環境とは一部ずれていたことなどが、キャンペーン開始直後に次々発覚。「監視用のダッシュボードも、マイクロサービスごとの担当者がそれぞれ個別に用意したものだったため、観点がバラバラ。マイクロサービスのボトルネックがどこにあるのか、把握するのが難しい状態だった」と平川氏は述べる。
そうした反省を受けて、平川氏たちは認識できていない微細な変化を捉え、速やかにボトルネックまで掘り下げられるよう、オブザーバビリティ向上を支援する「New Relic APM」を導入した。同時に、モニタリングルームを設置。50以上の主要指標を大型モニターに常時投影し、特にキャンペーン期間は朝昼夜のピークタイムはエンジニアが自分たちの目で監視する体制を敷いた。
このほか、カスケード障害を防止するためのサーキットブレーカーや、想定以上のアクセスがあった場合に処理の完了を優先した流入制限も導入した。この取り組みについてNew Relicの大谷和紀氏は、想定外の現象が起こっても緩やかにサービスを劣化させつつ、その影響をシステム全体に波及させない「グレースフルデグラデーション」が実践されていると評価。多少の犠牲があってもシステムは落とさない仕組みを取り入れたことが、その後の強化にもつながったのではないかと分析した。
その後、いくつかのキャンペーンを乗り越え、登録者数も1,000万人を突破。さらに弾みをつけるべく、2019年10月1日に開始した経済産業省の「キャッシュレス・消費者還元事業」と合わせて、5％還元対象店舗でさらに最大5％追加のポイント還元を行う「まちかどペイペイ」キャンペーンを実施した。そしてこれが、平川氏たちにとっての第2の試練となる。
キャンペーンは功を奏し、わずか3カ月で登録者数は約2,000万人に倍増した。だが、平川氏たちは新たな課題に直面する。同キャンペーンを開催した際に新規で増えたのは、これまでキャッシュレスを使ったことがない顧客層だ。レジでエラーが出て使えなかったとき、最悪の場合は二度と使ってもらえない可能性もある。
もう1つ、コンビニなどの加盟店のPOSシステムや、PayPayとレジ間をつなぐ決済ゲートウェイサービスがボトルネックになるケースが、この時期から増え始めた。
「どこに問題があるにせよ、ユーザーからすれば『PayPayが使えなかった』という体験に変わりはない。社会インフラになったことを自覚し、そこへの期待に応えられる品質や体制を整えなければならない。POS関連は自分たちのシステムではないとしても、そこのプロセス含めて負荷対策や安定性を担保することが私たちの使命であると痛感した」（平川氏）
ここで、PayPayは大きな決断をする。それは、これまで進めていた新機能の開発をすべて、1カ月半停めて負荷対策に取り組むことだった。「当時は130人ほど開発メンバーがおり、運用に最低限必要なメンバーを残して、約80名が負荷対策専任チームに割り当てられた」（平川氏）
このチームの中でも特に負荷試験だけを行う専任チームはまず、負荷試験を自動化し、毎週実施して結果を継続的に確認する仕組みを作った。また、加盟店ごとにダッシュボードを作り、加盟店と決済ゲートウェイとのエンドツーエンドの負荷試験も実施。加盟店単位でモニタリングやアラートの確認を行いながら、ボトルネックの洗い出しを行った。
新機能開発とサービスの信頼性はトレードオフと言われがちだが、その点はどう克服したのか大谷氏からの質問が出ると、平川氏は「一番重要なのがセキュリティで、次に安定稼働などシステムとしての信頼性。これらすべてが実現できた上での新機能開発だという意識は、エンジニアから経営層まで、会社全体で共有されていた。その意味で、リソースの確保や対応の優先順位で悩むことはなく、エンジニアとしてありがたい環境だ」と答えた。
特殊な力業ではない、先進的な「当たり前」で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の一番のライバルは、現金。コロナ禍のニューノーマル期に『決済のニューノーマル』という価値を創り、いかに提供できるか。今後もチャレンジしていきたい」（平川氏）
