2020年10月16日

相互に最適化されるストレージとコンテナ

コンテナベースのクラウドネイティブアプリケーションのニーズが高まったことで、エンタープライズストレージシステムに課題が生じる可能性があります。しかし、それを解決する仕組みはすでに存在しています。

現代の企業における標準インフラストラクチャの一部は、コンテナで稼働するマイクロサービス化アプリケーションに最適化されていません。それどころか、こうしたコンテナでの稼働に十分に適合できていないものもあります。その典型がエンタープライズクラスのストレージシステムです。

コンテナはその性質上、寿命が短いため、ストレージへの書き込みを一連の処理として行う必要があります。その処理は、データベーストランザクションのように、一連の処理がすべて完了するか、どの処理もまったく実行されないかのどちらかです。

コンテナ外にデータを保存するには、コンテナオーケストレーションの標準ソフトウェアであるKubernetesによって、永続ボリュームを利用できるようにします。これらのボリュームはストレージオブジェクトであり、それを使用するコンテナからは独立したライフサイクルを持っています。よくできたマイクロサービスアプリケーションは、永続ボリュームに一連の処理として書き込みを行います。

エンタープライズストレージシステムでは、管理者が、適切なボリュームをコンテナの適切な場所にマウントしなければなりません。開発者が永続ボリュームを適切に使用していれば、Kubernetesは、マウントすべきボリューム、マウント先、コンテナがインスタンス化された時間を把握しています。必ずしもすべてのストレージシステムが、この機能のソフトウェアを最初から適切にサポートしているとは限りません。

 

基本のコンテナ

コンテナの性質上、何の警告もなしに再起動が発生し、そのストレージ内のデータが消失する場合があります。ステートレスとなるように設計されたシンプルなWebアプリケーションなら、問題にはなりません。しかしコンテナ技術が成熟する一方で、それが適用されるビジネスワークロードは旧来型のままであるため、データをまったく消失させずに保存することが最重要課題になっています。

大部分のエンタープライズアプリケーションは、状態 (ステート) の形式を必要とします。ステートフルなアプリケーションでは、少なくとも実行から次の実行までの状態が保存されます。この状態データがどのように定義され、どこに保存されるかは、さまざまな要因で決まります。稼働しているときに実行したタスクのみではありません。企業で稼働しているアプリケーションのほとんどが、何らかの方法でビジネスの状態を毎日追跡しています。つまり、ビジネス上の中核的な役割を担っているのです。典型的なエンタープライズアプリケーションは、一時ファイル、データベース、システムレジストリにデータを保存します。これをローカルでも、サーバーでも行います。どの場合にも、状態データを保存する永続ストレージが必要です。

幸いなことに、コンテナ化アプリケーションの状態管理に対応した永続ストレージは近年劇的に改善され、それが今なお続いています。最新のエンタープライズアプリケーションは、スピンアップ、ジョブの実行、場合によってはクラッシュ、再起動、スピンダウンを行うコンテナに構築されます。それを考慮して、インフラストラクチャのさまざまなレイヤーと、ソフトウェアサービスを慎重に調整する必要があります。

そうした複雑さは、ますます増大する可能性があります。それは、すべてのアプリケーションが、あるマイクロサービスから永続ストレージのデータを受信し処理を行った後に、別のマイクロサービスに引き渡せる場合です。

同時に、企業のDevOpsチームが急速に拡大されており、必要となるストレージも増加しています。モノリシックアプリケーションがリファクタリングされるとともに、マイクロサービスベースの新しいアプリケーションが構築、展開され、コンテナで稼働するステートフルワークロードがますます増加しています。コンテナで永続ストレージに対応できるかどうかは、注意すべき重要な問題です。なぜなら、さまざまなハードウェアとソフトウェアは、どれも落ち着くべきところに落ち着き、採用が急速に進むからです。コンテナとストレージが良好に稼働していなければ、それらはIT運用全体の妨げになります。

 

なぜストレージが最後なのか

ソフトウェアそのものと、それがどのように開発されるのかによって、ハードウェアは長年変化してきました。アプリケーションが分野ごとに拡大したことで、必然的にハードウェアも分野ごとに拡大したのです。今ではコモディティのx86サーバーが、オンプレミス、クラウドを問わず、さまざまな分野において、これまでにないスピードで拡大を見せています。分野を超えて拡大するコモディティハードウェアとして最後の要素となるのが物理ストレージです。こうしたストレージは、サーバーの形態を取り、プールを作成してアプリケーションに公開できる多数のディスクで構成されています。

優れた技術である一方、これまでのエンタープライズストレージとその管理システムは、高可用性と絶対的な整合性を重視した旧来の設計に大きく依存しています。たとえば、エンタープライズSAN/NASソリューションは、高パフォーマンスとネットワーク分散ファイルシステムという素晴らしい性能を備えています。これらは、常に最新のストレージハードウェアにアップグレードされ、データの完全性とパフォーマンスが確実に維持されます。

しかし、そうした特別な管理リソースを必要とする高価な専門技術の概念は、DevOpsに適していません。DevOpsでは、開発者チームがセルフサービスのインターフェイスを利用してコンテナの開発と展開を行います。多くの場合、エンタープライズストレージシステムは、読み取りと書き込みが頻繁に発生する、モノリシックなアプリケーション別ワークロードに最適化されています。つまり、広域に分散される今日のワークロードのニーズに対応できません。こうしたワークロードは、何千ものマイクロサービスで構成され何千ものコンテナで稼働しています。しかもオンプレミス、クラウド、世界中のデータセンターに配置されています。

