第4回 『コンテナとストレージの切っても切れない関係』

記事をシェアする:

こんにちは。IBMテクノロジー事業本部の田中です。ストレージのテクニカルセールスをしています。

コンテナ化というとまずアプリケーションのことを考えますが、実際にコンテナ化したアプリケーションを動かす時にはストレージが必要になることが多く、実はコンテナ環境ではストレージは非常に重要な要素です。今回はKubernetes環境でコンテナを稼働させる際に検討が後回しになってしまったり、忘れられがちなストレージについて、これだけは知っておいていただきたいポイントをご紹介します。

 

コンテナ環境とストレージ

みなさんは仮想化の環境は利用されているでしょうか？当たり前だろうと思われた方がほとんどだと思いますが、今は仮想化を使っていない方を探す方が難しいほどあらゆる企業で利用されています。

仮想環境を運用している方はストレージを意識されているはずですが、利用者の方はストレージについてはそこまで意識はされていないかもしれません。一般的に仮想環境では複数ホストで外部ストレージを共有、あるいはハイバーコンバージド環境ではサーバー内蔵ディスクを利用してホスト間で共有できるストレージを構成した上で、同時アクセス可能なファイルシステムでフォーマットされています。

仮想マシンが持つ仮想ディスクは複数ホストで共有できるファイルシステム上にありますので、万一ホストに障害が起きた場合やサーバーメンテナンスの際には、仮想マシンを別のホストに移行して利用を継続することができます。

 

一方、コンテナ環境では仮想環境のようにホスト間でデータを共有するためのファイルシステムは標準では準備されていません。コンテナは非常に軽量ですのでコンテナイメージから短時間で新しいコンテナを起動することができるため、もしホストの障害などの理由でコンテナが落ちた場合には、新しいコンテナを起動すればいいという考え方になっています。

データを持たないステートレスなアプリケーションであればこれで問題ないのですが、複数コンテナで同じデータを共有したり、新しいコンテナが起動した場合にそれまでのデータを引き継ぎたいアプリケーションもあります。そういったアプリケーションのためにコンテナの外部でデータを保持する「永続ボリューム(PersistentVolume:PV)」という仕組みが準備されています。

自動化が実現されセルフサービスでユーザーがコンテナを作成できるKubernetes環境では、永続ボリュームもユーザーのリクエストで作成しコンテナに接続することができます。この点がユーザーにとっても管理者にとっても従来の仮想環境と異なるため、管理者はもちろん、ユーザーもストレージを意識する必要がでてきます。

 

永続ボリューム(PersistentVolume:PV)のアクセスモード

永続ボリュームにはアクセスモードと呼ばれる３種類のアクセス方法があります。コンテナと永続ボリュームの接続が1:1になるReadWriteOnce(RWO)、複数のコンテナに接続して同時に読むことができるReadOnlyMany(ROX)、複数のコンテナが同時に読み書きできるReadWriteMany(RWX)の3種類です。

アクセスモードはストレージの種類で決まります。基本的にはRWOはブロックストレージ、RWXはファイルストレージだと考えてください。ブロックストレージであればストレージのボリューム(LUN)が１つの永続ボリュームになり、ファイルストレージの場合はファイルサーバーからエクスポートしたディレクトリ、もしくはエクスポート内のディレクトリが１つの永続ボリュームとなります。

管理者がストレージを提供する際にアクセスモードの情報を登録しておくと、ユーザーは自分が使いたいアクセスモードを指定して永続ボリュームを要求することで要求を満たす永続ボリュームが提供されます。

 

コンテナ間でのデータ共有

複数のコンテナでデータを共有する方法としては、RWXもしくはROXの永続ボリュームを利用する方法もありますが、コンテナ間でデータの同期を行う方法もあります(各コンテナにはRWOの永続ボリュームを接続)。この場合はアプリケーションもしくはミドルウェアにデータを同期する仕組みを実装する必要がありますので、今動いているアプリケーションにそのような機能がない場合は、永続ボリュームを使う方がアプリケーションの変更は少なくコンテナ化を実現できます。

