Ping An クラウドネイティブデータベースの開発と実践

今号のゲストスピーカー：平安科技のシニアR&Dエンジニア、宋歌氏

紹介: Ping An Technology の R&D エンジニア。Kubernetes コントリビューターおよび TiDB コントリビューターとして精通しており、オープンソースを愛し、「TiDB in action」の著者の 1 人でもあります。

概要:オープンソースの分散リレーショナル データベースである TiDB は、優れたスケーラビリティを備えています。クラウド環境の柔軟なインフラストラクチャと組み合わせることで、分散データベースの利点を最大限に活用できます。なぜ TiDB をクラウドに移行する必要があるのでしょうか?クラウドネイティブ データベースの変革前の最大の課題は何ですか? Ping An Technology の答えは、効率、コスト、障害の自己修復の要件です。では、クラウドに移行するプロセスにおいて、TiDB はどのような主要コンポーネントを使用するのでしょうか? K8S 上で TiDB クラスターを効果的に管理するにはどうすればよいですか?クラウド環境を最大限に活用してTiDBを安定的に稼働させるには？ TiDB がクラウドに移行した後、より優れたユーザー エクスペリエンスを提供するにはどうすればよいでしょうか?この記事では、平安科技の実際のビジネス環境を組み合わせ、開発とアプリケーションの実践プロセスを具体的に紹介します。

クラウドネイティブ時代において、Kubernetesに代表されるオーケストレーションシステムは、新しいアプリケーションのデファクトスタンダードとなり、開発効率を向上させるキラーアプリケーションとも呼ばれています。ステートレスで弾力性のあるスケーリングと自動フェイルオーバー機能により、生産性がさらに向上したことは間違いありません。

実際、状態自体は消えることはなく、データベースやオブジェクト ストレージなどの基盤となるステートフル アプリケーションに移行します。では、TiDB に代表されるステートフルアプリケーションは、クラウドと Kubernetes の潜在能力を最大限に活用し、「高負荷で前進する」というプロセスでさらなる成功を収めるためにはどうすればよいのでしょうか。 Ping An Technology による TiDB と Kubernetes の「愛憎関係」のまとめは、より多くの企業のクラウド ネイティブ プラクティスに参考となる重要な情報を提供する可能性があります。

分散データベースであるTiDB技術のレビュー

Ping An Technology は 2018 年に TiDB の使用を開始し、2019 年に最初のオンライン ビジネスの展開を完了しました。2019 年以降、Ping An Technology は TiDB のクラウド移行に取り組み始めました。 2021 年、Ping An Technology はクラウドネイティブ分散データベース UbiSQL をリリースしました。

TiDB を導入した主な理由は、平安グループの主要なビジネス イベントである平安 1.8 財神祭をサポートするためです。イベントのピーク期間である 10 日間という短い期間に、TiDB はプロモーションをスムーズに完了しました。イベント中、TiDB は優れたスケーラビリティを実証し、ビジネスのピークに対応するために急速な拡張と縮小をサポートすることができました。

ご存知のとおり、TiDB は Google がリリースした Spanner から派生したオープンソースの分散型 NewSQL データベース サービスであり、OLTP と OLAP をサポートしています。同時に、TiDB は非常に強力な水平スケーラビリティを備えており、これは当然のアーキテクチャ上の利点です。 TiDB は分散トランザクションをサポートし、MySQL5.7 プロトコルとの高い互換性を備えています。これは、大量のデータ ストレージ、高い同時実行性、高いスループット、高い成長率を備えたビジネス シナリオに適した HTAP トランザクション分析ハイブリッド アプリケーションであり、移行コストを極めて低いレベルにまで削減できます。

TiDB をクラウド上に配置する必要があるのはなぜですか?

TiDB がクラウドに移行するのはなぜですか?運用・保守コストが最大の課題です！

当時は管理すべきクラスタが多数あり、運用・保守の効率性がユーザーの納期に間に合いませんでした。障害の自己修復の観点から、従来の環境で自動化を実現することは困難です。たとえば、サーバーがクラッシュすると、サービス機能が低下し、DBA は夜中に起きて問題の解決方法を考えなければなりません。夜間に業務のピークが発生する場合は、容量を拡張するために新しいインスタンスを作成する必要があり、これらの操作はすべて手動で行う必要があります。

