Fair Queuesで実現する公平なマルチテナントキューイング戦略

Transcript

1. @gitkado Fair Queuesで実現する 公平なマルチテナントキューイング戦略 JAWS-UG Shimane vol.14
2. 自己紹介: かど • プロダクトエンジニア • 所属: JAWS-UG Shimane • 趣味: 旅行、スポーツ観戦、コーヒー • 好きなAWSサービス: SQS!!!! 【重要】Fair Queuesの導入実績無いです！
3. 今日お話しすること • SQSとキュー戦略 • マルチテナントの課題 • Fair Queues(強み、弱み、使い所) • まとめ
4. Amazon SQS 使ったことある人？
5. Amazon SQS - メッセージキューサービス • AWSがフルマネージドにシステム間のメッセージを受け渡し • システムを疎結合にし、非同期処理を実現
6. なぜSQSが必要？ Ans: システムの安定性とユーザー体験を向上させるため ➔ 大量アクセスを吸収 ◆ セール開始の注文殺到 → サーバーダウンを防ぐ ➔ レスポンスを高速化 ◆ 重い処理は後回し → ユーザーには即座に「受付完了」 ➔ 障害に強いシステム ◆ 処理サーバーが停止 → メッセージは残るので後で再処理 ➔ サービス間連携 ◆ 適任サービスへ責務を移譲する中継機
7. SQSのキュー戦略 • Standard Queue:【こちらが採用されるケース多い】 ◦ ベストエフォート順序(基本FIFO) ◦ 高スループット(無制限) ◦ $0.40 / per Million requests
 • FIFO Queue: ◦ MessageGroupId内で厳密FIFO(テナント間は担保されない) ◦ テナント内でin-flightになるのは1つ(並列処理不可) ◦ スループットに上限あり(高スループットモードだと最大90k/s) ◦ $0.50 / per Million requests

8. マルチテナントの課題 : ノイジーネイバー問題 • 複数のテナントが1つのキューを共同で利用する場合 ◦ あるテナント（Noisy）が長尺処理や大量投入すると ◦ 他のテナント（Quiet）の処理が遅延してしまう => in-flightが偏るとQuietの待ち時間が伸びて遅延につながる
9. これまでの対策 ➔ 対策1: キューをテナントごとに分ける ◆ 管理が煩雑、テナントが増えるたびにインフラ変更、コスト増大 ➔ 対策2: プロデューサー側でレート制限を実装 ◆ 実装が複雑、テナントごとの流量制御ロジックのメンテが必要 ➔ 対策3: コンシューマーをひたすらスケール ◆ コスト効率が悪い、根本解決になっていない
10. Fair Queuesとは • SQS(Standard Queue)に追加されたオプション機能【2025年7月】 • 超簡単にノイジーネイバー問題を解消する ◦ ラウンドロビンではなく目立った不公平を補正する • $0.10 / per Million requests ※ Queue利用料は別途発生
11. 公平性の判断ロジック • テナントごとのin-flightメッセージ数を監視 • アンバランスを検知したらQuietテナントを優先配信 ◦ アンバランス...特定テナントが多くのin-flightを占有している状態 ◦ Noisyテナントも空きがあれば配信される（≠Noisy排除）
12. 利用方法 • プロデューサーでMessageGroupIdを追加しテナントを識別 • 投入後はSQSに任せておけばイイのでコンシューマー側の変更は不要 // After: MessageGroupIdを追加するだけ sqs.sendMessage({ QueueUrl: queueUrl, MessageBody: "...", MessageGroupId: "tenant-id-123" // テナント識別子 }); // Before sqs.sendMessage({ QueueUrl: queueUrl, MessageBody: "..." });
13. Fairの定義は事業によって異なる Tier、FIFO、利用量など重要視する部分は事業ごとに異なる（↓一例） • SaaS（マルチテナント） ◦ ex: 契約プランによてTierが分かれ上位が優遇される • EC、オークション ◦ ex: 先に入札したユーザに権利が移る • 通信キャリア ◦ 帯域(有限資源)をユーザで共有している ◦ ex: 大量利用ユーザに通信制限をかける
14. Fair Queuesで満たせないケース (1/2) • テナント毎に優越をつけられない ◦ プラン別のTier分けできない • 過去の利用状況を加味できない ◦ 直前まで大量利用してたテナントと初回利用したテナントが平等 ◦ 時間あたりの利用上限みたいなことは無理 ▪ ex: Claude usage limit reached. Your limit will reset at 1am. ◦ in-flightの件数を見ているので1件1件の重みも見ていない ▪ ex: token数じゃなくてreq数
15. Fair Queuesで満たせないケース (2/2) • 他テナントが利用してなければ同じテナントを捌き続ける ◦ スロットリングされない ◦ 1社に対してスケールさせ続けると投資対効果合わなくなる ◦ スケールトリガーが大切 ▪ ApproximateNumberOfMessag総数はやばい ▪ ApproximateAgeOfOldestMessage遅延時間なら問題ない • 仕様がブラックボックスなので細かく制御できない ◦ 処理順に対して温度感の高いケースでは選択しづらい ◦ Noisy判定されて遅延してる顧客から問い合わせが辛い
16. Fair Queuesが輝くとき • ✅ 最適なユースケース ... Quiet優先のシンプルな公平性を実現 ◦ SaaSなど多数テナントが単一キューを共有 ◦ 公平性をシンプルに担保したい ◦ コンシューマーの改修を避けたい • ❌ 向かないケース ◦ 処理時間が極端に異なる ◦ 公平性への温度感が高く事業インパクトに直結する ◦ 厳密な順番保証が必要
17. まとめ • 超簡単にマルチテナント考慮したQueueを利用できる • ただ、Fair Queuesは銀の弾丸というわけではない ◦ 期待値と効果が一致しているかは要確認 • Fair Queuesを聞いてもインパクト小さく感じるかもしれません ◦ これは問題が起きる前に張れる予防線です ◦ いつかのために非同期処理に保険をかけましょう <参考> https://aws.amazon.com/jp/blogs/compute/building-resilient-multi-tenant-systems-with-ama zon-sqs-fair-queues/