コンテナ向け永続ストレージとは

クラウドネイティブ・アプリケーションの開発に不可欠なコンテナは、アプリケーションとその依存関係をパッケージ化した、軽量でポータブルなソフトウェアのユニットで、最新のITインフラストラクチャ全体に簡単にデプロイできます。

コンテナは本質的に一時的なものです。これらは一時的で、必要に応じて起動および停止することが意図されています。この柔軟性により、非常に柔軟で拡張性の高いですが、コンテナが実行を停止すると、生成されたコンテナ・データはすべて失われます。永続ストレージは、個々のコンテナに関係なくデータを利用可能な状態に保つことで、この問題を解決します。

永続ストレージがなければ、クリティカルなシステムに障害が発生します。例えば、コンテナ内で稼働している銀行の取引データベースで、定期的な更新時に顧客の口座残高が失われたり、eコマースプラットフォームで再起動のたびにショッピングカートの内容が失われたりする可能性があります。

組織がクラウドネイティブやマイクロサービス・アーキテクチャーに次に進む中、コンテナはアプリケーションのデプロイメントと管理の中心的存在となっており、ステートフルなアプリケーションを大規模に実行するためにはコンテナ用のストレージが不可欠となっています。Strategic Market Researchの最近のレポートによると、2024年の世界のアプリケーション・コンテナ市場は約21億米ドルと評価されています。2030年には69億米ドルに達し、年平均成長率（CAGR）21.1％で成長すると予測されています。¹

エンタープライズ環境では、永続ストレージはファイル、ブロック、Object Storageの形で存在し、それぞれ異なるワークロードに適しています。組織は通常、ハイブリッドクラウドと分散型クラウド環境をサポートするように設計されたハードウェア・システムとソフトウェア定義ストレージ（SDS） プラットフォームを組み合わせて、これらのストレージ・ソリューションを提供します。

コンテナ化とは、実行に必要なオペレーティングシステム（OS）ライブラリーと依存関係（通常はLinuxベース）のみを含むソフトウェア・コードをパッケージ化することです。このプロセスにより、あらゆるインフラストラクチャーで一貫して実行できる、コンテナなどの単一の軽量ユニットが作成されます。

組織が仮想マシン（VM）からコンテナへと移行するにつれ、コンテナ化されたワークロードを大規模に管理する必要性が高まりました。2013年に登場したDockerは、開発者がコンテナを構築および共有するための標準化された方法を提供することで、コンテナを広く利用できるようにしました。しかし、ハイブリッド・マルチクラウド環境全体で何百、何千ものコンテナをオーケストレーションするには、複雑さを処理する方法が必要となります。そのため、Kubernetes がコンテナ化されたアプリケーションのデプロイメント、スケーリング、管理を自動化するために開発されました。

2014年にGoogleによって作られたKubernetesは、Cloud Native Computing Foundation（CNCF）によって管理されているオープンソース・プラットフォームです。AWS、Microsoft Azure、Google Cloud、IBM Cloudなどの主要なクラウド・プロバイダーがこのプラットフォームをサポートしています。

Kubernetesはコンテナをポッドで実行します。これらはKubernetesクラスター内の複数のノードにデプロイされます。アプリケーション・プログラミング・インターフェース（API）を通じてコンポーネント間のコンフィギュレーションとコミュニケーションを管理し、多様なシステム間で自動化されたオーケストレーションをサポートします。現在、Kubernetesはコンテナオーケストレーションの事実上の標準となっています。

データ・ストレージに関連して、Kubernetesの仕組みの重要な側面は、ステートレス・アプリケーションとステートフル・アプリケーションの違いを理解することです。ステートレス・アプリケーション（例えば、APIリクエストを処理するWebサーバー）は、各リクエストを個別に処理します。その結果、セッション間ではデータを保持しません。対照的に、ステートフル・アプリケーション（データベースなど）はデータを保持し、適切に機能するために以前のやり取りからの情報に依存します。

