GKE Data Cache を使用してステートフル ワークロードの読み取りパフォーマンスを高速化する

このガイドでは、Google Kubernetes Engine（GKE）クラスタで GKE Data Cache を使用して、読み取り負荷の高いステートフル アプリケーションのパフォーマンスを改善する方法について説明します。GKE Data Cache は、GKE で実行されるステートフル アプリケーション（データベースなど）の読み取りオペレーションを高速化するマネージド ブロック ストレージ ソリューションです。

Data Cache は GKE Standard クラスタでのみ使用できます。このガイドでは、新しい GKE Standard クラスタまたはノードプールを作成するときに GKE Data Cache を有効にし、Data Cache アクセラレーションを使用して GKE アタッチ ディスクをプロビジョニングする手順について説明します。

GKE Data Cache について

GKE Data Cache を使用すると、GKE ノード上のローカル SSD を、Persistent Disk や Hyperdisk などの永続ストレージのキャッシュ レイヤとして使用できます。ローカル SSD を使用すると、ディスクの読み取りレイテンシが短縮され、メモリ要件を最小限に抑えながら、ステートフル ワークロードの秒間クエリ数（QPS）が増加します。GKE Data Cache は、バッキング ディスクとしてすべてのタイプの Persistent Disk または Hyperdisk をサポートしています。

アプリケーションで GKE Data Cache を使用するには、ローカル SSD が接続された GKE ノードプールを構成します。アタッチされたローカル SSD の一部またはすべてを使用するように GKE Data Cache を構成できます。GKE Data Cache ソリューションで使用されるローカル SSD は、標準の Google Cloud 暗号化を使用して保存時に暗号化されます。

利点

GKE Data Cache には次の利点があります。

  • MySQL や Postgres などの従来のデータベースとベクトル データベースで、1 秒あたりに処理されるクエリのレートが増加します。
  • ディスクのレイテンシを最小限に抑えることで、ステートフル アプリケーションの読み取りパフォーマンスが向上します。
  • SSD がノードにローカルであるため、データのハイドレーションと再ハイドレーションが高速化されます。データのハイドレーションとは、必要なデータを永続ストレージからローカル SSD に読み込む最初のプロセスを指します。データのハイドレーションとは、ノードがリサイクルされた後にローカル SSD 上のデータを復元するプロセスを指します。

デプロイ アーキテクチャ

次の図は、それぞれアプリを実行する 2 つの Pod を含む GKE Data Cache 構成の例を示しています。Pod は同じ GKE ノードで実行されます。各 Pod は、個別のローカル SSD とバッキング永続ディスクを使用します。

GKE Data Cache のデプロイ アーキテクチャ
図 1. GKE Data Cache のデプロイ アーキテクチャ。

デプロイモード

GKE Data Cache は、次の 2 つのモードのいずれかで設定できます。

  • ライトスルー（推奨）: アプリケーションがデータを書き込むと、データはキャッシュと基盤となる永続ディスクの両方に同期的に書き込まれます。writethrough モードはデータ損失を防ぎ、ほとんどの本番環境ワークロードに適しています。
  • ライトバック: アプリケーションがデータを書き込むと、データはキャッシュにのみ書き込まれます。その後、データは永続ディスクに非同期（バックグラウンド）で書き込まれます。writeback モードは書き込みパフォーマンスを向上させ、速度に依存するワークロードに適しています。ただし、このモードは信頼性に影響します。ノードが予期せずシャットダウンすると、フラッシュされていないキャッシュ データが失われます。

目標

このガイドでは、次の方法について説明します。

要件と計画

GKE Data Cache を使用するには、次の要件を満たしていることを確認してください。

  • GKE クラスタでバージョン 1.32.3-gke.1440000 以降を実行している必要があります。
  • ノードプールでは、ローカル SSD をサポートするマシンタイプを使用する必要があります。詳細については、マシンシリーズのサポートをご覧ください。

計画

