第16章 ストレージソリューションとKubernetesの統合 ストレージ・ソリューションとKubernetesを統合する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
多くの場合、アプリケーションから状態を切り離し、マイクロサービスを可能な限りステートレスに構築することで、最大限の信頼性と管理性を備えたシステムが実現する。
しかし、データベースのレコードからウェブ検索エンジンの検索結果を提供するインデックスシャードに至るまで、複雑さを持つほぼすべてのシステムは、システムのどこかに状態を持つ。ある時点で、どこかにデータをストアしなければならない。
このデータをコンテナやコンテナ・オーケストレーション・ソリューションと統合することは、分散システム構築の最も複雑な側面であることが多い。この複雑さは、コンテナ化アーキテクチャへの移行が、非結合、不変性、宣言的なアプリケーション開発への移行でもあるという事実に大きく起因している。これらのパターンはステートレス・ウェブ・アプリケーションに適用するのは比較的簡単だが、CassandraやMongoDBのような「クラウド・ネイティブ」ストレージ・ソリューションでさえ、信頼性の高いレプリケーション・ソリューションをセットアップするために、ある種の手作業や命令的なステップを必要とする。
この例として、MongoDBでReplicaSetをセットアップすることを考えてみよう。Mongoデーモンをデプロイし、命令コマンドを実行して、Mongoクラスタのリーダーと参加者を特定する。 もちろん、これらのステップはスクリプト化できるが、コンテナ化された世界では、このようなコマンドをデプロイに統合する方法は難しい。同様に、レプリケートされたコンテナセットで個々のコンテナのDNS解決可能な名前を取得することさえ難しい。
さらに複雑なのは、データの重力があることだ。ほとんどのコンテナ化されたシステムは、真空の中で構築されているわけではない。それらは通常、仮想マシン上にデプロイされた既存のシステムから適応されたものであり、これらのシステムには、インポートまたはマイグレーションしなければならないデータが含まれている可能性が高い。
最後に、クラウドへの進化は、ストレージが外部化されたクラウドサービスであることを意味することが多く、その文脈では、Kubernetesクラスタの内部に存在することはあり得ない。
この章では、Kubernetesでコンテナ化されたマイクロサービスにストレージを統合するための様々なアプローチを取り上げる。まず、既存の外部ストレージソリューション(クラウドサービスまたは仮想マシン上で動作する)をKubernetesにインポートする方法を取り上げる。次に、Kubernetes内部で信頼性の高いシングルトンを実行し、以前ストレージソリューションをデプロイした仮想マシンとほぼ同じ環境を実現する方法を探る。最後に、多くの人がKubernetesのステートフルなワークロードに使うKubernetesリソースであるStatefulSetsについて説明する。
外部サービスをインポートする
多くの場合、ネットワーク内で稼働している既存のマシンで、何らかのデータベースが稼働している。 このような状況では、そのデータベースをすぐにコンテナやKubernetesに移行したくないかもしれない。おそらく、そのデータベースは別のチームによって運営されているか、段階的に移行しているか、あるいはデータを移行する作業が単純に面倒なだけなのだろう。 ...