動的ストレージ

このトピックでは、パーシステントボリュームとストレージクラスを使用して、Tanzu Kubernetes Grid (TKG) ワークロードクラスタに動的ストレージを実装する方法について説明します。

概要：PersistentVolume、PersistentVolumeClaim、および StorageClass

Kubernetes クラスタ内で、PersistentVolume (PV) オブジェクトは、ポッドのライフサイクルの影響を受けない共有ストレージをクラスタポッドに対して提供します。ストレージは、PersistentVolumeClaim (PVC) オブジェクトを介して PV にプロビジョニングされます。このオブジェクトは、ポッドが基盤となるストレージにアクセスできる容量と方法を定義します。詳細については、Kubernetes ドキュメントの「パーシステントボリューム」を参照してください。

クラスタ管理者は、StorageClass オブジェクトを定義して、クラスタユーザーがさまざまなストレージタイプとルールで PVC および PV オブジェクトを動的に作成できるようにします。Tanzu Kubernetes Grid には、ユーザーによるターンキー環境でのパーシステントストレージのプロビジョニングを可能にする、デフォルトの StorageClass オブジェクトも用意されています。

StorageClass オブジェクトには、PV をプロビジョニングする内部または外部サービスプラグインを識別する provisioner フィールドと、Kubernetes ストレージクラスをインフラストラクチャレベルで定義されたストレージオプション（vSphere の仮想マシンストレージポリシーなど）に関連付ける parameters フィールドが含まれます。詳細については、Kubernetes ドキュメントの「ストレージクラス」を参照してください。

サポート対象のストレージタイプ

Tanzu Kubernetes Grid は、Kubernetes 内部（「ツリー内」）または外部（「ツリー外」）プラグインによってプロビジョニングされる、さまざまなストレージタイプの StorageClass オブジェクトをサポートします。

ストレージタイプ

vSphere クラウドネイティブストレージ (CNS)
Amazon EBS
Azure Disk
Azure File
iSCSI
NFS

注
vSphere CSI はストレージ DRS をサポートしていませんが、vSphere CSI ドキュメントの「vSphere コンテナストレージプラグインでサポートされる vSphere 機能」で説明されている条件を備えた Storage vMotion をサポートしています。

vSphere CSI は条件付きで Storage vMotion をサポートします。詳細については、CSI ドキュメントを参照してください。

vSphere CNS、Amazon EBS、Azure Disk のデフォルトストレージクラスについては、「デフォルトストレージクラス」を参照してください。

外部プロビジョニング

TKG v2.1 では、すべてのデフォルトストレージクラスが「ツリー内」プロビジョニングではなく、外部（「ツリー外」）ストレージプロビジョニングを使用します。

ストレージクラスはコア Kubernetes に付属しません。
StorageClass オブジェクトの provisioner 値に、kubernetes.io はプリフィックスとして付加されません。
プロビジョナは、外部ストレージのコンテナストレージインターフェイス (CSI) 標準に従います。
以前のバージョンの TKG によって展開されたデフォルトのストレージクラスを持つワークロードクラスタには、ツリー内ストレージプロビジョニングが含まれる場合があります。「ストレージクラスを使用したパーシステントボリュームの作成」を参照してください。

デフォルトのストレージクラス

Tanzu Kubernetes Grid にはデフォルトの StorageClass オブジェクトが用意されています。これにより、ワークロードクラスタユーザーは、クラスタ管理者によって作成された StorageClass オブジェクトを必要とせずに、ターンキー環境のインフラストラクチャでパーシステントストレージをプロビジョニングできます。

ENABLE_DEFAULT_STORAGE_CLASS 変数は、tanzu cluster create の --file オプションに渡されるクラスタ構成ファイル内でデフォルトで true に設定されています。これにより、ワークロードクラスタのデフォルトストレージクラスが有効です。

