
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
提供:PayPay株式会社
リンクをコピー
記事をブックマーク
山本啓介氏(以下、山本):よろしくお願いいたします。本日は「PayPay 100億円キャンペーンのシステム構築」という題材でお話をさせていただきます。
本日は2パートに分けてお話しさせていただきます。
まず私からは、100億円キャンペーンを2度やりましたが、それまでの事績をお話できればと思います。後半パートは弊社のShileiから、PayPayのシステムのより細かいところや問題、今後に関してお話しできればと思っております。
山本と申します。会社の中ではKSKというニックネームで呼ばれております。この後登壇するShileiと共にテクノロジー全般を見ています。2007年にYahoo! JAPANに入社しまして、そこから半分以上の時間は決済関連のプロダクトに携わっています。PayPayについては、立ち上がる3ヶ月前ごろからこのプロジェクトに携わってきました。
私のセッションのアジェンダです。簡単にPayPayとはどういったものなのか、主に3つのミッションに分けてお話しします。最初はローンチ、2つ目は「100億円キャンペーン」、3つ目は「第2弾100億円キャンペーン」について説明をさせていただきます。
まず「PayPayとは」。みなさんご存知の通り、PayPayとはQRコード決済サービスになります。
店舗のオーナーさんは初期費用0、決済手数料0、当然入金手数料も0、本当に無料で導入できます。
オーナーさん向けに「PayPay for Business」というダッシュボードも用意しています。
会社の沿革なんですが、2018年6月15日に会社が設立されました。
その約3ヶ月後、10月5日にサービスをローンチし、話題になった「100億円キャンペーン」は12月4日から12月13日まで開催されました。第2弾のキャンペーンが、直近2月12日から5月の中頃まで開かれてます。現在は「ワクワクペイペイ」ということで、6月に関してはドラッグストアでお得なキャンペーンを行っています。
ローンチから7ヶ月間で登録者数が700万人、加盟店数は60万店舗を超えております。
職場環境についてはこの後細かくお話ししますが、われわれプロダクト本部は日本人もさる事ながら、かなりの外国のメンバーもおります。職場はかなりフラットで、スーパーフレックス制を導入しています。当然、開発環境もまだ立ち上がったばかりということもあり、ほぼすべて最新のものを使っております。
Hiringもします。「Be a Rockstar」ということで、ご興味がある方は見ていただければと思います。
連絡先は、こちらのメールアドレスですね。
では、本題に入ります。2018年7月頃から今年の6月まで、3段に分けて説明をしたいと思います。
まずはローンチです。
3ヶ月でQRコードの決済のサービスをローンチしなければいけないという、本当にこんなタイミングでスクラッチで作り始めました。
開発期間が短いこともあり、開発のサイクルを上げるためにマイクロサービスアーキテクチャを採用しています。また、多数のサービスを効率的に管理するためにKubernetesを、インフラの構築を最短にするためにAWSを使いました。PayPayはPaytmからのヘルプも得て、カナダやインドのメンバーの協力も得ながら3ヶ月で開発を行いました。
PayPayの中には、だいたい60以上のマイクロサービスがあります。7チームあり、1つのチームは複数サービスを見ていて、各サービスは独立したリソースで動いています。中身はほぼ非同期処理になってまして、各サービス間のやりとりはKafkaにイベントを流して、それをコンシュームするかたちで成り立っています。
少しわかりづらいですが、このようにサービスがいろいろと並んでいます。AWSの中にPayPayのサービスがあるんですが、クレジットカード決済をはじめとした決済情報はすべてYahoo! JAPANのシステムに保存されています。なので弊社の中には、クレジットカードカード番号などのセンシティブな情報は保存していません。
KubernetesはEC2上に独自にKubernetesのクラスタを構築しております。
だいたい40ノード、Pods数は1,000オーバー、サービスが60以上です。環境としては、開発環境、ステージングの環境、それからパフォーマンス環境、負荷試験環境ですね。こちらはほぼ本番と同等の環境になります。それとプロダクションの環境があります。
なぜEKSではなくEC2なのかというと、サービスのローンチ当初は東京リージョンでEKSがまだ利用できなかったので、EC2上でやっています。
他にはRDSですね。ローンチ当初はMySQLでやっていましたが、現在はほぼAuroraに切り替わっています。RedisやSESなどのAWSサービスを使っています。
リソースは基本的にTerraformで管理していて、管理コストの削減につなげています。
その他の技術スタックです。
メインのアプリケーションはJavaで作られていて、一部Scalaを採用しています。フレームワークはSpring Bootを使っていて、CI/CDにJenkins。あとはGitHubだったり、監視の部分はDataDogやPagerDutyという海外のサービスを主に使っています。他には、先ほど言ったようにKafkaを有効活用しています。
先ほどお話ししたように、私はYahoo! JAPANからの出向というかたちでPayPayに来ています。今までYahoo! JAPANのインフラで構築をした経験があったんですが、多くのメンバーがAWSは初めてだったにも関わらず、3ヶ月ほどでローンチできたのはすごくよかったと思っております。無事に約束の日にリリースができました。
2つ目のミッションです。
100億円キャンペーンが12月4日から始まりました。安定稼働させるためにいろいろとやってきましたが、結果的にはいろいろと障害を起こしてしまい、お客様や加盟店様には多大なご迷惑をおかけしてしまったと思っています。
何が起きたのかを分析をしてみると、やはりアクセスの急増です。アクセスが急増して、システムが不安定になってしまいました。そのため、何回も緊急メンテナンスを実施しています。ユーザが増加した時のアクセス数も予測していたのですが、結果的に私たちの読みよりもはるかに短い時間でキャンペーンが終了しました。
こちらは実際のアクセスの状況です。左が決済トランザクション、右がユーザのサインアップ数です。ほぼ毎日決算トランザクションが伸びている状況でしたので、ずっとサーバの追加をやっていました。ユーザのサインアップは凹凸がありますが、テレビの影響でかなりスパイクしたこともあり、増えたり減ったりを繰り返しましたが、基本的には右肩上がりでした。
では、どんな問題が発生したかをお話しします。
まず、外部の連携サービスでトランザクションが滞留しました。そして、加盟店向けツールから投げられる負荷の高いクエリが想定以上にコールされてしまい、不安定になってしまいました。あとはRedisのBigKeysですね。他には、SESのリミットに達してメール送信が止まってしまったり、サインアップの際のボーナスとして500円を付与しているんですが、サインアップが多すぎてボーナスの付与が1時間以上遅延するといったことが起きていました。
クレジットカード決済に関してはYahoo! JAPAN側にリクエストを飛ばしているんですが、そもそもその出口のところのPods数が少なかったです。そこが詰まることによってどんどん内部も詰まってしまい、サービスが停滞してしまいました。
当然ノードやPods、RDSもスケールアップをしていきましたが、なかなか追いつかない状況でした。
あとは、負荷の高いクエリの呼び出しですね。加盟店向けツールから、決済履歴などを参照しにいきます。その参照が重くなることによって、ペイメントサービスにも影響がでてしまいました。
これらの問題に対応するためにどんなことをやったかというと、何回かメンテナンスを入れさせていただきました。
夜中に緊急メンテナンスもいれたりしたのですが、まずは加盟店の情報をRedisのキャッシュに格納するように急遽変更しました。DBの読み込みに関しても、リードだけの読み込みに関しては、極力Slaveに振り向けるように対応しました。
機能も削りました。加盟店ツールのダッシュボードではオートリロードをしていたんですが、このオートリロードを停止しました。他には、決済のトランザクションを加盟店さん側でダウンロードできるんですが、大量に決済があるところでは一部制限をさせていただきました。
あとはアプリのホーム画面のデザインですね。サービスをローンチした当初は、支払い手段がホーム画面に並んでいました。それによって支払い手段、とくにクレジットカードの情報をYahoo! JAPAN側から引っ張ってくるんですが、そこでYahoo! JAPAN側にアクセスしないように、PayPayのシステムの中で完結するようなかたちにしました。
あとはRedisのBigKeysですね。認証はRedisの中に情報を格納していたんですが、Redisの負荷が上がってしまいました。とくに1つバグがあって、使っていないkeyに対して要素が375万件ぐらい入ってしまっていて、負荷があがってしまいました。アクセスがある度にどんどん要素が追加されていくので、一旦これはShardの再配置で分散をして逃げ切りました。その後使っていなかったkeyだったので削除しました。
次の問題です。内部はすべて非同期処理だったんですが、サインアップが多いことで500円の付与を行うキャンペーンシステムが追い付かなくなってしまい、非同期でやっているにもかかわらず1時間以上の遅延を起こしてしまいました。
こちらに関しては捌かれるのを待っていました。
あとは、SMSの送信遅延も起きました。
サインアップの際にSMSでワンタイムパスワードを送信して認証を行っていたのですが、サインアップが急激に増えたことで遅延が発生し、有効期限が切れてしまうという状況が発生しました。どんな手を打ったかというと、サインアップ用のSMS送信とその他のSMS送信を分割しました。
第1弾キャンペーンはいろいろあったので、第2弾のキャンペーンに向けてどんなことをしたのかをお話しします。
1番の課題は、一部の機能停止で重要な機能が停止してしまう点でした。負荷試験は事前に行っていましたが、パターンが足りていませんでした。また、チューニングが甘いといった課題があったので、1弾目のキャンペーンが終了したあと、すぐに対応しました。
まずGraceful Handlingとデータの可視化を行いました。
Rate Limitなんですが、突然大量アクセスが来たとしても、システムの表側でブロックというか、流入量の制限を行いました。なので突然大量のアクセスが来て一定のリミット値を超えたユーザに対しては、「ただいま込み合っています」という画面が出るようにしました。
そして、一定時間が経つと次のユーザがアクセスできるようになる、そういったRate Limitを入れています。詳細は次の章で説明します。
Circuit Breakerです。
外からの流入だけでなく、中のどこかしらのコンポーネントが応答できなくなったときに、そのコールをスキップする処理を入れました。
あとは遅い処理の可視化です。
アプリケーションパフォーマンスモニタリングとして、NewRelicを導入しました。これによってどこがシステムのボトルネックになるのか、簡単なもので言うとインデックスが貼られてないものを可視化して、すぐに修正するようにしました。
最後に、3D Secureの導入も行いました。
これらの作業を行ったことで、2弾目のキャンペーンでは大きな障害も起こすことなく無事に終えることができました。
では、後半はShileiから説明させていただきます。
PayPay株式会社
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
限られた時間で成果を上げるドイツ式仕事術
2025.01.21 - 2025.01.21
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29