商業銀行における分散データベース TiDB の設計と実践

リレーショナル データベースの開発には長い期間がかかっており、多くのトランザクションおよび分析データベース製品やテクノロジを含むこれらのデータベースは誰もがよく知っています。 TiDB 分散データベースは、オープンソースの分散 NewSQL データベースの新世代です。製品全体の構造は非常に明確で、コンピューティング層とデータストレージ層が分離されています。これは、ほとんどの最新の分散データ処理システムが通常採用し、考慮する傾向があるアーキテクチャです。

最下層「TiKV」は、分散データベースのストレージ エンジン層です。データへのアクセスと管理だけでなく、データに対する並列操作の実行にも使用されます。 TiKV の上には「TiDB」層があり、これは分散データベースの SQL エンジン層であり、接続セッション管理、権限制御、SQL 解析、オプティマイザー最適化、エグゼキューターなどのリレーショナル データベースのコア機能を処理します。さらに、クラスターの頭脳として機能する「PD」と呼ばれる集中型スケジューラがあります。同時に、展開、スケジュール、監視、バックアップなどを含むいくつかの運用および保守管理ツールが全体的なアーキテクチャに統合されます。

TiDB は、自動水平スケーリング、強力な一貫性を備えた分散トランザクション、Raft アルゴリズムに基づくマルチコピー レプリケーションなどの重要な NewSQL 機能を実現できるだけでなく、当行の高可用性、高パフォーマンス、高スケーラビリティの要件も満たしています。 TiDB は導入が簡単で、オンラインでの柔軟な拡張がビジネスに影響を与えません。マルチサイトのアクティブ/アクティブと自動障害回復により、データのセキュリティが確保されます。また、MySQL プロトコルと互換性があるため、移行コストが極めて低く抑えられます。本稿では、当行における TiDB の設計と実践について詳しく紹介します。

1. 設計目標

TiDB 分散データベース クラスターを設計する際には、要件のさまざまな側面を考慮する必要があります。そこで、プロジェクトの設計目標として以下の内容を策定しました。

2. ビジネス要件

1. ビジネスデータの推定

私たちが設計した TiDB 分散データベース クラスターは、第 1 フェーズでは、当銀行のコアとなる支払い取引システムであるビジネス システムをホストします。機器を購入する前に、事業展開の規模に応じて合理的な見積もりを行い、予想される1日の取引量、データサイズ、データ増加率などの情報を入手しました。

2. 設備需要予測

初年度のデータ量と日々のトランザクション量に基づいて機器要件が計画され、データのコピー数とディスク容量の空き状況が考慮されます。したがって、十分な冗長ストレージ容量を計画する必要があります。さらに、TiDB クラスターには、クラスターを一元的に管理するための中央制御マシン、クラスターを監視するための監視マシン、およびデータをバックアップするためのサーバーも必要です。したがって、これらのサーバーの計画も考慮する必要があります。

本番環境クラスターに加えて、オフサイトの災害復旧に使用するためのスレーブ クラスターも設計しました。実稼働クラスターと災害復旧クラスターは、binlog を通じてデータを同期します。 binlog 同期ツールとして Kafka を選択しました。そのため、Kafka サーバーの構成計画を検討する必要があります。

現時点では、当銀行の TiDB クラスターに必要な機器は次のように計画されています。

3. 全体的なアーキテクチャ設計

当社の TiDB クラスターは、2 サイト 3 センターのマルチアクティブ アーキテクチャを採用し、マスター スレーブ クラスターの災害復旧展開を設計しました。このセクションでは、アーキテクチャ設計について詳しく紹介します。

1. 論理アーキテクチャ設計

アーキテクチャの説明:

（１）クラスタ全体がマスタースレーブ構造を採用する。マスター クラスターは実稼働クラスターとして機能し、日常的な実稼働サービスを実行します。スレーブ クラスターは、binlog を介してマスター クラスターのデータを非同期的に同期し、災害復旧クラスターとして機能します。

（２）メインクラスター（本番クラスター）は、同一市内のIDC1、同一市内のIDC2、および別の場所のIDC3の2サイト3センターアーキテクチャを採用しています。

（３）スレーブクラスタとマスタークラスタはbinlogを介してデータ同期を完了する。

2. 物理的な場所の計画

