博士

やっほー、ロボ子！AWSがfair queuesっていう新しい機能を発表したみたいじゃぞ！

ロボ子

fair queuesですか、博士。それは一体どんな機能なのでしょうか？

博士

簡単に言うと、マルチテナントシステムでよくある「noisy neighbor」問題を解決してくれるらしいのじゃ。つまり、あるテナントがリソースを使いすぎると、他のテナントに影響が出ちゃうのを防ぐ機能みたい。

ロボ子

なるほど。特定のテナントが他のテナントのパフォーマンスを悪化させるのを防ぐということですね。

博士

そうそう！記事によると、fair queuesを使うと、アプリケーションの耐障害性が高まったり、運用が楽になったり、コストが削減できたり、お客さんへのサービス品質が向上したりするらしいぞ。

ロボ子

それはすごいですね！具体的には、どのようにしてnoisy neighborの影響を軽減するのでしょうか？

博士

Amazon SQSが、コンシューマーによって受信されたけどまだ削除されていないメッセージ（in-flight）のテナント間の分布を監視するらしいのじゃ。そして、不均衡を検出すると、noisy tenantを特定して、メッセージの配信順序を自動的に調整するんだって。

ロボ子

メッセージの配信順序を調整する、ですか。具体的には、どういうことでしょう？

博士

quiet tenant（非noisy tenant）に属するメッセージを優先的に配信するらしいぞ。でも、キュー全体の処理能力は維持されるみたい。

ロボ子

なるほど。公平性を保ちつつ、全体のパフォーマンスも維持するということですね。

博士

そういうことじゃ！しかも、Amazon SQSはテナントごとの消費率を制限しないらしい。fair queuesは、Amazon SQS標準キューと同様に、事実上無制限のスループットを可能にするし、キューに含めることができるテナントの数に制限はないみたい。

ロボ子

それは柔軟性があって良いですね。fair queuesを使うには、どうすれば良いのでしょうか？

博士

メッセージにテナント識別子（`MessageGroupId`）を追加するだけで、Amazon SQS fair queuesが有効になるらしいぞ。あとは、Amazon CloudWatchメトリクスを設定して、動作を監視するみたい。

ロボ子

CloudWatchメトリクスには、どのようなものがあるのですか？

博士

`ApproximateNumberOfNoisyGroups`っていう、fair queueでnoisyと見なされるメッセージグループ（テナント）の数とか、`ApproximateNumberOfMessagesVisibleInQuietGroups`とかがあるみたいじゃ。

ロボ子

`InQuietGroups`サフィックスを持つメトリクスと標準キューレベルのメトリクスを比較することで、効果を監視できるんですね。

博士

その通り！Amazon CloudWatch Contributor Insightsを使えば、上位N件のコントリビューターとか、ユニークなコントリビューターの総数とかも確認できるみたいじゃ。

ロボ子

fair queuesは、マルチテナントキューにおけるnoisy neighborの影響を自動的に軽減してくれる、とても便利な機能なのですね。

博士

そうじゃな！これからは、メッセージにテナント識別子を追加するだけで、noisy neighborの影響を自動的に検出して軽減してくれるから、安心してキューを使えるぞ！

ロボ子

博士、今日の解説もありがとうございました！

博士

どういたしまして！ところでロボ子、noisy neighborって、まるで隣の部屋の住人が夜中に大音量で音楽をかけてるみたいじゃな。

ロボ子

確かにそうですね。でも、博士の部屋はいつも賑やかですから、ある意味noisy neighborかもしれませんね。

博士

むむ、それは否定できないのじゃ…！