入門 Kubernetes

13章ストレージソリューションとKubernetesの統合

アプリケーションとその状態の情報を切り離し、マイクロサービスをできる限りステートレスに構築すると、システムの信頼性が最大化され、管理しやすくなります。

しかし、複雑性の高いシステムはたいていの場合、ステートフルな情報をどこかに持っているものです。それは、データベースの中のレコードであったり、検索エンジンに結果を返すためのインデックスのシャードであったりします。そのため、どこかのタイミングでデータを保存する場所を持つ必要があります。

コンテナやコンテナオーケストレーションの仕組みとデータを統合するのは、分散システムを作る上で特に難しい問題です。コンテナを使ったアーキテクチャを採用することはつまり、分離され、イミュータブルで、かつ宣言的なアプリケーション開発を行うことであり、それが問題を難しくしています。コンテナを使ったアーキテクチャは、ステートレスなWebアプリケーションには比較的簡単に適用できますが、CassandraやMongoDBのような「クラウドネイティブな」ストレージソリューションを使うには、手動あるいは命令的な手順を踏まないと、レプリケーションされた信頼性の高いシステムは作れません。

例として、MongoDBのレプリカセットをセットアップする場合を考えてみましょう。この時、mongodをデプロイし、命令的な方法でプライマリとその他のノードを特定する必要があります。もちろんこの手順はスクリプトにできますが、コンテナ化してしまうと、Deploymentにどのように組み込むか考えづらくなります。さらに、各コンテナのDNS名を引くことすら簡単ではないことが分かります。

また、データの重要性もさらに複雑性を増す要因になります。ほとんどのコンテナは、他のシステムと無関係に動いているわけではありません。コンテナは通常、仮想マシンにデプロイされた既存システムと関連しており、そのシステムはインポートしたりマイグレートする必要があるデータを持っています。 ...