読み取りレプリカ

ClickHouse Managed Postgres の読み取りレプリカを使用して、読み取り負荷の高いワークロードをスケール

読み取りレプリカを使用すると、プライマリの Managed Postgres データベースのコピーを 1 つ以上作成できます。これらのレプリカは、PostgreSQL のネイティブなレプリケーションを使用してプライマリ データベースに継続的に追従し、変更内容を常に反映します。

読み取りレプリカを管理するには、warehouse の編集アイコンをクリックします。

これにより warehouse ダイアログが開き、既存のサービスを確認したり、新しい読み取りレプリカを作成したりできます。

​

読み取りレプリカの管理

Read replicas ページでは、右上の Flow と Table のコントロールで切り替えられる 2 つのビューを利用できます。

Flow ビューにはレプリケーションのトポロジーが表示されます。上部にプライマリ インスタンスがあり、そこから各レプリカへ下向きの矢印で接続され、ティア、リージョン、ステータスをひと目で確認できます。

Table ビューには、各レプリカのサービス名、クラウドプロバイダーとリージョン、サービスのステータス、作成時刻、そして Detach service アクションが一覧表示されます。

新しいレプリカを作成するには、いずれかのビューの右上にある Create read replica をクリックします。

​

読み取りレプリカを使用する理由

​

スケーラビリティ

読み取りレプリカを使用すると、読み取り負荷の高いワークロードを複数の専用インスタンスに分散し、データベースを水平方向にスケールできます。これは、レポート用クエリ、分析処理、リアルタイムダッシュボードが本番トラフィックとリソースを奪い合うのを防ぐうえで、特に有効です。

​

分離

分析クエリやビジネスインテリジェンス向けのクエリを読み取りレプリカに振り分けることで、プライマリインスタンスは書き込み処理や重要なトランザクション処理に専念でき、高い応答性を維持できます。この分離により、システム全体のパフォーマンスと予測可能性が向上します。また、分析ツールやレポートツールに書き込み権限を付与する必要もありません。これらのツールはレプリカに対して安全に利用できるため、誤ってデータを変更してしまうリスクもありません。

​

事業継続

読み取りレプリカは、災害復旧において重要な役割を果たします。プライマリデータベースで障害が発生した場合は、読み取りレプリカをプライマリに昇格させることで、ダウンタイムとデータ損失を最小限に抑えられます。これにより、高可用性スタンバイに加えて、さらなる耐障害性を確保できます。

​

読み取りレプリカの仕組み

Managed Postgres の読み取りレプリカでは、ストリーミングレプリケーションではなく、WAL shipping アーキテクチャを採用しています。この設計は、プライマリデータベースへの影響を最小限に抑えることを重視したものです。

​

オブジェクトストレージを使用した WAL shipping

プライマリデータベースがトランザクションを処理すると、Write-Ahead Log (WAL) レコードが生成されます。これらの WAL セグメントは継続的にオブジェクトストレージ (S3) にアーカイブされます。読み取りレプリカは、プライマリとの同期を維持するため、オブジェクトストレージからこれらの WAL セグメントを取得して再生します。

このアーキテクチャは、プライマリへの直接接続を使用するストリーミングレプリケーションを利用する高可用性スタンバイとは異なります。

​

このアプローチを採用した理由

私たちは、読み取りレプリカがストリーミングスタンバイとしてプライマリに直接接続するのではなく、オブジェクトストレージから WAL を読み取るよう意図的に設計しました。このアプローチにより、読み取りレプリカとプライマリデータベースを完全に分離できます。

• プライマリでのレプリケーションのオーバーヘッドはゼロ: 読み取りレプリカはプライマリへのストリーミング接続を維持しないため、ミッションクリティカルなワークロードに CPU、メモリ、ネットワークの負荷を一切追加しません。
• 独立したスケーリング: プライマリのパフォーマンスにまったく影響を与えることなく、読み取りレプリカを追加または削除できます。
• ネットワーク分離: 読み取りレプリカは、接続先エンドポイントが分離された独自のネットワーク環境で動作します。

​

レプリケーションラグの特性

このアーキテクチャにおけるトレードオフは、レプリケーションラグです。WAL セグメントは一定間隔でプライマリからアーカイブされます (通常は 60 秒ごと、またはセグメントがいっぱいになった時点のいずれか早い方) 。そのため、通常の条件では、読み取りレプリカがプライマリに対して最大で数十秒遅れる可能性があります。

レポート、分析、ダッシュボードといった、ほとんどの読み取りスケーリングのユースケースでは、この遅延は許容範囲です。アプリケーションでほぼリアルタイムの読み取りが必要な場合は、クエリをプライマリに送れるか、またはこの時間内での結果整合性が要件を満たすかを検討してください。