ソリューションアーキテクトは、複数の店舗端末から届く在庫の増減を受け取り、Amazon DynamoDB のテーブルへ反映する仕組みを新しく設計しています。増減は 1 件ずつ別のメッセージとして送られ、1 つの商品は複数の店舗が扱います。同じ商品への増減は届いた順序どおりに反映する必要があり、繁忙期に増えるメッセージを並行して処理できることも求められます。 これらの要件を満たすにはどうすればよいですか。
順序を守る単位と並列度を両立させる、メッセージグループの決め方を選ぶ
送信時に連番を付け、受け取った側が連番の順に並べ替えてから反映する。
送信の順序を番号として持ち回れば、受け取った側で元の順序を復元できます。キューの機能に頼らずに済むため、どんな構成でも使えます。
ただし、次の番号が届くまで手元のメッセージを保留する待ち合わせが必要になります。保留をどこに置くか、番号が飛んだままのメッセージをいつ打ち切るかまで処理する側のコードが抱えることになり、並行して進めるならその管理を複数の処理で共有する仕組みも要ります。順序をキューの側で保証できる以上、自前で抱える理由がありません。
Amazon SQS の FIFO キューを使い、店舗 ID をメッセージグループ ID に指定して送信する。
FIFO キューを選ぶ方向は正しく、同じメッセージグループの中では厳密な順序が保たれます。店舗ごとに見れば、その端末が送った順番どおりに処理されます。
しかし、順序が保証されるのはグループの中だけです。1 つの商品を複数の店舗が扱うため同じ商品への増減が複数のグループへ分かれ、店舗 A の減算と店舗 B の加算が入れ替わる余地が残ります。守りたい順序の単位と、グループの単位がずれています。送信元ごとにグループを分ける設計が合うのは、送信元ごとに送った順序だけを守ればよい場合です。
Amazon SQS の FIFO キューを使い、商品 ID をメッセージグループ ID に指定して送信する。
標準キューの順序はベストエフォートで、送信した順に届くとは限りません。順序を保証するには FIFO キューを使いますが、FIFO キューが厳密な順序を守るのは、メッセージグループの中です。したがってメッセージグループ ID には、順序を守りたい単位そのものを指定します。
ここで守りたいのは 1 つの商品に対する増減の前後関係なので、商品 ID を指定します。同じ商品のメッセージはどの店舗から届いても1 つのグループにまとまってキューに届いた順に処理され、商品が違えばグループが違うので並行して処理でき、順序と並列度の両方を満たせます。
Amazon SQS の FIFO キューを使い、メッセージグループ ID にはすべて同じ固定の文字列を指定する。
グループが 1 つしかないので、キューに届いた順序が全体として厳密に守られます。同じ商品への増減が入れ替わることもありません。
その代わり、1 つのメッセージグループを同時に扱えるのは 1 つのコンシューマーだけです。同じグループの次のメッセージは前のものが処理されるまで他のコンシューマーへ渡らないため、並行して処理できる数がグループの数、つまり 1 に固定されます。メッセージが増えても処理量が伸びず、繁忙期には滞留が生まれます。
順序が絡む設計では、「順序をどの単位で守るのか」を先に決めます。
・標準キューの順序はベストエフォートです。送信順に届くこともありますが、保証はありません。並べ替えを受信側で自作すると、待ち合わせと欠番の扱いが増えます。
・FIFO キューは厳密な順序を守りますが、その範囲はメッセージグループの中です。MessageGroupId は「この単位の中では前後を守ってほしい」という宣言だと考えます。
・グループの単位が守りたい単位とずれると（この問題の店舗 ID）、同じ対象への操作が複数のグループに散り、前後関係が決まりません。
・逆に単位を広く取りすぎると（固定の文字列で全件を 1 グループ）、そのグループを同時に扱えるコンシューマーは 1 つだけになります。
メッセージグループの数がそのまま並行して処理できる数の上限になるので、グループを細かく取れるほどスループットも伸びます。メッセージグループの粒度が、順序の保証範囲と並列度の両方を同時に決めると覚えておきましょう。
・実務では「注文 ID」「口座番号」「デバイス ID」のように、業務上の整合性を守りたい単位がそのままメッセージグループ ID になります。単位の候補が複数あるときは、「どの 2 件が入れ替わると困るか」を確かめると決まります。