@orekyuuです。pixiv PAYのサーバーサイドを担当している今年新卒2年目のエンジニアです。今回はpixiv MARKETを支えた決済アプリ「pixiv PAY」の裏側。主にpixiv MARKETに向けて私が主導して進めたことを紹介します。

pixiv PAYとpixiv MARKET

pixiv MARKETは2018年6月10日に開催された、決済アプリpixiv PAY利用限定の日本初のキャッシュレスなオールジャンル同人誌即売イベントです。イベントの参加者全員がpixiv PAYで決済をするという状況はpixiv PAYにとって初めてで、どれだけの負荷がかかるか想定できませんでした。

想定される最悪の事態はpixiv PAYが耐えきれずに決済ができなくなることです。仮に決済ができなくなれば頒布ができなくなり、イベントが続行できなくなります。このような最悪の状況を避けるため、時間をかけて検証や対策などを行いました。

決済APIの調査

当日最も詰まりやすいのは決済を行うAPIです。決済処理は他のAPIと比べてもかなり遅く、当日多く叩かれることになるのでこのAPIの応答速度を調べました。

pixiv PAYには大きく分けてクレジットカード、PayPal、ポイント支払いの3つの支払手段があります。それぞれの決済完了までの応答時間は以下のとおりです。

クレジットカード: 1〜2秒
PayPal: 3〜4秒
ポイント: 約0.2秒

1リクエストをunicornの1ワーカープロセスが処理するため、処理が終わるまでワーカーをずっと握ったままになります。あまりにも決済が多いとワーカーを使い切りリクエストを受けられず、すべてのAPIが応答不可になる可能性があります。クレジットカード、PayPalの速度に関してはpixiv PAYのシステムでどうにかしても速度を早くすることはできないためunicornのワーカー数を12から50、APサーバーを2台から3台に増やすことで対応しました。

クレジットカード決済対策

クレジットカード決済が同時に処理できる数は決済代行サービスによって決まっています。これを超えてしまうと流量オーバーエラーとなり決済が失敗してしまいます。この数はお金を払うことによって増やすことができますが、すぐに変更ができるわけではないためイベント当日に「想定以上の決済が走ってしまったので今すぐ増やしたい」といった対応ができません。また、イベント開始直後は一斉に頒布を始めるタイミングなので流量オーバーエラーが発生しやすい状況です。ここでエラーが頻発するとユーザーの体験としては最悪なのでこれを避けたいと考えていました。

非同期処理を考えたとしても、決済代行サービスがさばける量が増えるわけではないので、解決策としてはプロダクトマネージャと相談しお金を払って増やせるだけ接続数を増やすという判断をしました。

決済APIのテスト

決済APIのテストは別々の観点から2種類のテストを行いました。1種類目は流量オーバーを起こすテストで、決済に失敗してロールバックしたときにアプリ側で正しくエラーの表示が出るかのテストです。実施時期はpixiv MARKETに向けてクレジットカード決済の並列実行数を増やす前です。このテストは社内で80人ほど人を集め、二人一組で一斉に決済を行ってテストを行いました。

このテストの結果、以下の2つのことが確認できました。

流量オーバーが発生した時正しくロールバックが行われていて、アプリにも正しくエラーが表示されている
流量オーバー発生時は1秒以下でレスポンスが返り、決済が受け付けられない状況ではすぐにレスポンスが返る

このうち2. は良い結果で、受け付けられないときも仮に処理に2秒ほどかかっていればどんどん処理が詰まっていくケースがありえていたかもしれません。

2種類目は決済のパフォーマンステストです。このテストではpixiv PAY自体の処理からpixiv社内の決済系の処理を行っている決済基盤というサービスの間に無駄がないかを確かめています。内容は本番の決済APIをテストユーザーでスクリプトを使って一斉に叩くという内容です。ただし実際にクレジットカード決済は行わずに2秒ほどsleepする処理を入れてあるMockの決済基盤の決済APIを叩きに行きます。

テストの結果、pixiv PAYから決済基盤間の処理は遅くても0.2秒程度で問題ないという結果でテストを終わりました。

障害対応フロードキュメントの用意

最後にpixiv MARKET当日に向けて障害予測、対応フロードキュメントを用意しました。この対応フロードキュメントは当日トラブルが発生した時に参考にするドキュメントで、早期復旧のために用意しました。書いた内容は以下のようなものです。

当日監視する内容
障害パターンの予測
各種障害に気付くための方法
各種障害が発生した場合の調査箇所
障害発生時の対応フロー
誰にエスカレーションするか
イベント会場との連携方法

　加えてpixiv PAYではCI/CDの仕組みは整っていますが、致命的なエラーが出ない限りデプロイを禁止するルールを定めました。これはunicornの再起動が行われるためで、起動直後のunicornは動きが遅くレスポンスを返すのに時間がかかってしまいます。そのためデプロイによってリクエストが詰まり状況が更に悪化する可能性があるためです。

今後の課題

pixiv MARKET当日大きな問題は発生しませんでしたが、一部のレスポンスタイムが劣化する現象が見られました。これはunicorn worker killerというgemに受けたリクエスト数で再起動する設定が入っていたためです。今までのイベントでは問題になることはなかったですが、pixiv MARKETという特殊な環境では不適切な設定でした。今後は再起動するリクエスト数を増やすか、メモリ使用量で再起動するようにすることで今後の決済体験を良くしたいと考えています。

まとめ

pixiv MARKET当日は大きな問題も発生せず無事乗り切ることができました。障害対応フロードキュメントをpixiv PAYチーム以外の多くのエンジニアにレビューをお願いしたり、様々な職種のメンバー達がテストに意欲的に参加してくれたこその成功だと思っています。そんな私のいるpixiv PAYチームでは、一緒に即売会を盛り上げていきたいエンジニアを募集しています！