Kubernetes ネイティブ データベース: TiDB Vs. DataStax アストラ DB

A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB.

クラウド コンピューティングの革命は、相互に関連する複数のトレンドから刺激を受け、恩恵を受けてきました。セルフサービスのパブリック クラウド インフラストラクチャが利用できるようになったことで、自動化や可観測性を含むマイクロサービス アーキテクチャや DevOps プラクティスの採用が促進されました。

コンテナー化とコンテナー オーケストレーションへの移行により、クラウドネイティブ アプリケーションを管理するための環境として Kubernetes が広く採用されるようになりました。

しかし、この革命で遅れをとっている分野の 1 つは、データとデータ インフラストラクチャです。あまりにも長い間、データは Kubernetes の外にあるものであり、開発者がクラウドネイティブ アプリケーションをデプロイする際に多くの余分な労力と複雑さをもたらしました。

Kubernetes の初期に繰り返された公理の 1 つは、まだステートフル ワークロードの準備ができていないというものでした。ありがたいことに、大きな変化は静かに進行しており、成熟点に達しています。

この変革は、既存のデータベースをコンテナ化する取り組みから始まり、最初はゆっくりと行われました。これは、単一のコンピューティング ノードで実行される小規模なデータベースや、Apache Cassandra や DynamoDB などのクラウド ネイティブ環境で設計されたデータベースでは比較的うまく機能しましたが、課題は残っていました。

過去 2 ～ 3 年間で、新世代のデータベースが登場しました。これらの「Kubernetes ネイティブ」データベースは、このオープンソース オーケストレーション システムで実行できるようにゼロから設計されています。

ここでは、データベースを Kubernetes ネイティブにする性質と、Kubernetes ネイティブ データベースを採用する利点を定義します。そのために、Kubernetes ネイティブ ラベルを主張する 2 つのデータベース、TiDB と DataStax Astra DB を見ていきます。

TiDB を使用した Kubernetes ネイティブ MySQL

まず、リレーショナルに重点を置いたデータベースを調べてみましょう: TiDB (Titanium Database の略)。 TiDB は PingCAP によって構築されたオープンソース システムであり、 MySQL 互換データベースと、ハイブリッド トランザクションおよび分析処理 (略して HTAP と呼ばれる) をサポートする列型データベースを提供します。

以下の図 1 に示すように、TiDB にはマイクロサービス設計があります。 TiDB クエリ レイヤー、TiKV MySQL データベース、TiFlash カラムナ データベース、Spark ノード、およびメタデータ管理は、それぞれクラスター内のスケーラブルなマイクロサービスとしてデプロイされます。この設計では、クエリ レイヤーとデータベース レイヤーが個別にスケーラブルであるため、コンピューティング集中型の作業とストレージ集中型の作業が分離されます。

TiDB 作成者が行った 1 つの重要なコミットメントは、データベースが Kubernetes 上でのみ実行されることでした。

それは Kubernetes ネイティブにするのに十分ですか?

もう少し掘り下げてみましょう。

まず、TiDB はカスタム リソース(CRD) を使用して Kubernetes オペレーターによってデプロイおよび管理されます。 TiDB CRD には TiDBCluster が含まれています。これにより、各マイクロサービスのスケーリングと構成、およびデータベース層コンポーネントが Kubernetes 永続ボリュームを介してストレージを使用する方法を指定できます。追加の CRD は、監視ツールを展開し、バックアップや復元などの運用タスクを管理するために使用されます。

TiDB には、デフォルトの K8s スケジューラと連携してよりアプリケーションを意識したスケジューリング決定を行う、オプションのスケジューラ拡張機能もあります。利用可能な場合に既存の Kubernetes 機能を使用することを強調することは、Kubernetes ネイティブ データベースの特徴です。

DataStax Astra DB を備えた Kubernetes ネイティブ Cassandra

ここで、別の Kubernetes ネイティブ データベースを見て、いくつかの類似点と相違点に注目してください。

Cassandraは非常にスケーラブルな NoSQL データベースであり、クラウド ネイティブであると主張した最初のデータベースの 1 つですが、Kubernetes に Cassandra をデプロイするとどうなるでしょうか?

DataStax Astra DB は、図 2 に示すように、マイクロサービスに組み込まれた Cassandra のバージョンです。

TiDB と同様に、データベースには、ID とアクセス制御、データ修復、バックアップ/復元のためのサービスだけでなく、クエリ処理とデータ ストレージに関係するマイクロサービスも含まれています。

データ サービスは、 ストレージの使用において特に興味深いものであり、Kubernetes Persistent Volumes はキャッシングのみに使用され、オブジェクト ストレージは長期的な永続性に使用されます。圧縮をサービスに分離することで、読み取りおよび書き込みトラフィックを処理するデータ サービスのパフォーマンスに影響を与えることなく、この計算集約型の処理をバックグラウンドで実行できます。

Astra DB は、複数のクラウド リージョンで利用できるマネージド サービスとして提供されます。各リージョンには、Kubernetes オペレーターによって管理される上記のサービスで構成されるデータ プレーンと、可観測性のためのKube-Promethusスタックやメタデータ管理のためのetcd などのインフラストラクチャ サービスが含まれます。

