クラウド コンピューティング アーキテクチャにおける Cloud TiDB の技術的秘密 (パート 1)

最近、中国を代表する中立型クラウドコンピューティングサービスプロバイダーであるUCloudと、国内のオープンソース分散型NewSQLデータベースTiDBチームであるPingCAPが正式に協力関係に至りました。両者は共同で、UCloud のグローバル データ センターで次世代 TiDB のクラウド バージョンである Cloud TiDB を立ち上げました。

クラウドネイティブ データベースとして、TiDB はクラウド統合において段階的な進歩を遂げてきました。 Cloud TiDB 製品は、UCloud プラットフォーム上でパブリック ベータ テストを正式に開始しました。 TiDB の柔軟なスケーリング機能は、クラウドが提供するインフラストラクチャのサポートにより完全に実証されています。

クラウド データベースの魅力を楽しみながら、TiDB とクラウドの背後にある技術的な秘密を探ってみましょう。

TiDBと従来のスタンドアロンリレーショナルデータベースの違い

まず、TiDB のアーキテクチャについて説明します。オープンソースの分散データベース製品である TiDB は、複数のコピー間で強力な一貫性を持ち、ビジネスニーズに応じて非常に便利に弾力的に拡張でき、拡張および縮小時に上位レベルのビジネスに影響を与えません。

TiDB の主なアーキテクチャは、Github の PingCAP 組織の 3 つのオープン ソース プロジェクト (TiDB / TiKV / PD) に対応する 3 つのモジュールで構成されています。

1. TiDB は主に、コンピューティング実行層に相当する SQL パーサーとオプティマイザーを担当し、クライアント アクセスと対話も担当します。

2. TiKV は、データベース全体のストレージ層として機能する分散型キー値ストレージ エンジンです。このレイヤーでは、データの水平拡張とマルチコピーの高可用性機能が実装されています。

3.PD は分散データベースの頭脳に相当します。一方では、各 TiKV ノードでのデータの収集と分散の維持を担当します。一方、PD はスケジューラの役割を果たし、データ分散状況や各ストレージノードの負荷に応じて適切なスケジューリング戦略を採用し、システム全体のバランスと安定性を維持します。

上記の 3 つのモジュールの各ロールは複数のノードで構成されるクラスターであるため、最終的な TiDB アーキテクチャは次の図のようになります。

分散システム自体の複雑さにより、手動での導入や運用・保守にかかるコストが高くなるだけでなく、エラーが発生しやすくなることがわかります。従来の自動デプロイメントおよび運用・保守ツール (Puppet/Chef/SaltStack/Ansible など) には状態管理機能がないため、ノードに問題が発生した場合にフェイルオーバーをタイムリーに自動的に完了することができません。運用および保守担当者による手動介入が必要です。一部のツールでは、大量の DSL を記述したり、シェル スクリプトと組み合わせたりする必要があります。携帯性が悪く、メンテナンスコストも高くなります。

クラウド時代において、コンテナはアプリケーションの配布と展開の基本単位となっています。 Google が数十年にわたって社内でコンテナ オーケストレーション システム Borg を使用してきた経験に基づき、オープンソースのコンテナ オーケストレーション システム Kubernetes が現在のコンテナ オーケストレーション テクノロジーの主流となっています。

TiDBとKubernetesの緊密な統合

クラウド ネイティブ データベースである TiDB は、コンテナ テクノロジーを採用し、Kubernetes と深く統合されているため、Kubernetes に基づくデータベース自動化管理を完了するのが非常に便利になります。 Kubernetes プロジェクトはクラウドのために生まれたとも言え、クラウド プラットフォームの IaaS 層が提供する API を使用することで、クラウドと簡単に統合できます。このように、TiDB が Kubernetes とより適切に統合されれば、さまざまなクラウド プラットフォームと統合でき、クラウド上での TiDB の迅速な導入と効率的な運用・保守が実現します。

1. Kubernetes の紹介

Kubernetes は、最初は純粋なコンテナ オーケストレーション システムとして作成されました。ユーザーは Kubernetes クラスターをデプロイした後、その組み込み関数を直接使用してアプリケーション サービスをデプロイできます。このPaaSプラットフォームは非常に使い勝手が良いため、多くのユーザーを魅了しています。さまざまなユーザーからさまざまな要件が提示されています。一部の機能では、Kubernetes をコア コードに直接実装する必要がありますが、一部の機能はメイン ブランチにマージするのに適していません。

このようなニーズを満たすために、Kubernetes はユーザーが拡張して独自のニーズを実現できるようにいくつかの API を公開しています。現在、Kubernetes はバージョン 1.8 にアップグレードされ、内部 API もますますオープンになり、クラウド上で動作するオペレーティング システムのような存在になっています。ユーザーはこれをクラウド SDK またはフレームワークとして使用し、独自のビジネス ニーズを拡張して満たすコンポーネントを簡単に開発できます。ステートフル サービスのサポートは代表的な例です。

