非同期処理でスループットを上げる

導入

「すべての処理をリクエストが来たその場で完了させる」必要は、実は多くありません。応答をすぐ返し、重い処理は裏で進める——これが非同期化によるスループット向上の考え方です。

説明

Webアプリの多くは「読み取り」と「書き込み」で性能上のボトルネックが異なります。

• 読み取りの負荷対策：レッスン51のキャッシュ（ElastiCache/DAX）や、データベースの リードレプリカ で読み取り専用の複製を増やし、参照系のアクセスを分散します。
• 書き込みの負荷対策：SQS（第8章）で書き込みリクエストをいったんキューに バッファ し、バックエンドが処理能力の範囲内でさばく非同期処理に切り替えます。

flowchart LR
    U["利用者のリクエスト"] --> API["APIサーバー"]
    API -->|"すぐ応答を返す"| U
    API --> Q["SQSキュー"]
    Q --> W["Lambda/ワーカーが<br/>裏で非同期に処理"]

同期処理では「バックエンドの処理が終わるまで利用者を待たせる」ため、バックエンドの処理速度がそのままシステム全体のスループットの上限になります。非同期化すると、リクエストの受付とその後の処理を切り離せるため、受付側は瞬時に応答でき、全体としてより多くのリクエストをさばけるようになります。

さらに、IoTセンサーやクリックストリームのような「絶え間なく大量に発生するデータ」をリアルタイムで取り込みたい場合は、Amazon Kinesis を使います。SQSが「個々のジョブを1回ずつ処理する」ためのキューであるのに対し、Kinesisは 大量データの連続的なストリーミング処理（順序を保った複数コンシューマーでの並行読み取り、リアルタイム分析など）に特化しています。

読んでみよう

「スループットを上げたい」「同期処理がボトルネックになっている」と出たら、非同期化（SQS＋Lambda/ワーカー）とリードレプリカ／キャッシュの組み合わせを思い出しましょう。「大量のストリーミングデータをリアルタイムに処理したい」と明示されていればKinesisが正解候補です。