HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

コンテナにバックアップが必要だって知ってた？

データ永続性は今や、一過性のコンテナ・アプリケーションの一部になり、バックアップとデータ保護がコンテンツに求められるようになった。

Storage Magazine6月号より
Chris Evans

コンテナ革命によって、パブリックとプライベートクラウド双方にデプロイされ稼働する一過性のコンテナ世界が到来するものと、一時期は考えられていた。しかし、実際のエンタープライズ・データマネジメントにおいては、アプリケーションデータは、一個のコンテナの寿命より長い期間の保存が必須である。その結果、ベンダーはコンテナ基盤にデータ永続性の機能を追加することになった。これは、他の全てのエンタープライズ・データと同じように、コンテナ・データを保護するためにコンテナのバックアップが必要になったことを意味する。

コンテナ・データの保護には、独自の要件と手順が存在する。この記事では、コンテナ・バックアップがどのように行われ、ベンダーがコンテナのバックアップに関してどのような基準を作りつつあるかを探っていく。

なぜ永続性が必要になったか

この4年間、コンテナの人気が高まるにつれて、完全に一過性のアプリケーションの実行は、一般の企業には向いていないことが明らかになってきた。少なくともこれは通常、ITが供給されるやり方ではない。アプリケーション開発のための12要素の方法論の中においてさえ、アプリケーションはステートレスで（第６要素）永続させなければならないとしても、データはバックアップサービスで保存しなければならないと明言している。

コンテナ技術のつい最近の実装は、アプリケーションデータを、コンテナと関連づけたフォルダにコンテナとして、同じホストに保存することだ。（これはDockerによって標準化されている）。コンテナを失えば、データも失われる。多くの会社が、コンテナ・データを保護する方法は、レジリエント基盤上にある多数のコンテナ間でデータをレプリケートすることだろう、と考えた。一個のコンテナ・アプリケーションに障害が起きても、データは残っているコンテナから再生可能なはずだ、と。

しかし、このアプローチにはいくつか欠点がある。一つめは、コンテナ・アプリケーションが常に稼働していることを前提にしている点だ。もしそのデータが数日間、数週間、数ヵ月使われなかったら、何が起きるか。二つめは、障害が起きてデータを再生成するときのオーバーヘッドを考慮していない点だ。プログラムの出来が悪いために、１日１回クラッシュする1TBのデータベース・アプリケーションを想像してみてもらいたい。これは、毎日１TBのデータ転送が発生するということで、本番システムのパフォーマンスに影響が出る。データを多数のコンテナにコピーするより、新しいコンテナを作って、既存のデータをマウントした方が、余程手っ取り早い。三つめは、これらのアプリケーションがステートレスのため、エージェントを必要とするバックアップ製品のような既存の技術を使うのが難しく、コンテナ・バックアップや他のデータ保護をコンテナ内で行わなければならない、という点だ。

コンテナ業界とプラットフォームは、前述の12要素の方法論のもとで作られたものでも、コンテナ・インスタンスに永続的なボリュームとファイル共有を付けられるように、いち早く変更を行った。これによって、従来型のストレージ・プラットフォーム上の外部ストレージや共有ストレージはコンテナ環境と接続を始めた。外部ストレージにはいくつもの利点がある。以下にそれを述べる。

■ データの寿命が、コンテナの稼働するホストに縛られない。共有ストレージによって、コンテナを稼働するホストは効率的にステートレスになれる。
■ 共有ストレージは、従来のSANやNASのプラットフォームにおいて見られるような拡張性、レジリエンシ、パフォーマンスの長所を、コンテナ環境でも提供できる。
■ コンテナ毎に幅広いメディアパフォーマンスを使い、パフォーマンスレベルを適用できる。
■ 外部ストレージ（特にSAN）は、データ保護を提供している。
■ 外部ストレージは、特にパブリッククラウドとの組み合わせでデータの高い機動性を発揮する。企業はデータにセキュリティ、保護、監査を求めるが、外部ストレージにコンテナ・データを持てば、これらの要件の全てを満たせる。

データとイメージを分離する

話を進める前に、コンテナ・データの意味を明確にしておくことが重要だ。稼働中のコンテナは２つの部分からなっている。一つは、データベースやWebサーバーなどのアプリケーション・プログラム、もう一つはそのアプリケーションの中のデータだ。このアプリケーション・プログラム、すなわちコンテナ・イメージは外部メディアや永続的メディアに保存する必要がない。コンテナが稼働する度に、ランタイム環境は、コンテナ・イメージがローカルで使えるようになっているかをチェックし、使えなければ、それをダウンロードする。

このプロセスは、コンテナの主要な価値の一つである。コンテナ・アプリケーションは、コンテナのイメージがダウンロード可能かローカルに保存されている状態であれば、いつでも、どこでも稼働することができる。

コンテナ・イメージにカスタマイズが必要かどうかは、議論のあるところだ。例えば、Webサーバーが特定のパフォーマンス設定を必要としたり、データベースが権限を付与されたユーザーのみ追加しなければならない、といったケースだ。とはいえ、これらの変更はスクリプトに書くか自動化でき、コンテナが起動するとき、簡単にイメージに適用できる。構成データだけのために、コンテナ・イメージを保存する理由はどこにもない。それ故、気を使わなければならない部分は、アプリケーションデータそのものだということになる。

コンテナはVMではない

