GKE 向け Filestore Enterprise マルチシェアの一般提供を開始

※この投稿は米国時間 2022 年 12 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）環境にストレージを設定する場合、お客様は、ブロック ストレージ（Persistent Disk、または PD）またはファイル ストレージ（Filestore Enterprise）のいずれかを選択できます。どちらのストレージ タイプも、アップグレードやフェイルオーバーなどのユースケースのためホスト間でコンテナを移行するなどの操作を含め、GKE 上のコンテナに完全対応していますが、Filestore Enterprise では、特にフェイルオーバー時に、お客様側で運用に関する専門知識はほとんど必要ありません。

Storage Spotlight では、GKE Autopilot クラスタと GKE Standard クラスタで使用する Filestore Enterprise マルチシェアをご紹介しましたが、このたび、この機能の一般提供が開始されました。このブログ投稿では、GKE 環境でブロックかファイルを選択する際の考慮事項と、新しい Filestore Enterprise のマルチシェア機能の使用方法について説明します。

ブロック ストレージかファイル ストレージを選択する際の考慮事項

ブロックベースの Persistent Disk を選択した場合、最高水準の費用対効果を得られるうえ、豊富な種類の PD から選択でき、これが多くの GKE ユーザーから支持されています。しかし、PD の場合、お客様はストレージ システムに関する専門知識が必要です。PD を使用する場合、ファイル システムのロジックはホストにあります。つまり、移行中にホストがコンテナを手際よくシャットダウンし、ファイル システムのマウントを解除し、PD をターゲット ホストに再アタッチして、ファイル システムをマウントする必要があります。そうして初めて、コンテナを起動できます。GKE はこれらの操作の多くを自動的に管理します。しかし、フェイルオーバーの場合、ファイル システムやディスクの破損の問題が発生する可能性があります。ユーザーは、マウントされたボリュームを使用する前に、いくつかのクリーンアップ処理（"fsck"）を実行する必要があります。

対照的に、Filestore Enterprise はホストから切り離されたフルマネージド型リージョン ファイル システムを備え、ボリュームを接続 / 切断するためのインフラストラクチャ操作を実行する必要がありません。また、複数（何百から何千）のコンテナで同時に読み書きができるストレージもお客様にとってメリットになります。このような理由から、JupyterHub などのデータにアクセスする複数のデベロッパー、Wordpress、Drupal、IBM FileNet などのコンテンツ管理システム、プロジェクトやプロセス管理ツールなどの対話型 SaaS アプリケーション、複数のユーザーが読み書きするケース、ゲノム処理など複数のファイルを消費する分析アプリケーションなど、さまざまなユースケースで Filestore Enterprise が人気を集めています。

Filestore Enterprise のマルチシェアによるストレージ利用率の最適化

GKE Autopilot クラスタと GKE Standard クラスタで使用する Filestore Enterprise マルチシェアの導入により、Filestore がより使いやすくなりました。Filestore は、Container Storage Interface（CSI）ドライバで 1 TB の容量から利用できるようになっています。お客様は、GKE ノードでコンテナを使用するように、Filestore インスタンスでボリュームをビンパッキングしたいと考え、Filestore インスタンスの利用率向上を促進するためにディレクトリを使用していました。しかしながら、このソリューションはシームレスではなく、容量の分離、ボリュームごとのオブザーバビリティ、CMEK のサポートといったエンタープライズ向け機能に欠けています。GKE の Filestore マルチシェア サポートは、Kubernetes ユーザーが慣れ親しんでいる粒度の細かいリソース サイズの適正化と、Filestore Enterprise の信頼性という、両者の長所を備えています。コンテナをノードにビンパッキングして効率を高めるのと同様に、複数の永続ボリュームを Filestore Enterprise インスタンスにパッキングして、ストレージの利用率を高め、費用を削減できます。さらに、Filestore のマルチシェアは、複数の共有で IP アドレスなどのネットワーク要素を共有することにより、ネットワーク リソースを節約し、アプリケーションのスケーラビリティを向上させることができます。

Filestore インスタンスには、100 GiB から最大 1 TiB までの永続ボリューム（PV）をプロビジョニングできます。GKE は、関連するすべてのリソースをシームレスに管理します。さらに、図 1 に示すように、Kubernetes の Persistent Volume Claim（PVC）を介してストレージを要求すると、内部で GKE Filestore CSI ドライバが Filestore Enterprise インスタンス上のボリューム要求をシームレスにビンパッキングし、特定のインスタンスのスペースがなくなると新しい Filestore インスタンスも作成します。ボリュームが削除されると、GKE Filestore CSI ドライバが、基盤となる Filestore インスタンスをシームレスに縮小または削除します。

「Filestore Enterprise は、コンピューティングから切り離され、GKE 上のコンテナとうまく連動するリージョン ストレージ システムを提供します。マルチシェアを利用することで、使用率を最適化し、費用効率を高めることができます」と Mandiant の Ajay Kemparaj 氏は語っています。同氏はまた、「この機能により、Filestore Enterprise を GKE におけるデフォルトのストレージ ソリューションとすることを決定しました」とも述べています。

デプロイと構成に関する考慮事項

Filestore の新しいマルチシェア機能を使用する場合は、以下の点に注意する必要があります。

ノイジー ネイバー: 共有を有効にすると、基盤となる Filestore インスタンスのスペースを再利用して費用を削減できます。ただし、IOPS やスループットなどのパフォーマンス リソースを共有することにもなります。

信頼境界: Filestore マルチシェアを使用するすべてのストレージ リクエスト（PVC 経由）は、基盤となる同じ Filestore インスタンスにパッキングできるため、PVC が同じ信頼境界を共有することをおすすめします。より強固な分離が必要な場合（たとえば、異なる 2 人のユーザーからストレージを要求し、データを分離しておきたい場合）、Filestore 単一共有インスタンス（各 PV が一意の Filestore インスタンスにマッピングされる）の使用をおすすめします。これは、CSI ダイナミック プロビジョニングが可能な GKE でもサポートされています。

リージョンでの可用性: Filestore Enterprise はリージョン サービスであり、99.99% の可用性 SLA を保証します。そのため、リージョン内の 3 つのゾーンに GKE クラスタをデプロイでき、すべてのクラスタが同じ Filestore NFS 共有にアクセスできます。このデプロイ アーキテクチャは、すべての Filestore Enterprise データが 3 つのゾーンで同期的に複製されるため、ゾーン停止から保護されます。

使ってみる

Filestore Enterprise マルチシェアは、動的プロビジョニングを含む標準的な Container Storage Interface セマンティクスを使用してプロビジョニングされます。永続ボリュームを持つ 2 つの Kubernetes デプロイが基盤となる Filestore Enterprise インスタンスを共有する方法の詳細な例については、ユーザーガイドをご覧ください。

-ソフトウェア エンジニア Saikat Roychowdhury

-プロダクト マネージャー Akshay Ram