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

「クラウド コンピューティング アーキテクチャにおけるクラウド TiDB の技術的秘密 (パート 1)」では、TiDB と従来のスタンドアロン リレーショナル データベースの違い、および複数のテクノロジを統合した後に形成される全体的なアーキテクチャを分析しました。次に、Cloud TiDB の主な機能と実装の詳細について詳しく説明します。

自動化された運用とメンテナンス

データベース製品をクラウドに移行するための前提条件は、自動化された運用および保守管理を実装できることです。クラウド上での手動による運用と保守はほぼ非現実的だからです。最初のステップは、Kubernetes を使用してクラウド プラットフォームのホスト リソースを管理し、大規模なリソース プールを形成することです。 2 番目のステップでは、tidb-operator や tidb-cloud-manager などのコンポーネントを使用して、TiDB インスタンスのワンクリック展開、容量の拡張と削減、オンライン ローリング アップグレード、自動フェイルオーバーなどの運用および保守操作を自動的に完了します。

• クラスターの作成を見てみましょう。前の記事で述べたように、TiDB は tidb、tikv、pd という 3 つのコア コンポーネントで構成されています。各サービスはマルチノード分散構造になっており、サービスの起動順序には依存関係があります。また、pd ノードを作成して参加する方法は etcd と似ています。最初に単一ノードの初期クラスターを作成し、次に特別な方法でノードに参加する必要があります。起動コマンドにも違いがあります。

いくつかの操作が完了したら、通知のために API を呼び出す必要があります。 Kubernetes 自体が提供する StatefulSet ではこのような複雑なデプロイメントを処理することは難しいため、この一連の操作を完了するには tidb-operator に特定のコントローラーを実装する必要があります。同時に、Kubernetes の強力なスケジューリング機能と組み合わせることで、クラスター全体のリソースが合理的に計画および割り当てられ、新しく展開された TiDB インスタンス ノードはクラスター内で可能な限り均等に分散され、最終的に LB を通じて対応するテナントに公開されます。

• オンラインアップグレードも同様です。 tikv/pd の Pod マウントはローカルストレージなので、クラウドプラットフォームが提供するブロックストレージやネットワークファイルシステムのように任意にマウントすることはできません。 tikv/pd が他のノードに移行されると、データ ディレクトリもクリアされるため、アップグレードが完了した後も tikv/pd Pod が元の場所にスケジュールされるようにする必要があります。これは、tidb-operator のコントローラーによっても保証されます。

Raft アルゴリズムは、TiDB のデータ レプリカ間の一貫性を確保するために使用されます。クラスター内のノードが一時的に切断されても、サービス全体には影響しません。したがって、クラスターのアップグレード プロセス中は、サービス依存関係に厳密に従って Pod をアップグレードする必要があります。

• ノードに障害が発生した場合、ローカル データ ディスクがマウントされているため、StatefulSet のように Pod を直接移行することはできません。 TiDB Operator はノード障害を検出すると、移行および回復操作を開始する前に、ノードが回復しないことを確認するためにしばらく待機します。

まず、スケジューラはポッドを起動するための新しいノードを選択し、次に障害が発生したノードを放棄して新しく起動したポッドをクラスターに追加するように TiDB に通知します。その後、TiDB の PD モジュールはデータ コピーの数を復元し、データを新しいノードに移行して、クラスター内のデータ バランスを復元します。

上記は、TiDB の一般的な運用および保守プロセスの一部のみを示しています。実際の生産運用や保守においては、考慮しなければならないケースが数多くあります。これらはすべて、tidb-operator でプログラム的に実装されています。 Kubernetes と tidb-operator は、手作業を置き換え、クラウド プラットフォーム上の TiDB データベースの複雑な運用と保守管理を効率的に完了するために使用されます。

（図：Cloud TiDB 全体アーキテクチャ図）

動的スケーリング

