【TECH BLOG】ZOZOTOWNカート機能のリプレイスPhase1裏側を大公開

こんにちは、カート決済部の佐藤です。普段はZOZOTOWNカート決済サービスの新機能開発、既存改修、運用保守を担当しております。

弊社はモノリスからマイクロサービスへのリプレイスを進めており、カート決済サービスも先日リプレイスPhase1の記事を掲載いたしました。

本記事ではカートリプレイスPhase1全体を振り返りつつ、リプレイスプロジェクトを進める中で苦労した点や得られた知見等の、リプレイスの裏側をご紹介したいと思います。

カート機能はECサイトの中核を担う機能であり、障害のリスクを考えるとドラスティックな改修には中々手を出しにくい機能だと思っています。しかし、弊社ではリプレイスをしたことで確実に前進できたため、同じようなお悩みを抱えている方の参考になれば幸いです。

はじまり

2021年元旦、特定商品へのカート投入リクエストの集中によりデータベースのキャパシティを超えてしまいエラーが多発する事象が発生しました。そのようにアクセスがスパイクするような商品を弊社では過熱商品と呼んでいます。

以前から過熱商品の販売によるアクセス数の増加はありましたが、2021年元旦は圧倒的に群を抜いたアクセス数を記録し、明らかに一般ユーザーの導線ではなくBOTによる過剰アクセスと判断できました。当時は過剰アクセスへの対抗策が少なく、結果的に数時間カート投入・注文がしづらい状況となり損害は大きいものとなってしまいました。

その後、BOTによる過剰アクセスにも耐えうるシステムの整備が急務となりましたが、以下の状況により問題はより深刻になっていきました。

• インフラ、アプリケーション両軸で対応を進めるものの、改良版BOTとのいたちごっこが続く
• さらに追い打ちとしてコロナにより外出できない時間が増えたことによるトラフィックの増加

カートリプレイス計画の始動

そんな中、小手先の改修に限界を感じはじめていたのと、弊社はリプレイス過渡期であり、カートシステムについてはオンプレミスで動いているため、抜本的な「スケールできるシステム」の必要性が高まっていました。

「リプレイスを推進するためには組織から変える」という弊社VPoE @sonots の舵取りのもと、カートシステムのリプレイスを推進するために新生カート決済チームが誕生しました。

この組織変更が無かったら通常業務もやりつつ片手間でリプレイスとなっていたため、リリースまで大分時間が掛かっていたはず。まず組織変更するというのは大正義！

カートリプレイス計画の策定

いざリプレイス計画を策定しようとすると、現状の課題解消のため「あれもこれも」となりがちです。弊社もまさにその状況となり、ロードマップを引くのに苦労しました。しかし、やりたいことが増えるほどリリーススパンも長くなりエンジニアのモチベーション低下にも繋がりやすく、ビッグバンリリースによるリスクも高まります。「リリーススパンは半年＋α」とし、その中でできることをマイルストーンに落とし込んでロードマップを引いていきました。

そして、Phase1では主に過熱商品販売時のBOTによる過剰アクセスにも耐えうるシステムを目的に、以下ゴールを設定しました。

• キューによるキャパシティコントロール可能なシステム
• 目標値として過去のBOTアクセス数からサンプリングしたアクセス数×N倍に耐えうる値

欲張りすぎず、豪華すぎる仕様にしない。
課題を正しく理解する前にどうしても解決を急いでしまいがちなため、そこのバランスは特に意識していました。合わせて技術的に正しくてもサービスへの貢献度が低いなら成果として不十分なため、解決すべき課題を明確にしてスコープを小さくすることも意識しました。また、事前にリリーススパンを決めたことで、そこから逆算した形で落としどころを決めることができました。

アーキテクチャ構成

カートリプレイスPhase1のアーキテクチャ構成の概念図は以下となります。

Phase1では、Cartデータベースの前段にキューイングシステムを置くことでキャパシティコントロールを実現しています。キューイングサービス選定の際、AWSが提供しているサービスという点より以下2択となりました。

• Amazon Simple Queue Service
• Amazon Kinesis Data Streams（以下、KDS）

カート投入リクエスト数に耐えうる性能、及び可用性の観点からKDSを採用しましたが、詳細は以下の記事にまとまっているためご興味のある方はご覧ください。

いよいよ負荷試験

無事製造も終わり、いよいよ負荷試験です。キュー導入によるチューニング等は発生するだろうとある程度身構えてはいたものの、想定以上のトラブル続きでした。

プロダクション環境を使った負荷試験

今回のアーキテクチャでは、キューイングサービスにKDSを採用しています。もちろん単体での性能検証、負荷試験を実施しておりますが、カート機能はECサイトの中核を担う機能であり、リプレイスによりユーザビリティを損なってしまうのは本末転倒です。可能な限りUXを損なわずに最適なキューの並列度を探るには、やはりプロダクション環境での負荷試験が必須だと考えました。

プロダクション環境を使うにあたりできるだけサービスに影響が出ないような工夫もしており、詳細は以下の記事にまとまっているためご興味のある方はご覧ください。

負荷試験で見つかった課題

ここでは負荷試験で見つかった課題と、解決に向けたアプローチについていくつかご紹介させていただきます。

続きはこちら