GKE Data Cache のストレージ容量を計画する際は、次の点を考慮してください。

  • GKE Data Cache を同時に使用するノードあたりの Pod の最大数。
  • GKE Data Cache を使用する Pod の予想されるキャッシュ サイズ要件。
  • GKE ノードで使用可能なローカル SSD の合計容量。ローカル SSD がデフォルトでアタッチされているマシンタイプと、ローカル SSD をアタッチする必要があるマシンタイプの詳細については、有効な数のローカル SSD ディスクを選択するをご覧ください。
  • 第 3 世代以降のマシンタイプ（デフォルトのローカル SSD 数が割り当てられているマシンタイプ）の場合、データ キャッシュ用のローカル SSD は、そのマシンの使用可能な合計ローカル SSD から予約されます。
  • ファイル システムのオーバーヘッド。ローカル SSD の使用可能な容量が縮小する可能性があります。たとえば、2 つのローカル SSD があり、合計物理容量が 750 GiB のノードでも、ファイル システムのオーバーヘッドにより、すべてのデータ キャッシュ ボリュームで使用可能な容量が少なくなってしまう可能性があります。一部のローカル SSD 容量は、システムで使用するために予約されています。

料金

ローカル SSD とアタッチされた永続ディスクのプロビジョニング容量の合計に対して課金されます。月ごと、GiB ごとに課金されます。

詳細については、Compute Engine のドキュメントのディスクの料金をご覧ください。

始める前に

始める前に、次の作業が完了していることを確認してください。

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

Data Cache を使用するように GKE ノードを構成する

高速ストレージに GKE Data Cache の使用を開始するには、ノードに必要なローカル SSD リソースが必要です。このセクションでは、新しい GKE クラスタを作成する場合、または既存のクラスタに新しいノードプールを追加する場合に、ローカル SSD をプロビジョニングして GKE Data Cache を有効にするコマンドについて説明します。既存のノードプールを更新して Data Cache を使用することはできません。既存のクラスタで Data Cache を使用する場合は、新しいノードプールをクラスタに追加します。

新しいクラスタの場合

Data Cache が構成された GKE クラスタを作成するには、次のコマンドを使用します。

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --data-cache-count=DATA_CACHE_COUNT \
    # Optionally specify additional Local SSDs, or skip this flag
    --ephemeral-storage-local-ssd count=LOCAL_SSD_COUNT

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。作成する GKE クラスタの一意の名前を指定します。
  • LOCATION: 新しいクラスタの Google Cloud リージョンまたはゾーン。
  • MACHINE_TYPE: クラスタの第 2 世代、第 3 世代、またはそれ以降の世代のマシンシリーズから使用するマシンタイプ（n2-standard-2 や c3-standard-4-lssd など）。ローカル SSD はデフォルトの e2-medium タイプでは使用できないため、このフィールドは必須です。詳細については、利用可能なマシンシリーズをご覧ください。
  • DATA_CACHE_COUNT: デフォルトのノードプール内の各ノードの Data Cache に排他的に使用するローカル SSD ボリュームの数。これらのローカル SSD の容量はそれぞれ 375 GiB です。ボリュームの最大数はマシンタイプとリージョンによって異なります。一部のローカル SSD 容量は、システムで使用するために予約されています。

  • （省略可）LOCAL_SSD_COUNT: 他のエフェメラル ストレージのニーズに応じてプロビジョニングするローカル SSD ボリュームの数。Data Cache に使用されない追加のローカル SSD をプロビジョニングする場合は、--ephemeral-storage-local-ssd count フラグを使用します。

    第 3 世代以降のマシンタイプの場合は、次の点に注意してください。

    • 第 3 世代以降のマシンタイプには、デフォルトで特定の数のローカル SSD がアタッチされています。各ノードにアタッチされるローカル SSD の数は、指定したマシンタイプによって異なります。
    • 追加のエフェメラル ストレージに --ephemeral-storage-local-ssd count フラグを使用する場合は、DATA_CACHE_COUNT の値を、マシン上のローカル SSD ディスクの合計数より小さい数に設定してください。使用可能なローカル SSD の合計数には、デフォルトでアタッチされているディスクと、--ephemeral-storage-local-ssd count フラグを使用して追加した新しいディスクが含まれます。

このコマンドは、デフォルトのノードプール用に第 2 世代、第 3 世代、またはそれ以降のマシンタイプで実行される GKE クラスタを作成し、Data Cache 用にローカル SSD をプロビジョニングします。必要に応じて、他のエフェメラル ストレージ用に追加のローカル SSD をプロビジョニングします（指定した場合）。

これらの設定は、デフォルトのノードプールにのみ適用されます。

既存クラスタの場合

既存のクラスタで Data Cache を使用するには、Data Cache が構成された新しいノードプールを作成する必要があります。

Data Cache が構成された GKE ノードプールを作成するには、次のコマンドを使用します。

gcloud container node-pool create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --data-cache-count=DATA_CACHE_COUNT \
    # Optionally specify additional Local SSDs, or skip this flag
    --ephemeral-storage-local-ssd count=LOCAL_SSD_COUNT

次のように置き換えます。

  • NODE_POOL_NAME: ノードプールの名前。作成するノードプールの一意の名前を指定します。
  • CLUSTER_NAME: ノードプールを作成する既存の GKE クラスタの名前。
  • LOCATION: クラスタと同じ Google Cloud リージョンまたはゾーン。
  • MACHINE_TYPE: クラスタの第 2 世代、第 3 世代、またはそれ以降の世代のマシンシリーズから使用するマシンタイプ（n2-standard-2 や c3-standard-4-lssd など）。ローカル SSD はデフォルトの e2-medium タイプでは使用できないため、このフィールドは必須です。詳細については、利用可能なマシンシリーズをご覧ください。
  • DATA_CACHE_COUNT: ノードプール内の各ノードの Data Cache に排他的に使用するローカル SSD ボリュームの数。これらのローカル SSD の容量はそれぞれ 375 GiB です。ボリュームの最大数はマシンタイプとリージョンによって異なります。一部のローカル SSD 容量は、システムで使用するために予約されています。

  • （省略可）LOCAL_SSD_COUNT: 他のエフェメラル ストレージのニーズに応じてプロビジョニングするローカル SSD ボリュームの数。Data Cache に使用されない追加のローカル SSD をプロビジョニングする場合は、--ephemeral-storage-local-ssd count フラグを使用します。

    第 3 世代以降のマシンタイプの場合は、次の点に注意してください。

    • 第 3 世代以降のマシンタイプには、デフォルトで特定の数のローカル SSD がアタッチされています。各ノードにアタッチされるローカル SSD の数は、指定したマシンタイプによって異なります。
    • 追加のエフェメラル ストレージに --ephemeral-storage-local-ssd count フラグを使用する場合は、DATA_CACHE_COUNT をマシンのローカル SSD ディスクの合計可用量よりも小さい値に設定してください。使用可能なローカル SSD の合計数には、デフォルトでアタッチされているディスクと、--ephemeral-storage-local-ssd count フラグを使用して追加した新しいディスクが含まれます。

このコマンドは、第 2 世代、第 3 世代、またはそれ以降のマシンタイプで実行される GKE ノードプールを作成し、Data Cache 用にローカル SSD をプロビジョニングします。必要に応じて、他のエフェメラル ストレージ用に追加のローカル SSD をプロビジョニングします（指定した場合）。

GKE の永続ストレージ用に Data Cache をプロビジョニングする

このセクションでは、ステートフル アプリケーションで GKE Data Cache のパフォーマンス上のメリットを活用する方法の例を示します。

Data Cache にローカル SSD を使用するノードプールを作成する

まず、GKE クラスタにローカル SSD がアタッチされた新しいノードプールを作成します。GKE Data Cache は、ローカル SSD を使用して、アタッチされた永続ディスクのパフォーマンスを高速化します。

次のコマンドは、第 2 世代のマシン n2-standard-2 を使用するノードプールを作成します。

gcloud container node-pools create datacache-node-pool \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --num-nodes=2 \
    --data-cache-count=1 \
    --machine-type=n2-standard-2

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。新しいノードプールを作成する GKE クラスタを指定します。
  • LOCATION: クラスタと同じ Google Cloud リージョンまたはゾーン。

このコマンドを実行すると、次の仕様のノードプールが作成されます。

  • --num-nodes=2: このプールのノードの初期数を 2 に設定します。
  • --data-cache-count=1: GKE Data Cache 専用のノードごとに 1 つのローカル SSD を指定します。

各ノードに 1 つのローカル SSD がプロビジョニングされているため、このノードプール用にプロビジョニングされるローカル SSD の合計数は 2 つです。

Data Cache の StorageClass を作成する

Data Cache を使用する永続ボリュームを動的にプロビジョニングする方法を GKE に指示する Kubernetes StorageClass を作成します。

次のマニフェストを使用して、pd-balanced-data-cache-sc という名前の StorageClass を作成して適用します。

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-balanced-data-cache-sc
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  data-cache-mode: writethrough
  data-cache-size: "100Gi"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
EOF

Data Cache の StorageClass パラメータには次のものがあります。

  • type: 永続ボリュームの基盤となるディスクタイプを指定します。その他のオプションについては、サポートされている Persistent Disk タイプまたは Hyperdisk タイプをご覧ください。
  • data-cache-mode: 推奨の writethrough モードを使用します。詳細については、デプロイモードをご覧ください。
  • data-cache-size: ローカル SSD の容量を 100 GiB に設定します。これは、各 PVC の読み取りキャッシュとして使用されます。

