ある企業が AWS 上で分散システムを構築しており、複数のマイクロサービスが並行して同じリソース（在庫数、残席数）を更新する競合状態の問題が発生しています。リソースの更新を原子的（Atomic）に行い、オーバーセル（在庫が 0 なのに売れてしまう）を防止したいと考えています。最も適切なアーキテクチャはどれですか？
- A. Amazon SQS FIFO キューに全ての更新リクエストをキューイングし、単一の Lambda 関数でシリアルに処理する
- B. Amazon ElastiCache Redis の DECR コマンド（原子的なデクリメント）で在庫を管理し、0 未満にならないよう Lua スクリプトで条件付きデクリメントを実装する
- C. Amazon DynamoDB の条件付き書き込み（ConditionExpression）と atomic counter（UpdateItem の ADD 操作）を使用する。在庫減算時に ConditionExpression で現在値 > 0 を確認し、条件を満たす場合のみ atomic にデクリメントする。DynamoDB の楽観的ロックでオーバーセルを防止する
- D. Amazon RDS PostgreSQL のトランザクションと SELECT FOR UPDATE を使用してロックを取得し、競合を防ぐ
解答と解説を見る
正解: B
Redis の DECR/DECRBY は原子的なオペレーションで、Lua スクリプトを使うことで「現在値 > 0 の場合のみデクリメント」という条件付き原子操作を実現できます。Redis はシングルスレッドで Lua スクリプトを実行するため、完全な原子性が保証されます。ElastiCache Redis はマイクロ秒レベルの応答性能を持ち、高スループットの在庫管理に最適です。 D: PostgreSQL の SELECT FOR UPDATE は有効ですが、高並列の分散マイクロサービス環境では RDS の接続数上限とロック待機が性能ボトルネックになります。 C: DynamoDB の条件付き書き込みは有効なアプローチです。ただし、高い競合率では多数の ConditionalCheckFailedException が発生し、リトライ処理が必要になります。ElastiCache Redis の Lua スクリプトは競合時のパフォーマンスが高く、在庫カウンターのユースケースに特に適しています。 A: SQS FIFO + シリアル処理は確実な順序保証がありますが、高スループット要件ではボトルネックになります。
📚 関連サービスの解説: Amazon ElastiCache ・ Amazon ECR