アーキテクチャ

このセクションでは、KubernetesにPostgreSQLを展開するときに考慮する必要がある主なアーキテクチャの側面について説明します。

重要

CNCFブログ用に書いたタイトル Recommended Architectures for PostgreSQL in Kubernetes の記事を読むことをお勧めします。

重要

自己管理のKubernetes環境にPostgreSQLを展開する場合、 Kubernetesアーキテクチャ

クラウドネイティブの世界への旅行を計画し始めるときは、以下を参照してください。

状態の同期

PostgreSQLはデータベース管理システムであるため、Kubernetesで ステートフルワークロード として扱う必要があります。ステートレスアプリケーションは、主にトラフィックリダイレクションを使用して高可用性HAとディザスターリカバリーDRを実現しますが、データベースの場合、次のいずれかを採用して、できれば連続的かつ瞬間的な方法で、状態を複数の場所にレプリケートする必要があります2つの戦略

** ストレージレベルのレプリケーション*、通常は永続ボリューム

** アプリケーションレベルのレプリケーション*、この特定の場合PostgreSQL

CloudNativePGは、簡単な理由でアプリケーションレベルのレプリケーションに依存しています。PostgreSQLデータベース管理システムには、 ログの先行書き込みWAL配送 に基づいた堅牢で信頼性の高いビルトイン 物理レプリケーション 機能が付属しています。 10年以上、世界中の何百万ものユーザーが実稼働環境で使用していました。

PostgreSQLは、ネットワークを介した非同期および同期ストリーミングレプリケーションの両方と、非同期ファイルベースのログ配布通常はフォールバックオプションとして使用される、オブジェクトストアにWALファイルを保存するなどをサポートしています。レプリカは通常 スタンバイサーバー と呼ばれ、 ホットスタンバイ 機能のおかげで、読み取り専用のワークロードに使用することもできます。

重要

**PostgreSQLを使用したストレージレベルのレプリケーションはお勧めしません**が、CloudNativePGではその戦略を採用できます。詳細については、KubeCon NA 2022でのChris MilstedとGabriele Bartoliniによる Data On Kubernetes, Deploying And Running PostgreSQL And Patterns For Databases In a Kubernetes Cluster というタイトルの講演を参照してください。

このトピックが詳細にカバーされている場所。

Kubernetesアーキテクチャ

Kubernetesは、冗長、低遅延、プライベートネットワーク接続を介して相互に接続されている別の物理的な場所データセンター、障害ゾーン、またはより頻繁に アベイラビリティーゾーン としても知られる場所にまたがる可能性をネイティブに提供します。

分散システムであるため、単一ゾーンの障害に対するコントロールプレーンの復元力を高めるために、Kubernetesクラスターの推奨最小アベイラビリティーゾーンの数は3です。詳細については、

Running in multiple zones を参照してください。これは、

各データセンターが常にアクティブ であり、ワークロードを同時に実行できることを意味します。

注釈

パブリッククラウドプロバイダーのマネージドKubernetesサービスのほとんどは、各リージョンに3つ以上のアベイラビリティーゾーンを既に提供しています。

マルチアベイラビリティーゾーン Kubernetesクラスター

3つ以上のゾーンを備えたマルチアベイラビリティーゾーンのKubernetesアーキテクチャは、PostgreSQLの使用にお勧めします。このシナリオは、クラウドプロバイダーによって管理されるKubernetesサービスの一般的なシナリオです。

Kubernetes cluster spanning over 3 independent data centers

Kubernetes cluster spanning over 3 independent data centers

このようなアーキテクチャにより、CloudNativePGオペレーターは、すべてのアベイラビリティーゾーンをアクティブとして扱うことにより、単一のKubernetesクラスター内のゾーンにわたってCluster リソースのライフサイクル全体を制御できます。これには、他の操作の中で、宣言的方法でワークロードの スケジューリング が含まれますアフィニティルール、トレランス、ノードセレクターなど)、自動フェイルオーバー、自己修復、および更新。すべては、単一のKubernetesクラスター内のゾーンを超えてシームレスに動作します。

PostgreSQLアーキテクチャ を参照してください。

ストレージ、ワーカーノード、およびアベイラビリティーゾーンレベルでのシェアードナッシング展開を介して、同じKubernetesクラスター内でPostgreSQLクラスターをデザインする方法の詳細については、以下のセクションを参照してください。

さらに、追加の マルチアベイラビリティーゾーン Kubernetesクラスター を使用して「パッシブ」PostgreSQLレプリカクラスターをホストすることにより、それを利用できます。この場合のフェイルオーバーとプロモーションは手動で行う必要がありますが、これは主にDR、読み取り専用操作、またはクロスリージョンの可用性のために使用する必要があります。

単一のアベイラビリティーゾーン Kubernetesクラスター

Kubernetesクラスターにアベイラビリティーゾーンが1つだけある場合でも、CloudNativePGは、PostgreSQLデータベースのHAおよびDRの結果を向上させるための多くの機能を提供し、可能な限り単一障害点SPoFをゾーンのレベルにプッシュします。つまり、CloudNativePGクラスターに障害が発生する前に、ゾーンを停止する必要があります。

このシナリオは、1つのデータセンターのみが使用できる自己管理のオンプレミスのKubernetesクラスターの一般的なシナリオです。

単一のアベイラビリティーゾーン Kubernetesは、残念ながら、低遅延接続の届く範囲内で 2つのデータセンター のみが利用できる唯一の実行可能なオプションです。通常は同じ大都市圏。ゾーンが2つだけであると、ユーザーはマルチプルを作成できません。 -可用性ゾーンのKubernetesクラスター最小数の3ゾーンに到達しないため、アクティブ/パッシブ構成で2つの異なるKubernetesクラスターを作成することを強制します。2番目のクラスターは、主にディザスターリカバリーに使用されます。

Example of a Kubernetes architecture with only 2 data centers

Example of a Kubernetes architecture with only 2 data centers

ヒント

Kubernetesの取り組みの初期段階にある場合は、このドキュメントをインフラストラクチャチームと共有してください。 2つのデータセンターのセットアップは、従来のベアメタルまたはVMベースのインフラストラクチャからKubernetesへの「リフトアンドシフト」移行の結果である可能性があり、3+ゾーンシナリオでKubernetesが提供するメリットは知られていない可能性があります、またはインフラストラクチャアーキテクチャの設計時に対処されました。最終的に、他の2つに接続された3番目の物理的な場所は、日常の複雑さをアプリケーションレベルから物理的インフラストラクチャレベルに移動することにより、インフラストラクチャの全体的なコストを削減するため、組織にとって検討すべき有効なオプションを表す可能性があります。

PostgreSQLアーキテクチャ を参照してください。

ストレージおよびワーカーノードレベルのみでのシェアードナッシング展開を介して、単一のアベイラビリティーゾーンKubernetesクラスター内でPostgreSQLクラスターをデザインする方法の詳細については、以下のセクションを参照してください。 HAの場合、このようなシナリオでは、PostgreSQLインスタンスが別のワーカーノードに配置され、同じストレージを共有しないことがさらに重要になります。

DRの場合、追加の マルチアベイラビリティーゾーン Kubernetesクラスター を使用して「パッシブ」PostgreSQLレプリカクラスターをホストすることにより、SPoFを単一ゾーンより上にプッシュできます。このシナリオの他のKubernetesワークロードと同様に、Kubernetesクラスターのプライマリとしての昇格を手動で行う必要があります。以下で説明するように、オペレーターは単一のKubernetesクラスター内でのみ作業できるため、現時点ではCloudNativePGを使用するPostgreSQLでは利用できません。

PostgreSQLアーキテクチャ

CloudNativePGは、非同期および同期ストリーミングレプリケーションに基づいてクラスターをサポートし、次の仕様で同じKubernetesクラスター内の複数のホットスタンバイレプリカを管理します。

  • 1つのプライマリ、HA用のオプションの複数のホットスタンバイレプリカ

アプリケーションで使用可能なサービス -rw アプリケーションはクラスターのプライマリインスタンスにのみ接続します ``-ro`` アプリケーションは読み取り専用ワークロードのホットスタンバイレプリカにのみ接続します -r アプリケーションは読み取り専用ワークロードのインスタンスに接続します

PostgreSQLクラスターの復元力を向上させるために推奨されるシェアードナッシングアーキテクチャ PostgreSQLインスタンスは別のKubernetesワーカーノードに存在し、ネットワークのみを共有する必要があります。その結果、インスタンスはストレージを共有せず、できれば自分が作成したノードに接続されたローカルボリュームを使用する必要があります。で実行されます * PostgreSQLインスタンスは、同じKubernetesクラスター/リージョン内の異なるアベイラビリティーゾーンに存在する必要があります

次の図は、3つの異なるアベイラビリティーゾーンにまたがるPostgreSQLクラスターに推奨されるシェアードナッシングアーキテクチャの単純化したビューを提供し、それぞれがPostgreSQLデータ専用のローカルストレージを備えた別のノードで実行されます。

CloudNativePGは、クラスターのトポロジが変更された場合に、上記のサービスの更新を自動的に処理します。たとえば、フェールオーバーが発生した場合、-rw サービスを自動的に更新して昇格したプライマリをポイントし、アプリケーションからのトラフィックがシームレスにリダイレクトされるようにします。

参考

CloudNativePGが同期設定を含むPostgreSQLレプリケーションに依存する方法の詳細については、 レプリケーションユーザーについて を参照してください。

参考

同じKubernetesクラスター内のステートレスアプリケーションからCloudNativePGに接続する方法については、 アプリケーションから接続する を参照してください。

参考

接続プーラーとしてPgBouncerを利用し、アプリケーションとPostgreSQLクラスターの間にアクセスレイヤーを作成する方法については、 接続プーリング を参照してください。

読み取り/書き込みワークロード

アプリケーションは、次の図に示すように、Kubernetesオペレーターによって 現在のプライマリ として選択されたPostgreSQLインスタンスに接続することを決定できます。

Applications writing to the single primary

Applications writing to the single primary

アプリケーションは、 -rw サフィックスサービスを使用できます。

プライマリが一時的または永続的に使用不可になった場合、高可用性の目的で、CloudNativePGはフェイルオーバーをトリガーし、-rw サービスをクラスターの別のインスタンスをポイントします。

読み取り専用ワークロード

重要

アプリケーションは、次の制限に注意する必要があります Hot Standby

は、これらのワークロードを処理するときにPostgreSQLが動作する方法を示し、精通しています。

アプリケーションは、オペレーターが利用できる-ro サービスを介してホットスタンバイレプリカにアクセスできます。このサービスにより、アプリケーションはプライマリノードから読み取り専用クエリをオフロードできます。

次の図は、アーキテクチャを示しています。

Applications reading from hot standby replicas in round robin

Applications reading from hot standby replicas in round robin

アプリケーションは、 -r サービスを介してPostgreSQLインスタンスにアクセスすることもできます。

Kubernetesクラスター全体のデプロイメント

注釈

CloudNativePGは、このセクションで説明する**レプリカクラスター**と呼ばれる機能を介して、複数のKubernetesクラスターへのPostgreSQLの展開をサポートしています。

分散PostgreSQLクラスターでは、常にプライマリとして機能する1つのPostgreSQLインスタンスのみが存在できます。これは、アプリケーションが常に単一のKubernetesクラスター内にのみ書き込むことができることを意味します。

ただし、ビジネス継続性の目標に関しては、次のことが基本です。

  • PostgreSQLバックアップデータを複数の場所、リージョンに保存し、場合によっては異なるプロバイダーを使用することにより、グローバルな リカバリポイント目標 RPOを削減します ディザスターリカバリー

  • プライマリKubernetesクラスター高可用性を超えたPostgreSQLレプリケーションを利用することにより、グローバルな 目標復旧時間 RTOを削減します。

上記の懸念事項に対処するために、CloudNativePGは PostgreSQLレプリカクラスター の概念を導入しています。レプリカクラスターは、プライベート、パブリック、ハイブリッド、マルチクラウドのコンテキストでマルチクラスター展開を有効にするCloudNativePG方法です。

レプリカクラスターは別個のCluster リソースです。

  1. 定義された外部ソースクラスターからのbootstrap オプションとしてpg_basebackup または完全なrecovery のいずれかを持つ

  2. replica.enabled オプションをtrue に設定する

  3. replica.source で指定される定義された外部クラスターからの複製。通常はKubernetesクラスターの外部にあります

  4. リカバリオブジェクトストアPostgreSQLのrestore_command パラメーターを使用して、またはストリーミングレプリケーションを介してPostgreSQLのprimary_conninfo パラメーターを使用、または2つのいずれかから受け取ったWAL情報の再生 barmanObjectStore とconnectionParameters の両方が外部クラスターで定義されている場合

  5. PostgreSQLのホットスタンバイでサポートされている読み取り接続のみの受け入れ

参考

別のクラスター`externalClusters` セクションで定義からのPostgreSQLクラスターのクローン作成の詳細については、 Bootstrap を参照してください。

次の図は、2つの異なるKubernetesクラスターにまたがるPostgreSQLクラスターを示しています。プライマリクラスターは最初のKubernetesクラスターにあり、レプリカクラスターは2番目にあります。 2番目のKubernetesクラスターは、会社のディザスターリカバリークラスターとして機能し、災害が発生して最初のクラスターが使用不可になった場合にアクティブ化される準備が整います。

レプリカクラスターは、プライマリクラスターと同じアーキテクチャを持つことができます。プライマリインスタンスの代わりに、レプリカクラスターには 指定されたプライマリ インスタンスがあります。これは、ストリーミングレプリケーション対称アーキテクチャで任意の数のカスケードスタンバイサーバーを持つスタンバイサーバーです。

指定されたプライマリは、いつでも昇格でき、レプリカクラスターを、書き込み接続を受け入れることができるプライマリクラスターにすることができます。

警告

CloudNativePGは、現時点ではクラスター間のスイッチオーバーまたはフェイルオーバーを実行しません。このような操作は手動で実行するか、マルチクラスター/フェデレーションクラスター対応当局に委任する必要があります。各PostgreSQLクラスターは、他から独立しています。

上記の例で指定されたプライマリは、WALストリーミングprimary_conninfo を介してフィードされ、restore_command およびbarman-cloud-wal-restore を介したファイルベースのWAL配送のフォールバックオプションを使用します。

CloudNativePGでは、複数のレプリカクラスターを定義できます。より少ない数のレプリカクラスターを定義し、クラスターがプライマリに昇格したときにこの数を増やすこともできます。

参考

物理レプリカクラスターの動作と、さまざまなKubernetesクラスターで読み取り専用クラスターを構成して、グローバルディザスターリカバリーとHA戦略を向上させる方法の詳細については、 レプリカクラスター を参照してください。