CW：コンテナストレージはアリなのか？（後編）

「コンテナでストレージ」が意外に有用な理由

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

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

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

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

　永続ストレージとコンテナの問題を解決する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日本語版

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  フィッシング／なりすまし攻撃を防ぐDMARCのススメ

• 

  Alexaスキル開発に失敗しないためのアドバイス

新着ホワイトペーパー PR

• 事例
  [日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は？　先行企業の導入事例3選
• 技術文書・技術解説
  [日本オラクル株式会社] 無自覚なリスク　秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由
• 製品資料
  [日本オラクル株式会社] 戦略的経理の第一歩　失敗のない「脱Excel」を実現する秘訣とは？
• 技術文書・技術解説
  [日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い　最適な製品をどう見極める？
• 事例
  [株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは？