第6章. データインフラをKubernetesスタックに統合する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
本書では、Kubernetes上で動作するモダンなクラウド・ネイティブ・アプリケーションの未来を描いている。ここまでの点で、歴史的にデータがこれを実現する上で最も難しい部分の1つであったことを述べてきた。これまでの章では、コンピューティング、ネットワーク、ストレージのリソースを管理するためにKubernetesが提供するプリミティブを紹介し(第2章)、これらのリソースを使用してKubernetes上にデータベース(第3章)をデプロイする方法について考えてきた。また、コントローラと演算子パターン(第4章)を使ったインフラの自動化についても検討してきた。
では、Kubernetesのアプリケーションアーキテクチャ全体にデータインフラがどのように適合するかを検討するために、フォーカスを広げてみよう。この章では、前の章で説明した構成要素を、デプロイが容易で各アプリケーション固有のニーズに合わせた統合データインフラスタックに組み立てる方法を探る。これらのスタックは、第1章で紹介した仮想データセンターの構想への一歩となる。このような大規模なアセンブリを構築して使用する際の考慮事項を学ぶために、K8ssandraを詳しく見てみよう。このオープンソースプロジェクトは、「Kubernetes上でApache Cassandraを実行する」で最初に説明したデータベースであるApache Cassandraをベースにした統合データスタックを提供する。
K8ssandra: Kubernetes上のプロダクション・レディなCassandra
その背景を説明するために、アプリケーションのワークロードをKubernetesに移行する際の現実的な課題について考えてみよう。組織が既存のアプリケーションをKubernetesに移行し、Kubernetesで新しいクラウドネイティブアプリケーションを作成し始めたとき、データ層の近代化はしばしば先送りされるステップだ。Kubernetesがステートフルなワークロードに対応できていないという考え、開発リソースの不足、その他の要因など、こうした遅れの原因が何であれ、その結果、アプリケーションがKubernetesで実行され、データベースやその他のデータインフラが外部で実行されるという、アーキテクチャのミスマッチが生じている。その結果、アプリケーションはKubernetesで実行され、データベースやその他のデータインフラは外部で実行されるという、不一致のアーキテクチャになっている。また、アプリケーションとデータベースインフラを監視するためのツールセットが別々であることも一般的で、クラウドコンピューティングのコストを増大させている。
この採用の課題は、Cassandraコミュニティで明らかになった。第5章で説明したように、単一のCassandra演算子を構築することに関する協力とコンセンサスが高まっているにもかかわらず、開発者は、データベースと演算子がより大きなアプリケーションのコンテキストにどのように適合するかに関する重要な疑問に直面していた:
アプリケーションとデータの両方を含むスタック全体の健全性を統合的に把握するにはどうすればいいのか?
インストール、アップグレード、その他の演算タスクの自動化を、データセンターの管理方法に合ったKubernetesネイティブな方法でカスタマイズするにはどうすれば ...