重要
デフォルトのストレージクラス定義は変更しないでください。ストレージクラスをカスタマイズするには、TKG によって作成されたデフォルトオブジェクトを変更する代わりに name を使用して新しい StorageClass 定義を作成します。

Tanzu Kubernetes Grid のデフォルトのストレージクラス定義は次のとおりです。

vSphere CNS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi.vsphere.vmware.com
parameters:
  storagePolicyName: optional

Kubernetes ドキュメントの vSphere CSI ストレージクラスパラメータを参照してください。

Amazon EBS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com

AWS ドキュメントの Amazon EBS CSI ドライバストレージクラスパラメータを参照してください。

Azure Disk

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: default
  annotations:
    storageclass.beta.kubernetes.io/is-default-class: "true"
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: disk.csi.azure.com
parameters:
  kind: Managed
  storageaccounttype: Standard_LRS
  cachingmode: ReadOnly
volumeBindingMode: WaitForFirstConsumer

Azure ドキュメントの Azure Disk CSI ドライバストレージクラスパラメータを参照してください。

Azure File

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-file
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: file.csi.azure.com
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS

Kubernetes ドキュメントの Azure File ストレージクラスパラメータを参照してください。

CNS の設定とストレージポリシーの作成 (vSphere)

vSphere 管理者は、vSphere CNS を設定し、Tanzu Kubernetes Grid クラスタユーザーのニーズに基づいて仮想ディスク (VMDK) ストレージのストレージポリシーを作成できます。

Kubernetes クラスタのパーシステントストレージには、次のように vSAN またはローカルの VMFS（仮想マシンファイルシステム）を使用できます。

vSAN ストレージ：

vSphere Client で vSAN ストレージのストレージポリシーを作成するには、[ホーム (Home)] > [ポリシーおよびプロファイル (Policies and Profiles)] > [仮想マシンストレージポリシー (VM Storage Policies)] に移動し、[作成 (Create)] をクリックして [仮想マシンストレージポリシーの作成 (Create VM Storage Policy)] ウィザードを起動します。

vSphere ドキュメントの「ストレージポリシーの作成」の手順に従います。次の手順を必ず実行します。

[データストア固有のルール (Datastore specific rules)] の [ポリシー構造 (Policy structure)] ペインで、[「vSAN」ストレージでルールを有効化 (Enable rules for “vSAN” storage)] を選択します。
その他のペインを構成するか、必要に応じてデフォルトを受け入れます。
参照のために、StorageClass オブジェクトの storagePolicyName 値としてストレージポリシー名を記録します。

ローカル VMFS ストレージ：

ローカルストレージのストレージポリシーを作成するには、ストレージにタグを適用し、そのタグに基づいて次のようにストレージポリシーを作成します。

トップレベルの vSphere メニューから、[タグとカスタム属性 (Tags & Custom Attributes)] を選択します。
[タグ (Tags)] ペインで [カテゴリ (Categories)] を選択し、[新規 (New)] をクリックします。
カテゴリ名（tkg-storage など）を入力します。チェックボックスを使用して、[データセンター (Datacenter)] およびストレージオブジェクト（[フォルダ (Folder)] および [データストア (Datastore)]）に関連付けます。[作成 (Create)] をクリックします。
トップレベルの [ストレージ (Storage)] ビューで VMFS ボリュームを選択し、その [サマリ (Summary)] ペインで [タグ (Tags)] > [割り当て (Assign)]… をクリックします。
[タグの割り当て (Assign Tag)] ポップアップで、[タグの追加 (Add Tag)] をクリックします。
[タグの作成 (Create Tag)] ポップアップで、tkg-storage-ds1 などの名前をタグに付けて、作成した [カテゴリ (Category)] に割り当てます。[OK] をクリックします。
[タグの割り当て (Assign Tag)] で、タグを選択し、[割り当て (Assign)] をクリックします。
トップレベルの vSphere から、[仮想マシンストレージポリシー (VM Storage Policies)] > [ストレージポリシーの作成 (Create a Storage Policy)] を選択します。構成ウィザードが起動します。
[名前と説明 (Name and description)] ペインで、ストレージポリシーの名前を入力します。参照のために、StorageClass オブジェクトの storagePolicyName 値としてストレージポリシー名を記録します。
[ポリシー構造 (Policy structure)] ペインの [データストア固有のルール (Datastore specific rules)] で、[タグベースの配置ルールを有効化 (Enable tag-based placement rules)] を選択します。
[タグベースの配置 (Tag based placement)] ペインで、[タグルールの追加 (Add Tag Rule)] をクリックし、次の構成を行います。
- タグカテゴリ：カテゴリ名を選択します
- 使用量オプション：Use storage tagged with
- タグ：タグ名を参照して選択します
他のペインを確認して構成するか、必要に応じてデフォルト値を受け入れ、[確認して完了 (Review and finish)] >[終了 (Finish)] をクリックしてストレージポリシーを作成します。

