坂内 理人

サービスで大きなイベントが控えており、ECサイトなどでの購入が急増すると見込まれていたため、想定する負荷に耐えられるのかを確かめるとともに、耐えられない場合はパフォーマンスチューニングを実施する必要がありました。 負荷テスト基盤がなかったため、Kubernetesを用いて本番環境とほぼ同じ環境を構築し、これまでのAPIに対するリクエスト数をもとに、イベント時の負荷を想定してLocustを用いて負荷テスト用のシナリオを記述し、負荷テストを実施しました。 DatadogやGCPのQuery Insightなどを確認した結果、ロックの取得待ち時間と、N+1問題が発生している箇所がボトルネックとなっていたため、最低限のロック取得で済むようにロジックを変更し、Eager Loadingを用いてコードを改善した結果、負荷テストをパスさせ、本番のイベントについても無事成功させることができました。 特に決済処理部分では、Stripe APIに決済リクエストを出し、その結果をデータベースに記録するということを１つのトランザクション内で行っていましたが、タイムアウト（THECOOのサービスで設定されているタイムアウト時間を超過したなど）等によってトランザクションがアボートされると、Stripeでは決済処理が行われたのにデータベースには決済が行われたことを示すデータがないという障害が発生する原因にもなっていました。そのため、新たに決済処理に保留ステータスを追加することでトランザクションを分離してロックの取得待ち時間を短縮するとともに、必ず決済記録が残るようにすることができました。