永続的データの実装についてここまで書いてきて、コンテナがかなり仮想マシンに似ているように思えたかもしれない。VMwareのような従来型の基盤上のVMは、多くの場合、ブート・ディスクと１つまたはそれ以上のデータディスクを持っている。VMとそのデータは、通常存在している間は常につながっている。ただしデータボリュームを他のVMに移動することはありうる。

その一方、コンテナは仮想マシンではない。コンテナのデータモデルを詳しく見ていくとき、これを知っておくことは重要だ。外部ストレージとの接続は、データをコンテナから独立させておく上で前述した利点があり、コンテナをVMのようにしてしまう使い方はすべきではない。

コンテナ用データ

コンテナ自身ではなく、コンテナ・アプリケーションデータにはやはり保護が必要だ。コンテナ・バックアップがどのように動くのかを明らかにするために、コンテナ・データがどのように実装されているのかを見ていこう

■ コンテナ内部

Dockerプラットフォーム上では、データはコンテナ・イメ―ジのファイルシステム内に保存できる。しかし、Dockerはイメージの生成を最適化するためにユニオン・ファイルシステムを使っている。それ故、コンテナ・イメージ内にデータを保存する考え方は良くない。この方法では、データを取得するのにコンテナ・アプリケーション自身を使うことになるので、コンテナのバックアップが困難になるのだ。

■ ボリュームとして
Dockerのエコシステム内では、ボリュームはコンテナが稼働するローカルホストに保存される。Linuxでは、/var/lib/docker/volumesのフォルダ内に保存される。このボリュームは、ファイルシステム内の特定マウントポイントで、コンテナ内にマウントされる。Kubernetesもボリュームの考え方を利用している。ここではボリュームはポッドの中に保存される。ポッドは１つまたはそれ以上のコンテナを有し、単一のコンテナよりも寿命が長い。

■ バインドマウントとして
Dockerでは、どのようなホストディレクトリもコンテナにマウントできるようになっている。これには良いところも悪いところもある。ホストは永続的データを保持するためのファイル構造を持てるが、システムフォルダーやシステムファイルが、うっかりにせよ、意図的にせよ、マッピングされコンテナによって書き換えられてしまうからだ。

■ プラグイン経由
DockerもKubernetesも、LUNとボリュームをマッピングしてコンテナに提供するプラグインを持っている。提供されるのはコンテナが生成される以前のボリュームやファイルシェアの場合もあるし、コンテナと同時に作られる場合もある。いくつかのベンダーは、ソフトウェア定義のプラットフォームまたは従来型のプラットフォームから、直接コンテナにストレージを提供するプラグインを使っている。

あなたのデータがコンテナ・ファイルシステム内に存在しているとすれば、答えはアプリケーションかコンテナを使ってデータをバックアップすることだ。コンテナ・バックアップに対するこのアプローチは、バックアップ・メカニズムの標準が出来上がっているデータベース・プラットフォームでは一応可能だが、一般的に、稼働中のコンテナに対するアプローチとしてはあまり実用的とは言えない。

Dockerで実装されているように、ボリュームはホストのファイルシステムからデータのコピーを取ることでバックアップできる。同じことがホスト上のバインドマウントにもあてはまる。難しいのは、ボリュームまたはマウントの名前をアプリケーションとマッチングさせるところだ。Dockerボリュームには任意の名前をつけることができる。それ故、きちんとした命名基準が重要になる。問題はデータをリストアさせるときにやってくる。ボリュームがまだホスト上にある時は、標準的なリストアでデータを当該ディレクトリに置けばよい。ボリュームが存在しない時、データを戻す前にボリュームを再作成しておく必要がある。バインドマウントの場合、これは大した問題ではない。ディレクトリ名はDockerストラクチャの外側にあり、いつでもバックアップとリストアができるからだ。

プラグインによって外部ストレージ上のデータはコンテナにマッピングされる。コンテナ・ストレージ・インターフェースは、大手コンテナ・オーケストレーション企業によって始められたオープンソース・イニシアチブである。コンテナ・ストレージ・インターフェースはこのマッピングプロセスについて一貫性のあるアプローチを開発することを目指している。このプラグインは、外部ストレージのマッピングをコンテナ・ホストに対して、さらにはコンテナ自身に対して実行する際の面倒を見てくれる。

多くのプラグインの実装は、外部ストレージのLUNやボリュームをコンテナに付属させることに注力している。かくして、ボリュームはホストにもマウントされ、従来型のバックアップソフトウェアでバックアップできる。もう一つの方法は、ボリュームをストレージアレイのスナップショットを使って保護し、バックアップができる別の地点から再マウントする方法である。

スナップショットをバックアップサーバーにマウントするのは、データ保護の古くからある技法だが、もしコンテナアプリが稼働していた場合、戻されたバックアップはクラッシュコピーのようになるだろう、ということだ。繰り返しになるが、LUNやボリュームに適切な名前をつけておけば、データを将来戻す時それが役に立つ。プラグインの定義によって既存のボリュームが新しいコンテナにマッピングできるようになった。

コンテナ・データも他の全てのエンタープライズ・データ同様、保護が必要だ。データ保護の細かい指令やバックアップの実装はコンテナ・エコシステムがどのように設計されたかによって変わってくる。しかし、一つ明らかなことがある。バックアップ・プロセスがクライアントやゲストからVMへ移行したために、コンテナは従来型のバックアップ・アプリケーションにはバックアップデータを提供しない。代わりに、これはホストまたはストレージレイヤーといった下位のオーケストレーション・プラットフォームで実現されることになる。

著者略歴：Chris EvansはLangton Blueをベースに活動する独立系コンサルタント。