「コンテナでストレージ」が意外に有用な理由：CW：コンテナストレージはアリなのか？（後編）

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

[Chris Evans，Computer Weekly]

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

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

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

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

• Computer Weekly日本語版　3月20日号：音声アシスタントアプリ開発のヒント

なお、同コンテンツの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」はストレージをコンテナ環境でマッピングするのに恐らく最も適している。

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

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

続きはComputer Weekly日本語版　3月20日号にて

本記事は抄訳版です。全文は、以下でダウンロード（無料）できます。

• Computer Weekly日本語版　3月20日号：音声アシスタントアプリ開発のヒント

■Computer Weekly日本語版 最近のバックナンバー

Computer Weekly日本語版　3月7日号　逆に考えるんだ「GDPRはチャンスだ」と

Computer Weekly日本語版　2月21日号　Spectre＆Meltdownの見つけ方

Computer Weekly日本語版　2月7日号　キャッシュレス先進国の現実