永続ストレージはクラウドネイティブ開発者にさらなる自由をもたらす

多くの組織では、DevOps チームがビジネス目標と戦略をサポートする傾向が高まっています。ソフトウェア開発の焦点がこのように変化する中で、開発チームはサービス提供の差別化、さらには業界を破壊し、最終的には変革する上で重要な役割を果たします。

その結果、アプリケーション アーキテクトは、モノリシック アプリケーションにカプセル化された大規模なワークフローにあまり関心を持たなくなります。今日の質問は、DevOps チームが必要なレベルの俊敏性 (クラウド ネイティブ プラットフォームを大規模に使用して一定のリズムでソフトウェアを展開すること) を達成するために何をしなければならないかを中心に展開されることが多く、これはそれほど昔には考えられなかったことです。

[[319876]]

アジャイルプラクティスと新しいクラウドネイティブ インフラストラクチャのおかげで、開発チームは数か月ごと (またはそれ以上) ではなく、1 日に数回コードをデプロイできます。

クラウドネイティブアプリケーション開発のメリット

従来のモノリシック アプリケーション開発手法を使用して開発されたアプリケーションとは異なり、クラウド ネイティブ アプリケーションは、その汎用性により、より小型で柔軟性が高く、他のアプリケーションやサービスと簡単に統合できます。多くの開発者は、より広範なエコシステムの一部となるアプリケーションやサービスを開発することもあります。

目標は、デプロイメントを一貫して高速かつ堅牢にすることです。最終的なテストは、これらのアジャイル展開が、競合製品よりも大規模かつ優れた方法でエンドユーザーのニーズを満たすことができるかどうかです。ステートレス コンテナ環境でデータとネットワークを迅速かつ一貫して展開する場合、予期しない問題が発生する可能性があるため、組織はクラウド ネイティブの世界でデータとネットワークを効率的に管理および拡張することを優先する必要があります。

コンテナ内の永続ストレージの管理

クラウド ネイティブに移行するときに組織が直面する大きな障害は、一時的なコンテナ環境でのステートフル アプリケーションのデータの管理であることがよくあります。

クラウド ネイティブ アーキテクチャ向けのソフトウェアを開発および展開する場合、開発者は、作成して配布するコードが組織の運用とどのように相互作用するかを常に理解する必要があります。コンテナとマイクロサービスは、開発者に信じられないほどのデプロイメントの柔軟性を提供します。基盤となるアーキテクチャのステートレスな性質により、即座に拡張でき、コードの展開を削減できます。ただし、データの配置に関しては、特にアプリケーション アーキテクトが複数の場所に存在する可能性のあるコードやマイクロサービスで作業している場合、データの永続性、安定性、セキュリティを維持することが課題となる可能性があります。

最初にコンテナを使用する新興の DevOps 環境では、CI/CD パイプライン、Git リポジトリ、またはアプリケーションにネットワーク ファイル システム (NFS) を接続するのが簡単な戦略になる場合があります。ただし、以下で説明するように、データの移植性、復元力、動的なプロビジョニング/デプロビジョニングは煩雑になり、標準以下になる可能性があります。共有できず、潜在的な障害点やデータ セキュリティの脅威がある独自のクラウド ストレージ インフラストラクチャを使用した場合にも同様の問題が発生する可能性があります。

つまり、クラウド ネイティブの旅を始める前に永続的なストレージ レイヤーを用意しておくと、面倒な作業や後戻りを防ぐことができます。

永続ストレージの仕組み

ステートレス環境でのアプリケーション開発と展開における永続ストレージの課題に対処する 1 つの方法は、コンテナ プラットフォームと統合されたストレージ レイヤーを採用することです。

開発者は Kubernetes オーケストレーターを使用してプロジェクト用のリソースを簡単に作成できるため、永続ストレージ層は理想的には動的ストレージ プラットフォームで構成する必要があります。開発者は、ストレージ層がアプリケーション展開のデータ セキュリティと回復力の要件も満たしていることに自信を持つ必要があります。

実用的なソフトウェア定義ストレージ プラットフォームを使用すると、開発チームは、NFS マウントを使用してこのプロセスを手動で完了するのではなく、プロジェクトのデータのニーズを動的に定義および調整できます。さらに、ストレージのプロビジョニングにストレージ管理者に頼る必要がなく、必要に応じてストレージ構成を変更できます。

同様に、SQL や NoSQL データベースなどのブロック プロトコルでデータを保存するアプリケーションの場合、組織によってはサービス プロバイダーの独自のソリューションを採用することを好む場合があります。ただし、これにより、異なるクラウドやリージョンにわたってストレージの可用性を提供する能力が制限され、開発者は単一のプロバイダーのソリューションに固定されてしまいます。

オープンソースのソフトウェア定義ストレージにより、ベアメタル、仮想マシン、パブリックおよびプライベート クラウド環境など、さまざまな種類のインフラストラクチャにわたって永続的かつポータブルなストレージを実現できます。データ フェデレーションはハイブリッド環境とマルチクラウド環境全体で実行できるため、開発者は機密データを必要な場所に配置し、さまざまなマルチクラウド デプロイメントからアプリケーションとマイクロサービスを統合できます。

人工知能 (AI) や機械学習 (ML) などの大規模な分析アプリケーションでは、データ サイエンティストは複数の場所やデバイスからの大量のデータ増分を管理しなければならないことがよくあります。もう 1 つの例は、エッジ デバイスと IoT リソースです。データの集約と配信は、デバイス エッジからリモート ステージング、そしてコア システムに至るまで、データのライフサイクル全体にわたってシームレスに提供される必要があります。多くの場合、さまざまなタイプのイベントには、オブジェクトからブロック、ファイルまで、さまざまなストレージ プロトコルが必要です。これらの非常に動的で多様なストレージ要件を処理するには、永続的なストレージ層機能が利用可能である必要があります。

最終的には、開発チームは、標準化されたプラットフォームに依存して、単一の API を通じて、マルチクラウド、ベアメタル、仮想マシンなど、多様で要求の厳しい環境全体でストレージ管理を自動化できる必要があります。ストレージ レイヤーは、開発者が必要に応じてスケールダウンまたは再デプロイする必要がある場合にも、大きなフェイルオーバーの利点を提供する必要があります。また、非常に柔軟性が高く、ほぼゼロのレイテンシを実現することで開発者が必要なものを定義することができる必要があります。

クラウドネイティブの永続ストレージはこれらの機能を提供し、DevOps チームに大きな柔軟性と移植性をもたらします。クラウドネイティブ環境でのソフトウェア展開に柔軟性を提供すると同時に、開発者が独自のストレージニーズを自由に管理できるようにします。

元のリンク:

https://thenewstack.io/how-persistent-storage-offers-cloud-native-developers-more-freedom/