Postgres LISTEN/NOTIFY スケーラビリティ分析

Postgres LISTEN/NOTIFY は 60k メッセージ/秒 にスケールできる

Postgres LISTEN/NOTIFY は 60,000 メッセージ/秒 まで処理でき、この機能はスケールしないという業界の常識に挑戦します。低ボリュームシグナリングのツールとしてしばしば否定されますが、適切なハードウェアと構成があれば、外部メッセージブローカーを必要とせず高スループット通知システムとして機能することをベンチマークが示しています。

ハードウェアと構成の依存関係

LISTEN/NOTIFY のハイパフォーマンスベンチマークは、基盤となるインフラストラクチャに大きく依存します。60k msg/s を達成するには、大規模な垂直スケーリングが必要です。あるベンチマークでは、96 コアと 384 GB の RAM を備えたデータベースサーバーを使用し、これらの結果が控えめなハードウェアでのデフォルト設定を代表しないことを示しています。

重要なパフォーマンス要因は次のとおりです：

• 垂直スケーリング: ピークスループットに到達するには、高いコア数と高い RAM が必要です。
• 接続管理: リクエストを行う接続の場所と数は、全体のレイテンシに大きく影響します。
• バッチング: クライアントがコマンドをバッチ処理してリクエストあたりのコストを分散させると、スループットが向上します。

技術的な制約と制限

スループットの観点でのスケーラビリティがあるにもかかわらず、LISTEN/NOTIFY には特定のユースケースに不適切になる可能性のある固有のアーキテクチャ上の制限があります：

• ペイロードサイズ制限: 通知データには 8,000 バイトのハードリミットがあります。この制限を超えるデータが必要な場合、システムはデータをテーブルに保存し、NOTIFY を介して行 ID のみを送信する必要があります。
• ディスク競合: LISTEN/NOTIFY を使ってカスタムキューを構築すると、特に AWS RDS のようなマネージドサービスでは、基盤となるテーブルで深刻なディスク競合と問題のある VACUUM 実行が発生する可能性があります。
• 運用の複雑さ: Postgres の内部構造の上に複雑なキューのセマンティクスを実装すると、エンジニアリングチームから「怖い」または標準外と見なされる可能性があり、SQS や Redis などの専用ツールを使用する場合と比較して、メンテナンスと所有が難しくなることがあります。

スケーリングに関する比較的視点

「スケーリング」に関する業界の見解は様々で、スケーリングは二元論ではなく連続体であると主張する人もいます。多くのアプリケーションでは、LISTEN/NOTIFY の上限は十分以上であり、主な利点は追加のサービスを管理する「DevOps税」を回避できることです。

"LISTEN/NOTIFY の上限は注意を払うほど小さいですが、多くのプロジェクトにとって十分であり、DB の他の部分との統合、その可用性、別のサービスとして DevOps する必要がないことから、単純に選択肢として却下すべきものではありません。"

逆に、極端なスケーラビリティが必要なシステムや、トラフィックの大規模なバーストに見舞われやすいシステムについては、リレーショナルデータベースの通知システムの固有の制限は、専用のメッセージブローカーと比較してリスクが高すぎると主張する人もいます。

トレードオフのまとめ

機能	LISTEN/NOTIFY	専用メッセージブローカー (SQS/Redis)
インフラストラクチャ	Postgres に統合	別サービス
整合性	DB データとの強い整合性	最終的な整合性 (通常)
複雑さ	初期設定が低く、カスタムキューの複雑さが高い	初期設定が高く、キューの運用複雑さが低い
ペイロード制限	8,000 bytes	はるかに大きい
スケーリングパス	垂直 (より大きなサーバー)	水平 (クラスター/分散)