「コンテナでストレージ」が意外に有用な理由CW:コンテナストレージはアリなのか?(後編)

コンテナそのものを永続ストレージのプラットフォームにするというアイデアは、一見すると不適切だ。しかし、それを上回る数々のメリットがある。

» 2018年03月20日 10時00分 公開
[Chris EvansComputer Weekly]
Computer Weekly

 前編(Computer Weekly日本語版 3月7日号掲載)では、コンテナ環境に求められるストレージの要件をまとめた。

 後編では、コンテナによるストレージ提供の可能性を検討する。

Computer Weekly日本語版 3月20日号無料ダウンロード

本記事は、プレミアムコンテンツ「Computer Weekly日本語版 3月20日号」(PDF)掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

なお、同コンテンツのEPUB版およびKindle(MOBI)版も提供しています。

ボタンボタン

コンテナによるストレージの提供

 永続ストレージとコンテナの問題を解決する1つの方法は、コンテナそのものをストレージプラットフォームとして使用することだ。

 一見、この考え方は適切だとは思えない。コンテナは一時的なものであり、いつでも破棄できる。また、個々のコンテナのIDは、従来型ストレージのIDのように固定されることはない。ホストWWN(World Wide Name)やiSCSI IQNという概念もない。それでは、コンテナによる永続ストレージはどうすれば実現できるだろう。また、そうする価値がある理由は何だろう。

 まずはコンテナによる永続ストレージを実現する「理由」から考えてみよう。

 前述のように、コンテナは短命となる可能性があり、効率を考えて設計されている。I/Oスタックを可能な限り取り除くことで、コンテナ環境全体のパフォーマンスを高めている。ストレージをコンテナとして提供すると、アプリケーションとストレージの通信が同じサーバ上のプロセス間通信になるため、通信パスが非常に軽量になる。アプリケーションを移動するたびに、新しいホストのコンテナがストレージへのアクセスを提供する。ストレージコンテナがまだ存在していなければ専用のコンテナを稼働させることもできる。

 データを複数のホスト間で保護して利用可能な状態にするには、バックエンドで多くの作業が必要になるのは明白だ。だが、その作業は従来のストレージアレイほど難しくはない。なぜなら、ほとんどのアプリケーションはどの時点においても1つのコンテナしかデータボリュームにアクセスしないためだ。

 このようにストレージへのアクセスを分離することにより、NVMeの普及とともに生じる「共有コントローラー経由のデータパス」という問題が1つ解決する。NVMeは従来のSAS/SATAよりもパフォーマンスが格段に優れているため、共有コントローラーがストレージの新たなボトルネックとなっている(訳注)。ハイパーコンバージドシステムがストレージの容量とパフォーマンスをスケールアウトサーバアーキテクチャ間に分散するのと同じように、分離によってこの問題が緩和される。

訳注:詳しくは「NVMeが速くない理由」を参照。

 コンテナによる永続ストレージを「どのように」実現するかという疑問は、永続化を行う場所を見れば解決する。

 答えはメディアにある。メディアは、HDDか、その機能を提供するフラッシュドライブのいずれかだ。構成やアクセスなどは、データを複数のノードとデバイスで確実に保護するために使われるコンセンサスアルゴリズムによって、複数のノードとメディアに分散できる。そうすることで、ストレージを提供するホストやコンテナが機能不全に陥った場合、別のホストやコンテナが稼働したり、ワークロードが(アプリケーションそのものなどの)残りのノードでバランスを取り戻したりすることが可能になる。設計上、データはアプリケーションとともに移動することになる。

コンテナストレージを提供するベンダー

 こうしたアーキテクチャはPortworx、OpenEBS、Red Hat、StorageOSなどの新興企業が実装している種類のものだ。いずれも分散ノードベースのスケールアウトアーキテクチャを採用し、ストレージとアプリケーションが同じプラットフォームで実行される。本質的には、これはコンテナのハイパーコンバージドモデルといえる。

 Scalityの「RING」や、Cisco SystemsとSpringpath(後にCiscoが買収)が共同で開発した「Cisco HyperFlex」など、コンテナ環境のみに対応するわけではなく、スケーラビリティを考慮しアーキテクチャ内でコンテナを使用するものもある。

 どのベンダーでも、コンテナオーケストレーションプラットフォームとの統合は不可欠だ。コンテナオーケストレーションプラットフォームとして代表的なのが「Kubernetes」で、「Kubernetes Volumes」はストレージをコンテナ環境でマッピングするのに恐らく最も適している。

機能の成熟とともに生じる問題

 テクノロジーの進化とともに考えなくてはならない問題が幾つかある。

 まず、データサービスが懸念される。圧縮と重複排除がパフォーマンスに影響を及ぼすのは明らかだ。オールフラッシュ市場で既に目にしてきたように、こうした機能の効率性がコンテナストレージを広く普及させる鍵になる。エンドユーザーが期待するのはスナップショット、クローン、レプリケーションなどのデータ保護機能だ。

 また、パブリッククラウドとの統合に関する問題もある。現在のソリューションは単一のサイトの実装にほぼ特化しているが、真のモビリティーはハイブリッド環境においてデータをあちこちに動かせることを意味し、こちらを実現する方がずっと難しい。

 最後に、セキュリティの問題にも注目しなくてはならない。

 2018年1月に発見されたプロセッサ脆弱(ぜいじゃく)性「Meltdown」は、コンテナ固有のセキュリティリスクをもたらし、パッチを導入していないシステムではコンテナ間のデータアクセスが可能になる。このニュースはデータセキュリティに関する疑問を投げ掛ける。また、不注意なデータ漏えいの防止に使われるインメモリ暗号化などの使用についても懸念を生む。

 新興企業が解決しなくてはならない問題がここにある。こうした問題は、コンテナベースのストレージシステムが普及するか否かに直接関係してくるだろう。また適切な解決策を提示できれば、想定外のリスクが明るみに出たときに、物理的な分離(共有ストレージ)という考え方が問題の緩和にいくらか役立つと考える企業も出てくるかもしれない。

別冊Computer Weekly “なんちゃってOffice”よりもOffice 365も公開中!

Microsoft Officeの代替製品は数あれど、やはりMicrosoft Office の地位は揺るがない。そして、Office 365はOffice 20xxの単なるクラウド版以上の価値を提供する。


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