ただし、クラウドのAvailability Zoneのようにデータセンターを分散してコンテナを稼働させる場合に、データセンター間でRWXの永続ボリュームを共有できるかどうかは環境によって異なるので注意が必要です。これはオンプレミスにKubernetesのインフラを構築する場合も同様で、データセンターをまたいでデータを共有する方法は検討が必要です。

永続ストレージは環境に依存して動作が異なる可能性があるため、実装の手間をかけてでもアプリケーション側でデータを同期する仕組みを作ることができれば、場所を気にせずどこでもコンテナを動かすことができます。

 

また、永続ストレージに頼らずに、Kubernetesインフラの外のオブジェクトストレージをデータ置き場として使うという選択肢も考えられます。オブジェクトストレージはネットワークが疎通していればどこからでもAPIでアクセスできる点が便利ですが、APIを利用するようにアプリケーションの変更が必要になる可能性が高いです。

 

データ共有の方法にもいろいろな方法が考えられますので、アプリケーションのコンテナ化を行う際には必ず検討が必要となります。アプリケーション側で検討した方法が、コンテナを動かそうとしているインフラで使えるのか、早い段階から運用チームとも会話が必要になります。コンテナ化を成功させるためには運用チームとアプリチームの連携が重要になります。

 

プロビジョニングの方式とContainer Storage Interface(CSI)

主に運用の方におさえておいていただきたいポイントになりますが、永続ボリュームの提供に静的と動的の2種類のプロビジョニング方法があります。

 

静的プロビジョニングでは管理者がストレージ上に作成したボリュームの情報(容量やアクセスモードなど)を１つずつ登録する必要があります。ユーザー/アプリケーションが少ない場合はこれでも運用できるでしょうが、ユーザーが増えてくると運用が回らなくなるのは容易に想像できます。

 

動的プロビジョニングは、最初にストレージの情報を登録しておけばユーザーの要求に応じて動的にストレージ上にボリュームが作成されユーザーに提供することができます。最初の設定を行うだけでストレージ提供が自動化できますので、ユーザーやアプリケーションが増えた場合でも運用が容易になります。

動的プロビジョニングはストレージを操作しますので、対応ストレージを利用する必要があります。Kubernetesには標準でいくつかのストレージに対応したプラグインが組み込まれており、動的に操作することができますが、Kubernetes組み込みの場合はもしプラグインにアップデートがあった場合にKubernetes全体のアップデートが必要になってしまいます。

 

これを避けるためにContainer Storage Interface(CSI)という仕組みが提供されており、様々なベンダーが提供しているドライバーから必要なものだけを組み込んで稼働させることができます。更新があった場合もドライバーのみを簡単にアップデートが可能で、容易にストレージ提供の自動化ができますので、今すぐ動的なプロビジョニングが不要だとしても、Kubernetes環境で利用するストレージを選定する際は、将来のことも考えてCSI対応ストレージの検討をおすすめします。

CSIではスナップショットやボリュームのクローン、拡張などの機能とコマンドが定義されており、ユーザーはバックエンドのストレージの違いを気にすることなく、共通のコマンドで様々なストレージを操作することができるようになります。

CSI対応しているストレージでも、ドライバーごとにサポートしている機能には差異があるので注意が必要です。CSIで定義されている全ての機能をサポートしていないストレージもあるので注意してください。

どのストレージがどの機能をサートしているのかを知るためには、GitHubのドキュメントを参照してください。CSI対応ストレージの一覧、ストレージごとにサポートしているCSIの機能、サポートされるアクセスモードなどのリストが公開されていますのでストレージ選定の参考にしてください。ベンダー製品/OSS、オンプレミス/クラウドなど幅広いストレージが掲載されています。

Kubernetes CSI Developer Documentation –  5. Drivers

 

ここまで、Kubernetes環境とストレージの関係について説明してきました。コンテナ化に取り組む際にデータをどう保存するのかも合わせて検討が必要になりますので、ストレージについてもあわせて検討していってください。今後IBMとRed Hatのストレージソリューションもご紹介していく予定です。