永続ストレージ: コンテナ時代の長期記憶

公開: 2023-04-17

永続ストレージとは、デバイスやアプリケーションの電源がオフになったり再起動したりした後でもデータを利用できるように、不揮発性でデータを保持することです。 データの保存と取得により、Web アプリケーションはユーザー情報と状態を保存し、確実に動作することができます。

モノリシック アプリケーションでは、サーバーとストレージが共存するため、ストレージへのアクセスは簡単です。 ただし、地理的に分散したシステムでは、世界中のすべてのコンポーネントがストレージ システムを利用できる状態を維持する必要があるため、アクセスがより複雑になります。

コンテナ化は問題をさらに複雑にします。コンテナは軽量で、ステートレスで、一時的なものであり、データの保存には適していないためです。 したがって、永続ストレージ ソリューションはコンテナとシームレスに連携できなければならず、さらに複雑なレイヤーが追加されます。

この記事では、永続ストレージのタイプ、アーキテクチャ、ユース ケースを調査することで、永続ストレージについて詳しく説明します。 また、Docker でのボリューム ストレージと永続ボリューム ストレージの違いを示す実践的なデモンストレーションも提供します。

永続ストレージの種類

不揮発性ストレージには、従来の回転ディスク (ハード ディスク ドライブまたは HDD)、ソリッド ステート ドライブ (SSD)、ネットワーク接続ストレージ (NAS)、ストレージ エリア ネットワーク (SAN) など、いくつかの種類があります。

  • HDD は、磁気メディアの回転ディスクを使用してデジタル データを保存および取得する電気機械式データ ストレージ デバイスです。 ディスクは、データの読み取りと書き込みを行う可動アクチュエータ アーム上の磁気ヘッドを使用します。
  • SSD は、半導体ストレージ デバイス、ソリッド ステート デバイス、またはソリッド ステート ディスクとも呼ばれ、集積回路アセンブリを使用してデータを永続的に保存します。通常は、可動部品を含まない相互接続されたフラッシュ デバイスを使用します。 それらの静止した性質​​により、HDD よりも高速で信頼性が高くなります。
  • ネットワーク接続ストレージは、 New Technology File System (NTFS) や 4 番目の拡張ファイル システム (EXT4) などのファイル システムを使用して、ローカル ネットワーク経由で接続された HDD、SSD、またはその両方のグループです。
  • SAN は、テープ ライブラリやディスク アレイなど、ネットワーク化された高速のブロック レベルのストレージ デバイスです。 それらの接続は、オペレーティング システムにはローカル ストレージとして表示され、ローカル エリア ネットワーク (LAN) 経由ではアクセスできません。
永続的なストレージを使用して、シャットダウンおよび再起動中にデータを安全に保ちます! クリックしてツイートする方法は次のとおりです

永続ストレージ アーキテクチャ

永続ストレージには 3 つのアプローチがあり、それぞれに固有のユース ケースと制限があります。

オブジェクト永続アーキテクチャ

オブジェクト永続アーキテクチャ アプローチでは、オブジェクト リレーショナル マッピング (ORM) を使用して、データをオブジェクトとしてリレーショナル データベースまたはキー値データベースに格納します。 このアプローチは、ORM がデータの格納と取得を処理するため、データにスキーマが定義されていない場合に役立ちます。

ブロック永続アーキテクチャ

ブロック永続アーキテクチャは、大きなファイルを格納する場合に便利なブロック レベルのストレージ デバイスを使用します。 このアプローチは、複数のブロックを使用してストレージ容量を増やすことができるため、大量のデータを保存する場合に役立ちます。

Filestore 永続アーキテクチャ

名前が示すように、ファイルストア永続アーキテクチャ アプローチでは、ファイル システムを使用してデータを格納します。 1 つの方法は、データを集中的に格納する方法を提供するデータベース サーバーを使用することです。 Kinsta のようなクラウド ホスティング ソリューションは、アプリケーションに簡単に接続でき、永続性を提供するデータベース サーバーを使用します。

Filestore 永続アーキテクチャは、ファイルを頻繁に取得する必要があるアプリケーションや、ファイルを管理するためのインターフェイスが必要な場合に役立ちます。

永続ストレージの使用例

このセクションでは、各ストレージ タイプのユース ケースのいくつかについて説明します。

オブジェクト永続ストレージ

  • クラウド ストレージ:オブジェクト永続ストレージは、クラウド ストレージ ソリューションで一般的に使用され、画像、ビデオ、ドキュメントなどの大量の非構造化データを保存および取得します。 クラウド プロバイダーは、オブジェクト ストレージを使用して、スケーラブルで可用性が高く、耐久性のあるストレージ サービスを顧客に提供します。
  • ビッグ データ分析:オブジェクト永続ストレージは、ビッグ データ分析で使用され、データ分析、機械学習、および AI によく使用される大規模なデータ セットを保存および管理します。 オブジェクト ストレージを使用すると、データにすばやく効率的にアクセスできるため、ビッグ データ アーキテクチャの重要なコンポーネントになります。
  • コンテンツ配信ネットワーク:オブジェクト永続ストレージは、コンテンツ配信ネットワーク (CDN) で使用され、画像、ビデオ、静的ファイルなどのコンテンツをサーバーのグローバル ネットワーク全体に保存および配信します。 オブジェクト ストレージにより、CDN は場所に関係なく、世界中のユーザーに高速コンテンツを配信できます。

