GKE에 가용성이 높은 PostgreSQL 데이터베이스 배포

Autopilot Standard

PostgreSQL은 안정성과 데이터 무결성으로 알려진 오픈소스 객체 관계형 데이터베이스입니다. ACID를 준수하며 외래 키, 조인, 뷰, 트리거, 저장 절차를 지원합니다.

이 문서는 Google Kubernetes Engine((GKE)에서 고가용성 PostgreSQL 토폴로지 배포에 관심이 있는 데이터베이스 관리자, 클라우드 설계자, 운영 전문가를 대상으로 합니다.

목표

이 튜토리얼에서는 다음과 같은 방법을 알아봅니다.

Terraform을 사용하여 리전별 GKE 클러스터를 만듭니다.
가용성이 높은 PostgreSQL 데이터베이스를 배포합니다.
PostgreSQL 애플리케이션에 대한 모니터링을 설정합니다.
PostgreSQL 데이터베이스 및 GKE 클러스터 업그레이드를 수행합니다.
클러스터 중단 및 PostgreSQL 복제본 장애 조치를 시뮬레이션합니다.
PostgreSQL 데이터베이스의 백업 및 복원을 수행합니다.

아키텍처

이 섹션에서는 이 튜토리얼에서 빌드할 솔루션의 아키텍처를 설명합니다.

서로 다른 리전에 기본 클러스터와 백업 클러스터라는 두 개의 GKE 클러스터를 프로비저닝합니다. 이 튜토리얼에서 기본 클러스터는 us-central1 리전에 있고 백업 클러스터는 us-west1 리전에 있습니다. 이 아키텍처를 사용하면 튜토리얼 뒷부분에서 설명하는 고가용성 PostgreSQL 데이터베이스를 프로비저닝하고 재해 복구를 테스트할 수 있습니다.

소스 클러스터의 경우 Helm 차트(bitnami/postgresql-ha)를 사용하여 고가용성 PostgreSQL 클러스터를 설정합니다.

다이어그램에서는 가용성이 높은 PostgreSQL 클러스터의 아키텍처 예시를 보여줍니다. — **그림 1**: 가용성이 높은 PostgreSQL 클러스터의 아키텍처 예시

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

프로젝트 설정

Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

API Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM 사용 설정

API 사용 설정

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

API Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM 사용 설정

API 사용 설정

역할 설정

Google 계정에 역할을 부여합니다. 다음 각 IAM 역할에 대해 다음 명령어를 한 번씩 실행합니다. role/storage.objectViewer, role/logging.logWriter, role/artifactregistry.Admin, roles/container.clusterAdmin, role/container.serviceAgent, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin
```
$ gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS" --role=ROLE
```
- PROJECT_ID를 프로젝트 ID로 바꿉니다.
- EMAIL_ADDRESS를 이메일 주소로 바꿉니다.
- ROLE을 각 개별 역할로 바꿉니다.

환경 설정하기

이 튜토리얼에서는 Cloud Shell을 사용하여 Google Cloud에서 호스팅되는 리소스를 관리합니다. Cloud Shell에는 Docker, kubectl, gcloud CLI, Helm, Terraform을 포함하여 이 튜토리얼에 필요한 소프트웨어가 사전 설치되어 있습니다.

Cloud Shell을 사용해 다음과 같이 환경을 설정합니다.

Google Cloud 콘솔에서 Cloud Shell 활성화를 클릭하여 Google Cloud 콘솔에서 Cloud Shell 세션을 시작합니다. 그러면 Google Cloud 콘솔 하단 창에서 세션이 시작됩니다.
환경 변수를 설정합니다.
```
export PROJECT_ID=PROJECT_ID
export SOURCE_CLUSTER=cluster-db1
export REGION=us-central1
```
다음 값을 바꿉니다.
- PROJECT_ID: Google Cloud 프로젝트 ID입니다.
기본 환경 변수를 설정합니다.
```
gcloud config set project PROJECT_ID
```

코드 저장소를 클론합니다.

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

작업 디렉터리로 변경합니다.

cd kubernetes-engine-samples/databases/gke-stateful-postgres

클러스터 인프라 만들기

이 섹션에서는 Terraform 스크립트를 실행하여 커스텀 Virtual Private Cloud(VPC), PostgreSQL 이미지 저장을 위한 Artifact Registry 저장소, 리전별 GKE 클러스터 두 개를 만듭니다. 한 클러스터는 us-central1에 배포되고 백업용 두 번째 클러스터는 us-west1에 배포됩니다.

클러스터를 만들려면 다음 단계를 따르세요.

Autopilot

Cloud Shell에서 다음 명령어를 실행합니다.

terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply -var project_id=$PROJECT_ID

메시지가 표시되면 yes를 입력합니다.

Terraform 구성 이해

Terraform 구성 파일은 인프라를 배포하기 위해 다음 리소스를 만듭니다.

Docker 이미지를 저장할 Artifact Registry 저장소를 만듭니다.

resource "google_artifact_registry_repository" "main" {
  location      = "us"
  repository_id = "main"
  format        = "DOCKER"
  project       = var.project_id
}

VM의 네트워크 인터페이스에 대한 VPC 네트워크 및 서브넷을 만듭니다.

module "gcp-network" {
  source  = "terraform-google-modules/network/google"
  version = "< 8.0.0"

  project_id   = var.project_id
  network_name = "vpc-gke-postgresql"

  subnets = [
    {
      subnet_name           = "snet-gke-postgresql-us-central1"
      subnet_ip             = "10.0.0.0/17"
      subnet_region         = "us-central1"
      subnet_private_access = true
    },
    {
      subnet_name           = "snet-gke-postgresql-us-west1"
      subnet_ip             = "10.0.128.0/17"
      subnet_region         = "us-west1"
      subnet_private_access = true
    },
  ]

  secondary_ranges = {
    ("snet-gke-postgresql-us-central1") = [
      {
        range_name    = "ip-range-pods-db1"
        ip_cidr_range = "192.168.0.0/18"
      },
      {
        range_name    = "ip-range-svc-db1"
        ip_cidr_range = "192.168.64.0/18"
      },
    ],
    ("snet-gke-postgresql-us-west1") = [
      {
        range_name    = "ip-range-pods-db2"
        ip_cidr_range = "192.168.128.0/18"
      },
      {
        range_name    = "ip-range-svc-db2"
        ip_cidr_range = "192.168.192.0/18"
      },
    ]
  }
}

output "network_name" {
  value = module.gcp-network.network_name
}

output "primary_subnet_name" {
  value = module.gcp-network.subnets_names[0]
}

output "secondary_subnet_name" {
  value = module.gcp-network.subnets_names[1]
}

기본 GKE 클러스터를 만듭니다.

Terraform은 us-central1 리전에 비공개 클러스터를 만들고 재해 복구를 위한 Backup for GKE를 사용 설정하고 클러스터 모니터링을 위해 Managed Service for Prometheus를 사용 설정합니다.

Managed Service for Prometheus는 GKE 버전 1.25 이상을 실행하는 Autopilot 클러스터에서만 지원됩니다.

module "gke-db1-autopilot" {
  source                          = "../modules/beta-autopilot-private-cluster"
  project_id                      = var.project_id
  name                            = "cluster-db1"
  kubernetes_version              = "1.25" # Will be ignored if use "REGULAR" release_channel
  region                          = "us-central1"
  regional                        = true
  zones                           = ["us-central1-a", "us-central1-b", "us-central1-c"]
  network                         = module.network.network_name
  subnetwork                      = module.network.primary_subnet_name
  ip_range_pods                   = "ip-range-pods-db1"
  ip_range_services               = "ip-range-svc-db1"
  horizontal_pod_autoscaling      = true
  release_channel                 = "RAPID" # Default version is 1.22 in REGULAR. GMP on Autopilot requires V1.25 via var.kubernetes_version
  enable_vertical_pod_autoscaling = true
  enable_private_endpoint         = false
  enable_private_nodes            = true
  master_ipv4_cidr_block          = "172.16.0.0/28"
  create_service_account          = false
}

재해 복구를 위해 us-west1 리전에 백업 클러스터를 만듭니다.

module "gke-db2-autopilot" {
  source                          = "../modules/beta-autopilot-private-cluster"
  project_id                      = var.project_id
  name                            = "cluster-db2"
  kubernetes_version              = "1.25" # Will be ignored if use "REGULAR" release_channel
  region                          = "us-west1"
  regional                        = true
  zones                           = ["us-west1-a", "us-west1-b", "us-west1-c"]
  network                         = module.network.network_name
  subnetwork                      = module.network.secondary_subnet_name
  ip_range_pods                   = "ip-range-pods-db2"
  ip_range_services               = "ip-range-svc-db2"
  horizontal_pod_autoscaling      = true
  release_channel                 = "RAPID" # Default version is 1.22 in REGULAR. GMP on Autopilot requires V1.25 via var.kubernetes_version
  enable_vertical_pod_autoscaling = true
  enable_private_endpoint         = false
  enable_private_nodes            = true
  master_ipv4_cidr_block          = "172.16.0.16/28"
  create_service_account          = false
}

표준

Cloud Shell에서 다음 명령어를 실행합니다.

terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply -var project_id=$PROJECT_ID

메시지가 표시되면 yes를 입력합니다.

Terraform 구성 이해

Terraform 구성 파일은 인프라를 배포하기 위해 다음 리소스를 만듭니다.

Docker 이미지를 저장할 Artifact Registry 저장소를 만듭니다.

resource "google_artifact_registry_repository" "main" {
  location      = "us"
  repository_id = "main"
  format        = "DOCKER"
  project       = var.project_id
}
resource "google_artifact_registry_repository_iam_binding" "binding" {
  provider   = google-beta
  project    = google_artifact_registry_repository.main.project
  location   = google_artifact_registry_repository.main.location
  repository = google_artifact_registry_repository.main.name
  role       = "roles/artifactregistry.reader"
  members = [
    "serviceAccount:${module.gke-db1.service_account}",
  ]
}

VM의 네트워크 인터페이스에 대한 VPC 네트워크 및 서브넷을 만듭니다.

module "gcp-network" {
  source  = "terraform-google-modules/network/google"
  version = "< 8.0.0"

  project_id   = var.project_id
  network_name = "vpc-gke-postgresql"

  subnets = [
    {
      subnet_name           = "snet-gke-postgresql-us-central1"
      subnet_ip             = "10.0.0.0/17"
      subnet_region         = "us-central1"
      subnet_private_access = true
    },
    {
      subnet_name           = "snet-gke-postgresql-us-west1"
      subnet_ip             = "10.0.128.0/17"
      subnet_region         = "us-west1"
      subnet_private_access = true
    },
  ]

  secondary_ranges = {
    ("snet-gke-postgresql-us-central1") = [
      {
        range_name    = "ip-range-pods-db1"
        ip_cidr_range = "192.168.0.0/18"
      },
      {
        range_name    = "ip-range-svc-db1"
        ip_cidr_range = "192.168.64.0/18"
      },
    ],
    ("snet-gke-postgresql-us-west1") = [
      {
        range_name    = "ip-range-pods-db2"
        ip_cidr_range = "192.168.128.0/18"
      },
      {
        range_name    = "ip-range-svc-db2"
        ip_cidr_range = "192.168.192.0/18"
      },
    ]
  }
}

output "network_name" {
  value = module.gcp-network.network_name
}

output "primary_subnet_name" {
  value = module.gcp-network.subnets_names[0]
}

output "secondary_subnet_name" {
  value = module.gcp-network.subnets_names[1]
}

기본 GKE 클러스터를 만듭니다.

module "gke-db1" {
  source                   = "../modules/beta-private-cluster"
  project_id               = var.project_id
  name                     = "cluster-db1"
  regional                 = true
  region                   = "us-central1"
  network                  = module.network.network_name
  subnetwork               = module.network.primary_subnet_name
  ip_range_pods            = "ip-range-pods-db1"
  ip_range_services        = "ip-range-svc-db1"
  create_service_account   = true
  enable_private_endpoint  = false
  enable_private_nodes     = true
  master_ipv4_cidr_block   = "172.16.0.0/28"
  network_policy           = true
  cluster_autoscaling = {
    "autoscaling_profile": "OPTIMIZE_UTILIZATION",
    "enabled" : true,
    "gpu_resources" : [],
    "min_cpu_cores" : 36,
    "min_memory_gb" : 144,
    "max_cpu_cores" : 48,
    "max_memory_gb" : 192,
  }
  monitoring_enable_managed_prometheus = true
  gke_backup_agent_config = true

  node_pools = [
    {
      name            = "pool-sys"
      autoscaling     = true
      min_count       = 1
      max_count       = 3
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-4"
      node_locations  = "us-central1-a,us-central1-b,us-central1-c"
      auto_repair     = true
    },
    {
      name            = "pool-db"
      autoscaling     = true
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-8"
      node_locations  = "us-central1-a,us-central1-b,us-central1-c"
      auto_repair     = true
    },
  ]
  node_pools_labels = {
    all = {}
    pool-db = {
      "app.stateful/component" = "postgresql"
    }
    pool-sys = {
      "app.stateful/component" = "postgresql-pgpool"
    }
  }
  node_pools_taints = {
    all = []
    pool-db = [
      {
        key    = "app.stateful/component"
        value  = "postgresql"
        effect = "NO_SCHEDULE"
      },
    ],
    pool-sys = [
      {
        key    = "app.stateful/component"
        value  = "postgresql-pgpool"
        effect = "NO_SCHEDULE"
      },
    ],
  }
  gce_pd_csi_driver = true
}

재해 복구를 위해 us-west1 리전에 백업 클러스터를 만듭니다.

module "gke-db2" {
  source                   = "../modules/beta-private-cluster"
  project_id               = var.project_id
  name                     = "cluster-db2"
  regional                 = true
  region                   = "us-west1"
  network                  = module.network.network_name
  subnetwork               = module.network.secondary_subnet_name
  ip_range_pods            = "ip-range-pods-db2"
  ip_range_services        = "ip-range-svc-db2"
  create_service_account   = false
  service_account          = module.gke-db1.service_account
  enable_private_endpoint  = false
  enable_private_nodes     = true
  master_ipv4_cidr_block   = "172.16.0.16/28"
  network_policy           = true
  cluster_autoscaling = {
    "autoscaling_profile": "OPTIMIZE_UTILIZATION",
    "enabled" : true,
    "gpu_resources" : [],
    "min_cpu_cores" : 10,
    "min_memory_gb" : 144,
    "max_cpu_cores" : 48,
    "max_memory_gb" : 192,
  }
  monitoring_enable_managed_prometheus = true
  gke_backup_agent_config = true
  node_pools = [
    {
      name            = "pool-sys"
      autoscaling     = true
      min_count       = 1
      max_count       = 3
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-4"
      node_locations  = "us-west1-a,us-west1-b,us-west1-c"
      auto_repair     = true
    },
    {
      name            = "pool-db"
      autoscaling     = true
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-8"
      node_locations  = "us-west1-a,us-west1-b,us-west1-c"
      auto_repair     = true
    },
  ]
  node_pools_labels = {
    all = {}
    pool-db = {
      "app.stateful/component" = "postgresql"
    }
    pool-sys = {
      "app.stateful/component" = "postgresql-pgpool"
    }
  }
  node_pools_taints = {
    all = []
    pool-db = [
      {
        key    = "app.stateful/component"
        value  = "postgresql"
        effect = "NO_SCHEDULE"
      },
    ],
    pool-sys = [
      {
        key    = "app.stateful/component"
        value  = "postgresql-pgpool"
        effect = "NO_SCHEDULE"
      },
    ],
  }
  gce_pd_csi_driver = true
}

클러스터에 PostgreSQL 배포

이 섹션에서는 Helm 차트를 사용하여 GKE에서 실행할 PostgreSQL 데이터베이스 인스턴스를 배포합니다.

PostgreSQL 설치

클러스터에 PostgreSQL을 설치하려면 다음 단계를 수행합니다.

Docker 액세스를 구성합니다.

gcloud auth configure-docker us-docker.pkg.dev

Artifact Registry에 필요한 PostgreSQL Docker 이미지를 채웁니다.
```
./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r0
./scripts/gcr.sh bitnami/postgres-exporter 0.11.1-debian-11-r27
./scripts/gcr.sh bitnami/pgpool 4.3.3-debian-11-r28
```
스크립트가 설치할 Helm의 Artifact Registry에 다음 Bitnami 이미지를 푸시합니다.
- postgresql-repmgr: 이 PostgreSQL 클러스터 솔루션에는 PostgreSQL 클러스터에서 복제 및 장애 조치를 관리하기 위한 오픈소스 도구인 PostgreSQL 복제 관리자(repmgr)가 포함되어 있습니다.
- postgres-exporter: PostgreSQL 내보내기 도구는 Prometheus 소비에 대한 PostgreSQL 측정항목을 수집합니다.
- pgpool: Pgpool-II는 PostgreSQL 프록시입니다. 연결 풀링 및 부하 분산 기능을 제공합니다.

올바른 이미지가 저장소에 저장되었는지 확인합니다.

gcloud artifacts docker images list us-docker.pkg.dev/$PROJECT_ID/main \
    --format="flattened(package)"

출력은 다음과 비슷합니다.

---
image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/pgpool
---
image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/postgres-exporter
---
image: us-docker.pkg.dev/h[PROJECT_ID]/main/bitnami/postgresql-repmgr

기본 클러스터에 대한 kubectl 명령줄 액세스를 구성합니다.

gcloud container clusters get-credentials $SOURCE_CLUSTER \
--region=$REGION --project=$PROJECT_ID

네임스페이스를 만듭니다.

export NAMESPACE=postgresql
kubectl create namespace $NAMESPACE

Autopilot 클러스터에 배포하는 경우 3개 영역에 노드 프로비저닝을 구성합니다. 표준 클러스터에 배포하는 경우 이 단계를 건너뛸 수 있습니다.

기본적으로 Autopilot은 2개 영역에 리소스를 프로비저닝합니다. prepareforha.yaml에 정의된 배포를 통해 Autopilot은 다음 값을 설정하여 클러스터의 3개 영역에 노드를 프로비저닝합니다.

replicas:3
requiredDuringSchedulingIgnoredDuringExecution 및 topologyKey: "topology.kubernetes.io/zone"이 있는 podAntiAffinity

kubectl -n $NAMESPACE apply -f scripts/prepareforha.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prepare-three-zone-ha
  labels:
    app: prepare-three-zone-ha
    app.kubernetes.io/name: postgresql-ha
spec:
  replicas: 3
  selector:
    matchLabels:
      app: prepare-three-zone-ha
      app.kubernetes.io/name: postgresql-ha
  template:
    metadata:
      labels:
        app: prepare-three-zone-ha
        app.kubernetes.io/name: postgresql-ha
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - prepare-three-zone-ha
            topologyKey: "topology.kubernetes.io/zone"
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              - key: cloud.google.com/compute-class
                operator: In
                values:
                - "Scale-Out"
            weight: 1
      nodeSelector:
        app.stateful/component: postgresql
      tolerations:
      - effect: NoSchedule
        key: app.stateful/component
        operator: Equal
        value: postgresql
      containers:
      - name: prepare-three-zone-ha
        image: busybox:latest
        command:
            - "/bin/sh"
            - "-c"
            - "while true; do sleep 3600; done"
        resources:
          limits:
            cpu: "500m"
            ephemeral-storage: "10Mi"
            memory: "0.5Gi"
          requests:
            cpu: "500m"
            ephemeral-storage: "10Mi"
            memory: "0.5Gi"

Helm 종속 항목을 업데이트합니다.

cd helm/postgresql-bootstrap
helm dependency update

Helm이 설치할 차트를 검사하고 확인합니다.

helm -n postgresql template postgresql . \
  --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"

Helm 차트를 설치합니다.

helm -n postgresql upgrade --install postgresql . \
    --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"

출력은 다음과 비슷합니다.

NAMESPACE: postgresql
STATUS: deployed
REVISION: 1
TEST SUITE: None

PostgreSQL 복제본이 실행 중인지 확인합니다.

kubectl get all -n $NAMESPACE

출력은 다음과 비슷합니다.

NAME                                                          READY   STATUS    RESTARTS   AGE
pod/postgresql-postgresql-bootstrap-pgpool-75664444cb-dkl24   1/1     Running   0          8m39s
pod/postgresql-postgresql-ha-pgpool-6d86bf9b58-ff2bg          1/1     Running   0          8m39s
pod/postgresql-postgresql-ha-postgresql-0                     2/2     Running   0          8m39s
pod/postgresql-postgresql-ha-postgresql-1                     2/2     Running   0          8m39s
pod/postgresql-postgresql-ha-postgresql-2                     2/2     Running   0          8m38s

NAME                                                   TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)    AGE
service/postgresql-postgresql-ha-pgpool                ClusterIP   192.168.99.236    <none>        5432/TCP   8m39s
service/postgresql-postgresql-ha-postgresql            ClusterIP   192.168.90.20     <none>        5432/TCP   8m39s
service/postgresql-postgresql-ha-postgresql-headless   ClusterIP   None              <none>        5432/TCP   8m39s
service/postgresql-postgresql-ha-postgresql-metrics    ClusterIP   192.168.127.198   <none>        9187/TCP   8m39s

