【TECH BLOG】ZOZOTOWN カート投入の分散キューイングシステム 〜 プロダクションレディまでの歩み

はじめに

こんにちは。家系らーめん好きが高じて鶏油を自分で取得するようになり、金色に輝く液体を見るだけでパブロフの犬的に涎が止まらない、SRE部の横田です。普段はSREとしてZOZOTOWNのリプレイスや運用に携わっています。

先日、弊社の高橋が執筆したZOZOTOWNカート機能リプレイスに関する記事が公開されました。

本記事では、上記記事で紹介したリプレイスのキーポイントとなる、キューイングシステムに焦点を当てます。キューイングシステムをDeep Diveし、サービス選定からプロダクションレディにするまでの取り組みを紹介します。

キューイングシステムの概要と選定

本章では、今回のテーマとなる「キューイングシステム」の概念を、ZOZOTOWNのカート投入システムを例に解説します。

ZOZOTOWNのカート機能は、カート投入や決済など、さらに細かい様々な機能から構成されています。そして、ZOZOTOWNにとって、最も重要な機能の1つと言えます。しかし、関連システムも多いため、一度にすべてをリプレイスするのではなく、段階的にいくつかのPhaseに分けたリプレイスを現在進めています。カート機能のリプレイス Phase1では、カート投入処理でWebサーバーとカート情報を扱うデータベース（以下、カートDB）間にキューイングシステムを挟みました。これにより非同期処理となり、イベント時のアクセス集中に伴うカートDBの負荷上昇を抑えることを可能にしました。

上図で用いられている用語を簡単に説明します。

• Queue

キュー（Queue）とは、「待機、待ち行列」を意味する
本システムでは、カート投入処理をキューで一時的に預かることで、後段のシステム負荷軽減を実現させている
First In First Out（以下、FIFO）、つまり順序性を保証したい場合は、要件に合うキューを選択する必要があるため、本システムではAmazon Kinesis Data Streams（以下、KDS）を採用している
KDSでは、キューの役割を持つリソースをシャードと呼び、シャードに投入するデータをレコードと呼ぶ

• Producer

キューにデータを投入する役割を持つ
本システムでは、上図のzozo-cart-apiがProducerの役割を果たす
前段のWebサーバーからリクエストを受け、KDSにレコードを投入するまでがzozo-cart-apiの役割である

• Consumer

キューからデータを取り出し、後続の処理を行う役割を持つ
本システムでは、上図のzozo-cart-workerがConsumerの役割を果たす
KDSから読み込んだレコードを後段のシステムに繋げる役割を持つ

• Polling

Consumerがキューの状態変化を検知するために、一定間隔でリクエストを送る処理をポーリングと呼ぶ
本システムでは、Consumerであるzozo-cart-workerがKDSにポーリングを行うことで、未処理のレコードに対するアクションを行う

このように、本システムではカート投入要求に対する非同期処理システムを、KDSを活用して実現しています。次に、なぜキューイングシステムとしてKDSを採用したのかを説明します。

検討したサービス

AWSが提供するキューイングシステムから、以下の選択肢を検討しました。

• Amazon Simple Queue Service（以下、SQS）
• KDS

それぞれの特徴は以下の通りです。

SQS

SQSはメッセージキューサービスであり、以下の特徴があります。

• 1リージョン内で複数AZの冗長構成なため、可用性が高い
• キューサービスのため、Consumerはメッセージの取り出しと削除が役割となる
• 標準キューとFIFOキューが存在し、タイプにより性能や動作が異なる
• デッドレターキューを利用することで、処理に失敗したメッセージに対するアクションが可能である

なお、標準キューとFIFOキューには、以下の違いがあります。

続きはこちら