PostgresBenchがマネージドPostgresの高可用性コストを比較

ClickHouseは、マネージドPostgresの高可用性構成が性能へ与えるコストを比べるオープンソースベンチマークPostgresBenchを紹介しました。

要点

• 比較条件として、2分以内に復旧でき、データ損失を保証上ゼロにできることを高可用性と定義しています。
• ClickHouse Managed Postgres、Amazon RDS、CrunchyはPostgreSQLのストリーミング待機系、AuroraとNeonは共有ストレージ型として比較します。
• 同等のCPUとメモリーへそろえていますが、ストレージの物理条件が公開されないサービスもあり、結果は総合的な製品順位ではありません。
• ベンチマークは高可用性の性能コストを測るもので、運用機能、地域、価格、障害履歴まで評価するものではありません。

今回のブログ記事で語られていること

PostgresBenchが解こうとしているのは、単一ノードの最大性能ではなく、高可用性を有効にしたときに書き込みや読み取りがどれだけ変わるかという問題です。公式記事は、高可用性を「障害から2分以内に復旧できること」と「保証上のデータ損失がゼロであること」でそろえます。比較対象はClickHouse Managed Postgres、Amazon RDS for PostgreSQL、Crunchy Bridge、Amazon Aurora PostgreSQL-Compatible、Neonです。CPUとメモリーの規模をできるだけ合わせ、同じ負荷を実行します。

構成の違いも重要です。ClickHouse Managed Postgres、RDS、CrunchyはPostgreSQLのストリーミングレプリケーションを使う共有なし型です。ClickHouseの非同期待機系1台は小さなRPOを許容する構成で、RPOゼロにする場合は同期方式の待機系2台へクォーラム書き込みを行います。RDSも同期待機系を使います。一方、Auroraは分散共有ストレージに書き込み、Neonは計算とストレージを分離し、障害時に新しい計算ノードを立ち上げる方式です。同じ「HA」でも、書き込み確認の経路と復旧方法が違います。

この記事を読む際は、数値をサービス全体の優劣へ拡大しないことが大切です。公式記事自身も、比較しているのは同等の可用性と耐久性を得るための性能コストだと位置付けています。マネージドサービスではストレージのハードウェアや配置が完全には公開されず、価格、バックアップ、アップグレード、リージョン間復旧、サポート品質も同じ表には入りません。自社で再現する場合は、同期コミット設定、接続プール、データ量、チェックポイント、キャッシュ温度、フェイルオーバー中のエラー率を固定し、平常時のTPSだけでなく復旧時の挙動まで測る必要があります。

今回のブログ記事が関係する人

Postgres基盤を選定するアーキテクト、SRE、データベース管理者、可用性と性能の費用対効果を説明する調達・FinOps担当に関係します。

結局、今回のブログ記事をどう読むべきか

高可用性をラベルではなく、RPO、復旧時間、確認経路へ分解して比較する試みです。公開結果をそのまま採用するのではなく、自社の障害条件と書き込み特性を同じ設定で再現するための基盤として使うのがよいです。