データ プレーンは、1 つ以上のクラウドで実行できるコントロール プレーンによって管理され、顧客のアカウントとデータベースを管理し、新しいリージョンで Kubernetes クラスターをプロビジョニングします。

Astra DB の新しい側面の 1 つは、複数のユーザー データベースが同じマイクロサービスとサポート インフラストラクチャを共有できるマルチテナント アーキテクチャであり、小規模ユーザーのユニット エコノミクスを低下させます。

ユーザーがアプリケーションを拡張するにつれて、専用のリソースに移行して、すべて「従量制」ベースで最適なパフォーマンスを大規模に実現できます。

Kubernetes ネイティブ データベースの原則

TiDB と Astra DB の観察に基づいて、データベースを Kubernetes ネイティブにする理由についていくつかのアイデアを導き出すことができます。これらの多くは、以前の記事で説明したクラウド ネイティブ データの原則のリストに対応しています。

• 構成可能なマイクロサービス アーキテクチャ:まず、構成要素のマイクロサービスに分割されたデータベースにより、各サービスを個別にスケーリングできます。特にマルチテナント設計と組み合わせた場合、一部の種類のコンピューティング集約型処理は、真のサーバーレス ソリューションのためにゼロにスケーリングされることさえあります。
• コンピューティング、ネットワーク、およびストレージを商品として扱う: Kubernetes ネイティブ データベースで構成されるマイクロサービスは、クラウド ネイティブ アプリケーションの基本的なリソースを管理するために Kubernetes API を最大限に活用する必要があります。StatefulSet などのコンピューティング リソースと、ワークロードを管理するためのデプロイ、永続ボリューム サブシステムストレージ、Kubernetes イングレス、データへのネットワーク アクセスを公開するためのサービスなど。これには、重複する機能を持つコンポーネントを持ち込む代わりに、メタデータ管理用の etcd など、Kubernetes に既に存在する機能を活用することが含まれます。
• Kubernetes のベスト プラクティスを活用する: Kubernetes アプリケーションの一般的なパターンに従うと、複数の運用上の利点が得られます。デフォルトでは、Kubernetes 自体が、安全性を確保する方法についてデータベースが従うべき優れた例を示しています。Kubernetes Secret を使用してセキュリティ資格情報を配布し、必要に応じてポートのみを公開するなどです。
• オペレーターによる宣言型管理: Kubernetes ネイティブ データベースは、従来のデータベース管理 UI と CLI に依存するのではなく、オペレーターとカスタム リソースを介した宣言型管理の Kubernetes 原則を具現化する必要があります。必要に応じて、スケジューラ拡張機能などの Kubernetes 拡張ポイントを使用して、アプリケーション固有の動作を追加できます。目標は、データ プレーン機能 (データの管理) をコントロール プレーン機能 (データベースの管理) から明確に分離することです。

これらの原則を忠実に採用するデータベースやその他のデータ インフラストラクチャは、あらゆる規模で最適なコストを実現するための高性能、市場投入までの時間の短縮につながる運用の複雑さの軽減、今日の高可用性とセキュリティの要求を満たす標準準拠のソリューションなどの利点をもたらします。

Kubernetes ネイティブ データ インフラストラクチャの未来

まだまだ多くの進歩が必要であり、それはデータベースだけに限ったことではありません。 Kubernetes ネイティブの原則は、ストリーミング、分析、機械学習など、他のタイプのデータ インフラストラクチャにも適用できます。

Kubernetes ネイティブ ソリューションは、マルチクラスターとマルチクラウドの展開で引き続き進歩を遂げ、グローバルにスケーリングし、マルチテナンシーとサーバーレスの原則を採用して、コストを最適化します。

Kubernetes 自体には、StatefulSet の柔軟性とマルチクラスター フェデレーションのサポートを追加する点で改善の余地があります。

継続的な進歩の鍵は、オープンなコラボレーションです。 Data on Kubernetes Community は、データ集約型アプリケーションのビルダーとそれらをサポートするインフラストラクチャを結集する、非常にアクティブなデータ オタクのグループです。

複数のデータベースを管理できる再利用可能なオペレーターの開発や、バックアップ/復元やデータの読み込みなどの概念のための共通の CRD セットの定義などのアイデアについてお話しください。私たちは共に、すべての人々の利益のためにクラウド コンピューティングの地平を押し進めていきます。

2023 年 3 月 14 日に開催されるCassandra Forwardデジタル サミットで、Kassandra ネイティブ データベースなどの詳細をご覧ください。

この記事は、Jeff Carpenter と Patrick McFadin によるO'Reilly の書籍「 Managing Cloud Native Data on Kubernetes 」の第 7 章「The Kubernetes Native Database」に基づいています。

[

ジェフ・カーペンター、DataStax

Jeff Carpenter は、複数の業界でソフトウェア エンジニアおよびアーキテクトとして働き、DataStax では開発者の支持者として、エンジニアが Apache Cassandra で成功するのを支援してきました。 Stargate や K8ssandra など、Cassandra および Kubernetes エコシステムの複数のオープン ソース プロジェクトに携わっています。彼は、O'Reilly の著書「Cassandra: The Definitive Guide」と「Managing Cloud Native Data on Kubernetes」の共著者です。