Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for gitkado gitkado
November 08, 2025

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

Avatar for gitkado

gitkado

November 08, 2025
Tweet

More Decks by gitkado

Other Decks in Technology

Transcript

  1. 自己紹介: かど • プロダクトエンジニア • 所属: JAWS-UG Shimane • 趣味:

    旅行、スポーツ観戦、コーヒー • 好きなAWSサービス: SQS!!!! 【重要】Fair Queuesの導入実績無いです!
  2. なぜSQSが必要? Ans: システムの安定性とユーザー体験を向上させるため ➔ 大量アクセスを吸収 ◆ セール開始の注文殺到 → サーバーダウンを防ぐ ➔

    レスポンスを高速化 ◆ 重い処理は後回し → ユーザーには即座に「受付完了」 ➔ 障害に強いシステム ◆ 処理サーバーが停止 → メッセージは残るので後で再処理 ➔ サービス間連携 ◆ 適任サービスへ責務を移譲する中継機
  3. SQSのキュー戦略 • Standard Queue:【こちらが採用されるケース多い】 ◦ ベストエフォート順序(基本FIFO) ◦ 高スループット(無制限) ◦ $0.40

    / per Million requests
 • FIFO Queue: ◦ MessageGroupId内で厳密FIFO(テナント間は担保されない) ◦ テナント内でin-flightになるのは1つ(並列処理不可) ◦ スループットに上限あり(高スループットモードだと最大90k/s) ◦ $0.50 / per Million requests

  4. これまでの対策 ➔ 対策1: キューをテナントごとに分ける ◆ 管理が煩雑、テナントが増えるたびにインフラ変更、コスト増大 ➔ 対策2: プロデューサー側でレート制限を実装 ◆

    実装が複雑、テナントごとの流量制御ロジックのメンテが必要 ➔ 対策3: コンシューマーをひたすらスケール ◆ コスト効率が悪い、根本解決になっていない
  5. Fairの定義は事業によって異なる Tier、FIFO、利用量など重要視する部分は事業ごとに異なる(↓一例) • SaaS(マルチテナント) ◦ ex: 契約プランによてTierが分かれ上位が優遇される • EC、オークション ◦

    ex: 先に入札したユーザに権利が移る • 通信キャリア ◦ 帯域(有限資源)をユーザで共有している ◦ ex: 大量利用ユーザに通信制限をかける
  6. Fair Queuesで満たせないケース (1/2) • テナント毎に優越をつけられない ◦ プラン別のTier分けできない • 過去の利用状況を加味できない ◦

    直前まで大量利用してたテナントと初回利用したテナントが平等 ◦ 時間あたりの利用上限みたいなことは無理 ▪ ex: Claude usage limit reached. Your limit will reset at 1am. ◦ in-flightの件数を見ているので1件1件の重みも見ていない ▪ ex: token数じゃなくてreq数
  7. Fair Queuesで満たせないケース (2/2) • 他テナントが利用してなければ同じテナントを捌き続ける ◦ スロットリングされない ◦ 1社に対してスケールさせ続けると投資対効果合わなくなる ◦

    スケールトリガーが大切 ▪ ApproximateNumberOfMessag総数はやばい ▪ ApproximateAgeOfOldestMessage遅延時間なら問題ない • 仕様がブラックボックスなので細かく制御できない ◦ 処理順に対して温度感の高いケースでは選択しづらい ◦ Noisy判定されて遅延してる顧客から問い合わせが辛い
  8. Fair Queuesが輝くとき • ✅ 最適なユースケース ... Quiet優先のシンプルな公平性を実現 ◦ SaaSなど多数テナントが単一キューを共有 ◦

    公平性をシンプルに担保したい ◦ コンシューマーの改修を避けたい • ❌ 向かないケース ◦ 処理時間が極端に異なる ◦ 公平性への温度感が高く事業インパクトに直結する ◦ 厳密な順番保証が必要
  9. まとめ • 超簡単にマルチテナント考慮したQueueを利用できる • ただ、Fair Queuesは銀の弾丸というわけではない ◦ 期待値と効果が一致しているかは要確認 • Fair

    Queuesを聞いてもインパクト小さく感じるかもしれません ◦ これは問題が起きる前に張れる予防線です ◦ いつかのために非同期処理に保険をかけましょう <参考> https://aws.amazon.com/jp/blogs/compute/building-resilient-multi-tenant-systems-with-ama zon-sqs-fair-queues/