TiDB ServerlessとTiDB Cloud(Dedicated)どちらがいいのだろう？
はじめに
PingCAPの小板橋です。はじめまして！
TiDBの入門記事から上級者編を取り扱う本アカウント第2回目はTiDB ServerlessとTiDB Cloud(Dedicated)どちらがいいのだろう？という問いに答えていきたいと思います。
TiDB ServerlessとTiDB Cloud(Dedicated)の違いは？
TiDBには、3つのラインナップが存在します。
- TiDB Serverless
- TiDB Cloud(Dedicated)
- OSSで公開されているTiDB(Self-host)
今回は、このうちTiDB ServerlessとTiDB Cloud(Dedicated)の違いについてを比較していこうと思います。
なお、比較するのは現時点(2024年4月2日時点のものになります。)
そもそもTiDBのアーキテクチャ
まず、TiDBのアーキテクチャとしては3つのコンポーネントに分かれます。
- TiDB サーバ
- ストレージサーバ (TiKV サーバ / TiFlash サーバ)
- PD(Placement Driver) サーバー
PD(Placement Driver) サーバー
PDサーバーは、クラスター全体のメタデータ管理や、クラスター全般の管理を行う頭脳で領域を管理します。
また、データの配置の管理[Data location（Region）]も管理したり、分散トランザクションにおけるトランザクションを割り当てるための「TSO」の発行したり、Raftグループの管理を行います。
このPDサーバについては、少なくとも3つのノードで構成され、高可用性を保持しています。
【Region】
Regionとは、TiDBの最小単位で1テーブル作成時に1つ作成される領域になります。
【TSO】
TSOとは、「Timestamp Oracle」の略で、クラスター全体でユニークになるタイムスタンプで必ず昇順で発行し、TiKVのトランザクションで使用します。
TiDB サーバー
- TiDBサーバーは、SQLリクエストを受信した後にSQLの解析を行い、最適化をした後に実行プランを作成します。この分析処理が終わった後に実際のデータを読み取るためのリクエストをストレージノード(TiKVノード / TiFlashノード)に送ります。
処理としては、下記の処理を行います。
- Parser: SQLの構文を解析
- Optimizer: クエリプランを計画
- Executor: SQLステートメントを実行
また、TiDBサーバーの仕組みとしては、ステートレスなのでデータを持たない形になります。
だから、TiDBサーバーについてはいくらでも横にスケールができるというのもあります。
ストレージサーバー (TiKV サーバー / TiFlash サーバー)
ストレージサーバについては、先ほども述べたように2つの種類があります。
TiKVサーバ
TiKVは、分散トランザクションのキーと値を保持するストレージエンジンです。
各リージョンには、StartKey から EndKey までの特定のキー範囲のデータが格納されています。
このリージョンというのは、論理的にバケットと呼ばれる小さな範囲に分割されているものを指します。TiKV はバケットごとにクエリ統計を収集し、バケットの状況をPDサーバに報告します。
TiFlashサーバ
TiFlash はデータを列ごとに保存し、主に分析処理を高速化するように設計されています。
TiDB Serverless
TiDB Serverlessがどのようなものなのかについて見ていきましょう。
上記で、触れたTiDBの基本コンポーネントがある前提でになります。
構成
現時点においては、シングルAZのみ
コスト
コストに関しては、利用に合わせた従量課金になります。
従量課金の仕組みなのですが、非常に複雑で、主に書き込み、読み込みそれぞれの処理に対して、および、SQLに対するCPUやネットーワークプロセスに対して、Request Unit (RU)という考え方で課金が行われる+ストレージ量によって課金が行われます。
Request Unit (RU) とは？
リクエストユニット (RU) とは、データベースへの1つのリクエストにつき消費されるリソースの量を表すために使用される単位を指しています。
リクエストによって消費されるRUの量は、操作の種類や取得または変更されるデータの量などに依存します。
詳しいコストの計算については下記をご覧ください。
ストレージ/vCPU
次にストレージ/vCPUについてなのですが、TiDB Serverlessでは、ストレージは無料枠として1ヶ月間、行ベースのデータ5GiBと列ベースのデータ5GiBを同時に保存できます。そこから先は、先ほどの受領課金に依存します。
vCPUに関しては、共有vCPUを割り当てて使う形のマルチテナントの形になります。
この仕様は、この後説明するTiDB Serverlessにおけるアーキテクチャに依存しているからです。
スケーラビリティ
スケーラビリティの観点だと、TiDB Serverlessではユーザがスケールの設定をしないAutoスケールの形となります。
接続方式
接続方式については、Public接続およびPrivate Endpointの２つとなります。
これもこの後説明するアーキテクチャに依存している為です。
下記は、AWS におけるプライベートエンドポイント経由で TiDB Serverless に接続する例になります。
TiDB Serverlessでは、この AWS VPC でホストされているTiDB CloudサービスへのAWS Private Link経由でのアクセスにより、あたかもそのサービスが独自のVPC内にあるかのような接続を実現することができます。
※ 注意
- リージョン間のプライベート エンドポイント接続はサポートされていません。
-
また、現時点では、エンドポイントサービスが AWS でホストされている場合にのみ、TiDB Serverless へのプライベート エンドポイント接続をサポートしています。
なので、サービスが Google Cloud でホストされている場合、プライベート エンドポイントは適用できません。 - また、仕組み上VPC Peeringもすることができません。
TiDB Serverlessの制限とクォータ
TiDB ServerlessはTiDBCLoudやセルフホストとは一部機能に制限があります。
例えば、下記のようなものです。
-
Audit logは現時点では利用できません。
-
VPC Peeringを使用して TiDB Serverless クラスターに接続することはできません。
-
顧客管理の暗号化キー (CMEK)の使用は現在利用できません。
-
サードパーティーの監視ツール(Datadog, Prometheus と Grafana, New Relic)とはインテグレーションすることができません。
https://docs.pingcap.com/ja/tidbcloud/third-party-monitoring-integrations -
組み込まれているアラートも使うことができません。
https://docs.pingcap.com/ja/tidbcloud/monitor-built-in-alerting -
Index Insightや、クラスタイベントといったものも使えません。
-
あとは、TiDB Cloudで利用できるデータマイグレーションツールなども利用できないです。
-
TTLといった機能も利用できません
クォータ制限としては、5つのクラスターを無料で使用することができ、6つ目のクラスターを作成する場合際は、クレジットカードの追加が必要です。
無料枠としては、行ベースのデータ5GiBを保存可能/列ベースのデータ5GiBを保存可能で、5000万RUを消費することが可能となります。
使用限度額を設定していない場合は、デフォルトで、クラスタの読み込みおよび書き込み操作は100RU/秒にスロットルされます。
使用限度額にぶち当たる、例えば、行ベースのストレージが5GiBに達するか、列ベースのストレージが5GiBに達するか、またはクラスタの無料クォータが月内に使い果たされるかのいずれかで、クラスタは自動的に10RU/秒にスロットルされます。(ほぼ使い物になりません。)
TiDB Serverlessのアーキテクチャ
最後に、TiDB Serverlessのアーキテクチャについてを説明していきます。
基本は、TiDBのアーキテクチャを現時点ではAWS上のみでTiDB Serverlessとして実現しています。
実現する大きな要は、Amazon S3 と Amazon EBS。
- S3 を中心としたストレージ層の設計を行い、先ほどのTiDBの主要なコンポーネントであるストレージ層のTiKVとTiFlashをS3に直接書き込み、それを共有ストレージとして使用します。共有ストレージというのが大きなポイントです。
- 先ほども述べたようにTiDB Serverlessはマルチテナントの形をとっています。そうするとなぜ、VPC Peeringなどが使えないのかは分かるかと思います。
また、下記の図のようにTiDB はほとんどのデータをS3に保存する一方で、EBS がメタデータや先行書き込みログなどのレイテンシに敏感な重要な情報を保存する実装になっています。
これは、TiKVで実装されている、少数ノードの損失を許容できる Raft コンセンサス プロトコルを使用していることに依存します。これ何をいっているかというと、たとえば、3 つのレプリカがある時TiDB は 1 つのレプリカの損失を許容することができます。
また、データベースは、可用性と耐久性を強化するために、異なるAZにレプリカを意図的に分散します。
TiDB Cloud(Dedicated)
TiDB Cloud(Dedicated)がどのようなものなのかについて見ていきましょう。
上記で、触れたTiDBの基本コンポーネントがある前提でになります。
基本、TiDB Cloud(Dedicated)については、お客様ごとの専用VPC内に構築するクラウド型のマネージドサービスになります。
選択できるパブリッククラウド
現時点ですと、AWSとGoogle Cloudの２つとなります。
構成
構成としては、マルチAZ構成となります。
機能
ほぼ全ての機能を使用することができます。
コスト
無償枠はありませんが、インスタンスタイプ/ディスクサイズによって月額コストが変化するそんなモデルになっています。
ストレージ/vCPU
1ノードあたり 最大6TiB / 最大32vCPUになります。
スケーラビリティ
スケールについては、GUI上で実施する若しくは、APIが提供されているので、そちらを利用しスケールさせていきます。
ここも自動化したい場合は、TiDB Cloud(Dedicated)ではアラート情報やモニタリングツールとのインテグレーションができるので、その情報を利用しAPI経由でスケールさせる場合が多いです。
接続方式
接続方式としては、Public接続と、Private接続として(VPC Peering および Private Endpoint)を選択することができます。
ではどちらがいいのだろう？
それは、使うユースケースによるという答えになります！(そりゃあそうだという感じですがw)
たた、よくユースケースとして使われる方は、検証時は、TiDB ServerlessをFreeで、開発環境ではTiDB Serverlessを従量課金で使用し、実際に検証/本番環境で利用する場合は、TiDB Cloud(Dedicated)を使うそんな使い分けをされることが多いような印象を受けます。
機能や制約を抑えつつ、検討するのが良さそうです！
まとめ
いかがだったでしょうか？
TiDBの世界は奥が深いです。引き続き様々な機能についてを深掘りブログ化していきたいと思います。
公式ドキュメント/ブログ
Discussion