クラウド自動化の次にユーザーに最も直接的な影響を与えるのは、コストと効率です。従来の環境に TiDB を導入すると、比較的断片化され、管理コストが高くなります。自動デプロイメントは構成スクリプトを通じて実行されますが、クラスター全体の状態に対するメンテナンスおよび自動管理機能が不足しています。リソースのスケジューリングも難しく、リソースのスケジューリングは外部のアルゴリズムやフレームワークに依存します。さらに、従来の環境では自己修復や弾力性のあるサービスを実現することは困難です。ただし、クラウドに移行した後、データベース インスタンスが一定期間応答しない場合は、Operator が自動的に新しいノードを起動し、データベース サービスの自己修復機能を提供します。ユーザー アプリケーション配信の観点から見ると、サーバーを申請し、いくつかのポートを計画する必要があったため、リソースを準備して実稼働クラスターを配信するまでに数日かかっていました。クラウドに移行してからは、配信時間はわずか数分になり、ユーザー エクスペリエンスが明らかに向上しました。

上記の要素に基づくと、クラウド上の TiDB が最良の選択になります。

クラウド化プロセスでは、TiDB Operator コンポーネントを使用し、二次開発を行って K8S クラスター上に TiDB コンテナ化クラスターを提供しました。これにより、リソース使用率が比較的高いレベルに大幅に向上しました。従来の環境では、リソースを手動で管理する必要があり、たとえば、大まかなリソース アルゴリズムを使用すると、リソースの使用率は比較的低くなります。クラウド化後は、リソース プールを統一的に管理できるようになり、K8s オーケストレーションとスケジューリングを通じてホスト リソースを最大限に活用できるようになり、ホスト リソースの使用率が大幅に向上します。同時に、クラウドはコンテナ化された方法で展開されます。ノードに障害が発生した場合、コントローラーによって自動的にプルアップされるため、適切なノード障害復旧が実現し、ホストに障害が発生した後も、他の​​ノードまたはコンピューティング レイヤーでレプリカの数を維持できるようになります。

特に重要なのは、TiDB がクラウドに移行し、すべての TiDB クラスターが集中的に管理されるようになると、スケール効果が明確にわかるようになることです。分散データベース クラスターには多数のコンポーネントとノードがあります。多数のクラスタを管理すると、情報管理コスト、クラスタ管理コスト、運用保守コストが大幅に増加します。すべてのクラスターを集中管理することで、規模の経済性が生まれます。 TiDB をクラウドに配置すると、各クラスターの限界管理コストを効果的に削減できます。

つまり、管理するクラスターの数が増えるほど、各ノードに費やす必要のある技術的コストと人的コストが少なくなります。同時に、集中的な管理によって、グループ内のさまざまな企業のユーザーがテクノロジーのメリットを共有できるという別のメリットも生まれます。コードを改善する際に、クイック バックアップ、ポイントインタイム リカバリ、パラメータ チューニングなどの新機能をリリースしました。クラウド上で集中管理方式でホストされたクラスターに技術的機能を提供することができ、最終的な効果はコストの削減と効率の向上です。

クラウド上で TiDB クラスターを管理するにはどうすればよいでしょうか?

では、K8S クラスター上で TiDB クラスターをどのように管理すればよいのでしょうか?おそらく、次の 5 つのコア機能を構築しました。

自動展開。まず、TiDB Operator を使用して二次開発を行い、クラウド上で自動管理機能を実装しました。たとえば、自動配信により、ユーザーは Ping An Cloud インターフェースを 1 回クリックするだけでクラスターを作成し、仕様とインスタンスを選択してから、ストレージ スペースのサイズを選択すると、バックエンドに TiDB クラスターが自動的に作成され、クラスターが配信されます。

2. ローリングアップグレード。 TiDB コミュニティ バージョンのアップグレード頻度は非常に高いです。ここ数年は、1ヶ月半に1回程度の頻度でマイナーバージョンアップが行われてきました。そのため、断片的な小さなバージョンもいくつかオンライン上に存在します。ローリング アップグレードを実行する場合、DBA は運用および保守期間中にクラスターを小さなバージョンにアップグレードできます。現在、ローリングアップグレードはワンクリックで実行できます。

3. バックアップ管理。基本的には、完全バックアップ、増分バックアップ、完全リカバリ、ポイントインタイムリカバリ (PITR) を実現します。

4. パラメータ管理。 DBA は Ping An Cloud ページでパラメータを設定できます。このパラメータ設定では、パラメータの変更履歴を記録し、いくつかのデフォルトパラメータを提供できます。さらに、さまざまなパッケージに基づいていくつかのデフォルト パラメータを提供することもできます。変更を行った後、誰が何をいつ変更したかが記録されます。さらに、パラメータを変更するための期間や、ビジネスのピーク時間帯にはこのパラメータを調整しないなど、パラメータの有効性を制御するためのルールを設定する期間があり、ユーザーはページでそれを構成できます。

5. ユーザー管理。現在、グループ内の子会社を中心に、データベースユーザー管理に関する管理仕様がいくつか存在します。社内システムの一部構築仕様と承認プロセスとを組み合わせ、承認後に仕様に沿ったユーザー機能を作成します。

クラウド環境を最大限に活用してTiDBを安定的に稼働させるには？