カスタムストレージクラスの作成

クラスタ管理者は、次のように新しいストレージクラスを作成できます。

vSphere で、Kubernetes StorageClass の基盤として使用する仮想マシンストレージポリシーを選択または作成します。
- vSphere 管理者は、上記の「ストレージポリシーの作成 (vSphere)」に従ってストレージポリシーを作成できます。
provisioner、parameters、およびその他のオプションを指定して、StorageClass 構成の .yaml を作成します。
- vSphere で、storagePolicyName パラメータを二重引用符で囲んだ文字列の vSphere ストレージポリシー名に設定して、Kubernetes ストレージクラスを vSphere ストレージポリシーに関連付けます。
kubectl create -f にファイルを渡します。
kubectl describe storageclass <storageclass metadata.name> を実行してストレージクラスを確認します。

例については、Kubernetes ドキュメントの「動的プロビジョニングの有効化」を参照してください。

vSphere CSI の情報とリソースについては、VMware vSphere Container Storage Plug-in のドキュメントを参照してください。

クラスタでのカスタムストレージクラスの使用

前述の「デフォルトのストレージクラス」の 1 つを使用しないクラスタノードにパーシステントストレージをプロビジョニングするには、次のように、クラスタユーザーがポッド構成にカスタムストレージクラスを含めます。

kubectl のコンテキストをクラスタに設定します。例：
```
kubectl config use-context my-cluster-admin@my-cluster
```
ストレージクラスを選択または作成します。
- 選択する場合：
  - 使用可能なストレージクラスを一覧表示するには、kubectl get storageclass を実行します。
- 作成する場合：
  - クラスタ管理者は、上記の「カスタムストレージクラスの作成」に従ってストレージクラスを作成できます。
PVC とその PV を作成します。
1. PersistentVolumeClaim 構成の .yaml を、StorageClass オブジェクトの metadata.name 値に設定した spec.storageClassName で作成します。例については、Kubernetes ドキュメントの「動的プロビジョニングの有効化」を参照してください。
2. kubectl create -f にファイルを渡します。
3. kubectl describe pvc <pvc metadata.name> を実行して PVC を確認します。
4. PV は PVC で自動的に作成されます。kubectl describe pvc 出力の Successfully provisioned volume の後に一覧表示されている名前を記録します。
5. kubectl describe pv <pv unique name> を実行して PV を確認します。
PVC を使用するポッドを作成します。
1. persistentVolumeClaim.claimName 以下の PVC を spec.volumes に含めるように設定する、Pod 構成の .yaml を作成します。例については、vSphere Container Storage Plug-in ドキュメントの「vSphere Container Storage Plug-in を使用したブロックボリュームの動的なプロビジョニング」を参照してください。
2. kubectl create -f にファイルを渡します。
3. kubectl get pod <pod metadata.name> を実行してポッドを確認します。

vSphere CSI のボリューム拡張の有効化 (vSphere 7)

ワークロードクラスタで使用される vSphere CSI ストレージのボリューム拡張を有効にするには、csi-resizer サイドカーポッドをクラスタの CSI プロセスに追加する必要があります。

