Kafkaは速い — それでも私はPostgresを使う

 (topicpartition.io)
2 ポイント 投稿者 GN⁺ 2025-10-31 | 1件のコメント | WhatsAppで共有
  • Postgresのパブリッシュ/サブスクライブ（pub-sub） と キュー（queue） の性能をベンチマークし、単一データベースでもメッセージングシステムを置き換えられる可能性を提示
  • 単一の4vCPUノードで 毎秒5,036件の書き込み・25,183件の読み取り、3ノードのレプリケーション環境でも同様のスループットを維持し、エンドツーエンド遅延186ms（p99） レベル
  • 大型の96vCPUノードでは 書き込み238MiB/s、読み取り1.16GiB/s を達成し、CPU使用率10%未満で余裕のある処理を確認
  • キューテストでも単一ノード基準で 毎秒2,885件、レプリケーション環境でも 2,397件 を処理可能で、ほとんどの企業規模には十分な性能
  • 複雑な分散システムの代わりに Postgres単一インフラでも数MB/s規模のワークロードを処理できる可能性 を実証し、「必要になるまではシンプルな技術を使え」という実践的アプローチを強調

技術選択の二つの陣営

  • 技術業界は バズワード中心の陣営 と 常識中心の陣営 に分かれる
    • 前者は「リアルタイム」「無限スケール」「AIベース」などのマーケティング用語に惹かれる
    • 後者はシンプルさと実用性を重視し、不必要な複雑さを避ける
  • 最近は Small Data と Postgresルネサンス という二つの流れが後者を後押ししている
    • データは小さくなり、ハードウェアは強力になっている
    • Postgresは単一システムでさまざまな目的特化ソリューションを置き換えられる（jsonb, pgvector, tsvector など）

ベンチマーク概要

  • 目的: Postgresが pub/subメッセージング と キュー処理 でどの程度スケール可能かを測定
  • テスト環境: AWS EC2 c7i.xlarge（4vCPU）および c7i.24xlarge（96vCPU）
  • 三つの構成を比較
    • 単一ノード
    • 3ノードのレプリケーションクラスター
    • 大型単一ノード

Pub/Subベンチマーク結果

  • 4vCPU単一ノード
    • 書き込み4.8MiB/s（5,036msg/s）、読み取り24.6MiB/s（25,183msg/s）、遅延60ms（p99）
    • CPU使用率60%、ディスク書き込み46MiB/s
  • 4vCPU 3ノードレプリケーション
    • 書き込み4.9MiB/s、読み取り24.5MiB/s、遅延186ms（p99）
    • スループットを維持し、年間コストは約 $11,514
  • 96vCPU単一ノード
    • 書き込み238MiB/s（243kmsg/s）、読み取り1.16GiB/s（1.2Mmsg/s）、遅延853ms（p99）
    • CPU使用率10%未満で、ボトルネックはパーティションあたりの書き込み速度
  • 結論: 低〜中規模のワークロードではKafkaと競合できる水準 で、シンプルな構成でも数十MB/sを処理可能

キューベンチマーク結果

  • SELECT FOR UPDATE SKIP LOCKED ベースのシンプルなキュー実装
  • 4vCPU単一ノード
    • 2.81MiB/s（2,885msg/s）、遅延17.7ms（p99）、CPU使用率60%
  • 4vCPU 3ノードレプリケーション
    • 2.34MiB/s（2,397msg/s）、遅延920ms（p99）、CPU使用率60%
  • 96vCPU単一ノード
    • 19.7MiB/s（20,144msg/s）、遅延930ms（p99）、CPU使用率40〜60%
  • 単一ノードでもほとんどの企業のキュー処理量要件を満たせる

Postgresを使うべきかの判断

  • ほとんどの場合 Postgresをデフォルト選択にするのが合理的
    • SQLでメッセージのデバッグ、修正、結合が可能
    • Kafkaと比べて運用がシンプルで保守しやすい
  • Kafkaは高性能向けに最適化 されているが、小規模ワークロードには過剰な選択
  • Donald Knuthの「早すぎる最適化は諸悪の根源」という警句を引用
    • 数MB/sレベルまではPostgresで十分