弾力的な水平スケーリングは、TiDB データベースの最も重要な機能の 1 つです。ビッグデータの時代において、人々のデータストレージに対する需要は急速に拡大しています。ユーザーにとって、自社のビジネス規模の成長率を予測することが難しい場合があります。従来のストレージ ソリューションを使用すると、ストレージ容量がボトルネックに達し、移行と拡張のためにシャットダウンしなければならないことがすぐに判明する可能性があります。 Cloud TiDB ソリューションを使用すると、このプロセスは非常に簡単になります。ビジネスの通常サービスに影響を与えることなく、拡張操作を迅速に完了するには、クラウド コンソールで TiDB ノードの数を変更するだけです。

次に、クラウドのバックグラウンドで、Kubernetes と tidb-operator の機能を使用して、TiDB ノードの増減操作を完了することもできます。 Kubernetes 自体の動作は、Reconcile メカニズムに基づいています。簡単に言えば、たとえば、ユーザーがクラスター内で 5 つの TiKV ノードを実行することを期待して新しいリクエストを送信したが、現在実行されているのは 3 つだけである場合、調整メカニズムはこの違いを検出します。 Kubernetes スケジューラは、まずクラスターの全体的なリソース状況に基づいて、TiDB ノード割り当てのアフィニティ原則とリソース分離原則と組み合わせてノードを割り当てます。もう 1 つの重要なポイントは、アイドル状態のローカル PV を持つマシンを選択して Pod を作成し、マウントし、最後に tidb-operator を介して 2 つのノードを TiDB クラスターに追加することです。

縮小のプロセスも同様です。データベースに保存されるデータの総量が減少した場合、コストを節約するためにノードの数を減らす必要があります。まず、ユーザーはクラウド コンソールを通じてバックエンドにリクエストを送信します。調整サイクル中に差異が見つかった場合、tidb-operator のコントローラーは TiDB クラスターにノードのオフライン操作を実行するように通知し始めます。安全なオフラインは、PD モジュールがオフライン ノードのデータを他のノードに移動する必要があるため、比較的長いプロセスになる可能性があります。その間、クラスターは通常のサービスを提供できます。オフライン プロセスが完了すると、これらの TiKV は tombstone 状態になり、tidb-operator は Kubernetes にこれらの Pod を破棄するように通知し、tidb-volume-manager はローカル PV をリサイクルします。

リソースの分離

リソースの分離もクラウド ユーザーにとって懸念事項です。特に、データベース、異なるテナントのデータベース インスタンス、またはテナントの複数のデータベース インスタンスなどのアプリケーションはすべて、大規模な Kubernetes 管理クラスター上で実行されます。それらの間でリソースの競合は発生しますか?インスタンスが高負荷のコンピューティング タスクを実行する場合、CPU、メモリ、I/O などが同じマシンにデプロイされている他のインスタンスに影響を与えますか?

実際、コンテナ自体がリソース分離のソリューションです。コンテナの基盤となる技術は、Linux カーネルが提供する cgroups であり、コンテナ内の CPU、メモリ、IO などのリソースの使用を制限し、名前空間技術を通じて分離を実現するために使用されます。コンテナ オーケストレーション システムとして、Kubernetes はクラスター内の各ノードのリソース ステータスに基づいてコンテナをスケジュールするための最適な戦略を選択できます。同時に、tidb-operator は TiDB 自身の特性と制約に基づいて、TiDB ノードのスケジュールと割り当てに関する包括的な決定を行います。

たとえば、Kubernetes クラスターが複数のアベイラビリティ ゾーンにまたがっていて、ユーザーが TiDB クラスターの作成を申請すると、まず高可用性の原則に基づいて、ストレージ ノードが可能な限り異なるアベイラビリティ ゾーンに割り当てられ、TiKV がラベル付けされます。次に、クラスター リソースを最大限に活用するために、同じ可用性ゾーン内の同じ物理ノードに複数の TiKV をデプロイしないようにしてください。

さらに、各ローカル PV も独立したディスクであり、各 TiKV Pod は異なるディスクをマウントするため、I/O も完全に分離されます。

Kubernetes では、Pod 間のアフィニティと反アフィニティを構成することもできます。たとえば、TiKV と TiDB の間では、アフィニティを使用してネットワーク遅延が小さいノードにスケジュールすることで、ネットワーク伝送効率を向上させることができます。アンチアフィニティの助けを借りて、TiKV はさまざまなホスト、ラック、および可用性ゾーンに展開され、ハードウェアまたはコンピューター ルームの障害によるデータ損失のリスクを軽減します。

