Dockerで永続ストレージ（前編）

Dockerで永続ストレージを実現するDockerボリュームとバインドマウント

Dockerでも永続的なストレージが必要な場面が増えてきた。永続ストレージを実現する方法は複数あるが、最適な方法を選択するには幾つかの要件を考慮する必要がある。

　コンテナはホットな話題であり。このテクノロジーで代表的なのが「Docker」だ。これを使うと、完全な仮想マシン（VM）ではなく軽量のプロセスセットとしてアプリケーションを展開できる。

　Dockerは、アプリケーションイメージのライブラリ（Dockerハブ）、実行環境（コンテナエンジン）、ネイティブの「Swarm」と「Kubernetes」（ともにDockerクラスタ管理ツール）のサポートといった一連のオーケストレーション機能を組み合わせて、コンテナの迅速な開発を可能にするエコシステムを築いてきた。

　当初コンテナは、恐らく数分または数時間ほどの短命なものと想定されていた。かつての典型的なユースケースは、マイクロサービスやWebベースのアプリケーションから構築されるアプリケーションだったからだ。

　しかし、従来型データベースやNoSQLデータベースなど、寿命が長いアプリケーションもコンテナのエコシステムを使って展開できることが次第に明らかになってきた。

　Dockerは典型的な3層アプリケーションからかなり複雑なWebネイティブのアプリケーションに至るまで、さまざまなシステムを構築できる可能性を秘めている。

　テクノロジーの実装方法によって、データの耐障害性（レジリエンス）がアプリケーションに存在する場合と、インフラによって提供される場合がある。その結果、コンテナのインスタンス化全体で、データの可用性を確保するストレージレイヤーに永続性が必要であると分かった。

　コンテナ技術が成熟するにつれて、他の要件も発生したことを忘れてはならない。開発が完了していない要件もあるが、今後時を追うごとに重要性が増してくるだろう。

• 永続性

永続性を備えるには、データが確実にコンテナの寿命を超え、さらには異なるホストとの間でもレジリエンスを維持することを保証しなければならない。アプリケーションに固有のレジリエンスが組み込まれていないか、あるいはコンテナが自動的にホスト間を移動する場合、これが不可欠になる。

• セキュリティ

アプリケーションのデータはどの方法で保護されるのだろうか。これには、暗号化と、各コンテナおよびその他の外部サービス（バックアップなど）からのアクセスを制御する際の要件が含まれる。

• パフォーマンス

各コンテナで使用するデータについて、入出力（I/O）のパフォーマンスをどのように管理するのか。I/Oスループットとレイテンシの管理について要件が存在する。

• 保護

データ保護はコンテナの世界でも適用される。これには、ドライブやメディアなどのハードウェア障害に対する物理的な保護と、大規模なインフラで障害が発生した際の復旧のしやすさが含まれる。

• モビリティー

複数の場所に分散しているデータの可用性の管理は、恐らく最も興味深い課題の1つになる。コンテナはプライベート（自社内）およびパブリック（クラウド上に構築した）のデータセンターで使用されるためだ。

Dockerボリューム vs. バインドマウント

　ストレージとコンテナのオプションは、コンテナレイヤーでの使用目的によって異なる。

　Dockerエコシステム内では、コンテナを実行するホストからストレージを調達できる。このストレージ空間は、新規作成されたファイルディレクトリ（コンテナの起動時に作成される）、またはホスト上に既に存在するディレクトリとして提供される。

　前者の技法はDockerボリュームと呼ばれる。これは基本的にDockerが管理するディレクトリだ（通常は/var/lib/docker/volumesディレクトリにある）。

　Dockerボリュームは、コンテナを開始する前にあらかじめ作成しておくこともできるし、複数のコンテナで共有することもできる。また、ボリュームプラグインを使用することもできるが、こちらの詳細については後述する。

　2番目の選択肢は、ホストのディレクトリをコンテナへマッピングすることだ。この技法はバインドマウントともいう。

この記事の著者

関連記事

• 

  発見者が解説――「Spectre」を発見したリバースエンジニアリング手法

• 

  ブロックチェーン開発者が今すぐ着手すべきは緊急時対応計画の策定