エンタープライズストレージをプロビジョニングする従来のプロセスでは、場合によっては、ストレージ管理者に配置を依頼して、一定のボリュームがプロビジョニングされた通知を待つ必要がありました。また、さまざまなインフラストラクチャをまたいだ膨大な数のボリュームにも、それ以外で開発者が求めるセルフサービスDevOps環境にも対応できませんでした。

 

Kubernetesでオーケストレーションするソフトウェア デファインド環境

DevOpsとマイクロサービスによって、ソフトウェア デファインド ストレージのニーズが高まっています。DevOpsには2つの要件が生じます。まず、開発者が、開発環境と本番環境のストレージリソースをセルフサービスでプロビジョニングできなければなりません。また、コンテナ化したアプリケーションにデータをロードして更新するために永続ストレージが必要です。これによって、コンテナが消失した際にそのデータが保持されます。これらの要件のどちらにもKubernetesで対応できます。

KubernetesではContainer Storage Interface (CSI) とストレージベンダーが開発したCSIドライバーによって、コモディティストレージを統合できます。これにより開発者のストレージ管理に必要な処理を自動化できます。これらのドライバーはKubernetesには付属していないため、ストレージソリューションを選択する際にはそれらが必要かどうかを確認する必要があります。各Kubernetesクラスタは最小でも1つのマスターノードと、コンテナが稼働する複数のワーカーノードで構成されます。また、Kubernetesオペレーターが要件を受け取り、アプリケーションによってストレージハードウェアがどのように利用されるのかを解釈します。

そのような自動化を達成するには、コンテナベースのマイクロサービスからなるソフトウェア デファインド エコシステム、Kubernetes、ストレージオペレーターが要件を伝達し、日常運用と容量使用率の点からストレージハードウェアを監視できなければなりません。これにより、コンテナに必要な永続ストレージが徐々に増加することを考慮しながら、追加のノードが必要かどうかを予測できます。

CPUとメモリの使用率で高可用性と柔軟な拡張性を維持するための自動化という点では、Kubernetesとハードウェアは良好な状態で統合されています。これに続き、ストレージの自動化もすぐに実現します。さらには、コンテナで稼働するマイクロサービスが従来のストレージハードウェアに与える負荷の軽減と、動的なコンテナでの永続ストレージの利用が可能になります。

私たちが目指しているのは、次のようなエンタープライズITの環境です。インフラストラクチャチームが、DevOpsチームにリソースプールを提供し、使用率を追跡できます。さらに、Kubernetesを活用して、ワークロードで使用する既存のワーカーノードを検索したり、指定された容量の永続ストレージを使用して新しいノードを作成したりすることで、コンテナの展開と統合を自動化できます。このプロセスでは、ソフトウェアのさまざまなレイヤーを緊密に統合する必要があり、それを達成できた企業は、クラウドの柔軟性というメリットを得られます。また、インフラストラクチャチームが、計画済みイベント、たとえば、休暇シーズン、四半期利益の報告、スポーツイベント、コンテナの大幅なアップデートなどに関連する使用率の急上昇に、事前に対処できるようになります。

 

改善を土台にして構築

この数年間の出来事が、ハードウェアとソフトウェアのレイヤーを緊密に統合して、DevOpsに必要な自動化を実現することがいかに重要かを実証しました。コンテナなどの仮想技術、ソフトウェア開発手法、ハードウェアが、相互に作用することで、エンタープライズコンピューティングが発展していきます。それは、あらゆるコンピューティングに当てはまるでしょう。ある要素が改善されると、それが別の要素に波及します。DevOpsチームがプロセスとツールを頻繁に変更して改善点を利用します。これによってレイヤー間のクラウドネイティブな統合が不可欠になります。これらがすべてKubernetes上に構築されます。そのようにして、あらゆるものをオーケストレーションする標準が出来上がったのです。ソフトウェア デファインドの未来は、企業に、柔軟な拡張性、高可用性、高パフォーマンス、効率的なリソース利用、コンテナと永続ストレージに関する優れた予見性をもたらします。

 

コンテナと永続ストレージ: リーダーのためのアドバイス

  • レガシーストレージシステムは、マイクロサービスを実装したコンテナアプリケーションに最適化されていません。コンテナとストレージが良好に稼働しなければ、それらはIT運用の妨げになります。
  • コンテナ化アプリケーション向けに行う、永続ストレージへの対応と状態管理は、自動化が増えたことで向上しています。
  • Kubernetesを基盤として、ハードウェアとソフトウェアのレイヤーでクラウドネイティブな統合を行うことが重要です。

この記事/コンテンツは、記載されている特定の著者によって書かれたものであり、必ずしもヒューレット・パッカード エンタープライズの見解を反映しているわけではありません。

enterprise.nxt

ITプロフェッショナルの皆様へ価値あるインサイトをご提供する Enterprise.nxt へようこそ。

ハイブリッド IT、エッジコンピューティング、データセンター変革、新しいコンピューティングパラダイムに関する分析、リサーチ、実践的アドバイスを業界の第一人者からご提供します。

enterprise.nxt
ニュースレターのご登録

enterprise.nxtから最新のニュースをメールで配信します。