上記で説明したコンテナ層での分離は、物理層での分離とも言えます。データ層の分離を見てみましょう。 TiDB のスケジューリング システムもこれを考慮に入れています。たとえば、大規模な TiDB クラスターでは、ノードは複数のラックと可用性ゾーンにまたがる多数のホストに分散されます。次に、ユーザーは論理的な概念である名前空間を定義できます。異なるビジネスのデータベースとテーブルは、異なる名前空間に配置されます。 PD モジュールは、ネームスペース、TiKV ノード、およびリージョン間の対応関係を構成することでスケジューリングを実行し、さまざまなビジネス データの物理的な分離を実現します。

高可用性

分散データベースである TiDB 自体は高可用性を備えており、各コア コンポーネントは個別にスケールアップまたはスケールダウンできます。任意のモジュールの複数のコピーを展開すると、1 つのコピーに障害が発生しても、モジュール全体は引き続き正常にサービスを提供できます。これは Raft プロトコルによって保証されます。ただし、データベース ノードのスケジュールに制限がない場合、データの複数のコピーを含むノードが同じホストにスケジュールされる可能性があります。この時点でホストに障害が発生すると、複数のレプリカが同時に失われます。 Raft グループ内の過半数ノードが失われると、クラスター全体が使用できなくなります。したがって、tidb-operator は TiKV ノードをスケジュールするときにこの状況を回避する必要があります。

さらに、TiDB はラベルベースのデータ スケジューリングをサポートしており、リージョン、アベイラビリティ ゾーン (AZ)、ラック、ホストなどのさまざまな TiKV インスタンスに物理情報を記述するラベルを追加できます。 PD はデータをスケジュールするときに、この情報を参照して、よりインテリジェントにスケジュール戦略を策定し、データの可用性を最大限に確保します。

たとえば、PD はラベル情報に基づいて、同じデータのコピーを異なるホスト、ラック、可用性ゾーン、およびリージョンに配布しようとします。こうすることで、物理ノードに障害が発生したり、ラックの電源が失われたり、コンピューター ルームに障害が発生したりしても、他の場所にデータのコピーが十分に残ります。 tidb-operator のコントローラー マネージャー コンポーネントを使用すると、物理トポロジの場所ラベルを TiKV インスタンスに自動的に追加できるため、PD のインテリジェントなデータ スケジューリング機能が最大限に活用され、データ レベルでの高可用性が実現します。

同時に、インスタンス レベルで高可用性を実現できます。 Kubernetes の強力なスケジューリング ルールと拡張スケジューラにより、TiKV は優先度に応じてさまざまなホスト、ラック、アベイラビリティ ゾーンにデプロイされ、ホスト、ラック、コンピューター ルームの問題による影響を最小限に抑え、最大限のデータ可用性を確保します。

また、Kubernetes上で動作することで、TiDBの各コンポーネントの動作状況をリアルタイムに監視することができます。問題が発生した場合、tidb-operator はできるだけ早くクラスターを自動的に修復 (自己修復) できます。具体的には、tidb/tikv/pd インスタンスに障害が発生すると、安全なオフライン操作が実行され、クラスターのスケールが以前のものと一致するように新しいインスタンスが追加されます。

まとめ

クラウド ネイティブ データベースである TiDB は、tidb-operator を通じて Kubernetes プラットフォームの強力な機能を最大限に活用し、クラウド上での自動管理を実現し、人的運用と保守のコストを大幅に削減します。ユーザーはビジネス ニーズに応じて容量を動的に拡張または縮小できます。マルチテナント分離機能により、異なるテナントのインスタンスが相互に干渉することなくコンピューティング リソースとストレージ リソースを共有し、クラウド リソースを最大限に活用できます。 Raft アルゴリズム、tidb オペレーターの自動修復機能、および 2 層スケジューリング メカニズムにより、Cloud TiDB の高可用性が保証されます。

UCloud と PingCAP が緊密な協力を通じて立ち上げた Cloud TiDB 製品が、現在パブリック ベータ版として公開されています。クラウド コンピューティング アーキテクチャに基づく新世代のデータベースを、どなたでも体験していただけます。