ワークロードクラスタの CSI 構成は、Kubernetes シークレットとしてエンコードされます。この手順では、CSI 構成シークレットを修正して csi-resizer プロセスを追加します。このシークレットには、2 つのエンコードされた構成データ文字列（シークレットの以前の CSI 構成データを含む values.yaml 文字列、および csi-resizer ポッドを展開する新しい overlays.yaml 文字列）を組み合わせた stringData 定義が追加されます。

注
オンラインボリューム拡張は、vSphere 7.0 Update 2 以降でサポートされています。詳細については、「vSphere with Tanzu でのボリュームの拡張」を参照してください。

変更するワークロードクラスタの管理クラスタにログインし、ワークロードクラスタの名前を取得する必要がある場合は tanzu cluster list を実行します。

ラベルセレクタ vsphere-csi とクラスタ名を使用して、ワークロードクラスタの CSI シークレットの名前を取得します。

$ kubectl get secret \
  -l tkg.tanzu.vmware.com/cluster-name=NAME_OF_WORKLOAD_CLUSTER \
  -l tkg.tanzu.vmware.com/addon-name=vsphere-csi
my-wc-vsphere-csi-secret

シークレットのコンテンツのバックアップを次のように YAML 形式で vsphere-csi-secret.yaml に保存します。
```
kubectl get secret my-wc-vsphere-csi-secret -o yaml > vsphere-csi-secret.yaml
```

シークレットの現在のコンテンツを、data.values 値を base64 デコードして、プレーン YAML に出力します。

$ kubectl get secret my-wc-vsphere-csi-secret -o jsonpath={.data.values\\.yaml} | base64 -d

#@data/values
#@overlay/match-child-defaults missing_ok=True
---
vsphereCSI:
CSIAttacherImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-attacher
  tag: v3.0.0_vmware.1
  pullPolicy: IfNotPresent
vsphereCSIControllerImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/vsphere-block-csi-driver
  tag: v2.1.1_vmware.1
  pullPolicy: IfNotPresent
livenessProbeImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-livenessprobe
  tag: v2.1.1_vmware.1
  pullPolicy: IfNotPresent
vsphereSyncerImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/volume-metadata-syncer
  tag: v2.1.1_vmware.1
  pullPolicy: IfNotPresent
CSIProvisionerImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-provisioner
  tag: v2.0.0_vmware.1
  pullPolicy: IfNotPresent
CSINodeDriverRegistrarImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-node-driver-registrar
  tag: v2.0.1_vmware.1
  pullPolicy: IfNotPresent
namespace: kube-system
clusterName: wc-1
server: 10.170.104.114
datacenter: /dc0
publicNetwork: VM Network
username: <MY-VSPHERE-USERNAME>
password: <MY-VSPHERE-PASSWORD>

エディタで vsphere-csi-secret.yaml を開き、次の手順を実行して、以下のコードのようになるようにします。

長い文字列である values.yaml の既存の定義を削除します。
最初の行の後に、stringData を定義する行を追加し、values.yaml をインデントして最初の要素にします。
前の手順の data.values 出力をコピーします。
3 行目の後で、data.values の出力を貼り付けて、それを values.yaml の値としてインデントします。
values.yaml の定義のすぐ下に、次に示すように、overlays.yaml に別の stringData 定義を追加します。ファイル内の他の定義は変更しないでください。

