画像アップロードAPIに短時間の大量アクセスが発生する。画像変換はカスタムバイナリを使う長時間処理で、APIの応答を待たせずに実行したい。
取り込み側と処理側を別々にスケールし、処理待ちのジョブを失わずに吸収したい。
最も適切な構成はどれか。
SQSでアップロード受付と長時間の画像処理を非同期に分離し、キュー深さを指標に処理ワーカーだけをスケールする。
詳細解説
Kinesisは順序性を持つストリーム処理向けで、シャードと固定ワーカーの設計が必要になる。ジョブキューとして処理側をキュー深さに応じて独立スケールする要件には適さない。
Kinesisは順序性を持つストリーム処理向けで、シャードと固定ワーカーの設計が必要になる。ジョブキューとして処理側をキュー深さに応じて独立スケールする要件には適さない。
SNSは通知のファンアウトが主目的で、長時間ジョブの待ち行列として処理側を独立スケールさせる構成ではない。固定の同時実行数も突発的な滞留を解消しない。
SNSは通知のファンアウトが主目的で、長時間ジョブの待ち行列として処理側を独立スケールさせる構成ではない。固定の同時実行数も突発的な滞留を解消しない。
同期呼び出しではAPIとワーカーが結合し、処理時間が応答へ波及する。取り込み量と処理量を独立して調整できず、待ち行列も保持できない。
同期呼び出しではAPIとワーカーが結合し、処理時間が応答へ波及する。取り込み量と処理量を独立して調整できず、待ち行列も保持できない。
SQSが送信側と処理側を非同期に分離し、メッセージを一時保持する。ApproximateNumberOfMessagesVisibleなどを指標にワーカーを独立して増減できる。
SQSが送信側と処理側を非同期に分離し、メッセージを一時保持する。ApproximateNumberOfMessagesVisibleなどを指標にワーカーを独立して増減できる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
Amazon SQSのデカップリングと、キューのメッセージ数を使ったコンシューマーの水平スケールを確認する。
参考にした公式資料
確認できる内容
取り込み側は処理完了を待たず、キューに蓄積されたジョブを処理ワーカーが独立した台数で消化する。
理解のポイント
- Amazon SQS
- 非同期デカップリング
- キュー深さによるスケール
確認時の注意
- 確認環境:
- AWS公式SAA-C03ガイドと各サービスの公式ドキュメントで現行仕様を確認する。
基礎のおさらい
同期と非同期
応答を待つ必要がない長時間ジョブは、キューに預けて受付と処理を分離すると突発負荷を吸収しやすい。
スケール単位
取り込み側とコンシューマー側で異なる負荷指標を使い、必要なコンポーネントだけをスケールさせる。