ブロック永続ストレージ

  • ハイパフォーマンス コンピューティング (HPC) : 大量のデータを迅速かつ効率的に処理する HPC 環境。 ブロック永続ストレージにより、HPC クラスターは、科学シミュレーション、気象モデリング、財務分析などの大規模なデータセットを保存および取得できます。 ブロック ストレージは、ハイ パフォーマンスで低レイテンシのデータ アクセスを提供し、処理時間を大幅に短縮できる並列入出力 (I/O) 操作を可能にするため、HPC に好まれることがよくあります。
  • ビデオ編集:ビデオ編集アプリケーションは、大きなビデオ ファイルへの高性能で低遅延のアクセスを必要とします。 また、ビデオ ファイルをリアルタイムでレンダリングおよび編集するために、1 秒あたりの大量の I/O 操作と低レイテンシにも対応する必要があります。 ブロック ストレージはこれらの機能を提供するため、ビデオ編集ワークフローにとって理想的なソリューションとなります。
  • ゲーム:ゲーム アプリケーションでは、ゲーム アセットやプレイヤー データにアクセスするために、高いパフォーマンスと低レイテンシも要求されます。 ブロック ストレージは、大量のデータをすばやく格納および取得することで、ゲーム環境が迅速に読み込まれ、ゲームプレイ中の応答性が維持されるようにします。

Filestore 永続ストレージ

  • メディアとエンターテイメント:ビデオ編集、アニメーション、およびレンダリング アプリケーションは、通常、永続ストレージを使用します。 これらのアプリケーションは、ビデオ、オーディオ、画像などの大きなメディア ファイルへの高パフォーマンスで低遅延のアクセスを必要とします。 Filestore は、複数のクライアントからアクセスできる共有ファイル システムを提供するため、これらのアプリケーションにとって理想的なストレージ ソリューションになります。
  • Web コンテンツ管理: Web コンテンツ管理システム (CMS) は、共有ファイル システムのファイルストア永続ストレージを使用して、テキスト、画像、マルチメディア ファイルなどの Web サイト コンテンツを保存および管理します。 Filestore は Web サイトのコンテンツを一元管理する場所を提供し、コンテンツの管理と更新を容易にします。 また、複数のユーザーが同じコンテンツで同時に作業できるため、コラボレーションと生産性が向上します。

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

コンテナーは、軽量で、移植可能で、安全で、簡単であり、さまざまなアプリケーション間の融合を提供します。 コンテナーの再起動と削除の間でデータを保持するメカニズムが必要です。 コンテナには、従来のアプリケーションと同様にファイル ストレージまたはファイル システムがありますが、新しい変更を加えてコンテナを再構築すると、すべての非永続データが失われます。

そのため、コンテナーには、ボリューム ストレージを含めるか、ストレージ ボリュームをマウントするオプションが用意されています。 コンテナは、ストレージ ボリュームをディレクトリとして扱います。 ボリュームに書き込まれたデータはすべて、ホスト ファイル システムに入ります。

コンテナーを再起動すると新しいインスタンスが作成され、古いインスタンスが破棄されるため、コンテナーの永続ストレージはこのように機能する必要があります。 コンテナのデータ ビューが一貫していない場合、コンテナを再起動するとデータが消えます。 ストレージ ボリュームは、セッションやコンテナーの再起動後もデータを保持するため、コンテナーが移動または再起動されても、コンテナーはその状態を維持できます。

ボリュームと永続ボリューム

コンテナーは、ボリュームと永続ボリュームを使用して、永続データを格納する 2 つの方法を提供します。 それらの間には大きな違いがあります。 コンテナーは、ボリューム ストレージ内のデータを管理します。 コンテナを停止しても、データはそのまま残り、コンテナを再起動したときに使用できます。 ただし、コンテナーを削除または削除すると、基になるボリューム ストレージも削除されるため、データは失われます。

永続的なボリューム ストレージまたはバインド マウントは、コンテナーのファイル システムの外部にデータを格納する方法です。 これにより、コンテナを削除してもデータは失われません。 手動で削除するまで永続的です。

次のセクションでは、例を使用して両方のボリューム タイプを示します。

コンテナ永続ストレージのデモ

Docker コンテナーを使用した永続ストレージを示すために、小さな Web アプリケーションを作成しました。 Docker をインストールして、この GitHub リポジトリからコードを取得することで、手順を追うことができます。

アプリケーションは、ユーザー入力用の 2 つのフィールドを持つ基本フォームです。

  • タイトル
  • 文書のテキスト
スクリーンショット: デモ アプリケーションのフィードバック フォームのグラフィカル インターフェイス。
Title フィールドとDocument Textフィールドを含むデモ アプリケーションの GUI。

