【TECH BLOG】ZOZOTOWN カート決済機能リプレイス Phase1 〜 キャパシティコントロールの実現

こんにちは。ECプラットフォーム部 カート決済ブロックの高橋です。

ZOZOTOWNでは、数年前よりClassic ASPからJavaへのリプレイスが実施されています。そのリプレイスの一環として、2021年4月からカート決済機能のマイクロサービス化を開始しました。

ZOZOTOWNの中長期目標である「商品取扱高5000億円」を達成するために、リプレイス後は以下の要件をシステムが満たしている必要があります。

• セールなどの高負荷イベント時にスケール可能であること
• キャパシティコントロールが可能であること
• Datadog、SentryなどのSaaSを利用した運用監視の効率化できること
• CI/CDなどを取り入れ、開発生産性を向上できること
• レガシー技術をモダン化できること

そして、カート決済機能はZOZOTOWNの中でも最も大きな機能であり、最も重要な機能です。そのため、リプレイスは慎重に進めなければなりません。

本記事では、そのリプレイスのPhase1として先日リリースし、キャパシティコントロールを実現させた事例を紹介します。

カート投入機能のリプレイス

本章では、リプレイスしたカートの1つの機能である「カート投入機能」の概要を説明します。

カート投入機能の仕様

まず、ZOZOTOWNにおけるカート投入の仕様を説明します。

「カートに入れる」ボタンを押すことで、以下の処理が行われます。

1.在庫を引き当てる
　　同時に、在庫数を減らす
2.カートテーブルへ、その情報を登録する

ZOZOTOWNのカート機能の大きな特徴は、カート投入時に在庫の引き当てをしている点です。今回のリプレイスでは、それらのカート投入の仕様は変更せず、アーキテクチャの変更のみを行っています。

つまり、カート投入時に在庫の引き当てをする仕様を変更しないため、「FIFO（First-In First-Out）であること」が重要な要件となりました。

ZOZOTOWNのカート機能の大きな特徴は、カート投入時に在庫の引き当てをしている点です。今回のリプレイスでは、それらのカート投入の仕様は変更せず、アーキテクチャの変更のみを行っています。

つまり、カート投入時に在庫の引き当てをする仕様を変更しないため、「FIFO（First-In First-Out）であること」が重要な要件となりました。

アーキテクチャの変更

これまでは、下図に示すアーキテクチャでした。リクエストをIISで受け、Classic ASPからストアドプロシージャを呼び出し、処理を実行していました。

そして、今回のリプレイスでは、下図のアーキテクチャに変更しています。IISとストアドプロシージャの間にCart Queuing Systemを新規で作成します。これにより、Cart Queuing Systemとストアドプロシージャ呼び出し用のIISを新たに追加しています。

リプレイスの目的

現在のシステムでは、ZOZOTOWNの成長に伴い、高負荷に耐えられなくなる可能性があります。そのため、今回のカート機能のリプレイスの目的は、キャパシティコントロールを可能にすることです。

それを実現するために、Cart Queuing Systemは、下図に示す構成にしました。

リクエストのステータス管理をAmazon DynamoDB（以下、DynamoDB）で管理します。そして、Amazon Kinesis Data Streams（以下、KDS）には、IISへのリクエスト情報やカート投入情報テーブルのキー情報を送信します。

全体の流れは、Cart APIの登録APIが呼び出されるところから始まります。その登録APIでは、以下の処理を行います。

続きはこちら