（1）IDC1とIDC2はそれぞれ2つのキャビネットで構成されており、両方ともメインの運用クラスタを展開するために使用されます。 IDC3 には、メインの本番クラスターを展開するためのキャビネットが 1 つと、災害復旧スレーブ クラスターを展開するためのキャビネットがもう 1 つあります。

（２）各IDCは2台の10ギガビットスイッチ（マスタースレーブモードで展開）で構成されています。マスター クラスター内のマシン間の内部通信、スレーブ クラスター内のマシン間の内部通信、およびマスター クラスターとスレーブ クラスター間の内部通信はすべて 10 ギガビット ネットワークを使用します。

（３）３つのIDCのロードバランサはグローバルDNS配下に配置されている。各 IDC ロード バランサは、TiDB サーバーを独自のセンター内にマウントし、ギガビット ネットワーク環境で外部にビジネス サービスを提供します。

4. 運用・保守ソリューションの設計

1. 高可用性ソリューション

高可用性は、TiDB データベースの機能の 1 つです。 TiDB/TiKV/PD の 3 つのコンポーネントは、クラスター全体の可用性に影響を与えることなく、一部のインスタンスの障害を許容できます。当銀行の TiDB 運用クラスターは、運用センター、同じ市内の災害復旧センター、および別の場所にある災害復旧センターで構成されており、2 サイト、3 センター、マルチアクティブ、高可用性の展開ソリューションを共同で実装しています。次に、さまざまな側面からクラスターの高可用性を分析します。

（１）サーバーの役割の観点から

クラスター内のサーバーには、TiDB、TiKV、PD の 3 つの役割があります。これら 3 つの役割からクラスターの高可用性を分析します。

TiDB はステートレスであり、フロントエンドの負荷分散デバイスを通じてインスタンスごとに外部サービスを提供します。単一の TiDB インスタンスに障害が発生した場合、現在のインスタンスのセッションにのみ影響します。アプリケーション サービスへの単一の要求が失敗した場合、アプリケーションは他の TiDB インスタンスに再接続した後、引き続きサービスを取得できます。この時点で、インスタンスを削除して問題をトラブルシューティングするか、新しいインスタンスを再デプロイすることができます。

TiKV はクラスターにデプロイされ、Raft プロトコルを使用して複数のレプリカのデータの一貫性を維持し、PD を使用してデータ レベルで負荷分散スケジューリングを実行します。 1 つの TiKV ノードに障害が発生すると、このノードに保存されているすべてのリージョンが影響を受けます。リージョン内のリーダー ノードの場合、サービスは中断され、他の TiKV のリージョンがリーダーを再選出するのを待機し、リーダーが選出された後も外部へのサービスの提供を継続します。リージョン内のフォロワーノードの場合、サービスは影響を受けません。 TiKV ノードに障害が発生し、一定期間内 (デフォルトでは 30 分) に復元できない場合、PD はそのデータを他の TiKV ノードに移行します。

PD もクラスター モードで展開され、Raft プロトコルを通じてデータの一貫性を維持します。単一のインスタンスに障害が発生した場合、それがリーダーでなければ、サービスはまったく影響を受けません。リーダーである場合、PD クラスターは新しいリーダーを再選出し、サービスを自動的に復元します。

（２）ダウンタイム規模の観点から

当銀行の TiDB データベース クラスターは、単一マシン、ラック レベル、データ センター レベルの障害に耐えることができるため、高い可用性を実現できます。

単一マシンのサーバー障害は、TiDB、TiKV、PD の 3 つのロールに分割されます。前のセクションの説明を参照してください。

クラスター内のすべてのサーバーを別々のラックに配置します。 Raft プロトコルのほとんどの原則によれば、単一のラックに障害が発生しても、クラスターの外部サービスには影響しません。当銀行のアーキテクチャでは、クラスター内の 2 つのラックが同時に故障しても問題ありません。

いずれかのデータセンターに障害が発生した場合でも、Raft プロトコルの多数決原理に従って、残りの 2 つのデータセンターが外部にサービスを提供し続けることができます。

2. ストレージソリューション

TiDB クラスター データベース クラスターのデータには、業務データ、データベース ログ、データベースの動作状況データが含まれます。ハードディスク容量やI/O読み取り・書き込み速度などの要素を総合的に考慮した結果、サーバーのハードディスクストレージとしてSASディスク+SSDディスクを選択しました。容量を計画する際には、データの複数のコピーの特性を考慮して、十分なストレージ容量を計画する必要があることに注意してください。