さらに、Kubernetes のコンテナとPodは一時的なもので、いつでも停止、再起動、再スケジュールすることができます。ステートレス・アプリケーションの場合、この動作は問題ではありません。ただし、ステートフル・アプリケーションでは、コンテナが停止すると、コンテナ内に保存されているデータが失われます。ここでは、コンテナのライフサイクルからデータを分離することで、永続ストレージがコンテナ化された設定で重要な役割を果たします。

コンテナに移行する従来のアプリケーションに加え、データベース、人工知能（AI）、機械学習（ML）などのデータ集約型ワークロードのクラウド・ベース化が進んでいます。このようなワークロードでは、データがコンテナの終了後も存続し、分散システム内の状態を維持し、モデルトレーニングが要求する高スループット、低遅延 のパフォーマンスを提供できるよう、永続ストレージが必要となります。

コンテナの永続ストレージは、コンテナからデータを分離するために連携して動作する一連のコンポーネント上に構築されています。Kubernetesでは、管理者がストレージ・インフラストラクチャーを構成し、開発者とアプリケーションは簡単なリクエストを通じてストレージ・インフラストラクチャーにアクセスします。

これらのコンポーネントには次のものが含まれます。

• ボリュームとバインド・マウント
• PersistentVolume（PV）
• PersistentVolumeClaim（PVC）
• ストレージクラス
• コンテナ・ストレージ・インターフェース（CSI）

コンテナにストレージを接続するには、主にバインド・マウントと名前付きボリューム（Dockerボリュームなど）の2つの方法があります。

• バインド・マウントは、ホスト・マシンから特定のファイルまたはディレクトリーをコンテナに直接接続します。

• Kubernetesが複数のストレージ・システムにわたってボリュームを管理するため、ボリュームの柔軟性が向上します。

ボリュームは、Pod内のコンテナからアクセスできるストレージの場所です。コンテナが停止すると消去されるコンテナ内の一時ストレージとは異なり、ボリュームはポッドの存続期間中、保持されます。つまり、コンテナに障害が発生して同じポッド内で再起動しても、ボリューム内のデータは引き続き使用できます。

ボリュームは、ローカル・ディスク、ネットワーク・ファイル・システム（NFS）などのプロトコルによるネットワーク接続ストレージ、クラウド・ベースのストレージ・サービスなど、さまざまなタイプのストレージ・デバイスに接続できます。

PersistentVolumeはKubernetesクラスター内にストレージを提供し、手動または自動で作成されます。

通常のボリュームと永続ボリューム（PersistentVolume、PV）の主な違いは寿命です。永続ボリュームはどのポッドとも独立して存在します。この設定は、ストレージにアクセスするポッドが削除されたり、別のマシンに移動されたりした場合でも、ストレージが保持されることを意味します。

PersistentVolumeには、それを使用するポッドとは異なる独自のライフサイクルがあります。管理者は、特定のストレージ容量、読み取り／書き込みアクセス権限（単一ポッド・アクセスの場合はReadWriteOnce、共有アクセスの場合はReadWriteManyなど）を構成できます。

PersistentVolumeClaimは、アプリケーションまたはユーザーによるストレージ要求です。ポッドはPersistentVolumeに直接接続するのではなく、PersistentVolumeClaimを中間層として利用します。クレームには、必要なストレージ容量と必要なアクセス・モードを指定します。Kubernetesは、それを利用可能なPersistentVolumeに照合します。この分離により、開発者は基盤となるストレージ・インフラストラクチャーを理解しなくても、ストレージを要求できます。

クレームがPersistentVolumeに接続されると、ポッドはファイル・システムの場合と同様に、データの読み書きをできます。 ポッドを移動または再起動しても、同じクレームと同じ永続データにアクセスできます。

エンタープライズ環境では、アプリケーションごとにストレージ・ボリュームを手動で作成することは複雑で管理が困難になります。Kubernetesは、さまざまな種類のストレージ（高性能ソリッドステート・ドライブなど）を定義し、プロビジョナーを使用して必要に応じてデータボリュームを自動的に作成するStorageClassによってこの課題を解決します。

アプリケーションがストレージを要求し、StorageClassを参照すると、Kubernetesは手動セットアップを必要とせずに適切なボリュームをプロビジョニングします。この機能は全体の ストレージ管理を簡素化します。

