第7章 Kubernetesネイティブデータベース Kubernetesネイティブデータベース
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
ソフトウェア業界には、主要なトレンドを一言や短いフレーズで定義する用語があふれている。本書のタイトルにある「クラウドネイティブ」もそのひとつだ。別の例としては、マイクロサービスがある。マイクロサービスは、ここで議論しているテクノロジーの多くに関わる主要なアーキテクチャパラダイムだ。さらに最近では、Kubernetesネイティブや サーバーレスといった言葉も登場した。
簡潔でキャッチーではあるが、複雑なトピックやトレンドを1つのサウンドバイトに絞り込むと、曖昧さや、少なくとも "これは実際に何を意味するのか?"といった合理的な疑問が残る。さらに水を差すようだが、このような用語は、他の競合製品との差別化を図るために、マーケティング製品の文脈で頻繁に使われる。あなたが消費しているコンテンツがあからさまな文であろうと、単なるサブテキストであろうと、あるテクノロジーがKubernetesネイティブと銘打たれているからには、他の製品よりもKubernetes上で実行する方が良いに違いないと思ったことがあるかもしれない。
もちろん、これらの用語がアプリケーションの評価や適切なテクノロジーの選択に役立つためには、第1章でクラウドネイティブデータという用語について行ったように、その本当の意味を解き明かすことが真の課題である。本章では、データ・テクノロジーがKubernetesネイティブであることの意味を調べ、合意できる定義にたどり着けるかどうかを確認する。そのために、これらの用語を主張するいくつかのプロジェクトを検証し、共通原則を導き出す:TiDBとAstra DBだ。準備はいいか?さあ、飛び込もう!
Kubernetesネイティブなアプローチが必要な理由
まず、そもそもなぜKubernetesネイティブデータベースのアイデアが出てきたのかについて説明しよう。本書ではここまで、MySQLやCassandraを含む既存のデータベースのKubernetesへのデプロイに焦点を当ててきた。これらは、Kubernetesが存在する以前から存在し、時間をかけて実証されてきた成熟したデータベースだ。これらには大規模なインストールベースとユーザコミュニティがあり、このような投資のおかげで、Kubernetes環境でこれらのデータベースを実行する大きなインセンティブがあり、それらを自動化する演算子の作成に関心が集まっている理由がわかるだろう。
同時に、これらのデータベースをKubernetes上で実行するように適合させる際に、厄介な点があることにもお気づきだろう。マウントパスを変更するだけで、データベースをKubernetesベースのストレージに向けることは非常に簡単だが、複数のノードで構成されるデータベースを管理するためのKubernetesとの緊密な統合は、もう少し複雑になる可能性がある。レガシーな管理UIをPodにデプロイしてHTTPポートへのアクセスを公開するような比較的単純な作業から、第6章で見たようなサイドカーをデプロイして管理やメトリック収集のためのAPIを提供するような複雑な作業まで、様々なものが考えられる。
この複雑さを認識した一部のイノベーターは、初日からKubernetesネイティブとなるように設計された新しいデータベースを開発するようになった。 ...