NAME                                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgresql-postgresql-bootstrap-pgpool   1/1     1            1           8m39s
deployment.apps/postgresql-postgresql-ha-pgpool          1/1     1            1           8m39s

NAME                                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/postgresql-postgresql-bootstrap-pgpool-75664444cb   1         1         1       8m39s
replicaset.apps/postgresql-postgresql-ha-pgpool-6d86bf9b58          1         1         1       8m39s

NAME                                                   READY   AGE
statefulset.apps/postgresql-postgresql-ha-postgresql   3/3     8m39s

테스트 데이터 세트 만들기

이 섹션에서는 샘플 값을 사용하여 데이터베이스와 테이블을 만듭니다. 데이터베이스는 이 튜토리얼의 뒷부분에서 테스트할 장애 조치 프로세스의 테스트 데이터 세트 역할을 합니다.

PostgreSQL 인스턴스에 연결합니다.

cd ../../
./scripts/launch-client.sh

출력은 다음과 비슷합니다.

Launching Pod pg-client in the namespace postgresql ...
pod/pg-client created
waiting for the Pod to be ready
Copying script files to the target Pod pg-client ...
Pod: pg-client is healthy

셸 세션을 시작합니다.

kubectl exec -it pg-client -n postgresql -- /bin/bash

데이터베이스와 테이블을 만든 다음 테스트 행을 삽입합니다.
```
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/generate-db.sql
```
각 테이블의 행 수를 확인합니다.
```
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql
```
출력은 다음과 비슷합니다.
```
select COUNT(*) from tb01;
 count
--------
 300000
(1 row)

select COUNT(*) from tb02;
 count
--------
 300000
(1 row)
```
팁: pgbench를 사용하여 더미 데이터를 만들 수도 있지만 쿼리 요청 트래픽을 보다 쉽게 구분하려면 제공된 스크립트를 사용하여 읽기/쓰기 테스트 중에 쿼리할 데이터베이스와 테이블을 만드는 것이 좋습니다.