まず、コンテナネットワーク。 K8S でより一般的な Cal​​ico がネットワーク プラグインとして使用されます。 Flannel と比較した利点は、コンテナ ネットワークの相互接続をネットワーク レベルで BGP を介して実現できるため、オーバーレイ モデル トンネルのオーバーヘッドを回避できることです。さらに、自社開発のK8Sネットワークプラグインをベースに、静的IPを実装するネットワークソリューションの検証も行っています。

2番目はロードバランサーです。データベース インスタンスの数が増えると、ビジネス アクセスにロード バランサーが必要になります。現在、ロードバランサーとして K8S サービスを使用しています。同時に、グレースケール アップグレードやローリング アップグレードを実行する際には、ロード バランサーのラベル選択機能を使用してトラフィックを制御します。

3番目は、サービス検出です。 DNS に基づく自動サービス検出。いわゆる「サービス検出」では、PD を構築するときにいくつかの静的ノードを構成する必要があります。 PD クラスターを構築する方法はいくつかあります。 1 つは、各ノードが他のノードの IP アドレスを認識する静的クラスターを構成することです。ノードは、サービス検出メカニズムに基づいて自動的にクラスターを形成することもできます。サービス ディスカバリを使用する利点は、クラスターの規模がより柔軟になり、静的なアプローチを使用するよりも動的なクラスターを作成する方が簡単なことです。

4番目は、バックアップと復元です。コミュニティ ツールとオブジェクト ストレージに基づいてデータをバックアップおよび復元します。これまでのバックアップおよびリカバリ機能は、MySQL と Lightning をベースにして、TiDB レイヤーでデータのバックアップとリカバリを実行していました。 Lightning には KV の作成も含まれていました。バックアップと復元ツールは、KV レイヤーから直接データをバックアップします。バックアップは各 TiKV ノードで直接実行されるため、より高い同時実行性とスループットもサポートできます。また、コンピューティング層での SQL 解析が回避され、回復速度が速くなります。現在、このツールは非常に高速であり、バックアップと復元ツールが統合されています。同時に、クラウドベースのオブジェクトストレージにバックアップし、オブジェクトストレージからデータを復元することもできます。

さらに、ユーザーは、コンテナ化を導入した後の安定性をどのように確保するか、複雑なシステムで新しいテクノロジーをどのように使用してシステム全体を悪化させるのではなく改善するかについて、より関心を持っています。

比較的スマートなテクノロジーをいくつか紹介します。

自動フェイルオーバー。これは、TiKV 自体が障害から自己修復する能力を持つことと同じです。 3 つのレプリカが指定されていると仮定すると、Operator はレプリカがクラッシュし、30 分以上回復していないことを検出すると、自己修復操作を実行します。これは従来の Ansible にはない機能ですが、TiDB Operator に固有の機能です。これもクラウドベースのサービスによってもたらされる利点です。レプリカが 3 つあり、そのうち 1 つのレプリカが 30 分以上ヘルス チェックに失敗した場合、新しいレプリカが自動的に復元されます。オリジナルのコピーを気にせず、柔軟なサービス機能を維持できます。もちろん、障害が発生したノードが復元されると、予想を上回る 4 つのレプリカが存在することになります。このとき、DBA は障害状況に基づいて、新しく追加されたレプリカをオフラインにするかどうかを判断します。もちろん、この 30 分の制限は Operator 自体のパラメーターでもあり、Operator が新しいノードを作成するのにかかる時間を設定できます。

自動スケーリングは、 Prometheus、TiDB の Pod、K8S の HPA 機能と組み合わせることで、メトリックのいくつかの主要な指標に基づいてインスタンス ノードの拡張を実現します。ノードまたはビジネスが特に混雑していることが判明した場合、リソース プールに基づいて容量を拡張します。ユーザーは、最大拡張制限や拡張の待機時間などの拡張ルールを、ユーザー側のページでオンデマンドで設定できます。同時に、拡大のための削減戦略も存在します。例えば、冷却時間があります。この時間が経過しても、主要指標が削減の最小値に達しない場合、管理および制御コンポーネントは自動的に容量を削減し、プロセスを終了するように指示します。データベースは新しいセッションの受け入れを停止し、現在のセッションの処理を完了します。取引に長い待ち時間が発生することはなく、待ち時間が経過しても取引はクリアされません。

自動運転:データベース クラスター全体には変動や異常があります。異常をスムーズに処理するにはどうすればよいでしょうか?これは、監視とログ記録を通じてパラメータを自動的に分析および識別する自動運転によって実現できます。

TiDB がクラウドに移行した後、ユーザー エクスペリエンスを向上させるにはどうすればよいでしょうか?

