Kubernetes ストレージの問題を解決する方法

すでに Kubernetes を使用している場合、その理由はおそらく単純で、作業が楽になるからです。結局のところ、それがコンテナ オーケストレーションの前提なのです。インフラストラクチャを使い捨てにして、必要なときに起動し、使用し終わったら破棄できるので、あまり考える必要がありません。少なくとも、それはそのように機能するはずです。

ご存知のように、永続データに依存するジョブを構築すると、すぐにストレージという大きな問題に直面することになります。

Kubernetes はコンピューティングとネットワーク インフラストラクチャを完全に抽象化しますが、アプリケーションがステートフルでデータが永続的である場合は、それを保存する適切な方法が必要です。必要なデータを見つけるには、基盤となるストレージ インフラストラクチャについて知っておくべきことをすべて知っておく必要があります。

データの場所だけでなく、他の種類のストレージ インフラストラクチャに伴うその他の細かい考慮事項 (パフォーマンス、保護、復元力、データ ガバナンス、コスト) も存在しますが、ほとんどのデータ サイエンティストはこれらについて考えたくありません。

基盤となるハードウェアの複雑さの管理の多くが自動化されているクラウド ネイティブの世界において、ストレージが依然として面倒なのはなぜでしょうか?その理由は、2 つの言葉で表せます。データ サイロです。

データ自体に焦点を当てるのではなく、データが存在するさまざまなインフラストラクチャを通じてデータを管理し続ける限り、必然的に多くのストレージ サイロが生まれてしまいます。幸いなことに、これは難しい問題ではありません。データ管理に対する考え方をインフラストラクチャ中心のアプローチからデータ中心のアプローチにシフトすることで、Kubernetes を使用して、ストレージを SEP (Someone Else's Problem) にするという当初の約束を実現できます。

必要なデータが、それぞれ独自の属性（「または」、「クラウド」、「オンプレミス」、「オブジェクト」、「高パフォーマンス」など）を持つさまざまなストレージ アイランドに分散している場合、インフラストラクチャの考慮事項を抽象化することは不可能です。パイプラインを構築するには、パフォーマンス、コスト、データ ガバナンスに関するすべての質問に答える必要があります。 (あなたが助けを求めている人が IT 管理者であれば、スレッドであなたの名前が出てくるたびに彼らはうんざりするでしょう。なぜなら、彼らは、さまざまなレプリカやデータ ストア間でデータを台無しにするために、難解なインフラストラクチャ インターフェイスと格闘するのに多くの時間を費やすことになり、昼食前にタスクを終える方法がないことを知っているので。

この悩みを解消する唯一の方法、つまり Kubernetes が実現するはずのスピードとシンプルさを実際に実現する唯一の方法は、データを仮想化することです。基本的に、データとさまざまなストレージ インフラストラクチャの間にインテリジェントな抽象化レイヤーが必要です。この抽象化レイヤーにより、特定のインフラストラクチャが適切なコスト、場所、またはガバナンスを備えているかどうかを心配したり、常に新しいコピーを作成したりすることなく、どこからでもデータを表示してアクセスできるようになります。

これを実行するのは思ったほど難しくありません。キー: メタデータ。データがどこに存在していても、データ要件、コンテキスト、系統の考慮事項をすべてメタデータとしてエンコードできる場合、特定の時点でデータがどのインフラストラクチャに存在するかは問題ではなくなります。これで、データ パイプラインを構築するときに、メタデータをフルに活用できるようになります。また、仮想化レイヤーでは AI/ML を使用して、基盤となるデータ管理とインフラストラクチャの考慮事項をすべて自動的に処理できます。

仮想化レイヤーを導入し、メタデータを通じてデータ管理を行うと、これまでは不可能だったさまざまなことが可能になります。

1. データ サイロを排除する: 必要なデータがどのインフラストラクチャ上にあるか、またはそのインフラストラクチャがどこに配置されているかは問題ではありません。アプリケーションにとって、これまでサイロ化されていたすべてのストレージ リソース (オンプレミス、クラウド、ハイブリッド、アーカイブ) は、共通のグローバル名前空間のように見えます。

2. ストレージ リソースへのプログラムによるアクセス: さまざまな基盤ハードウェア インフラストラクチャではなくメタデータを扱うため、パイプラインを設定し、宣言的なステートメントを通じてデータにアクセスできるようになりました。つまり、このパフォーマンスでデータが必要であり、それが本当に必要なことです。そうすれば、アプリケーション (または負担の大きい IT 管理者) が具体的な方法を指示しなくても、インテリジェントな仮想化レイヤーを実現および実装できるようになります。

3. データ管理をセルフサービスにする: データ サイエンティストは、パイプラインを構築するたびに、異なるストレージ タイプのコストを比較したり、データ保護を有効にしたり、セキュリティとコンプライアンスの要件が満たされていることを確認したりする必要がありません。 (したがって、IT チームやセキュリティ チームも、データ サイエンティストがそのような選択を行うことを望んでいないでしょう。ただし、すべてを可能な限り最も高価なストレージで、適切なコンプライアンスなしで実行することを望んでいる場合は別です。) メタデータとデータの管理を分離すると、そのようなことはすべてなくなります。ストレージ管理者は、基本ポリシーを一度構成するだけでガードレールを設定できます。ユーザーは、今後はチケットを開かずに、またパイプラインを構築するたびに手動でこれらの呼び出しを行う際に生じるミスもなく、データ管理のニーズのほとんどをセルフサービスで処理できるようになります。

4. データを継続的に充実させる: システムがカスタマイズ可能で拡張可能なメタデータをサポートすれば、さまざまな興味深いことが可能になります。たとえば、システムを通じてデータを実行し、いくつかの結果を取得し、その結果をメタデータに追加して、ジョブを再度実行する再帰プロセスを構築できます。データを取り巻くデータについての深い文脈的理解を構築し始めることができます。処理して使用するデータが増えるほど、将来的に他のジョブで使用できるデータが豊富になります。そして今、インテリジェンスは、それを利用したい他のアプリケーションやデータ サイエンティストにとって、常に手の届く範囲にあります。それは、どこかのストレージ サイロに保管された単一のレプリカに限定されるものではありません。

データを仮想化すると、サイロ化されたストレージ インフラストラクチャよりもはるかに柔軟にメタデータを使用できるため、これらすべてが可能になります。データ パイプラインの設定とオーケストレーションに伴うストレージの考慮事項が、自動的に処理されるようになりました。ストレージ リソースはプログラム可能、セルフサービス、自動準拠となり、多くの場合、手動による介入は必要ありません。

突然、Kubernetes とソフトウェア定義ストレージが常に提供することになっていた現実に実際に生きることになります。インフラストラクチャに関係なく、ストレージはソフトウェア定義でプログラム可能であり、ハイブリッド クラウド環境全体で一貫しています。データはより豊富で柔軟になります。壁にダーツを投げるために IT チームが残した ID カードの爆発写真が不要になります。何よりも、データの保存場所について心配する時間が減り、実際にデータを扱う時間が増えます。