이 페이지에서는 GKE의 컨테이너에서 데이터베이스를 실행하기 위한 권장사항을 설명합니다. 배포를 사용해서 Kubernetes로 관리되는 컨테이너화된 데이터베이스 인스턴스 집합을 만들 수 있습니다. 그런 다음 특정 포드와 독립적으로 데이터베이스에 대한 액세스를 제공하는 서비스를 만듭니다. 포드가 다른 노드로 이동하더라도 서비스는 변경되지 않습니다.
데이터베이스 인스턴스의 데이터에 액세스하려면 PersistentVolumeClaim(PVC) 리소스를 만들고 워크로드에 제공합니다.
데이터베이스는 지속성을 위해 로컬 디스크에 의존합니다. Kubernetes 클러스터에서 서비스로 실행되는 데이터베이스와 PersistentVolumeClaim의 데이터베이스 파일은 클러스터의 수명 주기에 바인딩됩니다. 클러스터가 삭제되면 데이터베이스도 삭제됩니다.
GKE에서 실행되는 스테이트풀(Stateful) 애플리케이션을 빌드하거나 배포하는 경우 데이터베이스 인스턴스에 대해 다음 배포 옵션 중 하나를 사용합니다.
- 완전 관리형 데이터베이스: Cloud SQL 또는 Spanner와 같은 관리형 데이터베이스는 감소된 운영 오버헤드를 제공하며, Google Cloud 인프라에 최적화되었습니다. 관리형 데이터베이스는 Kubernetes에 직접 배포하는 데이터베이스보다 유지보수 및 운영 노력이 적게 필요합니다.
- Kubernetes 애플리케이션: GKE 클러스터에 MySQL 또는 PostgreSQL 같은 데이터베이스 인스턴스를 배포하고 실행할 수 있습니다.
GKE의 데이터베이스 배포 고려사항
앞에서 설명한 각 옵션은 비즈니스 목표 및 제약조건에 따라 장단점이 있습니다. 다음 표에 따라 GKE의 데이터베이스 배포가 적합한 선택인지 결정하세요.
| 고려사항 | 설명 |
|---|---|
| 데이터베이스 독립성 | PersistentVolumeClaim의 수명 주기는 해당 GKE 클러스터에 연결되어 있습니다. 특정 GKE 클러스터에 따라 데이터베이스 수명 주기가 달라지지 않도록 하려면 데이터베이스를 관리형 데이터베이스로 또는 VM 인스턴스에 별개로 유지하는 것이 좋습니다. |
| GKE로 확장 | 수직 확장: 포드 요청이 자동 확장되도록 구성할 수 있습니다. 하지만 수직형 포드 자동 확장으로 포드가 확장될 때 데이터베이스 애플리케이션이 중단을 견딜 수 있는지 확인해야 합니다. 수평 확장: 데이터베이스는 복제본 추가를 통해 읽기 또는 쓰기를 수평 확장할 수 있습니다. 데이터베이스에서 수평 확장을 지원하는지 여부는 단일 작성자 또는 멀티 작성자 아키텍처가 사용되는지에 따라 달라집니다. 수평 확장을 사용하려면 복제본 수를 수직 확장하는 것 외에도 데이터베이스 구성을 업데이트해야 합니다. |
| GKE 오버헤드 | Autopilot 클러스터에서는 리소스 예약에 대해 요금이 청구되지 않으며 리소스 요청에 대해서만 청구됩니다. Standard 클러스터에서 GKE는 자체 작업을 위한 리소스를 예약합니다. Standard 클러스터의 데이터베이스는 자동으로 확장되지 않으므로 작은 포드의 경우 오버헤드가 높을 수 있습니다. |
| 데이터베이스 인스턴스 수 | Kubernetes 컨텍스트에서 각 데이터베이스 인스턴스는 자체 포드에서 실행되며 자체 PersistentVolumeClaim을 갖습니다. 인스턴스 수가 많으면 대량의 포드, 노드, 볼륨 클레임을 운영하고 관리해야 합니다. 대신 관리형 데이터베이스를 사용해야 할 수 있습니다. |
| GKE의 데이터베이스 백업 | PersistentVolumeClaim은 GKE 클러스터로 범위가 지정됩니다. 이 범위를 지정하면 GKE 클러스터가 삭제될 때 볼륨 클레임이 삭제됩니다. 클러스터에 있는 모든 데이터베이스 파일도 삭제됩니다. 데이터베이스 파일이 실수로 손실되지 않도록 보호하려면 복제본을 만들거나 백업을 자주하는 것이 좋습니다. Backup for GKE를 사용해서 주기적으로 애플리케이션 구성 및 볼륨 데이터의 스냅샷을 작성할 수 있습니다. Backup for GKE는 볼륨 백업 예약, 백업 수명 주기 관리, 클러스터에 백업 복원을 처리합니다. |
| Kubernetes 관련 복구 동작 | Kubernetes에서 포드가 실패하면 다시 생성됩니다. 즉, 데이터베이스 인스턴스 관점에서 포드가 다시 생성될 경우 데이터베이스 내 또는 포드 외부의 안정적인 스토리지에서 영구적이지 않은 모든 구성도 다시 생성됩니다. |
| 데이터베이스 아키텍처 | 데이터베이스가 활성-수동 아키텍처를 사용하도록 구성된 경우 복제본 하나만 기본으로 구성되도록 해야 합니다. 많은 관계형 데이터베이스에 활성-수동 장애 조치 옵션이 있으며, 기본 복제본에 장애가 발생한 경우 보조 복제본을 기본 복제본으로 승격할 수 있습니다. |
| 데이터베이스 마이그레이션 | 기존 데이터베이스 시스템을 GKE로 마이그레이션하려면 데이터베이스 마이그레이션: 개념 및 원칙(1부)과 데이터베이스 마이그레이션: 개념 및 원칙(2부)을 참조하세요. |
| 사용자 재학습 | 자체 관리형 또는 제공업체 관리형 배포에서 Kubernetes 데이터베이스 배포로 이전하는 경우 데이터베이스 관리자를 재학습시켜서 새로운 환경에서도 현재 환경처럼 안정적으로 운영할 수 있도록 해야 합니다. 애플리케이션 개발자도 차이점을 어느 정도는 알고 있어야 합니다. |
위 표는 데이터베이스 배포에 대한 몇 가지 고려사항을 설명합니다. 하지만 표에 모든 고려사항이 포함되지는 않습니다. 또한 재해 복구, 연결 풀링, 모니터링도 고려해야 합니다.
다음 단계
- GKE에 고가용성 MySQL 토폴로지를 배포하는 방법 알아보기
- GKE에 고가용성 PostgreSQL 인스턴스를 배포하는 방법 알아보기
- GKE의 워크로드 백업 및 복원 서비스인 Backup for GKE 자세히 알아보기
- 영구 볼륨 자세히 알아보기