一般的に、DBA はログの表示など、Linux でのデータベースの保守に慣れています。ただし、分散システムでは、異なるパスを表示するには各ノードにログインする必要があるため、これは非常に面倒です。クラウドに移行すると、集中ログ管理（社内では Log Cloud と呼んでいます）など、クラウド独自の機能の一部にアクセスできるようになります。 K8S Pod のログを集中的に収集し、他の製品ページでキーワードのフィルタリングと分析を行います。

さらに、DBA がより適切な分析を行えるようにし、ユーザーがデータベースのパフォーマンスを分析できるようにするための統合監視ページもあります。この機能は、クラウド プラットフォームの製品ページに基づいて追加できます。これには、容量の拡張、購入仕様の調整、前払いや従量課金制などの支払い方法の調整などの機能が含まれます。

最後に、クラウドネイティブ データベースも継続的な進化のプロセスです。最適なアプリケーション パフォーマンスを実現するために、私たちは新たな探求も行っており、基盤となる技術サポートにも引き続き力を入れています。

1. 垂直スケーリング（VPA）。 2021 年にリリースした UbiSQL 分散データベースでは、インスタンスに基づいて垂直スケーリング (VPA) を実行する方法など、この点に関してさらに調査を行っています。元々CPUには限界がありましたが、ビジネスは突然ピークを迎えました。水平展開するとなると、まず、容量と時間が限られていました。さらに、水平展開における一部の大規模な SQL では、依然として単一インスタンスでボトルネックが発生していました。そのため、パッケージ仕様を拡張する必要があります。アプリケーションを再起動せずに、利用可能なリソース制限をその場で増加し、パッケージ仕様を垂直に拡張する必要があります。

2. 異機種クラスター基盤となるストレージを含むストレージ ノードの容量が拡張または縮小されると、各 TiKV に対応するストレージ ブロックは異なります。クラスターを構築する際には、メモリ、CPU、ストレージ ディスクの比率を変更できます。 TiKV 全体では、ディスク上の各ブロックの異なる比率が許可されます。同時に、異種クラスターには、AP と TP からの要求を分離できるという別の機能があります。たとえば、データミドルエンドの企業が当社に相談に来ましたが、その企業のビジネスの一部はトランザクションベースであり、特定のノードで実行したいと考えています。さらに、彼らのビジネスの一部は分析的なものであり、それを別のコンピューティング ノードで実行したいと考えています。さらに、これらのノードのリソース仕様は異なります。この機能を製品化した形でユーザーに提供していくことも、現在取り組んでいるところです。

3. データベースの自律性。また、データベースの自律性についても調査を行っています。まず、データベース ガバナンス システムを構築します。ガバナンス システムは、データベースの自律性を実現するための重要な道だからです。まず、ガバナンス プロセス、データ、ガバナンス機能が必要です。次に、データに基づく分析やパラメータ調整など、データとガバナンス機能に基づいた自動化を実行します。

TiDB には最適化できるパラメータが多数あり、分散アーキテクチャ コンポーネントと組み合わせると、この 2 つを組み合わせるとチューニング プロセスが非常に複雑になります。データベースの自律性は多くの問題を解決できます。 1つ目はパラメータの調整です。環境や業務負荷に応じて、データベースの一部のパラメータを比較的良好な状態に調整できます。提供されるクラスターにはすべてデフォルトのパラメーターがあるため、これらのパラメーターは専門家のモデルに基づいており、専門家はこのパッケージが 80% のビジネスに対応できると信じており、これらのパラメーターを使用しているため、このように使用されます。ただし、クラスターが納品された後、実際のビジネス負荷特性に基づいて、いくつかのパラメータを適切に調整できます。データベースの自律性により、パラメータの調整を自動化されたプロセスに変えることができます。

では、蓄積されたスローログデータを最適化するにはどうすればよいでしょうか?これまで、多くのログデータは手作業による経験に基づいて分析されていました。スローログの分析機能を自動化したいと考えています。現在、これらの機能はすべて、使用されているインフラストラクチャに依存しています。まず、すべてのスローログが収集され、エキスパートモデルに基づいて自動化されたプロセスに変換されます。

4. 新しいハードウェアを使用して KV ストレージ (KVSSD) を最適化します。 Rocksdb を SSD ハードウェアに統合して、ハードウェア KV インターフェイス機能を直接使用します。上位層アプリケーションは、もともと Rocksdb を介して SSD ハードウェアにアクセスする必要がありました。現在、ハードウェア メーカーは、統合ストレージおよびコンピューティング ハードウェアと同様に、KV 機能をハードウェアに直接統合しており、SSD の KV 読み取りおよび書き込みパフォーマンスを大幅に向上させることができます。

つまり、TiDB は従来のデータベースを超え、データの価値を高めることができます。コンテナに関連する主要コンポーネントが重要な役割を果たします。クラウドネイティブデータベース設計の将来の発展の観点から見ると、さらに多くの可能性と探求の余地があります。