このページでは、GKE のコンテナでデータベースを実行するためのベスト プラクティスについて説明します。Deployment を使用すると、Kubernetes が管理するコンテナ化されたデータベース インスタンスのセットを作成できます。次に、特定の Pod とは独立してデータベースへのアクセスを提供する Service を作成します。Pod が別のノードに移動されても、Service は変更されません。
データベース インスタンスのデータにアクセスするには、PersistentVolumeClaim（PVC）リソースを作成し、それをワークロードで使用できるようにします。
データベースは、永続性に関してローカル ディスクに依存します。Kubernetes クラスタ内でサービスとして実行されるデータベースと、その PersistentVolumeClaim 内のデータベース ファイルは、クラスタのライフサイクルにバインドされます。クラスタが削除されると、データベースも削除されます。
GKE で実行するステートフル アプリケーションを構築またはデプロイする場合は、データベース インスタンスに次のいずれかのデプロイ オプションを使用することを検討してください。
- フルマネージド データベース: Cloud SQL や Spanner などのマネージド データベースは、運用上のオーバーヘッドの削減に有効で、Google Cloud インフラストラクチャ用に最適化されています。マネージド データベースの保守や運用は、Kubernetes に直接デプロイするデータベースよりも簡単です。
- Kubernetes アプリケーション: データベース インスタンス（MySQL や PostgreSQL など）を GKE クラスタでデプロイして実行できます。
GKE でデータベースをデプロイする際の考慮事項
上記の各オプションにはトレードオフがあるため、ビジネスの目標と制約を考慮する必要があります。次の表を使用して、GKE でのデータベース デプロイが適しているかどうかを判断してください。
| 検討対象 | 説明 |
|---|---|
| データベースの独立性 | PersistentVolumeClaim のライフサイクルは、対応する GKE クラスタに関連付けられます。データベースのライフサイクルが特定の GKE クラスタに依存しないようにするには、データベースをマネージド データベースとして、または VM インスタンス内で維持することを検討してください。 |
| GKE によるスケーリング | 垂直方向のスケーリング: 自動的にスケーリングするように Pod リクエストを構成できます。ただし、垂直 Pod 自動スケーリングによって Pod がスケールアップされるときに、データベース アプリケーションが中断に対応できるようにする必要があります。 水平方向のスケーリング: データベースが、レプリカを追加することによって読み取りまたは書き込みを水平方向にスケーリングできる場合があります。データベースが水平方向のスケーリングをサポートしているかどうかは、データベースがシングル ライター アーキテクチャかマルチライター アーキテクチャかによって異なります。水平スケーリングを使用するには、レプリカの数をスケールアップするだけでなく、データベース構成の更新も必要になる場合があります。 |
| GKE オーバーヘッド | Autopilot クラスタでは、リソースの予約に対しては課金されず、リソース リクエストに対してのみ課金されます。 Standard クラスタでは、GKE は独自のオペレーション用にリソースを予約します。Standard クラスタのデータベースは自動的にスケーリングされないため、小規模な Pod のオーバーヘッドが高くなる可能性があります。 |
| データベース インスタンスの数 | Kubernetes のコンテキストでは、各データベース インスタンスは独自の Pod で実行され、独自の PersistentVolumeClaim を持ちます。多数のインスタンスがある場合、多数の Pod、ノード、ボリュームの要求を操作および管理する必要があります。代わりにマネージド データベースを使用することをおすすめします。 |
| GKE でのデータベースのバックアップ | PersistentVolumeClaim のスコープは GKE クラスタです。このスコープは、GKE クラスタが削除されると、ボリュームの要求が削除されることを意味します。クラスタ内のデータベース ファイルもすべて削除されます。データベース ファイルが誤って削除されないように、レプリケーションまたは頻繁なバックアップをおすすめします。 Backup for GKE を使用すると、アプリケーションの構成とボリューム データのスナップショットを定期的に作成できます。Backup for GKE は、ボリューム バックアップのスケジューリング、バックアップ ライフサイクルの管理、クラスタへのバックアップの復元を処理します。 |
| Kubernetes 固有の復旧動作 | Kubernetes で Pod が失敗すると、Pod が再作成されます。これはデータベース インスタンスの観点から見ると、Pod が再作成されると、データベース内または Pod 外の安定したストレージに永続的でない構成も再作成されることを意味します。 |
| データベースのアーキテクチャ | データベースがアクティブ / パッシブ アーキテクチャを使用するように構成されている場合は、1 つのレプリカのみがプライマリとして構成されるようにする必要があります。多くのリレーショナル データベースにはアクティブ / パッシブ フェイルオーバーのオプションがあり、プライマリに障害が発生した場合にセカンダリをプライマリに昇格できます。 |
| データベースの移行 | 既存のデータベース システムを GKE に移行する場合は、データベースの移行: コンセプトと原則（パート 1）およびデータベースの移行: コンセプトと原則（パート 2）をご覧ください。 |
| ユーザーの再トレーニング | セルフマネージドまたはプロバイダが管理するデプロイから Kubernetes データベース Deployment に移行する場合は、データベース管理者が現在の環境と同じように新しい環境でも運営ができるように再トレーニングする必要があります。また、アプリケーション デベロッパーは、違いについてある程度学ぶことが必要な場合があります。 |
上記のテーブルには、データベースのデプロイに関する考慮事項がいくつかまとめられています。ただし、このテーブルには潜在的なすべての考慮事項が含まれているわけではありません。また、障害復旧、接続プール、モニタリングについても考慮する必要があります。
次のステップ
- GKE に高可用性 MySQL トポロジをデプロイする方法を確認する。
- GKE に高可用性 PostgreSQL インスタンスをデプロイする方法を確認する。
- GKE でワークロードをバックアップおよび復元するためのサービスである Backup for GKE の詳細を確認する。
- 永続ボリュームの詳細を確認する。