PersistentVolumeClaim（PVC）を使用してストレージをリクエストする

作成した pd-balanced-data-cache-sc StorageClass を参照する PVC を作成します。PVC は、Data Cache が有効になっている永続ボリュームをリクエストします。

次のマニフェストを使用して、ReadWriteOnce アクセス権を持つ 300 GiB 以上の永続ボリュームをリクエストする pvc-data-cache という名前の PVC を作成します。

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data-cache
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 300Gi
  storageClassName: pd-balanced-data-cache-sc
EOF

PVC を使用する Deployment を作成する

前に作成した pvc-data-cache PVC を使用する Pod を実行する postgres-data-cache という名前の Deployment を作成します。cloud.google.com/gke-data-cache-count ノードセレクタにより、GKE Data Cache の使用に必要なローカル SSD リソースを持つノードに Pod がスケジュールされます。

次のマニフェストを作成して適用し、PVC を使用して Postgres ウェブサーバーをデプロイする Pod を構成します。

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres-data-cache
 labels:
   name: database
   app: data-cache
spec:
 replicas: 1
 selector:
   matchLabels:
     service: postgres
     app: data-cache
 template:
   metadata:
     labels:
       service: postgres
       app: data-cache
   spec:
     nodeSelector:
       cloud.google.com/gke-data-cache-disk: "1"
     containers:
     - name: postgres
       image: postgres:14-alpine
       volumeMounts:
       - name: pvc-data-cache-vol
         mountPath: /var/lib/postgresql/data2
         subPath: postgres
       env:
       - name: POSTGRES_USER
         value: admin
       - name: POSTGRES_PASSWORD
         value: password
     restartPolicy: Always
     volumes:
     - name: pvc-data-cache-vol
       persistentVolumeClaim:
         claimName: pvc-data-cache
EOF

Deployment が正常に作成されたことを確認します。

kubectl get deployment

Postgres コンテナのプロビジョニングが完了し、READY ステータスが表示されるまでに数分かかることがあります。

Data Cache のプロビジョニングを確認する

Deployment を作成したら、Data Cache を含む永続ストレージが正しくプロビジョニングされていることを確認します。

  1. pvc-data-cache が永続ボリュームに正常にバインドされていることを確認するには、次のコマンドを実行します。

    kubectl get pvc pvc-data-cache

    出力は次のようになります。

    NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                VOLUMEATTRIBUTESCLASS   AGE
pvc-data-cache   Bound    pvc-e9238a16-437e-45d7-ad41-410c400ae018   300Gi      RWO            pd-balanced-data-cache-sc   <unset>                 10m

  2. Data Cache の論理ボリューム マネージャー（LVM）グループがノードに作成されたことを確認する手順は次のとおりです。

    1. ノードの PDCSI ドライバの Pod 名を取得します。

      NODE_NAME=$(kubectl get pod --output json |  jq '.items[0].spec.nodeName' | sed 's/\"//g')
kubectl get po -n kube-system -o wide | grep ^pdcsi-node | grep $NODE_NAME

      出力から、pdcsi-node Pod の名前をコピーします。

    2. LVM グループの作成に関する PDCSI ドライバログを表示します。

      PDCSI_POD_NAME="PDCSI-NODE_POD_NAME"
kubectl logs -n kube-system $PDCSI_POD_NAME gce-pd-driver | grep "Volume group creation"

      PDCSI-NODE_POD_NAME は、前の手順でコピーした実際の Pod 名に置き換えます。

      出力は次のようになります。

      Volume group creation succeeded for LVM_GROUP_NAME

このメッセージは、Data Cache の LVM 構成がノードで正しく設定されていることを示しています。

クリーンアップ

Google Cloud アカウントに課金されないようにするには、このガイドで作成したストレージ リソースを削除します。

  1. Deployment を削除します。

    kubectl delete deployment postgres-data-cache

  2. PersistentVolumeClaim を削除します。

    kubectl delete pvc pvc-data-cache

  3. ノードプールを削除します。

    gcloud container node-pools delete datacache-node-pool \
    --cluster CLUSTER_NAME

    CLUSTER_NAME は、Data Cache を使用するノードプールを作成したクラスタの名前に置き換えます。

次のステップ