ユーザー入力を保存したら、 [タイトル]フィールドに指定された名前のファイルをフィードバックディレクトリで開くことでアクセスできます。 Document Textフィールドからの入力は、ファイルのコンテンツです。

ボリューム ストレージの使用方法

自分のマシンにアプリケーションをインストールすると、 Dockerfileに示されているようにボリューム ストレージを使用できます。

スクリーンショット: VOLUME 属性を含む Docker ファイルの内容。
ボリューム ストレージの使用を示す Dockerfile。

次に、イメージをビルドしてコンテナーを実行します。 これを行うには、次のコマンドを実行します。

 docker build -t feedback-node:volumes . docker run -d -p 3000:80 --name feedback-app feedback-node:volumes
スクリーンショット: ボリューム ストレージを使用した docker build コマンドの結果を示すターミナル ウィンドウ。
ボリューム ストレージを使用してアプリケーションを構築します。
スクリーンショット: ボリューム ストレージで docker run コマンドを実行した後のターミナル ウィンドウ。
コンテナーを実行すると、コンテナーがボリューム ストレージを管理していることがわかります。

アプリケーションが実行されたら、localhost:3000 に移動してフィードバックを送信します。

スクリーンショット: デモ アプリケーションのグラフィカル インターフェイスを介してフィードバックを送信します。
アプリケーションへのフィードバックの送信。

[保存]をクリックし、 localhost:3000/feedback/test.txtに移動して、入力が正常に保存されたかどうかを確認します。

スクリーンショット: 送信された test.txt ファイルが開いているブラウザー。
正常なフィードバックが確認されました。

コンテナを削除して再起動し、入力が持続するかどうかを確認します。

 docker stop feedback-app docker start feedback-app

同じ URL にアクセスすると、フィードバックがまだ残っていることがわかります。 しかし、コンテナを削除して再起動するとどうなるでしょうか?

 docker stop feedback-app docker rm feedback-app docker run -d -p 3000:80 --name feedback-app feedback-node:volumes

再起動後、その URL に戻ると、コンテナーを削除したときにデータが失われたため、その URL は存在しなくなります。 ボリューム データは、コンテナーを削除するときではなく、コンテナーを停止するときにのみ保持されます。

スクリーンショット: ブラウザーが test.txt ファイルを開けないことを報告しています。
フィードバック データが失われました。

この問題を軽減し、コンテナーを削除してもデータを保持するには、永続的なボリューム ストレージまたは名前付きストレージを使用する必要があります。 まず、コンテナーとイメージをクリーンアップする必要があります。

 docker stop feedback-app docker rm feedback-app docker rmi feedback-node:volumes

永続ボリューム ストレージの使用方法

これをテストする前に、Dockerfile から VOLUME 属性を削除し、イメージを再構築する必要があります。

スクリーンショット: VOLUME 属性を削除するように編集された Dockerfile。
Dockerfile を更新して VOLUME 属性を削除しました。
 docker build -t feedback-node:volumes . docker run -d -p 3000:80 --name feedback-app -v feedback:/app/feedback feedback-node:volumes

ご覧のとおり、2 番目のコマンドでは、 -vフラグを使用して、コンテナーの外部にある永続ボリュームを定義しています。これは、コンテナーを削除しても保持されます。

前の手順と同様に、コンテナーを停止、削除、再起動したら、フィードバックを追加してアクセスしてみてください。

スクリーンショット: デモ アプリケーションのフィードバック フォームにテキストを入力しています。
永続性テストの新しいフィードバックを追加します。
 docker stop feedback-app docker rm feedback-app docker run -d -p 3000:80 --name feedback-app -v feedback:/app/feedback feedback-node:volumes

ご覧のとおり、コンテナーを停止して削除した後でも、データにアクセスでき、そのまま残ります。

スクリーンショット: 2 番目のテスト ファイルを正常に開いたブラウザー。
コンテナーを停止して削除した後、データは残ります。
永続ストレージ: 安定性と信頼性に優れたコンテナ化アプリの鍵! タイプ、アーキテクチャ、ユースケースについてはこちら

まとめ

永続ストレージは、コンテナーのライフサイクル外でデータを永続化できるため、コンテナー化されたアプリケーションに不可欠です。 コンテナー化されたアプリケーションの永続ストレージの主な 2 つのタイプは、ボリュームとバインド マウントであり、それぞれに利点とユース ケースがあります。

ボリュームはコンテナのファイル システム内に格納されますが、バインド マウントはホスト マシン上で直接アクセスできます。

永続ストレージを使用すると、コンテナ間でデータを共有できるため、複雑な多層アプリケーションを構築できます。 永続ストレージは、コンテナ化されたアプリケーションの安定性と継続性を確保するために不可欠であり、重要なデータを格納するための信頼性が高く柔軟な方法を提供します。

また、Docker を使用して Web アプリケーションを開発している場合は、Kinsta のアプリケーション ホスティング サービスを使用して Dockerfile の展開を簡単に構成できることがわかります。