スピードとスケールを目的とした Amazon Simple Queue Service (SQS) の最適化

Amazon Simple Queue Service (Amazon SQS) は、いくつかのパブリックベータを経て 2006 年にローンチされました。20 年近く経った今でも、このフルマネージドサービスはマイクロサービス、分散システム、サーバーレスアプリケーションの基本的な構成要素であり、ピーク時には毎秒 1 億件を超えるメッセージを処理しています。

より良い方法は常に存在するので、パフォーマンス、セキュリティ、内部効率などを改善する方法の模索が続いています。AWS では、何かを改善できる可能性のある方法が見つかった場合、既存の動作を維持するように注意し、結果を比較できるように新しいシステムと古いシステムを並行して実行することがあります。

6月26日は、Amazon SQS が最近どのように改善され、レイテンシーの削減、フリートキャパシティの増強、スケーラビリティの限界の緩和、そして消費電力の削減が実現したかをお伝えします。

SQS の改善
多くの AWS のサービスと同様に、Amazon SQS は内部マイクロサービスのコレクションを使用して実装されます。6月26日は、そのうちの 2 つにフォーカスします。

お客様のフロントエンド – お客様が操作するフロントエンドは、CreateQueue や SendMessage などの API コールの受け入れ、認証、承認を行います。次に、各リクエストをストレージバックエンドにルーティングします。

ストレージバックエンド – この内部マイクロサービスは、標準 (非FIFO) キューに送信されたメッセージを永続化する役割を果たします。セルベースのモデルでは、セル内の各クラスターに複数のホストが含まれ、各カスタマーキューは 1 つまたは複数のクラスターに割り当てられ、各クラスターは多数のキューを処理します。

接続 — 新旧の比較
元の実装では、これらの 2 つのサービス間でリクエストごとに 1 つの接続を使用していました。各フロントエンドは多数のホストに接続しなければならないので、接続プールを使用する必要があることに加えて、オープンな接続の数が最終的に制限されるリスクもありました。このような問題はシンプルにハードウェアを増強してスケールアウトすることで解決できますが、それが常に最善の方法であるとは限りません。現在の瞬間 (「スケーラビリティの崖」) を先送りするだけではリソースを効率的に使用することにはなりません。

Amazon SQS チームは、いくつかの長期的なソリューションを慎重に検討した結果、お客様のフロントエンドとストレージバックエンドの間における独自の新しいバイナリフレーミングプロトコルを開発しました。このプロトコルは、128 ビットの ID とチェックサムを使用して 1 つの接続で複数の要求と応答を多重化し、クロストークを防ぎます。サーバー側の暗号化は、キューデータへの不正アクセスに対する保護をさらに強化します。

望ましい結果
新しいプロトコルは今年初めに実用化され、この記事を執筆している時点で 744 兆 9 千億件のリクエストが処理されました。スケーラビリティの壁は解消され、この新しいプロトコルを他の方法で機能させる方法が既に模索されています。

パフォーマンス面では、新しいプロトコルによりデータプレーンのレイテンシが平均で 11% 減少し、P90 マークで 17.4% 削減されました。この変更は、SQS 自体のパフォーマンスを向上させるだけでなく、SQS を基盤とするサービスにもメリットをもたらします。例えば、Amazon Simple Notification Service (Amazon SNS) を介して送信されるメッセージは、配信される前の「内部滞在」時間が 10% 短縮されました。最後に、プロトコルの変更により、SQS ホストの既存のフリート (X86 と Graviton を利用したインスタンスの混合) は、以前よりも 17.8% 多くのリクエストを処理できるようになりました。

その他の情報
Amazon SQS の実装の裏側はいががでしたか。コメント欄でお知らせください。他に共有できるストーリーが見つかるかもしれません。

– Jeff;

原文はこちらです。