【セッションレポート】同期という思い込み世界は非同期で構成されている（AWS-56）#AWSSummit

AWS Summit Japan 2024

#AWS

#セッションレポート

#非同期処理

平井裕二

2024.06.24

はじめに

AWS Summit Japan 2024 に参加しました。

「同期という思い込み世界は非同期で構成されている」のセッションレポートです。

セッション概要

サーバーレスサービスである API Gateway や Lambda を使って REST API を構築されている方は多いのではないでしょうか。サーバーレスで REST API をつくると、サーバーの確保作業や設定の手間から解放され、デフォルトの可用性が与えられるなどメリットは大きいです。そして、その効果を最大化させるのが非同期アーキテクチャです。サーバーの呪縛から解放されるサーバーレスの真価はここにあります。このセッションではさまざまなサーバーレスの非同期パターンを紹介するとともに、実際の顧客事例においてどのようなユースケースで非同期系サーバーレスが利用されているかをご紹介いたします。

セッションスピーカー：下川賢介

所属：アマゾンウェブサービスジャパン合同会社サービススペシャリスト統括本部アプリケーション開発技術本部

アジェンダ

身近な話から
非同期が求められる理由
非同期について
世界は非同期で構成されている

セッションレポート

身近な話から

日常の非同期になっているもの
- 宅配
  - 荷物を届ける→置き配←帰宅時に荷物を受け取る

非同期が求められる理由

イノベーションループ
1. ビジネスアイデア
2. 実験
3. 傾聴（1. ビジネスアイデンティへ）
アーキテクチャ結合度
小さなピースに分けてゆるく結合させたい = マイクロサービス
- 小さなピースをAPIで結合してみる
デリバリー速度の獲得
- マイクロサービスのメリットは、ビジネス変化に対応すること = デリバリー速度の獲得
  - ただし、APIは強いインターフェース契約があるため、APIサービスは頻繁な変更の対応が難しい

API利用者と提供者は、互いに依存する

API利用者はAPI提供者の公開内容に従って送信する必要がある。契約を守る
API提供者は、契約を破棄できない
- JSONスキーマを変えられない

仕様と実装の乖離が許されないAPI(契約)

API 仕様書（Swaggerなど）
契約は公開できるが、クライアントに対して強制は難しい

ビジネスが大きくなると、多様化、複雑化する依存関係となる。

同期的なAPIの課題

他のサービスの障害に影響を受ける
クライアントへの統一して提供が難しい
- 高スループット対策
- スロットリング対策
HTTPリソースやメソッドごとに要件が複雑になる

デリバリー速度の獲得に向けて、疎結合にマイクロサービスを組み立てるなら、非同期にゆるく結合してみては？という提案。

APIにおける様々な解決

本セッションでは、非同期と同期を対比構造で説明するが、本来同期と非同期は、排他の関係ではなく、適材適所でそれぞれ利用する。

非同期について

同期と非同期のアーキテクチャパターンの違い

同期（API）
1. クライアント → サービスA → サービスB
2. サービスB → サービスA → クライアント
非同期（イベント）
1. クライアント → サービスA
2. サービスA → クライアント、サービスA → サービスB

結合度を実例で確認

同期的なAPIの課題
- クライアント → プロデューサー（受注サービス）→ コンシューマ（発送サービスと会計サービス）
  - 発送サービスが障害になると、プロデューサにも影響を受ける。
    - 複数サービスが障害ポイント
    - サービスクオリティが低いものに引きづられる形で、全体のサービス品質が決まる
  - コンシューマに在庫サービスを追加した場合
    - プロデューサにもコード修正が必要になる。同期的にリリース作業しなければならない
非同期イベント
- クライアント → プロデューサ（受注サービス）→ イベント ← コンシューマ（発送サービスと会計サービス）
  - 各サービスは独立している。プロデューサとコンシューマは疎結合である
  - 品質、可用性はコンポーネントごとに設計できる
  - 発送サービスが障害になっても、他のサービスは影響を受けにくい
  - コンシューマに在庫サービスを追加した場合
    - プロデューサはコード修正不要

世界は非同期で構成されている(顧客事例を添えて)

4パターンを紹介する

非同期レスポンスパターン
- モバイル決済
トラフィックのコントロール
段階的なキャッシュ生成
- リアルタイムリコメンデーション
非同期による分割統治
セキュアなアップローダー

非同期レスポンスパターン

非同期では、クライアントがサービスAから受け取るのは、実際の処理結果ではない。どのようにサービスBの処理結果を受け取るのか？

非同期(イベント)
1. クライアント → サービスA
2. サービスA → クライアント、サービスA → サービスB

モバイル決済の構成

クライアントからのモバイル決済 → SQS → Lambda → API Gateway → WebSocket → 店舗POS
- フロントエンドのリクエストをLambdaで処理して、API Gatewayと店舗POSはWebSocketで接続されており、応答を返している

モバイル決済におけるイベント駆動の決済完了通知サービス

同期箇所）アプリ → 決済処理システム → API Gateway → Lambda → DynamoDB（決済完了内容を保存）
- 非同期箇所）DynamoDB Steams → Lambda → API Gateway → WebSocketによってアプリに通知
非同期では、クライアントがサービスAから受け取るのは、実際の処理結果ではない。どのようにサービスBの処理結果を受け取るのか？
- WebSocketによるサーバーサイドプッシュで返せる

API と WebSocketによる応答性向上

クライアント → API Gateway → SQS → Lambda（API Gatewayを介してクライアントにサーバーサイドプッシュ）
- クライアントからAPI Gateway経由で常にWebSocket接続されている
- クライアントからAPI Gatewayは同期。SQS以降は非同期である

トラフィックのコントロール

プロビジョン
- 予想したリクエスト量より少ないと、余剰リソースになる
- 予想したリクエスト量より多いと、さばけない
オートスケール
- タイムラグにより、リクエストが落ち着いているが余剰リソースとなることがある
サーバレス
- リクエストに応じてスケールさせることができる

店舗での音楽のチャンネル選曲とプレイリスト配信サービス

店舗の雰囲気や時間帯、天候に合わせたBGMを提供する
- データセンターの楽曲管理や配信処理 → API Gateway → SQS → Lambda

トラフィックの方向性は２つある

クライアントからサービスまでのトラフィック
- ここを深堀りする
サービス間のトラフィックコントロール
クライアント　→ API Gateway → トラフィックの終端
- クライアントからサービスまでのトラフィックにおいて、トラフィックの終端をできるだけクライアントに寄せる
- キューやストリームでトラフィックを終端させて、HTTP status 202を返却する
  - クライアント → SQS → API Gateway → トラフィックの終端
- CDNを前段に配置しキャッシュを返却する
  - クライアント　→ CloudFront → API Gateway → トラフィックの終端

段階的なキャッシュ生成

キャッシュから応答できていれば高速なレスポンスになる
キャッシュ切れの場合、応答が遅延する

段階的なキャッシュ生成

キャッシュ更新指示を受けるキュー
- 同期リクエスト応答には、有効期限切れオブジェクトを返しつつ、SQSに更新命令する
  - SQSからトリガーされたLambdaが非同期でキャッシュを最新化する
  - 次回以降のキャッシュヒットでは、有効期限内のオブジェクト応答となる
- 厳密に最新さを求めらない場合に有効

段階的なキャッシュ生成の構成

キャッシュ有効期限内のオブジェクト応答）
- クライアント→ API Gateway → Lambda → キャッシュ
  - 「クライアント→ API Gateway → Lambda → キャッシュ」　は同期
キャッシュ有効期限切れのオブジェクト応答）
- クライアント→ API Gateway → Lambda → SQS → Lambda → データストアで最新データを取得 + キャッシュを更新
  - 「SQS → Lambda → データストアで最新データを取得 + キャッシュを更新」」は非同期

非同期による分割統治

分割統治は、依存関係を少なくして、コンポーネントを分離し、それぞれを自律的に統治すること

小さくて大量のタスクを捌きたい

分散処理
再試行の管理を手軽にしたい

非同期による分割統治の構成例

S3 → SNS → SQS → Lambda → S3 → SNS → SQS → Lambda → S3 → SNS → SQS → .....
- 数珠つなぎにアーキテクチャを構成
- 「S3 → SNS → SQS → Lambda」のコンポーネントにおいて、独立してスケールできる。 = 分割統治
Step Functions
- 数珠つなぎのアーキテクチャ = Step Functionsワークフローでも実現できる
  - ワークフローで各コンポーネントのリトライ処理やエラーハンドリングが対応できる
- 軽量 Map Reduceは、Step Functionsで対応できる

セキュアなアップローダー

アップローダーとしての非同期パターン

API Gateway
- API Gatewayにはペイロードサイズ10MB制限がある
- API Gatewayは API操作の同期的なread/commandに専念してもらう
署名付きURLを発行することで、S3にアップロード可能
- write / uploadは、S3を対象にすることでスケール
署名付きなのでセキュア
- 署名付きURLを取得できるクライアントは、API Gatewayで認証済み

構成