最小実行インフラ（MVI）アプローチ

  • Minimum Viable Infrastructure: 組織がすでに慣れている技術で最小限のシステムを構築する
    • Postgresは広く採用されており、人材確保もしやすい
    • 構成要素が少ないほど障害や運用負荷が減る
  • 不要な技術導入は 組織的オーバーヘッド を招く
    • 学習、監視、デプロイ、運用コストが増加

スケーラビリティの議論

  • Postgresは実際にスケール可能
    • OpenAIはいまも 単一書き込みインスタンスベースのPostgres を使用
    • 数億人規模のユーザーに対しても安定運用できる
  • ほとんどの企業は成長速度が緩やかで、技術を置き換えるまでに数年の猶予 がある
  • 「バイラルに備えた設計」は過度な オーバーデザイン である
    • 「Coldplayの前座のためにMarshallアンプを買うようなものだ」という比喩を示す

結論

  • 「壊れるまでPostgresを使え」
    • シンプルな技術でも十分に高い性能を確保できる
    • 必要以上に複雑な分散システムを導入するのは非効率
    • Postgresは現代のハードウェアと組み合わせることで、ほとんどのワークロードに耐えられる実用的な選択肢 である

関連記事

1件のコメント

 
GN⁺ 2025-10-31
Hacker News の意見

  • パレートの法則をあらゆる状況に当てはめるのは誤った解釈である
    Postgres が Kafka より 20% の労力で 80% のユースケースを処理できると言うのは根拠のない主張である
    パレートの法則は べき乗則分布が現れる状況でのみ意味を持つ
    単に Postgres は十分に多くのユースケースをカバーでき、安定していて、実績のあるツールだと言えばよい

    • ただし、ユースケースと機能の対応関係そのものがべき乗則分布に従うのではないかという意見もある

  • 小規模（毎時数百イベント）から大規模（毎時数兆イベント）まで扱ってきた経験上、まず キューが本当に必要か から検討すべきである

    1. 単純に DB ポーリングで十分な場合もある
    2. 1 ノードで処理できるならサーバーレスや単一プロセスで対応可能である
    3. 分散キューが絶対に必要な状況でなければ、ロードバランシング + REST API + 非同期リトライでも十分である
    4. 本当に分散キューが必要なら、Kafka のような専用ソリューションを使うほうがよいと思う
    • Kafka は実際には キューではなく分散ログシステムであることを明確にすべきである。MQ の代替と誤解されることが多い
    • スタートアップでは、エンジニアが現在のプロジェクトよりも 次のキャリア を意識して複雑な技術を選ぶ傾向がしばしばある
    • コード構造を PostgreSQL ベースのキューと Kafka ベースのキューの両方に対応できるよう設計しておけば、後で移行しやすい
    • PostgreSQL は 書き込み負荷 が大きくなるとボトルネックになりやすい。UPDATE ストリームは特に厳しい
    • Java 開発者として、常にキューが必要だった。DB ポーリングは複数コンシューマー/プロデューサー環境では 頭痛の種 だった。Kafka の consumer group と partition は状態管理に大いに役立った

  • Postgres を万能用途に使うアプローチは危険である
    ロックと分離レベル は直感的ではなく、性能ボトルネックを生むことがある
    何十年も Postgres を使ってきたが、盲目的な信念で設計すべきではない

    • トラフィック急増時には 垂直スケーリングの限界 が問題になる。Kafka はトラフィックバーストを吸収するが、Postgres は簡単に過負荷になる
    • Postgres に 持続可能なキュー構造 が追加されるとよいのだが、Redis レベルを超えるスケーリングは難しく、LISTEN/NOTIFY はスケールしない (関連リンク)
    • 実際のところ、どのデータストアでも 並行性モデル を理解する必要がある。リレーショナル DB 同士でも大きな違いがある
    • Postgres は無限にスケールするのは難しいが、バッチ処理 と単一行単位の作業でかなり多くのデータを処理できる
    • 個人的には、まず Postgres で始めて、ボトルネックが出たらその時点で別システムに移行する戦略を取っている

  • SQL ベースの イベントログテーブル アプローチは有効だと思う
    ただし、クライアント側の ツール不足 が欠点である。Kafka はライブラリエコシステムが豊富なので、その点が強みである
    私たちの会社では、サービス間イベント配送を SQL ベースで標準化した (feedapi-spec)
    Kafka ほど成熟してはいないが、複数のストレージエンジンをサポートする共通ライブラリスタックへ発展する可能性がある

    • LLM ベースのコード生成ツールが進化したことで、こうした クライアントギャップ を埋めるのが容易になった
    • Kafka が嫌いな立場からすると、このアプローチのほうがずっと魅力的に見える

  • 最近の人はあまりにも 新しい技術 に惹かれる傾向がある
    Postgres は素晴らしいが、問題に合った道具 を使うべきである
    Postgres は pub-sub 用に設計されたわけではなく、Kafka はそのために作られた
    すべての製品が「何でもやろうとする」トレンドは避けるべきであり、それぞれ 一つのことをうまくやるツール のほうが良いと思う

  • 「単調増加オフセット番号」を実装するのは厄介な問題である
    単純なシーケンスはトランザクション順序とコミットタイミングがずれて問題を引き起こす

    • 一つの方法は カウンター専用テーブル を置き、同じトランザクション内でロックによって順序を保証することである (参考リンク)
    • Lamport Clock や Vector Clock を使って分散環境で順序を保証することもできる (Lamport timestamp, Vector clock)
    • 絶対的な順序を強制するより、バッチ単位 で番号を割り当てたり、コミット後に別プロセスが順序を付与したりする方式のほうが現実的である
    • SELECT FOR UPDATE SKIP LOCKED を使って重複処理を避ける方法もある

  • Kafka を実際にベンチマークしたのか疑問である
    96 vCPU 環境で得た結果は、Kafka の 4 vCPU 設定でも出せる
    Postgres の性能が 異常に遅い
    Kafka が不要なら使わなければよいが、Postgres で 5k msg/s を誇っても意味はない

    • Redpanda（Kafka 互換実装）は ノート PC でも毎秒 25 万メッセージ を処理する (動画リンク)
    • 288 vCPU 環境でそれより低い性能しか出ないのは無駄である
    • Postgres を使う理由が単に「すでにあるから」なら理解できるが、新しいインフラを追加する前の検証 は必要である
    • Kafka は少ないハードウェアでも ネットワーク帯域の限界 に達する
    • AWS で 24xlarge インスタンス 1 台で運用するのは非効率であり、そのコストがあれば 大規模な Kafka クラスター を運用できる

  • 「新技術に執着する人たち」と「学んだことだけに固執する人たち」という二つの極端がある
    現実的なエンジニアはその中間で 実用的な選択 をする

    • 私は三つ目のタイプで、「今あるものはどれもいまひとつだし、新しいものも結局いまひとつだろう」と考えるタイプである
    • 結局重要なのは、問題を合理的に見て 最適な解決策 を見つける姿勢である
    • 例えば Elasticsearch を Postgres で置き換えようとする試みは可能だが、検索機能の完成度 は ES のほうがはるかに高い

  • Kafka の中核機能は コンシューマーごとのオフセット制御 である
    複数チームが同じトピックを読む環境では必須の機能である
    オフセットを前後に調整できる点が何度も 命綱 になった
    Postgres キューでこうした機能をサポートできるのか気になる

    • 各コンシューマーが独自にオフセットを管理すればよいのではないかという意見もある
    • しかし多くの場合、高スループットが必要でなければ、Kafka の複雑なオフセット管理までは不要である
    • 結局は ビジネス要求の速度 と 運用の複雑さ のバランスの問題である

  • 「バズワードを追う陣営 vs 常識派」という構図そのものが間違っている
    Kafka を Postgres で再実装しようとするのは常識ではない
    本当に Kafka 級の機能が必要なら、そのまま Kafka を使えばよい

    • 実際には Kafka 全体を実装したのではなく、単純な pub-sub クエリ 2 つ を作っただけの事例だった