apiVersion: v1
stringData:
  values.yaml: |
    #@data/values
    #@overlay/match-child-defaults missing_ok=True
    ---
    vsphereCSI:
      CSIAttacherImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-attacher
        tag: v3.0.0_vmware.1
        pullPolicy: IfNotPresent
      vsphereCSIControllerImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/vsphere-block-csi-driver
        tag: v2.1.1_vmware.1
        pullPolicy: IfNotPresent
      livenessProbeImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-livenessprobe
        tag: v2.1.1_vmware.1
        pullPolicy: IfNotPresent
      vsphereSyncerImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/volume-metadata-syncer
        tag: v2.1.1_vmware.1
        pullPolicy: IfNotPresent
      CSIProvisionerImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-provisioner
        tag: v2.0.0_vmware.1
        pullPolicy: IfNotPresent
      CSINodeDriverRegistrarImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-node-driver-registrar
        tag: v2.0.1_vmware.1
        pullPolicy: IfNotPresent
      namespace: kube-system
      clusterName: wc-1
      server: 10.170.104.114
      datacenter: /dc0
      publicNetwork: VM Network
      username: <MY-VSPHERE-USERNAME>
      password: <MY-VSPHERE-PASSWORD>
  overlays.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind": "Deployment", "metadata": {"name": "vsphere-csi-controller"}})
    ---
    spec:
      template:
        spec:
          containers:
          #@overlay/append
            - name: csi-resizer
              image: projects.registry.vmware.com/tkg/kubernetes-csi_external-resizer:v1.0.0_vmware.1
              args:
                - "--v=4"
                - "--timeout=300s"
                - "--csi-address=$(ADDRESS)"
                - "--leader-election"
              env:
                - name: ADDRESS
                  value: /csi/csi.sock
              volumeMounts:
                - mountPath: /csi
                  name: socket-dir
kind: Secret
...

kubectl apply を実行して、修正された定義でクラスタのシークレットを更新し、csi-controller ポッドを再作成します。
```
kubectl apply -f vsphere-csi-secret.yaml
```

vsphere-csi-controller および外部リサイズ機能がクラスタで動作していることを確認するには、次の手順を実行します。

vsphere-csi-controller が 6 つの健全なポッドがあるワークロードクラスタで実行されていることを確認します。

$ kubectl get pods -n kube-system -l app=vsphere-csi-controller
NAME                                     READY   STATUS    RESTARTS   AGE
vsphere-csi-controller-<ID-HASH>   6/6     Running   0          6m49s

vsphere-csi-controller のログを確認して、外部リサイズ機能が開始したことを確認します。

$ kubectl logs vsphere-csi-controller-<ID-HASH> -n kube-system -c csi-resizer
I0308 23:44:45.035254       1 main.go:79] Version : v1.0.0-0-gb22717d
I0308 23:44:45.037856       1 connection.go:153] Connecting to unix:///csi/csi.sock
I0308 23:44:45.038572       1 common.go:111] Probing CSI driver for readiness
I0308 23:44:45.040579       1 csi_resizer.go:77] CSI driver name: "csi.vsphere.vmware.com"
W0308 23:44:45.040612       1 metrics.go:142] metrics endpoint will not be started because `metrics-address` was not specified.
I0308 23:44:45.042184       1 controller.go:117] Register Pod informer for resizer csi.vsphere.vmware.com
I0308 23:44:45.043182       1 leaderelection.go:243] attempting to acquire leader lease  kube-system/external-resizer-csi-vsphere-vmware-com...
I0308 23:44:45.073383       1 leaderelection.go:253] successfully acquired lease kube-system/external-resizer-csi-vsphere-vmware-com
I0308 23:44:45.076028       1 leader_election.go:172] new leader detected, current leader: vsphere-csi-controller-87d7dcf48-jcht2
I0308 23:44:45.079332       1 leader_election.go:165] became leader, starting
I0308 23:44:45.079638       1 controller.go:241] Starting external resizer csi.vsphere.vmware.com

オンラインモードまたはオフラインモードで vSphere CSI ストレージボリュームを拡張する方法の詳細については、「オンラインモードでのパーシステントボリュームの拡張」および「オフラインモードでのパーシステントボリュームの拡張」を参照してください。

トポロジ対応のボリュームのプロビジョニング (vSphere)