データベース ログは、TiDB ログ、TiKV ログ、PD ログに分かれており、それぞれのインスタンス ノードに保存されます。

データベース操作ステータスに関連するデータは、クラスターのデフォルト データベースに保存され、すべての TiKV ノードにも保存されます。定期的に分析操作を実行することで更新されます。

3. 監視と警告

当行の TiDB データベース監視は、データベースの動作状況のリアルタイム監視、バイパス監視、モカ監視の 3 つのモジュールに分かれています。アラームもそれぞれこれら 3 つのモジュールによってトリガーされます。

（１）データベースの動作状況をリアルタイムに監視

この部分には、最も重要かつ最も包括的な監視コンテンツが含まれています。

TiDB クラスターは、オープンソースの時系列データベース Prometheus を監視およびパフォーマンス指標情報ストレージ ソリューションとして使用し、Grafana 視覚化コンポーネントを使用して監視データを表示します。警報チャネルは 2 つあり、1 つは当行が独自に開発した統合監視プラットフォーム、もう 1 つは AlertManager です。監視コンポーネントは監視サーバーにインストールされ、Prometheus によって生成された監視データもここに保存されます。

監視とアラームの全体的なアーキテクチャを次の図に示します。

クラスターの TiDB/PD/TiKV コンポーネントはそれぞれ Prometheus Pushgateway にデータをプッシュし、Prometheus サーバーは統一された方法でデータをキャプチャします。 Prometheus の監視データは、カスタマイズされた Grafana 表示テンプレートを通じて表示されます。

監視値が指定されたしきい値を超えると、アラームがトリガーされ、アラーム情報は AlertManager または統合監視プラットフォームを通じて電子メールと SMS で管理者に通知されます。障害の重大度に応じて、アラームは警告、重大、緊急の 3 つのレベルに分類されます。緊急は最高レベルであり、最も重大な障害を示します。ビジネス要件と情報システムのセキュリティ要件に基づいて、さまざまなアラーム戦略をカスタマイズしました。

（２）バイパス監視

バイパス監視は、プロメテウス監視の補足です。一方で、プロメテウスモジュールが正常かどうかを検出します。一方、TiDB の主要サービスの動作状態を直接監視し、異常が発生した場合にアラームを生成します。次の図はバイパス監視の概略図です。

（３）モカモニタリング

データベース レベルの健全性を監視します。

4. バックアップとリカバリ

TiDB クラスターのマルチコピー戦略により、障害発生時のデータ損失を回避できますが、データ セキュリティをさらに強化するには、完全なデータ バックアップおよびリカバリ戦略を策定する必要があります。

完全バックアップ ツール (Mydumper) と増分バックアップ コンポーネント (binlog) を使用して、任意の時点での TiDB クラスター データベースの状態を保存します。データを特定の時点に復元する必要がある場合、まず完全データ復旧ツール (Loader) を使用して、その時点より前の最後の完全バックアップを復元します。完全インポートが正しいことを確認した後、増分リカバリ ツール (Reparo) を使用して、PB ファイル形式の binlog 増分データを必要なリカバリ時点に復元します。

（１）バックアップ

すべてのバックアップ コンポーネントはバックアップ サーバーにインストールされます。自動バックアップ スクリプトを作成しました。完全バックアップと増分データ ファイルは両方とも最初にローカルに保存され、その後テープにダンプされます。

バックアップ戦略:

業務量が少ない夜間に週 1 回フルバックアップを実行します。

毎日増分データをリアルタイムでバックアップします。

バックアップ機能:

テーブルによるデータ復旧をサポートします。

TiDB バックアップ データは、TiDB クラスターまたは MySQL (5.7.x) に復元できます。

TiDB 増分バックアップは、データベースのライフサイクル全体にわたって実行されます。これは、Drainer が binlog を解析することによって生成される PB ファイルの形式で存在します。

バックアップ図は次のとおりです。

（２）回復

MySQL インスタンスがインストールされている任意のサーバーを使用してデータを復元できます。バックアップされた本番データは、感度を下げた後、テスト環境の TiDB クラスターで使用することもできます。

5. 日常の運用と保守計画

（１）製品アップグレード戦略

オープンソース ソフトウェアである TiDB は、製品の反復速度が速く、パッチ形式の更新を頻繁に使用します。エラーが見つかったらすぐに更新できます。これは銀行業界が要求する安定性とは異なり、規制当局が要求する変更プロセスに準拠していません。したがって、当社の現在のアップグレード戦略は、新しくリリースされたメジャー バージョンが安定した後に変更とアップグレードを調整することです。パッチ型のマイナーバージョンについては、業務に影響なくバージョンアップを延期いたします。

（２）クラスターの日常的な検査

当行では、24 時間のリアルタイム監視に加え、データベースを毎日定期的に検査することを義務付けています。この部分では、データベースの操作ステータスを電子メールでプッシュするための自動検査スクリプトを作成しました。

（３）クラスター拡大・縮小ソリューション

TiDB クラスターは、オンライン サービスに影響を与えることなく動的に拡張および縮小できるため、柔軟でスケーラブルなオンライン機能を実現します。容量の拡張と縮小も、TiDB、TiKV、PD の 3 つの状況に分けられます。具体的な操作については、PingCAP の公式 Web サイトで明確に説明されているため、ここでは繰り返しません。

PD 容量を拡張する場合、クラスターをローリング方式でアップグレードする必要があることに注意してください。アップグレード プロセスにより TiDB 接続が切断され、ビジネスに影響を及ぼします。アップグレード完了後に復元できます。したがって、取引量が少ない期間を選択するのが最適です。

6. 災害復旧計画

当銀行の TiDB クラスターでは、本番マスター クラスターに加えて、オフサイトの災害復旧を実現するためのスレーブ クラスター設計も追加されています。そのため、当社は包括的なマスタースレーブ クラスター災害復旧スイッチング ソリューションも開発しました。

次の図は、単純なマスター/スレーブ クラスターの展開図です。マスタースレーブ クラスターは、binlog を通じてデータを同期します。

切り替え中、マスター スレーブ クラスター アーキテクチャは変更されず、マスター スレーブ同期データ フローの方向のみが変わります。切り替えプロセスは次のとおりです。

1) ビジネスを停止し、マスターとスレーブの同期が完了するまで待ちます。

2) メイン クラスターの Drainer を閉じて、マスターとスレーブの同期を停止します。

3) メイン クラスターを閉じて、現在のタイムスタンプを記録します。

4) ビジネス データベース接続をスレーブ クラスターに切り替えます。

5) メインクラスターを起動します。

6) クラスターから Drainer を実行し、ホスト グループに同期します。

7. アプリケーションの適応と最適化

（１）ライブラリ、テーブル、インデックスなどの内部オブジェクトのチェックと最適化

TiDB オプティマイザーは、統計情報に基づいて最適な SQL 実行プランを選択します。

統計はテーブル レベルと列レベルで情報を収集し、stats_meta、tats_histograms、stats_buckets の 3 つのテーブルに保存されます。自動システム更新に加えて、統計を手動で更新し、毎日定期的に ANALYZE ステートメントを実行して統計を収集するスクリプトも作成しました。

SQL 実行プランは一連の演算子で構成されます。 TiDB は、SQL ステートメントの実行の詳細を表示するための EXPLAIN ステートメントを提供します。

データベース内のオブジェクトの最適化が必要な場合、統計情報と実行計画を総合的に分析し、最適化ソリューションを提供します。

（２）性能検査及び判定

アプリケーションが TiDB データベースに接続された後は、QPS、TPS、応答時間、ビジネス ライブラリのサイズ、ビジネス テーブルの成長率、データベース接続セッションの数、ホット ディスクなど、いくつかの指標をチェックすることに重点を置く必要があります。現在、監視、検査、ログ記録を通じて包括的な指標分析を実施し、データベースのパフォーマンスを判断しています。

V. 結論

以上は、当行の分散データベース TiDB の 2 サイト 3 センター マルチアクティブ アーキテクチャのソリューション設計と具体的な実践をまとめたものであり、監視とアラーム、クラスター チューニング、バックアップとリカバリ、災害復旧の切り替え、容量の拡張と削減など、日常の運用と保守管理のあらゆる側面をカバーしています。今後、当行はより多くのビジネス シナリオを分散データベースに移行し、より実用的な領域を模索していきます。同時に、私たちは実践的な経験を皆様と共有し、お互いに学び合い、共に進歩していきたいと考えています。貴重なご提案をお待ちしております！