테스트 데이터를 생성합니다.

export DB=postgres
pgbench -i -h $HOST_PGPOOL -U postgres $DB -s 50

출력은 다음과 비슷합니다.

dropping old tables...
creating tables...
generating data (client-side)...
5000000 of 5000000 tuples (100%) done (elapsed 29.85 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 36.86 s (drop tables 0.00 s, create tables 0.01 s, client-side generate 31.10 s, vacuum 1.88 s, primary keys 3.86 s).

postgres 클라이언트 포드를 종료합니다.
```
exit
```

PostgreSQL 모니터링

이 섹션에서는 PostgreSQL 인스턴스에 대한 측정항목을 보고 알림을 설정합니다. Google Cloud Managed Service for Prometheus를 사용하여 모니터링 및 알림을 수행합니다.

측정항목 보기

PostgreSQL 배포에는 postgresql-exporter 사이드카 컨테이너가 포함됩니다. 이 컨테이너는 /metrics 엔드포인트를 노출합니다. Google Cloud Managed Service for Prometheus는 이 엔드포인트에서 PostgreSQL 포드를 모니터링하도록 구성됩니다. Google Cloud 콘솔 대시보드를 통해 이러한 측정항목을 볼 수 있습니다.

Google Cloud 콘솔은 대시보드 구성을 만들고 저장하는 몇 가지 방법을 제공합니다.

만들기 및 내보내기: Google Cloud 콘솔에서 직접 대시보드를 만든 후 코드 저장소에 내보내고 저장할 수 있습니다. 이렇게 하려면 대시보드 툴바에서 JSON 편집기를 열고 대시보드 JSON 파일을 다운로드합니다.
저장 및 가져오기: +대시보드 만들기를 클릭하고 JSON 편집기 메뉴로 대시보드의 JSON 콘텐츠를 업로드하여 JSON 파일에서 대시보드를 가져올 수 있습니다.

PostgreSQL 애플리케이션과 GKE 클러스터에서 데이터를 시각화하려면 다음 단계를 따르세요.

다음 대시보드를 만듭니다.

cd monitoring
gcloud monitoring dashboards create \
        --config-from-file=dashboard/postgresql-overview.json \
        --project=$PROJECT_ID
gcloud monitoring dashboards create \
        --config-from-file dashboard/gke-postgresql.json \
        --project $PROJECT_ID

Google Cloud 콘솔에서 Cloud Monitoring 대시보드로 이동합니다. Cloud Monitoring 대시보드로 이동
대시보드 목록에서 커스텀을 선택합니다. 다음 대시보드가 표시됩니다.
- PostgreSQL 개요: 데이터베이스 업타임, 데이터베이스 크기, 트랜잭션 지연 시간을 포함한 PostgreSQL 애플리케이션의 측정항목을 표시합니다.
- GKE PostgreSQL 클러스터: CPU 사용량, 메모리 사용량, 볼륨 사용률 등 PostgreSQL이 실행되는 GKE 클러스터의 측정항목을 표시합니다.
각 링크를 클릭하여 생성된 대시보드를 확인하세요.

알림 설정

알림을 통해 애플리케이션의 문제를 적시에 파악하여 문제를 신속하게 해결할 수 있습니다. 알림 정책을 만들어 알림을 받을 상황과 방법을 지정할 수 있습니다. 또한 알림 채널을 만들어 알림이 전송되는 위치를 선택할 수도 있습니다.

이 섹션에서는 Terraform을 사용하여 다음 알림 예시를 구성합니다.

db_max_transaction: 트랜잭션의 최대 지연 시간(초)을 모니터링합니다. 값이 10을 초과하면 알림이 트리거됩니다.
db_node_up: 데이터베이스 포드의 상태를 모니터링합니다. 0은 포드가 다운되어 알림을 트리거함을 의미합니다.

알림을 설정하려면 다음 단계를 따르세요.

Terraform으로 알림을 구성합니다.

EMAIL=YOUR_EMAIL
cd alerting/terraform
terraform init
terraform plan -var project_id=$PROJECT_ID -var email_address=$EMAIL
terraform apply -var project_id=$PROJECT_ID -var email_address=$EMAIL

다음 값을 바꿉니다.

YOUR_EMAIL: 이메일 주소입니다.

출력은 다음과 비슷합니다.

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

클라이언트 포드에 연결합니다.

cd ../../../
kubectl exec -it --namespace postgresql pg-client -- /bin/bash

db_max_transaction 알림을 테스트하기 위한 부하 테스트를 생성합니다.

pgbench -i -h $HOST_PGPOOL -U postgres -s 200 postgres

출력은 다음과 비슷합니다.

dropping old tables...
creating tables...
generating data (client-side)...
20000000 of 20000000 tuples (100%) done (elapsed 163.22 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 191.30 s (drop tables 0.14 s, create tables 0.01 s, client-side generate 165.62 s, vacuum 4.52 s, primary keys 21.00 s).

알림이 트리거되고 '[알림] 최대 지연 시간'으로 시작하는 제목이 포함된 이메일을 YOUR_EMAIL로 전송합니다.

Google Cloud 콘솔에서 알림 정책 페이지로 이동합니다.

알림 정책으로 이동
나열된 정책에서 db_max_transaction을 선택합니다. 차트에서 Prometheus 측정항목 pg_stat_activity_max_tx_duration/gauge의 임곗값 10을 초과하는 부하 테스트에서 급증이 나타날 수 있습니다.
postgres 클라이언트 포드를 종료합니다.
```
exit
```

PostgreSQL 및 GKE 업그레이드 관리

PostgreSQL 및 Kubernetes의 버전 업데이트는 정기적으로 출시됩니다. 작업 권장사항에 따라 소프트웨어 환경을 정기적으로 업데이트하세요. 기본적으로 GKE는 클러스터 및 노드 풀 업그레이드를 자동으로 관리합니다.

PostgreSQL 업그레이드

이 섹션에서는 PostgreSQL의 버전 업그레이드를 수행하는 방법을 보여줍니다. 이 튜토리얼에서는 모든 포드가 다운되지 않도록 포드를 업그레이드하는 데 순차적 업데이트 전략을 사용합니다.

버전 업그레이드를 수행하려면 다음 단계를 따르세요.

postgresql-repmgr 이미지의 업데이트된 버전을 Artifact Registry로 푸시합니다. 새 버전을 정의합니다(예: postgresql-repmgr 15.1.0-debian-11-r1).
```
NEW_IMAGE=us-docker.pkg.dev/$PROJECT_ID/main/bitnami/postgresql-repmgr:15.1.0-debian-11-r1
./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r1
```

kubectl을 사용하여 순차적 업데이트를 트리거합니다.

kubectl set image statefulset -n postgresql postgresql-postgresql-ha-postgresql postgresql=$NEW_IMAGE
kubectl rollout restart statefulsets -n postgresql postgresql-postgresql-ha-postgresql
kubectl rollout status statefulset -n postgresql postgresql-postgresql-ha-postgresql

StatefulSet는 가장 높은 서수 복제본부터 가장 낮은 순서까지 순차적 업데이트를 완료합니다.

출력은 다음과 비슷합니다.

Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 1 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 2 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 3 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...

Standard 클러스터에서 GKE 업그레이드 계획

이 섹션은 Standard 클러스터를 실행하는 경우에 적용됩니다. 다음을 포함하여 스테이트풀(Stateful) 서비스를 실행할 때 위험을 줄이고 클러스터를 매끄럽게 업그레이드할 수 있도록 사전적인 단계를 수행하고 구성을 설정할 수 있습니다.

클러스터 업그레이드를 위한 GKE 권장사항을 따릅니다. 유지보수 기간 중 업그레이드가 수행되도록 적절한 업그레이드 전략을 선택합니다.
- 비용 최적화가 중요하고 워크로드가 60분 이내의 단계적 종료를 허용할 수 있는 경우 일시 급증 업그레이드를 선택합니다.
- 워크로드가 중단에 대한 내결함성이 낮고 리소스 사용량이 더 많아서 일시적으로 비용이 증가하는 경우 블루-그린 업그레이드를 선택합니다.
자세한 내용은 스테이트풀(Stateful) 워크로드를 실행하는 클러스터 업그레이드를 참조하세요.
추천자 서비스를 사용하여 서비스 중단을 방지하기 위해 지원 중단 통계 및 권장사항을 확인합니다.
의도한 시간에 업그레이드가 수행되도록 유지보수 기간을 사용합니다. 유지보수 기간 이전에 데이터베이스 백업이 성공적인지 확인합니다.
업그레이드한 노드로 트래픽을 허용하기 전 준비 프로브 및 활성 프로브를 사용하여 트래픽에 사용할 준비가 되었는지 확인합니다.
트래픽을 수락하기 전 복제가 동기화되었는지 여부를 평가하는 프로브를 만듭니다. 이 작업은 데이터베이스의 복잡성 및 스케일에 따라 커스텀 스크립트를 통해 수행할 수 있습니다.

Standard 클러스터 업그레이드 중 데이터베이스 가용성 확인

이 섹션은 Standard 클러스터를 실행하는 경우에 적용됩니다. 업그레이드 중 PostgreSQL 가용성을 확인하기 위한 일반적인 프로세스는 업그레이드 프로세스 중에 PostgreSQL 데이터베이스에 대한 트래픽을 생성하는 것입니다. 그런 다음 pgbench를 사용하여 데이터베이스가 완전히 사용 가능한 경우와 비교하여 업그레이드 중에 데이터베이스가 기본 수준의 트래픽을 처리할 수 있는지 확인합니다.

PostgreSQL 인스턴스에 연결합니다.

./scripts/launch-client.sh

출력은 다음과 비슷합니다.

Launching Pod pg-client in the namespace postgresql ...
pod/pg-client created
waiting for the Pod to be ready
Copying script files to the target Pod pg-client ...
Pod: pg-client is healthy

Cloud Shell에서 클라이언트 포드에 셸을 적용합니다.
```
kubectl exec -it -n postgresql pg-client -- /bin/bash
```

pgbench를 초기화합니다.

pgbench -i -h $HOST_PGPOOL -U postgres postgres

다음 명령어를 사용하여 업그레이드 기간 동안 PostgreSQL 애플리케이션이 고가용성을 유지하는지 확인하기 위한 기준 결과를 가져옵니다. 기준 결과를 얻으려면 30초 동안 다중 작업(스레드)을 통해 다중 연결로 테스트합니다.

pgbench -h $HOST_PGPOOL -U postgres postgres -c10 -j4 -T 30 -R 200

결과는 다음과 유사합니다.

pgbench (14.5)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 4
duration: 30 s
number of transactions actually processed: 5980
latency average = 7.613 ms
latency stddev = 2.898 ms
rate limit schedule lag: avg 0.256 (max 36.613) ms
initial connection time = 397.804 ms
tps = 201.955497 (without initial connection time)

업그레이드 중 가용성을 보장하기 위해 데이터베이스에 대해 일부 부하를 생성하고 PostgreSQL 애플리케이션이 업그레이드 도중 일관된 응답률을 제공하도록 할 수 있습니다. 이 테스트를 수행하려면 pgbench 명령어를 사용하여 데이터베이스에 약간의 트래픽을 생성합니다. 다음 명령어는 1시간 동안 pgbench를 실행하여 200TPS(초당 트랜잭션 수)를 타겟팅하고 2초마다 요청 비율을 나열합니다.
```
pgbench -h $HOST_PGPOOL -U postgres postgres --client=10 --jobs=4 --rate=200 --time=3600 --progress=2 --select-only
```
각 항목의 의미는 다음과 같습니다.
- --client: 시뮬레이션된 클라이언트 수, 즉 동시 데이터베이스 세션 수입니다.
- --jobs: pgbench 내의 작업자 스레드 수입니다. 스레드를 두 개 이상 사용하면 멀티 CPU 머신에서 유용할 수 있습니다. 클라이언트는 사용 가능한 스레드 간에 가능한 한 고르게 분산됩니다. 기본값은 1입니다.
- --rate: 초당 트랜잭션 수에 적용되는 요율입니다.
- --progress: 초마다 진행 상황 보고서를 표시합니다.
출력은 다음과 비슷합니다.
```
pgbench (14.5)
starting vacuum...end.
progress: 5.0 s, 354.8 tps, lat 25.222 ms stddev 15.038
progress: 10.0 s, 393.8 tps, lat 25.396 ms stddev 16.459
progress: 15.0 s, 412.8 tps, lat 24.216 ms stddev 14.548
progress: 20.0 s, 405.0 tps, lat 24.656 ms stddev 14.066
```
Google Cloud 콘솔에서 Cloud Monitoring의 PostgreSQL 개요 대시보드로 돌아갑니다. DB당 연결 및 포드당 연결 그래프에서 급증을 확인합니다.
클라이언트 포드를 종료합니다.
```
exit
```

클라이언트 포드를 삭제합니다.

kubectl delete pod -n postgresql pg-client

PostgreSQL 서비스 중단 시뮬레이션

이 섹션에서는 복제 관리자 서비스를 중지하여 PostgreSQL 복제본 중 하나에서 서비스 중단을 시뮬레이션합니다. 이렇게 하면 포드가 트래픽을 피어 복제본에 전달하지 않으며 활성 프로브가 실패합니다.

새 Cloud Shell 세션을 열고 기본 클러스터에 kubectl 명령줄 액세스를 구성합니다.
```
gcloud container clusters get-credentials $SOURCE_CLUSTER \
--region=$REGION --project=$PROJECT_ID
```

Kubernetes에서 내보낸 PostgreSQL 이벤트를 봅니다.

kubectl get events -n postgresql --field-selector=involvedObject.name=postgresql-postgresql-ha-postgresql-0 --watch

이전 Cloud Shell 세션에서 PostgreSQL repmgr을 중지하여 서비스 오류를 시뮬레이션합니다.

데이터베이스 컨테이너에 세션을 연결합니다.

kubectl exec -it -n $NAMESPACE postgresql-postgresql-ha-postgresql-0 -c postgresql -- /bin/bash

repmgr을 사용하여 서비스를 중지하고 체크포인트와 dry-run 인수를 삭제합니다.

export ENTRY='/opt/bitnami/scripts/postgresql-repmgr/entrypoint.sh'
export RCONF='/opt/bitnami/repmgr/conf/repmgr.conf'
$ENTRY repmgr -f $RCONF node service --action=stop --checkpoint

PostgreSQL 컨테이너에 구성된 활성 프로브가 5초 내에 실패하기 시작합니다. 6번 실패라는 실패 기준에 도달할 때까지 10초마다 반복됩니다. failureThreshold 값에 도달하면 컨테이너가 다시 시작됩니다. 이러한 매개변수를 구성하여 활성 프로브의 내결함성을 줄여 배포의 SLO 요구사항을 조정할 수 있습니다.

이벤트 스트림에서 포드의 활성 및 준비 프로브가 실패하고 컨테이너를 다시 시작해야 한다는 메시지가 표시됩니다. 출력은 다음과 비슷합니다.

0s          Normal    Killing                pod/postgresql-postgresql-ha-postgresql-0   Container postgresql failed liveness probe, will be restarted
0s          Warning   Unhealthy              pod/postgresql-postgresql-ha-postgresql-0   Readiness probe failed: psql: error: connection to server at "127.0.0.1", port 5432 failed: Connection refused...
0s          Normal    Pulled                 pod/postgresql-postgresql-ha-postgresql-0   Container image "us-docker.pkg.dev/psch-gke-dev/main/bitnami/postgresql-repmgr:14.5.0-debian-11-r10" already present on machine
0s          Normal    Created                pod/postgresql-postgresql-ha-postgresql-0   Created container postgresql
0s          Normal    Started                pod/postgresql-postgresql-ha-postgresql-0   Started container postgresql

재해 복구 대비

서비스 중단 이벤트 발생 시 프로덕션 워크로드를 계속 사용할 수 있도록 하려면 재해 복구(DR) 계획을 준비해야 합니다. DR 계획에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.

Kubernetes의 재해 복구는 두 단계로 구현할 수 있습니다.

백업에는 서비스 중단 이벤트가 발생하기 전에 상태 또는 데이터의 특정 시점 스냅샷을 만드는 작업이 포함됩니다.
복구에는 재해 발생 후 백업 복사본에서 상태 또는 데이터를 복원하는 작업이 포함됩니다.

GKE 클러스터에서 워크로드를 백업 및 복원하려면 Backup for GKE를 사용하면 됩니다. 새 클러스터와 기존 클러스터에서 이 서비스를 사용 설정할 수 있습니다. 그러면 클러스터에서 실행되는 Backup for GKE 에이전트가 배포됩니다. 이 에이전트는 구성 및 볼륨 백업 데이터를 캡처하고 복구를 담당합니다.

백업 및 복원의 범위는 전체 클러스터, 네임스페이스 또는 애플리케이션(예: matchLabels와 같은 선택기로 정의)으로 지정할 수 있습니다.

PostgreSQL 백업 및 복원 시나리오 예시

이 섹션의 예시에서는 ProtectedApplication 커스텀 리소스를 사용하여 애플리케이션 범위에서 백업 및 복원 작업을 수행하는 방법을 보여줍니다.

다음 다이어그램은 ProtectedApplication의 구성요소 리소스를 보여줍니다. 즉, postgresql-ha 애플리케이션을 나타내는 StatefulSet와 동일한 라벨(app.kubernetes.io/name: postgresql-ha)을 사용하는 pgpool 배포를 보여줍니다.

가용성이 높은 PostgreSQL 클러스터의 백업 및 복구 솔루션 예시를 보여주는 다이어그램 — **그림 2**: 가용성이 높은 PostgreSQL 클러스터의 백업 및 복구 솔루션 예시

PostgreSQL 워크로드 백업 및 복원을 준비하려면 다음 단계를 따르세요.

환경 변수 설정 이 예시에서는 ProtectedApplication을 사용하여 소스 GKE 클러스터(us-central1)에서 PostgreSQL 워크로드와 해당 볼륨을 복원한 다음 다른 리전(us-west1)에 있는 다른 GKE 클러스터로 복원합니다.

export SOURCE_CLUSTER=cluster-db1
export TARGET_CLUSTER=cluster-db2
export REGION=us-central1
export DR_REGION=us-west1
export NAME_PREFIX=g-db-protected-app
export BACKUP_PLAN_NAME=$NAME_PREFIX-bkp-plan-01
export BACKUP_NAME=bkp-$BACKUP_PLAN_NAME
export RESTORE_PLAN_NAME=$NAME_PREFIX-rest-plan-01
export RESTORE_NAME=rest-$RESTORE_PLAN_NAME

클러스터에서 Backup for GKE가 사용 설정되었는지 확인합니다. 이전에 수행한 Terraform 설정의 일부로 이미 사용 설정되어 있어야 합니다.
```
gcloud container clusters describe $SOURCE_CLUSTER \
    --project=$PROJECT_ID  \
    --region=$REGION \
    --format='value(addonsConfig.gkeBackupAgentConfig)'
```
Backup for GKE가 사용 설정되면 명령어 결과에 enabled=True가 표시됩니다.

백업 계획 설정 및 복원 수행

Backup for GKE를 사용하면 크론 작업으로 백업 계획을 만들 수 있습니다. 백업 계획에는 소스 클러스터, 백업할 워크로드 선택, 이 계획으로 생성된 백업 아티팩트가 저장되는 리전을 포함한 백업 구성이 포함됩니다.

백업 및 복원을 수행하려면 다음 단계를 따르세요.

cluster-db1에서 ProtectedApplication의 상태를 확인합니다.

kubectl get ProtectedApplication -A

결과는 다음과 유사합니다.

NAMESPACE    NAME            READY TO BACKUP
postgresql   postgresql-ha   true

ProtectedApplication의 백업 계획을 만듭니다.

export NAMESPACE=postgresql
export PROTECTED_APP=$(kubectl get ProtectedApplication -n $NAMESPACE | grep -v 'NAME' | awk '{ print $1 }')

gcloud beta container backup-restore backup-plans create $BACKUP_PLAN_NAME \
--project=$PROJECT_ID \
--location=$DR_REGION \
--cluster=projects/$PROJECT_ID/locations/$REGION/clusters/$SOURCE_CLUSTER \
--selected-applications=$NAMESPACE/$PROTECTED_APP \
--include-secrets \
--include-volume-data \
--cron-schedule="0 3 * * *" \
--backup-retain-days=7 \
--backup-delete-lock-days=0

수동으로 백업을 만듭니다.

gcloud beta container backup-restore backups create $BACKUP_NAME \
--project=$PROJECT_ID \
--location=$DR_REGION \
--backup-plan=$BACKUP_PLAN_NAME \
--wait-for-completion

복원 계획을 설정합니다.

gcloud beta container backup-restore restore-plans create $RESTORE_PLAN_NAME \
  --project=$PROJECT_ID \
  --location=$DR_REGION \
  --backup-plan=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME \
  --cluster=projects/$PROJECT_ID/locations/$DR_REGION/clusters/$TARGET_CLUSTER \
  --cluster-resource-conflict-policy=use-existing-version \
  --namespaced-resource-restore-mode=delete-and-restore \
  --volume-data-restore-policy=restore-volume-data-from-backup \
  --selected-applications=$NAMESPACE/$PROTECTED_APP \
  --cluster-resource-scope-selected-group-kinds="storage.k8s.io/StorageClass","scheduling.k8s.io/PriorityClass"

백업에서 복원합니다.

gcloud beta container backup-restore restores create $RESTORE_NAME \
  --project=$PROJECT_ID \
  --location=$DR_REGION \
  --restore-plan=$RESTORE_PLAN_NAME \
  --backup=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME/backups/$BACKUP_NAME \
  --wait-for-completion

클러스터가 복원되었는지 확인

복원된 클러스터에 예상한 모든 포드, PersistentVolume, StorageClass 리소스가 있는지 확인하려면 다음 단계를 수행합니다.

백업 클러스터 cluster-db2에 kubectl 명령줄 액세스를 구성합니다.

gcloud container clusters get-credentials $TARGET_CLUSTER --region $DR_REGION --project $PROJECT_ID

StatefulSet가 3/3 포드로 준비되었는지 확인합니다.

kubectl get all -n $NAMESPACE

출력은 다음과 비슷합니다.

NAME                                                   READY   STATUS    RESTARTS        AGE
pod/postgresql-postgresql-ha-pgpool-778798b5bd-k2q4b   1/1     Running   0               4m49s
pod/postgresql-postgresql-ha-postgresql-0              2/2     Running   2 (4m13s ago)   4m49s
pod/postgresql-postgresql-ha-postgresql-1              2/2     Running   0               4m49s
pod/postgresql-postgresql-ha-postgresql-2              2/2     Running   0               4m49s

NAME                                                   TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)    AGE
service/postgresql-postgresql-ha-pgpool                ClusterIP   192.168.241.46    <none>        5432/TCP   4m49s
service/postgresql-postgresql-ha-postgresql            ClusterIP   192.168.220.20    <none>        5432/TCP   4m49s
service/postgresql-postgresql-ha-postgresql-headless   ClusterIP   None              <none>        5432/TCP   4m49s
service/postgresql-postgresql-ha-postgresql-metrics    ClusterIP   192.168.226.235   <none>        9187/TCP   4m49s

NAME                                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgresql-postgresql-ha-pgpool   1/1     1            1           4m49s

NAME                                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/postgresql-postgresql-ha-pgpool-778798b5bd   1         1         1       4m49s

NAME                                                   READY   AGE
statefulset.apps/postgresql-postgresql-ha-postgresql   3/3     4m49s

postgres 네임스페이스의 모든 포드가 실행 중인지 확인합니다.

kubectl get pods -n $NAMESPACE

출력은 다음과 비슷합니다.

postgresql-postgresql-ha-pgpool-569d7b8dfc-2f9zx   1/1     Running   0          7m56s
postgresql-postgresql-ha-postgresql-0              2/2     Running   0          7m56s
postgresql-postgresql-ha-postgresql-1              2/2     Running   0          7m56s
postgresql-postgresql-ha-postgresql-2              2/2     Running   0          7m56s

PersistentVolume 및 StorageClass를 확인합니다. 복원 프로세스 중에 Backup for GKE는 소스 워크로드(예시 출력의 gce-pd-gkebackup-dn)에 프로비저닝된 StorageClass를 대체할 대상 워크로드에 프록시 클래스를 만듭니다.

kubectl get pvc -n $NAMESPACE

출력은 다음과 비슷합니다.

NAME                                         STATUS   VOLUME                 CAPACITY   ACCESS MODES   STORAGECLASS          AGE
data-postgresql-postgresql-ha-postgresql-0   Bound    pvc-be91c361e9303f96   8Gi        RWO            gce-pd-gkebackup-dn   10m
data-postgresql-postgresql-ha-postgresql-1   Bound    pvc-6523044f8ce927d3   8Gi        RWO            gce-pd-gkebackup-dn   10m
data-postgresql-postgresql-ha-postgresql-2   Bound    pvc-c9e71a99ccb99a4c   8Gi        RWO            gce-pd-gkebackup-dn   10m

예상한 데이터가 복원되었는지 확인

예상된 데이터가 복원되었는지 확인하려면 다음 단계를 따르세요.

PostgreSQL 인스턴스에 연결합니다.

./scripts/launch-client.sh
kubectl exec -it pg-client -n postgresql -- /bin/bash

각 테이블의 행 수를 확인합니다.
```
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql
select COUNT(*) from tb01;
```
이전에 테스트 데이터 세트 만들기에서 작성한 데이터와 비슷한 결과가 표시됩니다. 출력은 다음과 비슷합니다.
```
300000
(1 row)
```
클라이언트 포드를 종료합니다.
```
exit
```

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

프로젝트 삭제

청구되지 않도록 하는 가장 쉬운 방법은 튜토리얼에서 만든 프로젝트를 삭제하는 것입니다.

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Google Cloud 프로젝트를 삭제합니다.

gcloud projects delete PROJECT_ID

다음 단계

GKE의 데이터베이스 배포 권장사항 알아보기
영구 볼륨 자세히 알아보기
고가용성 PostgreSQL 클러스터로 스트리밍 복제를 위해 Pgpool-II를 사용하는 방법의 예시를 참조하세요.