SQS、RabbitMQ、Kafkaはもう忘れよう。Postgresを使えばいい。

日本語العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia한국어PortuguêsРусский中文
BBetter Stack
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00SQSやKafka、RabbitMQはもうお払い箱です。なぜなら、Postgres上で「PGMQ」を使えば
00:00:05キューを直接管理できるようになったからです。「そんなのスケールしない」という声が聞こえてきそうですが、
00:00:11実際のところ、Postgresは数百万行ものデータや
00:00:15毎秒数千件のリクエストを余裕で処理できるため、しっかりとスケールします。インフラをシンプルに保ちたいなら、
00:00:20本日はPGMQを使った大容量分散アプリの構築について見ていきましょう。
00:00:30それでは早速、デモに飛び込みましょう。Docker環境を構築し、PGMQをインストールしてあります。
00:00:34これには2つの利用方法があり、SQLのみを使用するか、RustやPythonといった公式クライアントライブラリのいずれかを利用できます。
00:00:41さらに、Rubyや複数のTypeScript向けなど、コミュニティによるライブラリも多数用意されています。
00:00:47言語の好みが分かれるところですので、今回はSQLのみのオプションを使ってデモを実行します。
00:00:52まずは新しいキューの作成から始めましょう。「select pgmq.create」を実行し、その後にキュー名を渡します。
00:00:58ここでのキューはそれぞれ独自のテーブルになっています。データベースを直接確認してみると、
00:01:04新しいテーブルが作成されているのが分かります。次に、キュー名とメッセージをJSON形式で指定して、
00:01:09キューにメッセージを送信できます。オプションで遅延時間を設定することも可能です。これによりメッセージはキューにプッシュされますが、
00:01:15例えば5秒間はコンシューマーが取得できません。これでキューにメッセージが入りました。
00:01:20それではコンシューマーで処理していきましょう。「read」コマンドを使って行います。「VT」とは可視性タイムアウト（Visibility Timeout）の略です。
00:01:26ここでは、読み込んだメッセージが30秒間ロックされ、他のプロセスが取得できなくなることを意味します。
00:01:31これが、PGMQが「正確に1回（exactly-once）」の配信を保証する仕組みです。「quantity」は読み込みたいメッセージの数です。
00:01:38制限時間内に削除やアーカイブが行われない場合、メッセージは再び可視状態に戻ります。それを実行するには、
00:01:44キューから削除してアーカイブテーブルに追加する「archive」を実行するか、単に
00:01:49「delete」を実行します。例えばここでは、IDが2のメッセージを削除しています。ちなみに、この内容が
00:01:54役に立ったと感じた方は、チャンネル登録をしていただけると非常に助かります。一人でも多くの開発者に役立つ無料コンテンツを
00:01:59作り続ける原動力になります。それでは、PGMQのストレステストを行ってみましょう。まず、キューに10万件の行を追加します。
00:02:06これにかかる時間は約0.4秒です。次に、100個のワーカーを起動し、それぞれが10件ずつバッチ処理でジョブを処理させ、
00:02:13すべての読み込みにどれくらいの時間がかかるかを見てみます。このテストでワーカーが行うのは、メッセージを読み込み、
00:02:18読み込んだ内容をログに記録し、削除することだけです。もちろん実際のアプリではそのデータで何らかの処理を行います。
00:02:23ですが、ここではPGMQのパフォーマンスを直接テストすることだけが目的です。そして、それは9秒で完了しました。
00:02:29各ワーカーは平均して毎秒111件のメッセージを処理し、全体を合わせると毎秒約11,100件のメッセージを処理しました。
00:02:37本番サービスを想定し、DockerコンテナのリソースはあえてCPU 2コア、メモリ2ギガバイトに制限しています。
00:02:44先ほどもお伝えした通り、クライアントライブラリを使用してPGMQを操作することも可能です。
00:02:49TypeScriptとPrismaを使えば、キューの作成、メッセージの送信、メッセージバッチの読み込みを行うことができ、
00:02:55Pythonでも同様の操作が可能です。余計な依存関係を増やしたくないのであれば、
00:03:01PGMQを使ってPostgres内で大規模なキューを本当に運用することができます。そして、この手法をさらに発展させ、
00:03:08スタックの大部分をPostgresに置き換える試みについては、こちらの動画で解説しています。

핵심 요약

Postgres上のPGMQを使用することで、外部の専用キューイングシステムを使わずに秒間11,100件を超える大規模メッセージ処理をインフラをシンプルに保ったまま構築できる。

하이라이트

  • Postgres上でPGMQを利用することで、専用のメッセージキューイングシステムを導入せずにキューを直接管理できる。

  • SQLを用いた操作のほか、Rust、Python、Ruby、TypeScriptなどの公式・コミュニティ製クライアントライブラリに対応している。

  • 可視性タイムアウト機能により、メッセージ読み込み時に30秒間ロックされ正確に1回のみの配信が保証される。

  • CPU 2コア・メモリ2GBの制限環境において、10万件のメッセージ処理を9秒間で完了し、秒間約11,100件のスループットを記録した。

타임라인

Postgresによるメッセージキュー管理とPGMQの概要

  • PGMQを使用することでPostgres上で直接メッセージキューを管理できる。
  • Postgresは数百万行のデータや毎秒数千件のリクエストを処理できるスケーラビリティを備えている。

SQSやKafkaなどの外部サービスに依存せず、インフラをシンプルに保ったまま大容量分散アプリケーションを構築する手法としてPostgresの活用が示されている。数百万行のデータ処理実績により、スケールに関する懸念を払拭している。

SQLを通じたキュー操作とメッセージのライフサイクル

  • キューはそれぞれ独自のテーブルとして作成される。
  • 可視性タイムアウト機能により指定時間内は他のプロセスからの取得がロックされる。
  • 処理完了後はメッセージを削除するかアーカイブテーブルへ移動させる。

SQLコマンドを用いて新しいキューの作成やJSON形式でのメッセージ送信が行われる。遅延時間の設定によりコンシューマーによる取得タイミングの制御が可能である。また、可視性タイムアウトにより正確に1回のみの配信が保証される仕組みが備わっている。

ストレステストによるパフォーマンス検証

  • 10万件の行追加が約0.4秒で完了する。
  • 100個のワーカーによるバッチ処理により秒間約11,100件のメッセージ処理を達成した。
  • CPU 2コア・メモリ2GBの制約下での本番想定環境でテストを実施している。

大規模な負荷がかかる状況下でのパフォーマンスを計測するため、10万件のデータを用いたストレステストが実行されている。各ワーカーが平均して秒間111件のメッセージを処理し、全体として9秒間で全処理を完了している。

多様なクライアントライブラリと実用性

  • TypeScriptやPythonなどのクライアントライブラリを用いた操作に対応している。
  • 余分な依存関係を増やさずにPostgres内で大規模なキュー運用が可能である。

SQLだけでなく、TypeScriptとPrismaあるいはPythonなどの言語環境からもキューの作成やメッセージ送受信が可能である。インフラの複雑さを軽減しつつ、Postgresを軸としたスタック構築の選択肢を提示している。

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기