Kubernetesにおける外部ボリュームスナップショットを用いた効率的なデータクローニング

2021年9月のKubernetes Blogの投稿で、CAST AIのAugustinas Stirbis氏は、リソースを大量に消費するクラスターでのデータ複製を処理する方法について概説しました。この記事では、大規模データセットのコピーに伴うパフォーマンス上のボトルネックに対処し、事前にプロビジョニングされたVolumeSnapshotsを使用して、効率的に隔離された開発環境を作成することを提案しています。

何が起きたか

開発者は、本番システムへのリスクなくスキーマ変更のテストや一括操作を実行するために、本番データの正確なコピーを必要とすることがよくあります。従来、これにはブロックストレージから計算ノードへデータをダウンロードし、再びストレージへアップロードするというプロセスが含まれます。このプロセスはネットワーク帯域幅、CPU、RAMを大量に消費し、反復サイクルの遅延や高いインフラコストにつながります。ハードウェアアクセラレーションは助けになりますが、ネットワーク経由でデータを移動させるという根本的な非効率性は依然として大きな障害です。

Kubernetesはこの問題に対応するためVolumeSnapshotsを導入し、1.12でアルファ版、1.17でベータ版を経て、バージョン1.20で一般提供（General Availability）に至りました。これらのスナップショットは、ストレージプロバイダーのAPIを活用してデータボリュームを複製します。オンプレミスシステムでは、これは通常、新しいディスクを不変のスナップショットにポイントするメタデータ操作であり、差分のみを保存します。パブリッククラウドでは、スナップショットはオブジェクトストレージに保存され、ブロックストレージにコピーバックされます。これはプロバイダー側で計算およびネットワークリソースを使用しますが、Kubernetesクラスター自体からの負荷を軽減するため、ユーザーにとっては操作が瞬時に行われたように見えます。

しかし、設計上の制限が存在します。VolumeSnapshotsは名前空間に属しています。Kubernetesはテナント分離を確保するため、ある名前空間内のポッドが別の名前空間内のPersistentVolumeClaims（PVC）をマウントすることを禁止しています。つまり、本番名前空間で作成されたスナップショットを、開発名前空間から直接参照することはできません。同じ名前空間内で重複ボリュームを作成することは可能ですが、誤ったコピーを参照するリスクが高まり、アクセス制御が弱まるため危険です。

仕組み

提案されたソリューションは、「ゴールデン・スナップショット」を外部で作成することで、Kubernetesの名前空間制限を回避します。初期スナップショットを取得するためにKubernetes APIを使用する代わりに、管理者はクラウドプロバイダーのツールを使用してディスク状態をキャプチャします。その後、この外部スナップショットはVolumeSnapshotContentとしてKubernetesにインポートされます。VolumeSnapshotContentは特定の名前空間にバインドされないクラスタースコープのリソースです。このコンテンツは橋渡し役となり、複数の名前空間が同じ基盤となるデータソースを参照できるようにします。

VolumeSnapshotContentが確立されると、チームは特定のNamespace内で、このグローバルなコンテンツにマップされるVolumeSnapshotを作成できます。そこから、そのスナップショットに基づくPersistentVolumeClaimを生成します。このPVCは、開発環境内のデプロイメントまたはステートフルセットによってマウントできます。各チームはデータの一意で書き込み可能なコピーを取得でき、元のゴールデン・スナップショットは不変のまま、クラスター全体で効率的に共有されます。

主要な詳細

• VolumeSnapshotsは、1.12でアルファ版、1.17でベータ版を経た後、Kubernetesバージョン1.20で一般提供（Generally Available）となりました。
• 従来のダウンロード-アップロード方法によるデータ複製は、ストレージレベルのスナップショットと比較して、過度なネットワークトラフィックと計算リソースを消費します。
• KubernetesのVolumeSnapshotsは設計上名前空間に属しており、テナント分離を保護するために名前空間間の直接的なPVCマウントを防止します。
• 回避策には、AWS CLIやgcloudなどのクラウドプロバイダーのCLIツールを使用して、Kubernetesの外側でスナップショットを事前プロビジョニングすることが含まれます。
• 管理者は外部スナップショットIDをVolumeSnapshotContentとしてインポートします。これはクラスタースコープであり、任意の名前空間から参照できます。
• 各チームは、グローバルなVolumeSnapshotContentにマップされるローカルなVolumeSnapshotとPVCを作成し、隔離されたが同一のデータコピーを確保します。

なぜ重要なのか

データ集約型アプリケーションを管理するソフトウェアエンジニアやSREにとって、このアプローチはステージング環境やテスト環境の立ち上げに関連する時間とコストを大幅に削減します。大規模データセットをネットワーク経由で繰り返し移動する必要を避けることで、チームはデータベーススキーマの変更やデータ集約型の機能に対してより迅速に反復作業を行えます。また、本番名前空間をロックダウンしたまま開発者に現実的なデータセットを提供するため、セキュリティベストプラクティスにも合致しています。

VolumeSnapshotsのような名前空間リソースと、VolumeSnapshotContentのようなクラスタースコープリソースの区別を理解することは、高度なKubernetes運用において不可欠です。このパターンは、プラットフォームの制限を克服するために、Kubernetesの抽象化とともにクラウドプロバイダーの機能をどのように活用するかを示しています。最適なパフォーマンスと柔軟性を達成するために、いつKubernetes APIの外側に出るべきかを知ることの重要性を強調しています。

あなたができること

• ゴールデンデータコピーのソースとなる本番名前空間内のPersistentVolumeClaimを特定してください。
• クラウドプロバイダーのコンソールまたはCLIを使用して、基盤となるディスクのスナップショットを作成し、スナップショットIDを記録してください。
• クラウドプロバイダーからの外部スナップショットIDを参照するVolumeSnapshotContentマニフェストをKubernetesに作成してください。
• クラスター全体のVolumeSnapshotContentにバインドされる、各ターゲット開発名前空間内のVolumeSnapshotを定義してください。
• ローカルVolumeSnapshotをデータソースとして使用し、開発名前空間内にPersistentVolumeClaimを生成してください。
• 新しいPVCを使用してアプリケーションまたはデータベースのステートフルセットをデプロイし、データクローンがアクセス可能かつ隔離されていることを確認してください。