APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > AWS > 【AWS】マルチテナントの観点からAmazon SQS Fairキューの登場した背景を整理する

【AWS】マルチテナントの観点からAmazon SQS Fairキューの登場した背景を整理する

AWS Amazon SQS

こんにちは、クラウド事業部の山路です。

今回は先日導入されたAmazon SQS Fairキューについて、導入の背景となったマルチテナント周辺の整理と簡単な検証を行いました。

aws.amazon.com

SQS Fairキュー概要

Amazon SQSはこれまで標準キュー、FIFOキューという2つのキューを提供していました。今回新たにFairキューという機能が追加され、マルチテナントにおけるノイジーネイバー問題に対応できるようになりました。具体的にどう対応できるかは後述します。

Fairキューは標準キューに対し MessageGroupId を付与したメッセージを送信することで利用可能です。SQSキューの作成画面ではFairキューは選択肢に表示されませんが、現在はFairキューの案内がアナウンスされています。

またFairキューの導入に合わせてCloudWatchメトリクスが追加されました。 ApproximateNumberOfNoisyGroups というメトリクスを使うことで、Fairキュー内部でノイジーと判定されたテナント数を表示できます。また従来のメトリクスに InQuietGroups というサフィックスが追加されたものがあり、こちらはノイジーテナントを排除した値が確認できます。

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2025/07/18/image-6-10.png

※AWS公式ブログより抜粋

マルチテナントとは

マルチテナントとは、ある1つのリソースを複数の独立したユーザー・グループが共有して使う形態のことを指します。近年はSaaSを提供する際に採用されることも多いアーキテクチャであり、O’Reilly社は『マルチテナントSaaSアーキテクチャの構築』という書籍も出版しています。

www.oreilly.co.jp

テナントとは、CLIやAPI・UIなどのインターフェイスを通じて、システムへのアクセス権を持つユーザー・グループの集まりを指します。上記書籍にあるテナントの説明文が分かりやすいと感じたので、一部抜粋します。

テナントという概念は、一棟の建物を所有し、それをさまざまなテナントに貸し出す集合住宅のイメージと非常によく似ています。このマインドセットでは、建物はソリューションの共有インフラストラクチャに例えられ、テナントは集合住宅のさまざまな居住者に例えられます。建物のテナントは、建物内の共有資源（電力、水など）を利用します。あなたは建物の所有者として、建物全体の管理と運営を行い、さまざまなテナントが出入りします。入居率は刻々と変わる可能性があります。

※『マルチテナントSaaSアーキテクチャの構築』P.24より抜粋

マルチテナントアーキテクチャを採用することで、コスト削減や運用効率の改善といったメリットを得られます。

  • コスト削減: AWSなどのクラウド環境では、複数のユーザー・グループ向けに共有リソースを提供することで、リソースによる従量課金コストを削減できます。
  • 運用効率の改善: 各ユーザーに専用のリソースを提供すると、運用作業時に環境の切り替え手順を踏む必要があり、作業効率の悪化やオペレーションミスにつながります。共有リソースを提供することでこれを回避できます。
  • リソース利用効率の向上: 提供するサービスの利用率は利用者によって異なります。各ユーザーに専用のリソースを提供すると余剰リソースが発生しやすいですが、共有リソースを提供することで使用率のばらつきを軽減できます。

AWSの案内するマルチテナントのパターン

マルチテナントは様々な観点から複数のモデルが提唱されています。AWSのホワイトペーパーや公式ブログでは、マルチテナントでリソースを分離するための3つのモデルを案内しています。

  • サイロモデル: テナントごとに個別のリソースを用意する。テナント間の分離レベルは最も高いが、マルチテナントによるコスト削減や運用効率向上のメリットは低下する。
  • プールモデル: 各テナントが共有するリソースを用意する。マルチテナントのメリットを享受できる一方、後述のノイジーネイバーなどの課題が発生する。
  • ブリッジモデル: サイロモデルとプールモデルを組み合わせ、一部テナント向け専用のリソースを用意しつつ、その他向けの共有リソースも提供する、といった構成を実現する。

aws.amazon.com

Amazon SQSを採用する場合も、基本的には上記3つのモデルから選択します。特にプールモデル・ブリッジモデルを採用することで、マルチテナントの利点を最大限生かせるでしょう。

※なおマルチテナントの考え方やSaaSの実装例、SaaSをAWSで実現する際の観点については、以下のような資料で紹介されています。

マルチテナントにSQSを使うときの課題

SQSを (特に) プールモデル・ブリッジモデルで採用する場合の課題となるのがノイジーネイバー問題です。これは、あるテナントが大量のリクエストを送信し、共有リソースを大量に消費することで、他のテナントへの処理が遅延してしまい、サービスレベルの低下を起こす現象です。Amazon SQSの場合、あるテナントから大量のメッセージが送信され、他のテナントからのメッセージの処理に遅延が発生する可能性があります。

ノイジーネイバーを回避する方法はいくつか考案・紹介されています。

  • リソースの分離: あるリソースをプールモデルからサイロモデルに変更することで、他テナントからの影響を受けなくする。
  • リソースの制限: テナントごとの利用できるリソース量を制限し、他テナントへの影響を緩和する (API GatewayのUsage plan + APIキー、ECS/EKSのコンテナリソース上限設定など)
  • リソースのスケーリング: リソース利用量の増加に合わせてスケールアウトし、影響を緩和する (EC2等のオートスケーリングなど)

AWS公式ブログでは、ノイジーネイバーを回避する方法として、「SQSの後段に配置するEC2/Lambdaなどのコンシューマーをスケーリングする」、「複数テナントがティアごとにキューを共有し、メッセージレートの設定やキューの分散などで影響を抑制する」、という2つを案内しています。

Fairキューが解消する課題

先日公開されたAmazon SQS Fairキューは、各テナントを識別するIDを MessageGroupId として付与したメッセージを識別し、特定のテナントIDがキューにたまると他のIDを持つメッセージを優先的に配信することで、ノイジーネイバー問題に対応します。

AWS公式ブログやドキュメントには以下のような図が掲載されており、Producer側で特定のテナントからのメッセージが集中すると、他のテナントからのメッセージを優先して処理する様子が書かれています。

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2025/07/18/image-2-15.png

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2025/07/18/image-3-13.png

※AWS公式ブログより抜粋

docs.aws.amazon.com

またAWSの公式ドキュメントでは、SQSのFIFOキューとFairキューとの違いについて紹介しています。SQSのFIFOキューを使うと、メッセージの処理順序を厳密に管理できるため、ノイジーネイバー問題に対応可能です。ただしFIFOキューでは各テナントのスループットが制限されるため、基本的にはFairキューを使うことが推奨されそうです。

FIFOキューは、各テナントからの送信中メッセージ数を制限することで、厳密な順序付けを維持します。これにより、ノイジーネイバーは回避されますが、各テナントのスループットは制限されます。フェアキューは、高スループット、短い滞留時間、そして公平なリソース割り当てが優先されるマルチテナントシナリオ向けに設計されています。フェアキューにより、複数のコンシューマーが同じテナントからのメッセージを同時に処理できると同時に、すべてのテナントで一貫した滞留時間を維持できます。

※AWS公式ドキュメントを日本語変換したものを掲載。

Fairキューを簡単に使ってみる

最後にSQS Fairキューを簡単に動かしてみます。今回はAWS CLIからメッセージの送受信を行い、 MessageGroupId が付与されている様子を確認するにとどめます。

先に適当な名称のSQSを標準キューで作成しておき、CloudShellからコマンドを実行しました。

[cloudshell-user@ip-10-135-14-37 ~]$ QUEUE_URL=https://sqs.ap-northeast-1.amazonaws.com/<AWS account ID>/sqs-fair-queue-test
[cloudshell-user@ip-10-135-14-37 ~]$ TENANT_ID="tenant-a"
[cloudshell-user@ip-10-135-14-37 ~]$ MESSAGE_BODY="This is a test message for ${TENANT_ID}."

# メッセージの送信
[cloudshell-user@ip-10-135-14-37 ~]$ aws sqs send-message \
>   --queue-url "$QUEUE_URL" \
>   --message-body "$MESSAGE_BODY" \
>   --message-group-id "$TENANT_ID" # MessageGroupIdを付与
{
    "MD5OfMessageBody": "a65e57385ea0990d952e5fbc7eb77ded",
    "MessageId": "fa78cbde-cc73-4ab4-b735-9271a60b8cc8"
}

# メッセージの受信
[cloudshell-user@ip-10-135-14-37 ~]$ aws sqs receive-message \
>   --queue-url "$QUEUE_URL" \
>   --max-number-of-messages 1 \
>   --attribute-names All
{
    "Messages": [
        {
            "MessageId": "fa78cbde-cc73-4ab4-b735-9271a60b8cc8",
            "ReceiptHandle": "AQEBCAlBm28x4lnzRUP7PX0yH/hFIPMpdBVueD9DgWPWmbXEYrKXbEZ+SLZcKZJ+hRZdQVv5AtkCi0O4fi3KEqlEJfrjb/WxDmMJGdFbv3mAAgOF36+THXk4utLbP8gd7dYEKSxKKQ5P5yYpSrAKhi9SUOcURclxGAK/z8jA914o3K/q1NUZ4d4PU5H21qzrqJbhe/yfnBhNrxVu1vHZ59JbupErQ8HT+rKmbfDx14LWI2sQ2zG6surkHOimMThmD2V2gt0Ofo2XNhif+RY7R1Bss0iaFEniF3Xtt5x94Lag/59dD137JNw+PkCAnfJselXUK6/M/fAr6yVmo9IeWOp7kNvospGwnBgJSLWxGeJZTfESPgcWq/BudpbPbm/CJUQVzdz9fD434FL21zkkeH70EPQslZ6lzCMhkhsfwfzU6Ek=",
            "MD5OfBody": "a65e57385ea0990d952e5fbc7eb77ded",
            "Body": "This is a test message for tenant-a.",
            "Attributes": {
                "SenderId": "AIDAIQ4CCWEDUNWNJ2JIY",
                "ApproximateFirstReceiveTimestamp": "1753857857924",
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1753857769582",
                "MessageGroupId": "tenant-a" # MessageGroupIdを確認できる
            }
        }
    ]
}
[cloudshell-user@ip-10-135-14-37 ~]$

さいごに

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。


その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp