PGO を使用して Amazon EKS での PostgreSQL デプロイを合理化する - AWS 規範ガイダンス
概要前提条件と制限アーキテクチャツールベストプラクティスエピックトラブルシューティング関連リソース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

PGO を使用して Amazon EKS での PostgreSQL デプロイを合理化する

Shalaka Dengale (Amazon Web Services)

概要

このパターンは、Crunchy Data の Postgres オペレーター (PGO) を Amazon Elastic Kubernetes Service (Amazon EKS) と統合して、クラウドネイティブ環境での PostgreSQL デプロイを合理化します。PGO は、Kubernetes で PostgreSQL データベースを管理するための自動化とスケーラビリティを提供します。PGO を Amazon EKS と組み合わせると、PostgreSQL データベースを効率的にデプロイ、管理、スケーリングするための堅牢なプラットフォームが形成されます。

この統合には、次のような主な利点があります。

  • 自動デプロイ: PostgreSQL クラスターのデプロイと管理を簡素化します。

  • カスタムリソース定義 (CRD): PostgreSQL 管理に Kubernetes プリミティブを使用します。

  • 高可用性: 自動フェイルオーバーと同期レプリケーションをサポートします。

  • 自動バックアップと復元: バックアップと復元プロセスを合理化します。

  • 水平スケーリング: PostgreSQL クラスターの動的スケーリングを有効にします。

  • バージョンアップグレード: 最小限のダウンタイムでローリングアップグレードできるようにします。

  • セキュリティ: 暗号化、アクセスコントロール、認証メカニズムを適用します。

前提条件と制限

前提条件

製品バージョン

  • Kubernetes バージョン 1.21～1.24 以降 (PGO のドキュメントを参照してください)。

  • PostgreSQL バージョン 10 以降。このパターンでは、PostgreSQL バージョン 16 を使用します。

制限事項

アーキテクチャ

ターゲットテクノロジースタック

  • Amazon EKS

  • Amazon Virtual Private Cloud (Amazon VPC)

  • Amazon Elastic Compute Cloud (Amazon EC2)

ターゲット アーキテクチャ

PGO を 3 つのアベイラビリティーゾーン、2 つのレプリカ、PgBouncer、PGO オペレーターとともに使用するためのアーキテクチャ。

このパターンでは、3 つのノードがある Amazon EKS クラスターを含むアーキテクチャを構築します。各ノードは、バックエンドの一連の EC2 インスタンス上で実行されます。この PostgreSQL セットアップはプライマリレプリカアーキテクチャに準拠しており、読み取り負荷の高いユースケースに特に効果的です。アーキテクチャには、以下のコンポーネントが含まれます。

  • プライマリデータベースコンテナ (pg-primary): すべての書き込み操作を指示するメインの PostgreSQL インスタンスをホストします。

  • セカンダリレプリカコンテナ (pg-replica): プライマリデータベースからデータをレプリケートし、読み取り操作を処理する PostgreSQL インスタンスをホストします。

  • PgBouncer: PGO に含まれている PostgreSQL データベース用の軽量接続プーラーです。これはクライアントと PostgreSQL サーバーの間に位置し、データベース接続の中継役として機能します。

  • PGO: この Kubernetes 環境で PostgreSQL クラスターのデプロイと管理を自動化します。

  • Patroni: PostgreSQL の高可用性設定を管理および自動化するオープンソースツールです。PGO に含まれています。Kubernetes で PGO とともに Patroni を使用すると、PostgreSQL クラスターのレジリエンスと耐障害性を確保する上で重要な役割を果たします。詳細については、Patroni のドキュメントを参照してください。

ワークフローのステップは次のとおりです。

  • PGO オペレーターのデプロイ: Amazon EKS で実行される Kubernetes クラスターに PGO オペレーターをデプロイします。これは、Kubernetes マニフェストまたは Helm チャートを使用して実行できます。このパターンでは、Kubernetes マニフェストを使用します。

  • PostgreSQL インスタンスの定義: オペレーターが実行されたら、カスタムリソース (CR) を作成して、PostgreSQL インスタンスの目的の状態を指定します。これには、ストレージ、レプリケーション、高可用性設定などの設定が含まれます。

  • オペレーター管理: CR などの Kubernetes API オブジェクトを通じてオペレーターをやり取りし、PostgreSQL インスタンスを作成、更新、または削除します。

  • モニタリングとメンテナンス: Amazon EKS で実行されている PostgreSQL インスタンスの状態とパフォーマンスをモニタリングできます。多くの場合、オペレーターはモニタリングのためにメトリクスとログ記録を提供します。必要に応じて、アップグレードやパッチ適用などの定期的なメンテナンスタスクを実行できます。詳細については、Amazon EKS ドキュメントの「クラスターのパフォーマンスをモニタリングし、ログを表示する」を参照してください。

  • スケーリングとバックアップ: オペレーターが提供する機能を使用して、PostgreSQL インスタンスをスケーリングし、バックアップを管理できます。

このパターンでは、モニタリング、メンテナンス、およびバックアップ操作については説明しません。

自動化とスケール

  • を使用して CloudFormation インフラストラクチャの作成を自動化できます。詳細については、Amazon EKS ドキュメントの「CloudFormationを使用して Amazon EKS リソースを作成する」を参照してください。

  • GitVersion または Jenkins のビルド番号を使用して、データベースインスタンスのデプロイを自動化できます。

ツール

AWS のサービス

  • Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。 

  • AWS Command Line Interface (AWS CLI) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。

その他のツール

  • eksctl は、Amazon EKS 上にクラスターを作成するためのシンプルなコマンドラインツールです。

  • 「kubectl」は、 Kubernetes クラスターに対してコマンドを実行するためのコマンドラインユーティリティです。

  • PGO は、Kubernetes での PostgreSQL データベース管理を自動化およびスケーリングします。

ベストプラクティス

スムーズで効率的なデプロイを確実に行うには、次のベストプラクティスに従ってください。

  • EKS クラスターを保護します。サービスアカウント (IRSA)、ネットワークポリシー、VPC セキュリティグループの AWS Identity and Access Management (IAM) ロールの使用など、EKS クラスターのセキュリティのベストプラクティスを実装します。EKS クラスター API サーバーへのアクセスを制限し、TLS を使用してノードと API サーバー間の通信を暗号化します。

  • Amazon EKS で実行されている PGO と Kubernetes のバージョン互換性を確保します。一部の PGO 機能では、特定の Kubernetes バージョンが要求される場合や、互換性の制限が生じる場合があります。詳細については、PGO ドキュメントの「Components and Compatibility」を参照してください。

  • CPU、メモリ、ストレージなど、PGO デプロイのリソース割り当てを計画します。PGO とそれが管理する PostgreSQL インスタンスの両方のリソース要件を考慮してください。リソースの使用状況をモニタリングし、必要に応じてリソースをスケーリングします。

  • 高可用性を実現するように設計します。高可用性を実現するように PGO デプロイを設計し、ダウンタイムを最小限に抑え、信頼性を確保します。複数のアベイラビリティーゾーンに複数の PGO レプリカをデプロイして、耐障害性を確保します。

  • PGO が管理する PostgreSQL データベースのバックアップおよび復元手順を適用します。Kubernetes および Amazon EKS と互換性がある PGO またはサードパーティーのバックアップソリューションが提供する機能を使用します。

  • PGO デプロイのモニタリングとログ記録を設定し、パフォーマンス、状態、イベントを追跡します。メトリクスのモニタリングには Prometheus、視覚化には Grafana などのツールを使用します。トラブルシューティングと監査のために PGO ログを取得するようログ記録を設定します。

  • PGO、PostgreSQL インスタンス、Kubernetes クラスター内のその他のサービス間の通信を許可するようにネットワークを適切に設定します。ネットワークポリシーの適用とトラフィックの分離には、Amazon VPC ネットワーク機能と、Calico や Amazon VPC CNI などの Kubernetes ネットワークプラグインを使用します。

  • パフォーマンス、耐久性、スケーラビリティなどの要素を考慮して、PostgreSQL データベースに適したストレージオプションを選択します。永続的ストレージには、Amazon Elastic Block Store (Amazon EBS) ボリュームまたは AWS マネージドストレージサービスを使用します。詳細については、Amazon EKS ドキュメントの「Amazon EBS で Kubernetes ボリュームを保存する」を参照してください。

  • などのInfrastructure as Code (IaC) ツールを使用して CloudFormation 、Amazon EKS での PGO のデプロイと設定を自動化します。EKS クラスター、ネットワーク、PGO リソースなどのインフラストラクチャコンポーネントを整合性、再現性、バージョン管理のためのコードとして定義します。

エピック

タスク説明必要なスキル

IAM ロールを作成します。

  1. AWS CLIで次のコマンドを使用して、IAM ロールを作成します。

    aws iam create-role \
    --role-name {YourRoleName} \
    --assume-role-policy-document '{
        "Version": "2012-10-17",		 	 	 
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Service": "eks.amazonaws.com"
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }' && \
aws iam attach-role-policy \
    --role-name {YourRoleName}\
    --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy && \
aws iam attach-role-policy \
    --role-name {YourRoleName}\
    --policy-arn arn:aws:iam::aws:policy/AmazonEKSServicePolicy && \
aws iam attach-role-policy \
    --role-name {YourRoleName}\
	    --policy-arn arn:aws:iam::aws:policy/CloudWatchFullAccess

  2. AWS マネジメントコンソールでロールを確認します。

    1. [IAM コンソール] を開きます。

    2. [ロール] を選択し、先ほど作成したロールを検索します。

    3. 次のポリシーがアタッチされていることを確認します。

      AmazonEKSClusterPolicy

      AmazonEKSServicePolicy

      CloudWatchFullAccess

AWS 管理者
タスク説明必要なスキル

Amazon EKS クラスターを作成します。

既にクラスターをデプロイしている場合は、このステップをスキップします。それ以外の場合は、eksctl、Terraform、または AWS アカウント を使用して Amazon EKS クラスターを現在の にデプロイします CloudFormation。このパターンでは、クラスターのデプロイに eksctl を使用します。

注記

このパターンでは、Amazon EKS のノードグループとして Amazon EC2 を使用します。を使用する場合は AWS Fargate、eksctl ドキュメントmanagedNodeGroupsの設定を参照してください。

  1. 次の eksctl 入力ファイルを使用してクラスターを生成します。

    sample-cluster.yaml:

    apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: postgresql
  region: us-east-1
  version: "1.29"
accessConfig:
  authenticationMode: API_AND_CONFIG_MAP
availabilityZones:
- us-east-1a
- us-east-1b
- us-east-1c
nodeGroups:
  - name: ng-1
    instanceType: m5.16xlarge
    desiredCapacity: 2
  - name: ng-2
    instanceType: m5.16xlarge
    desiredCapacity: 2
  - name: ng-3
    instanceType: m5.16xlarge
    desiredCapacity: 2
vpc:
  cidr: 192.168.0.0/16
  clusterEndpoints:
    publicAccess: true
  nat:
    gateway: HighlyAvailable
iamIdentityMappings:
  - arn: arn:aws:iam::<account-id>:role/<role-name> # update the IAM role ARN created in step 1
    username: <user-name> # Enter the user name per your choice
    noDuplicateARNs: false

  2. 次のコマンドを実行して、クラスターを作成します (sample-cluster.yaml ファイルへのファイルパスを指定します)。

    eksctl create cluster -f sample-cluster.yaml
AWS 管理者、Terraform または eksctl 管理者、Kubernetes 管理者

クラスターのステータスを検証します。

次のコマンドを実行して、クラスターのノードの現在のステータスを確認します。

kubectl get nodes

エラーが発生した場合は、Amazon EKS ドキュメントのトラブルシューティングセクションを参照してください。

AWS 管理者、Terraform または eksctl 管理者、Kubernetes 管理者
タスク説明必要なスキル

IAM OIDC プロバイダーを有効にします。

Amazon EBS Container Storage Interface (CSI) ドライバーの前提条件として、クラスターに既存の IAM OpenID Connect (OIDC) プロバイダーが必要です。

次のコマンドを使用して、IAM OIDC プロバイダーを有効化します。

eksctl utils associate-iam-oidc-provider --region={region} --cluster={YourClusterNameHere} --approve

このステップの詳細については、Amazon EKS のドキュメントを参照してください。

AWS 管理者

Amazon EBS CSI ドライバーの IAM ロールを作成します。

次の eksctl コマンドを使用して、CSI ドライバーの IAM ロールを作成します。

eksctl create iamserviceaccount \
  --region {RegionName} \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster {YourClusterNameHere} \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-only \
  --role-name AmazonEKS_EBS_CSI_DriverRole

暗号化された Amazon EBS ドライブを使用する場合は、ポリシーをさらに設定する必要があります。手順については、Amazon EBS SCI のドキュメントを参照してください。

AWS 管理者

Amazon EBS CSI ドライバーを追加します。

次の eksctl コマンドを使用して、Amazon EBS CSI ドライバーを追加します。

eksctl create addon \
  --name aws-ebs-csi-driver \
  --cluster <YourClusterName> service-account-role-arn arn:aws:iam::$(aws sts get-caller-identity \
  --query Account \
  --output text):role/AmazonEKS_EBS_CSI_DriverRole \
  --force
AWS 管理者
タスク説明必要なスキル

PGO リポジトリのクローンを作成します。

PGO の GitHub リポジトリのクローンを作成します。

git clone https://github.com/CrunchyData/postgres-operator-examples.git
AWS DevOps

サービスアカウント作成のためにロールの詳細を指定します。

Amazon EKS クラスターに必要な AWS リソースへのアクセスを許可するには、 service_account.yaml ファイルで前に作成した OIDC ロールの Amazon リソースネーム (ARN) を指定します。このファイルは、リポジトリの名前空間フォルダにあります。

cd postgres-operator-examples
---
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<accountId>:role/<role_name> # Update the OIDC role ARN created earlier
AWS 管理者、Kubernetes 管理者

名前空間と PGO の前提条件を作成します。

  1. 名前空間を作成するには、次のコマンドを実行します。

    kubectl apply -k kustomize/install/namespace

    これにより、PGO 専用の名前空間が確立されます。必要に応じて、namespace.yml ファイルを変更し、名前空間に別の名前を割り当てることができます。

  2. 次のコマンドを実行して、クラスターにデフォルト設定を適用します。

    kubectl apply --server-side -k kustomize/install/default

    kustomize/install/default は、Kubernetes ロールベースのアクセスコントロール (RBAC)、カスタムリソース定義 (CRD)、Kubernetes Manager ファイルのデフォルト設定を提供します。

Kunernetes 管理者

ポッドの作成を確認します。

名前空間とデフォルト設定が作成されていることを確認します。

kubectl get pods -n postgres-operator
AWS 管理者、Kubernetes 管理者

PVC を確認します。

次のコマンドを使用して、永続ボリュームのクレーム (PVC) を確認します。

kubectl describe pvc -n postgres-operator
AWS 管理者、Kubernetes 管理者
タスク説明必要なスキル

オペレーターを作成します。

/kustomize/postgres/postgres.yaml にあるファイルの内容を修正して、以下と一致させます。

spec:
  instances:
    - name: pg-1
      replicas: 3
  patroni:
    dynamicConfiguration:
      postgresql:
      pg_hba:
        - "host all all 0.0.0.0/0 trust" # this line enabled logical replication with programmatic access
        - "host all postgres 127.0.0.1/32 md5"
      synchronous_mode: true
  users:
  - name: replicator
    databases:
      - testdb
    options: "REPLICATION"