スタンドアローン管理クラスタから作成されたワークロードクラスタの場合は、トポロジ対応のローカルストレージボリュームプロビジョニングを構成できます。トポロジ対応のボリュームプロビジョニングにより、Kubernetes はボリュームを動的にプロビジョニングするときにインテリジェントな決定を下すことができます。Kubernetes は、ポッドのボリュームをプロビジョニングするのに最適な場所でスケジューラ入力を取得します。

アベイラビリティゾーン (AZ) を作成します。

「複数のアベイラビリティゾーンへのワークロードクラスタの展開（vSphere テクニカルプレビュー）」で説明されている手順に従って、vSphere で次を作成します。
1. ホストグループと仮想マシングループを追加します。
2. 仮想マシングループをホストグループ内に制限するルールを追加します。
  
  1 つの仮想マシングループとホストグループを使用して、ワークロードクラスタで AZ を実行します。
  
  注
  この制限ルールは、ローカルボリューム構成でのみ使用します。複数のアベイラビリティゾーンに展開する場合は、制限ルールを作成する必要はありません。
3. カスタムリソース定義 (CRD) VSphereFailureDomain および VSphereDeploymentZone を、スタンドアローン管理クラスタに展開します。
  
  AZ は、VSphereDeploymentZone にマッピングしてから、vSphere のホストグループにマッピングします。

新しい AZ を追加します。新しい AZ は、ytt オーバーレイ構成を使用するか、Tanzu CLI を使用して追加できます。

ytt

レガシークラスタとクラッシークラスタの ytt オーバーレイ構成を示します。

レガシークラスタ

#@overlay/match by=overlay.subset({"kind":"MachineDeployment", "metadata":{"name": "${CLUSTER_NAME}-md-0"}})
  ---
  apiVersion: cluster.x-k8s.io/v1beta1
  kind: MachineDeployment
  metadata:
    name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
  spec:
    clusterName: #@ data.values.CLUSTER_NAME
    replicas: #@ data.values.WORKER_MACHINE_COUNT_0
    selector:
      matchLabels: null
    strategy:
      type: #@ verify_and_configure_machine_deployment_rollout_strategy(data.values.WORKER_ROLLOUT_STRATEGY)
    template:
      metadata:
        labels:
          node-pool: #@ "{}-worker-pool".format(data.values.CLUSTER_NAME)
      spec:
        clusterName: #@ data.values.CLUSTER_NAME
        version: #@ data.values.KUBERNETES_VERSION
        bootstrap:
          configRef:
            name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
            apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
            kind: KubeadmConfigTemplate
        infrastructureRef:
          name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
          apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
          kind: AWSMachineTemplate
        failureDomain: #@ default_az_0

クラッシークラスタ

workers:
  machineDeployments:
  #@overlay/match by=overlay.index(0)
  - class: tkg-worker
    name: md-0
    replicas: #@ data.values.WORKER_MACHINE_COUNT_0
    #@overlay/match missing_ok=True
    failureDomain: #@ default_az_0
    metadata:
      annotations:
        run.tanzu.vmware.com/resolve-os-image: #@ "ami-region={},os-name={},os-arch={}".format(data.values.AWS_REGION, data.values.OS_NAME, data.values.OS_ARCH)

Tanzu CLI

Tanzu CLI を使用してトポロジ対応のローカルストレージプロビジョニングをサポートする新しい AZ を作成できます。

レガシークラスタ

tanzu cl node-pool set cl-name -f node-pool.yaml

# node-pool.yaml
name: vsphere-wc-1-manual-node-pool
replicas: 1
az: "rack4"

クラッシークラスタ

「ClusterClass ベースのクラスタのノードプール構成」の「設定（作成）」を参照してください。

動的ストレージ

概要：PersistentVolume、PersistentVolumeClaim、および StorageClass

サポート対象のストレージ タイプ

デフォルトのストレージ クラス

CNS の設定とストレージ ポリシーの作成 (vSphere)

カスタム ストレージ クラスの作成

クラスタでのカスタム ストレージ クラスの使用