Kubernetes でのクラウドネイティブデータの管理

序文

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

Kubernetesはステートフルなワークロードに対応できるか？

これが本書を開くきっかけとなった質問かもしれない。クラウド・コンピューティングが登場して以来、データ・インフラ（NoSQL/NewSQL、ストリーミング、アナリティクス）とアプリケーション・インフラ（Docker、Kubernetes）は急速に成熟してきたが、別々の道を歩んできた。我々の見解では、今こそこの2つの分野を正式に統合する時だ。これは将来の願望ではなく、すでに複数のコミュニティでコラボレーションが行われている。アプリケーションとデータのために2つの異なるスタックを管理しようとしている組織は、すぐに競争上欠点に気づくだろう。

2014年にKubernetesが公開されてから最初の数年間は、データやステートフルなワークロードには対応できていないという格言に疑問が呈されることはほとんどなかった。この通説の例は、2018年のKelsey Hightowerのツイートで発見できる：

Kubernetesは、データベースやメッセージキューを含むステートフルなワークロードを実行する能力を大幅に向上させたが、私はまだそれらをKubernetes上で実行することを好まない。

ここ数年で、流れは変わった。問題解決型のエンジニアたちは、ケルシーからのこの挑戦を受け止め、行動に移した。ステートフルなワークロードに対するKubernetesの成熟は、ある意味、需要が大きかったので必然だった。なぜデータベースはベアメタルマシンで実行しなければならないのか、なぜデータインフラをコンテナでデプロイしてはならないのか、といった引数を覚えている人なら、この懸念に共感できるだろう。

我々はまた、"決して "と "まだ "の間には大きな違いがあることも学んだ。コンピュート、ストレージ、ネットワークは今やコモディティと考えられている。コスト削減とアプリケーション開発の簡素化というKubernetesの価値提案は、データインフラをKubernetesに移行することが必然だったことを意味する。変化はKubernetesだけではない。後述するように、データインフラのプロジェクトも変化している。

この本を書いた理由

DataStaxでの "本業 "の責任から、KubernetesでApache Cassandraを効果的にデプロイして運用する方法を検討することになったとき、私たちはステートフルなワークロードをKubernetesに移行するトレンドに巻き込まれた。オープンソース開発の精神に基づき、私たちはデータベースやその他のステートフルなワークロードで同様の偉業を試みている（そして成功している）他の実務家を探した。私たちは志を同じくする人々のグループを発見し、2020年にData on Kubernetes Community（DoKC）を立ち上げる手助けをした。DoKCは現在、独立した組織となり、100を超えるミートアップといくつかの対面イベントを開催してきた。DoKCのミートアップにおける様々なトピックとプレゼンターは、標準とベストプラクティスを確立するために協働している、活気あるコミュニティの証拠である。最も重要なことは、私たちは共に学び、過去の教訓を生かし、新しいものを作り上げるために互いに支え合っているということだ。

これらのミートアップに参加するうちに、共通のテーマが浮かび上がってきた。PersistentVolumeサブシステムの長所、StatefulSetsの長所と短所、データベース操作をより管理しやすくする演算子パターンの有望性、新しいタイプのデータ管理に関するアイデアの初期のヒントなどである。時が経つにつれ、私たちは、この駆け出しの実務家コミュニティには、複数のプレゼンテーションやブログ投稿に散在する知恵をすべて集め、消化しやすい形に抽出する場が必要だと強く確信するようになった。本書はそのプロセスの成果である。 ...