これらの更新により、以下が実行されます。

  • PostgreSQL 設定を調整して、PostgreSQL インスタンスへのアクセスを容易にします。

  • レプリケーションユーザー、データベースユーザー、スーパーユーザーの設定を含めて、ストリーミングレプリケーション、データベースアクセス、クラスター管理を有効にします。

AWS 管理者、DBA、Kubernetes 管理者

オペレーターをデプロイします。

PGO オペレーターをデプロイして、Kubernetes 環境での PostgreSQL データベースの効率的な管理とオペレーションを可能にします。

kubectl apply -k kustomize/postgres
AWS 管理者、DBA、Kubernetes 管理者

デプロイメントを確認する。

  1. オペレーターがデプロイされたことを検証します。

    kubectl get pods -n postgres-operator --selector=postgres-operator.crunchydata.com/instance-set \   -L postgres-operator.crunchydata.com/role

  2. オペレーターポッドに関連付けられたサービスリソースが作成されていることを確認します。

    kubectl get svc -n postgres-operator

コマンド出力を確認し、プライマリレプリカ (primary_pod_name) とリードレプリカ (read_pod_name) を書き留めます。これらは次のステップで使用します。

AWS 管理者、DBA、Kubernetes 管理者
タスク説明必要なスキル

プライマリレプリカにデータを書き込みます。

次のコマンドを使用して、PostgreSQL プライマリレプリカに接続し、データベースにデータを書き込みます。

kubectl exec -it <primary_pod_name> bash -n postgres-operator
psql
CREATE TABLE customers (firstname text, customer_id serial, date_created timestamp);
\dt
AWS 管理者、Kubernetes 管理者

リードレプリカに同じデータがあることを確認します。

PostgreSQL リードレプリカに接続し、ストリーミングレプリケーションが正しく機能しているかどうかを確認します。

kubectl exec -it {read_pod_name} bash -n postgres-operator
psql
\dt

リードレプリカには、前のステップでプライマリレプリカで作成したテーブルが必要です。

AWS 管理者、Kubernetes 管理者

トラブルシューティング

問題ソリューション

ポッドが起動しません。

  • 次のコマンドを使用して、ポッドの状態を検査します。

    kubectl get pods -n your-namespace

  • ログにエラーがないか検査します。

    kubectl logs your-pod-name -n your-namespace

  • ポッドに関連する異常なイベントがないかポッドイベントを確認します。

    kubectl describe pod your-pod-name -n your-namespace

レプリカがプライマリデータベースに対して大幅に遅延しています。

  • レプリケーションの遅延を確認します。

    SELECT * FROM pg_stat_replication;

  • レプリカに十分な CPU リソースとメモリリソースがあることを確認します。リソースの制限を確認します。

    kubectl describe pod your-replica-pod -n your-namespace

  • ストレージバックエンドが最適に動作していることを確認します。ディスク I/O が遅いとレプリケーションの遅延が発生する可能性があります。

PostgreSQL クラスターのパフォーマンスと状態を可視化できません。

  • Amazon CloudWatch Logs を有効にして、分析用のためにログが Amazon CloudWatch に送信されていることを確認します。詳細については、Amazon EKS のドキュメント参照してください。

  • pg_stat_activity を確認します。

    SELECT * FROM pg_stat_activity;

レプリケーションが機能しません。

  • postgresql.conf 内のレプリケーション設定を表示して、プライマリ設定を確認します。

    wal_level = replica
    max_wal_senders = 10
    wal_keep_size = 64  # or wal_keep_segments in older versions

  • pg_hba.conf にレプリケーションのアクセス許可が含まれていることを確認します。

    host replication replica_user all md5

  • レプリカ設定を確認します。recovery.conf または同等の設定 (standby.signal および primary_conninfo) がレプリカで正しく設定されていることを確認します。

関連リソース