初期の頃、Kubernetes プロジェクトはステートレス サービス管理のみをサポートしていました。ステートレス サービスは ReplicationController を通じて複数のレプリカを定義し、Kubernetes スケジューラは負荷分散とフェイルオーバーを実現するために異なるノードで複数の Pod を起動することを決定しました。ステートレス サービスの場合、複数のレプリカに対応する Pod は同等であるため、ノードに障害が発生した場合、新しいノードで Pod を起動することは、障害が発生した Pod を起動することと同等であり、状態移行の問題は発生しないため、管理は非常に簡単です。

2. ステートフルサービス

ただし、ステートフル サービスの場合、データをディスクに永続化する必要があるため、異なる Pod を同等と見なすことはできなくなり、ステートレス サービスのように任意にスケジュールしたり移行したりすることはできなくなります。 Kubernetes v1.3 では、ステートフル サービスを管理するための PetSet の概念が導入され、v1.5 で StatefulSet に名前が変更されました。

StatefulSet は、Pod セット内の各 ID を明示的に定義し、特定の順序で Pod を起動および更新します。さらに、永続ボリュームストレージ (PersistentVolume) は、データを保存するためのキャリアとして使用されます。ノードに障害が発生し、Pod を移行する必要がある場合、対応する PV は umount/mount メソッドを通じて新しいノードに移行されるか、分散ファイル システムが PV の基盤となるストレージとして直接使用されるため、移行後も Pod は以前のデータにアクセスできます。

同時に、Pod が移行されると、そのネットワーク ID (IP アドレスなど) が変更されます。多くの分散システムはこの状況を受け入れることができません。したがって、Pod を移行するときに、StatefulSet はドメイン名をバインドして、クラスター内の Pod のネットワーク ID が変更されないようにすることができます。

しかし、現実には、一部の分散システムはより複雑であり、StatefulSet だけでは不十分です。たとえば、一部の分散システム ノードでは、クラスターに参加したりオフラインになったりするときに追加の登録およびクリーンアップ操作を実行したり、ローリング アップグレード中にバージョンの互換性やその他の問題を考慮したりする必要があります。

上記の理由に基づいて、CoreOS は Operator コンセプトを提案し、Etcd や Prometheus などの複雑な分散システムを管理するために etcd-operator と prometheus-operator を実装しました。ユーザーは独自のオペレーターを開発し、Kubernetes 上にカスタム コントローラーを実装し、ステートフル サービスの分野で特定の運用知識をエンコードして、特定の分散システムの管理を実現できます。同時に、Operator 自体も Kubernetes で実行される Pod (デプロイメント) であり、Kubernetes システムに侵入することはありません。

3. TiDBマルチコンポーネントサポート

TiDB のような複雑な分散サービス向けに、Kubernetes プラットフォーム上の TiDB クラスター インスタンスの作成、破棄、スケーリング、ローリング アップグレード、フェイルオーバーを管理するための tidb-operator などの一連のコンポーネントを開発しました。同時に、上位層に tidb-cloud-manager コンポーネントがカプセル化され、RESTful インターフェースを提供し、クラウド プラットフォーム コンソールとの接続機能を実現します。これにより、DBaaS (Database as a Service) アーキテクチャの基本形式が完成します。

TiDB はディスク I/O の要件が比較的高いため、PV を介してネットワーク ディスクをマウントすると、パフォーマンスが大幅に低下します。さらに、TiKV 自体は、分散ファイル システムの複数のコピーと同様に、データの複数のコピーを保持します。そのため、Pod にローカルディスクをマウントし、Kubernetes 上のローカル PV を特定のリソースとして管理する必要があります。

Kubernetes は長い間、Local PV サポートを公式に提供しておらず、ローカル ストレージは hostPath と emptyDir のみをサポートしています。 hostPath のライフサイクルは Kubernetes 管理とは独立しています。 hostPath を使用する Pod が破棄された後、その中のデータは自動的にクリーンアップされず、次に Pod がマウントされたときにダーティ データが生成されます。 emptyDir は一時的なディスクのようなもので、Pod が再構築されるとクリーンアップされてリセットされ、永続的な PV として使用することはできません。

この目的のために、Kubernetes クラスター内の各物理ホスト上のローカル ディスクを管理し、それらを特別な PV リソースとして公開する tidb-volume-manager コンポーネントを開発しました。 TiDB ノードをデプロイする場合、オペレーターはローカル PV リソースを参照して、デプロイする特定のノードを選択し、ポッドにバインドする空のローカル PV を割り当てます。 Pod が破棄されると、特定の状況に基づいてローカル PV のライフサイクルを終了するかどうかが決定されます。 GC サイクルの後、解放されたローカル PV は tidb-volume-manager によってリサイクルされ、ディスク上のデータはクリーンアップされ、再度割り当てられて使用されるのを待機します。

Cloud TiDB の全体アーキテクチャ図

これらのコンポーネントを統合すると、上の図に示す全体的な Cloud TiDB アーキテクチャが形成されます。 Kubenetes によって管理されるクラスターでは、tidb-operator などのコンポーネントを通じてクラスター リソースがターゲットを絞って割り当てられ、使用されるため、TiDB クラスター インスタンスのライフサイクル管理が実現されます。このようにして、TiDB 分散データベースとクラウド プラットフォームの統合が実現されます。