コンテナ・ストレージ・インターフェイス（CSI）は、Kubernetes がさまざまなストレージ・システムと対話できるようにする、標準化されたベンダー中立のAPIです。

CSIを使用すると、ストレージ・プロバイダーのプラットフォーム（IBM Storage Fusion、NetAppなど）が独自のプラグインを個別に開発および更新できます。これらのプラグインは、必要に応じてボリュームを作成、接続、プロビジョニング、削除するなど、ストレージのライフサイクル全体を管理します。

コンテナ用永続ストレージは、組織がコンテナ化された設定でステートフル・アプリケーションを実行することを可能にし、次のようなメリットをもたらします。

• データの耐久性とレジリエンス：各永続ボリュームに書き込まれたデータは、コンテナの障害、再起動、スケジュール変更にも耐え、データ損失を防ぎ、基盤となるコンテナ・インフラストラクチャーが変化してもステートフル・アプリケーションのレジリエンスを維持します。

• オペレーションの簡素化：動的なプロビジョニングと自動化されたストレージ管理により、手作業によるワークロードを軽減します。プラットフォーム・チームがストレージ・ポリシーを一度定義することで、アプリケーションは、名前空間内のセルフサービス・リソースとしてストレージを利用できるようになります。

• 高性能と拡張性：コンテナ用のストレージは、AI/MLトレーニングやリアルタイム分析などのデータ集約型ワークロードに必要なスループット、低遅延、拡張性を実現します。

• 柔軟性と携帯性：Kubernetes永続ボリュームとCSIドライバーはストレージを抽象化し、組織がオンプレミスインフラ、プライベートクラウド、パブリッククラウド環境でアプリケーションを運用できるようにし、ハイブリッドクラウド戦略をサポートします。

• セキュリティーとコンプライアンス：エンタープライズ・ストレージ・システムによってバックアップされた永続ボリュームは、コンプライアンスや規制要件を満たすために必要なデータ保護機能、暗号化、複製、バックアップなどの機能を提供します。

• コスト効率：ダイナミック・プロビジョニングは需要に応じてストレージを増減し、自動化されたデータ階層化は使用頻度の低いデータをコスト効率の高いストレージ階層に移動させるため、組織はコストを最適化できます。

• 共有アクセス：コンテナ用の永続ストレージにより、複数のポットが同じデータを同時に読み書きできるようになり、ストレージ・リソースを重複させることなく共同作業ワークフローをサポートします。

組織は、さまざまなツールやソリューションを通じてコンテナの永続ストレージにアクセスできます。

• コンテナ・オーケストレーション・プラットフォーム
• エンタープライズ・ストレージ・ソリューション
• パブリッククラウド・プロバイダー

コンテナ・オーケストレーション・プラットフォーム（Red Hat OpenShiftなど）は、CSIドライバーと動的なストレージ・プロビジョニングのサポートが組み込まれた、統合された永続ストレージ管理を提供します。

これらのプラットフォームは、コンテナ化されたワークロードを大規模に実行する組織のデプロイメントと運用を簡素化します。

エンタープライズ・ストレージ・プラットフォーム（IBM Storage Fusionなど）は、スナップショット、クローン作成、複製、ディザスター・リカバリーなどの高度なデータ・サービスを備えた、コンテナ・ネイティブのストレージ・ソリューションを提供します。

これらのプラットフォームは、CSIドライバーを介してKubernetesと直接統合され、ステートフル・アプリケーションのセキュリティ、コンプライアンス機能、共有アクセス制御を提供します。

AWS、Microsoft Azure、Google Cloud、IBM Cloudなどのパブリッククラウド・プロバイダーは、Amazon Elastic Block Store（EBS）やIBM Cloud Block Storageなどのネイティブの永続ストレージ・オプションを備えたマネージドKubernetesサービスを提供しています。

コンテナ用の永続ストレージは、以下のビジネス・ユースケースをサポートします。

• データベースとデータ管理
• AIワークロード
• DevOpsおよびCI/CD
• バックアップとディザスター・リカバリー（BDR）