by 現在、クラウドネイティブまたはコンテナ化されたアプリケーションが主流になっています。 Cloud Native Computing Forum (CNCF) によると、現在最大 82% の企業が Kubernetes を運用環境に導入しています。これは 2023 年までに 66% 増加します。業界団体によると、98% の組織が少なくともいくつかのクラウドネイティブ アプリケーションを使用しています。
ただし、アプリケーションをクラウドネイティブ環境に移行するということは、単に新しいコードを作成することを意味するわけではありません。それはインフラを適応させることも意味します。コンピューティング、ネットワーキング、データ ストレージはコンテナ環境で動作する必要があります。特にローカル ハードウェアに関しては、すべてのシステムがこれをそのまま実行できるわけではありません。
同時に、企業の IT アーキテクトは、アップグレードされていないレガシー アプリケーションと仮想マシン (VM) の要件を考慮する必要があります。そして企業は、アプリケーション環境に関係なく、ストレージ ハードウェアを最も効率的に利用したいと考えるでしょう。
コンテナーへの移行は、永続ストレージ用に設計されていないテクノロジーをビジネスに不可欠なデータの管理に適応させることを意味します。
国家のない国家
コンテナー化されたアプリケーションはステートレスまたは一時的なものとして開始されました。設計者は、コンテナーに永続的なデータを保持させることを意図していませんでした。彼らは、マイクロサービスやコンテナ化されたアプリケーションが不揮発性ストレージを使用せず、タスクが完了するとメモリの内容や構成さえも破棄することを期待していました。
対照的に、コンテナ化されたアプリケーションは外部データ ストア (通常はデータベースまたはキャッシュ) に依存します。
このアプローチには利点があります。これには、導入の容易さ、スケーリングの容易さ、フォールトトレランスとリカバリ、アプリケーションの移植性が含まれます。しかし、ほとんどではないにしても、ほとんどのビジネス アプリケーションは永続的なデータを必要とします。
「ほとんどのビジネス アプリケーションにはストレージが必要です。実際には、華氏から摂氏への変換、またはその逆の変換をしない限り、何かをどこかに保存することになります」と、Nutanix のバイスプレジデント兼クラウド ネイティブ担当ゼネラル マネージャーの Dan Ciruli 氏は述べています。
また、企業が従来の仮想マシンの代替としてコンテナに注目しているため、永続データを扱う必要性はさらに重要になっています。
しかし、これはアプリの動作方法を再考することを意味します。また、IT アーキテクトは、最新のクラウドネイティブ アプリケーションをサポートするためにストレージ システムをアップグレードする必要があります。これは、アレイ メーカーがコンテナをサポートする場合に直接行うことも、Everpure の Nutanix や Portworx などのコントロール プレーンを通じて行うこともできます。
企業が最新のクラウドネイティブ環境でデータ量の多いワークロードをサポートしようとしているため、ほぼ必然的に、変化は人工知能によって推進されています。ただし、仮想化アプリケーションをコンテナに移行する傾向やコスト管理の必要性など、他の要因もあります。
「Kubernetes は 10 年以上前から存在しますが、AI がデータの処理方法を変革するにつれて進化し続けています。Kubernetes はすでに、一時的なステートレス アプリケーション専用に構築されていた時代を超えています」と Veeam Software のグローバル フィールド テクノロジー ディレクターである Michael Cade 氏は述べています。
「今日、データベース、機械学習パイプライン、ストリーミング システムなどのステートフル アプリケーションは、第一級市民として扱われています。 [in containerised environments] そして、成功するために必要な特殊なツールが与えられています。」
ストレージ接続
ただし、ストレージを Kubernetes に接続するには、アプリケーション開発者とハードウェア ベンダーの両方からのサポートが必要です。
ストレージをコンテナ環境に接続する主な方法は、コンテナ ストレージ インターフェイス (CSI) を使用することです。 CSI は、ハードウェア メーカー、クラウド サービス、ソフトウェア デファインド ストレージ (SDS) プロバイダーのいずれであっても、ストレージ プロバイダーによって直接サポートされる必要があります。
CNCF の Kubernetes ページには、「CSI は、Kubernetes のようなコンテナ オーケストレーション システムのコンテナ化されたワークロードに任意のブロックおよびファイル ストレージ システムを公開するための標準として開発されました。」と記載されています。 CSI を使用すると、サードパーティのストレージ ベンダーは、コアの Kubernetes コードを変更せずに、ストレージ用のプラグインを作成してデプロイできるようになります。
一方、SDS テクノロジーも CSI コントローラーを使用しますが、専用のストレージ アレイではなく一般的なハードウェアやハイパーコンバージド インフラストラクチャ上で実行されます。 OpenEBS、Longhorn、Ceph などのオープン ソース オプションも含まれています。
「すべての環境には、CSI ドライバーを使用して Kubernetes に接続するストレージ バックエンドが必要です。CSI ドライバーを提供するかどうかはストレージ ベンダー次第です」と、Kubernetes とコンテナーの著者で独立専門家である Nigel Poulton 氏は述べています。
「ほとんどのCSIコントローラは、ストレージ層とその機能にマッピングするStorageClassを少なくとも1つ作成します。たとえば、CSIコントローラは、リモートの場所への高速フラッシュストレージの自動レプリケーションにマッピングする『高速レプリケーション』と呼ばれるStorageClassを作成する場合があります。このクラスを使用するアプリケーションは、自動的にその層と一連の機能を取得します。」と同氏は付け加えた。
このレベルの抽象化は、ストレージ システムの物理的な機能を心配する必要がなくなるため、アプリケーション開発者にとって非常に役立ちます。これは CSI コントローラーによって処理されます。
「CSI ドライバーを使用すると、コンテナー化されたアプリケーションからストレージにアクセスできますが、 [for firms to] Nutanix の Ciruli 氏は、「VM で実行されているものと同じ方法でストレージを引き続き管理できます。これは大きな利点です。」と述べ、顧客がベアメタル クラスターに Kubernetes をインストールしていることも確認しています。
これにより、Kubernetes ワークロードと基盤となるストレージ ハードウェア間の分離も維持されます。少なくとも机上では、企業は、コードを書き換えることなく、中断を最小限に抑えて、コンテナ化されたアプリケーションを別のプラットフォームやベンダー、または新しいストレージ ハードウェアに移動できます。
実際には、Kubernetes アプリケーションをプラットフォーム間で大規模に移動することはまだ比較的まれです。企業は、ビジネス要件に応じて、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、またはオンプレミスのハードウェア上で実行するアプリケーションを開発する傾向があります。
CSI によってサポートされているアプリケーションのポータビリティは有用な保険ですが、プラットフォーム間には注意が必要なほどの違いがあります。
「EBS の方法について専門家になる必要はありません。 [Elastic Block Store] Azure ディスクまたはローカル SSD と比較したパフォーマンス [solid-state drives] エバーピュア社ポートワークスのゼネラルマネージャー、グレッグ・マスカレラ氏はこう語る。企業は単一のクラウド環境に注目する傾向があります。」
同氏によれば、「ボタンを押して別のクラウドに移動」できるコードを持っている組織はほとんどなく、その主な理由はハードウェア ベンダーとクラウド プロバイダーのストレージ アーキテクチャの違いにあるという。しかし、企業はより多くのアプリケーションをクラウドネイティブ環境に移行させています。これには、従来の仮想マシン上で実行されていたデータベースやアプリケーションがますます多く含まれます。
新しいプラットフォーム
アプリケーションのモダナイゼーションにおける最も重要なトレンドの 1 つは、仮想マシンとコンテナベースのアプリケーションの両方を移行することです。コスト、サプライヤーの妨害の回避、少数のプラットフォームに統合する必要性が決定要因となっています。
「『コンテナ化』と『仮想化』の境界線は曖昧になっています」と Veeam の Cade 氏は示唆しています。 「長い間、コンテナと VM は 2 つの別々のサイロとみなされていました。しかし、ステートフル アプリケーションが開発されるにつれて、VM は本質的に典型的なステートフル ワークロードであるため、Red Hat OpenShift Virtualization などのプラットフォームを使用して Kubernetes 内で VM を直接実行する企業が大幅に増加しています。」
ポールトン氏も同意する。 KubeVirt などのツールを使用して、仮想化ワークロードをコンテナーに移動する組織が増えています。しかし、組織が仮想化されたアプリケーションやデータベースを移植している場合でも、IT アーキテクトはストレージ層がすべてのアプリケーション要件を満たしていることを確認する必要があります。
「データベースには、秩序ある起動、レプリケーション、自動バックアップとバックアップなど、はるかに厳しい要件があります」と同氏は警告する。 「2 つの最大の変更は、ストレージ システムに CSI コントローラが確実に存在することと、キャリアを導入する可能性があることです。」
Kubernetes オペレーターは、データベースや場合によってはストレージの特定の要件に関する詳細を提供します。データベースが Kubernetes を通じてエンタープライズ ワークロードを配信できるようにするには、キャリアのサポートが不可欠です。繰り返しになりますが、通信事業者は、ストレージ アレイやクラウド ストレージ サービスからコードを分離するという最新のアプリケーションの目標をサポートしています。
たとえば、Percona は、Everest だけでなく、MySQL、PostgreSQL、MongoDB のオペレーターを提供しています。 「オペレーターは基本的にゲームチェンジャーです」と、同社のネイティブクラウド担当ゼネラルマネージャーの Kate Obiidykhata 氏は言います。 「人間の DBA の知識がソフトウェアにエンコードされており、最も重要な復元コンポーネント、バックアップ、フェイルオーバー、レプリケーション、自動アップデートがすべて備わっています。」
同氏は、通信事業者は企業がハイブリッド アーキテクチャやマルチクラウド戦略を導入するのを支援し、アプリケーションを書き直す必要なくデータのポータビリティを可能にしていると付け加えた。しかし、仮想マシン上で実行されるワークロードは、コンテナ上で自動的に実行されるわけではないと彼女は言います。企業は導入を慎重に計画し、テストする必要があります。
「適用する必要がある特定のプレイブックと、仮想マシン上の従来のデータベース設定とは明らかに異なる方法論があります」と Obiidykhata 氏は言います。 「しかし、それはすべて実行可能であり、多くの企業がそれらのデータベースを Kubernetes 上で実行しています。彼らはそれらの問題を軽減するための別のプレイブックを持っているだけです。」
企業は、移植したアプリケーションを実稼働環境でどのように実行するかについても考慮する必要があります。当然のことながら、この開発は多くの注目を集めています。しかし、システムが「2日目」からどのように機能するかが重要です。これには、ストレージのプロビジョニングと管理、バックアップ、リカバリ、セキュリティが含まれます。
CSI コントローラーは困難な作業の多くを処理しますが、企業はコンテナへの移行を促進するために、新しいハードウェア、さらにはクラウドネイティブ環境に重点を置いたベンダー ストレージへの投資を検討する可能性があります。
「これは通常、既存のベンダーの新しいストレージ製品による新しいストレージ アーキテクチャの導入によるものですが、新しいベンダーとのコラボレーションによるものも増えています」と Poulton 氏は言います。同氏は、企業は依然として古いハードウェア システムを実行している可能性があるが、それを Kubernetes に使用する可能性は低いと付け加えた。
