GaussDB 技術解説シリーズ: 運用・保守 自動運転の探求

最近、第 14 回中国データベース技術カンファレンス (DTCC2023) で、GaussDB の「5 つの高さと 2 つの簡単」コア技術が世界により良い選択肢、ファーウェイのクラウドデータベース運用保守研究開発ディレクターの Li Dong 氏が、データベースの自動運転について詳しく説明しました。 GaussDB 運用保守システムの探索と実践。

企業のデジタルトランスフォーメーションが深層水領域に進出するにつれて、データベースシステムはますます複雑になり、運用および保守チームが維持するデータベースの規模はますます大きくなり、従来のツールベースの運用および保守ではもはや時代に対応できなくなっています。運用と保守の要件が強化され、データベースの運用と保守が徐々にインテリジェントになってきています。

データベース障害をより適切に認識して予測し、インテリジェントな診断と適応的な回復を実行する方法は、私たちが模索してきたことです。次に、この記事では、クラウドデータベースの運用保守の課題、GaussDBの運用保守アーキテクチャ、迅速な認識と迅速な診断の実行方法の4つの方向から、運用保守の自動運転におけるGaussDBの探索と実践を共有します。

クラウド データベースの運用と保守はどのような課題に直面していますか?

企業がデータベースをクラウドに移行するにつれて、クラウド データベースの運用と保守で直面する課題はさらに複雑になっています。データベースは、ベアメタル、仮想マシン、コンテナなどのさまざまなインフラストラクチャにデプロイされる可能性があり、さまざまなインフラストラクチャが直面する障害シナリオも多様です。

パフォーマンスのジッターを伴うサブヘルス問題が発生した場合、通常の解決策は、アプリケーション データベース、オペレーティング システム、コンピューティング、ストレージ、ネットワークなどの複数のレベルで包括的に分析することです。障害は各層で発生する可能性があり、異なる層で障害が発生することもあります。レベルによっては、同じ亜健康現象が発生する可能性があります。たとえば、SQL が遅い場合は、ディスク障害やネットワーク ジッターが原因である可能性がありますが、顧客にとっては SQL が遅いように見えます。

運用および保守能力が不十分な場合、処理プロセスには一般に次の 3 つの課題があるため、サブヘルス問題を短期間で特定して解決することは困難になります。

まず、健康状態以下の問題を正確に予測し監視することは不可能です。

これには主に「多かれ少なかれ」という問題が含まれます。「少ない」とは、各層でのサブヘルス問題の監視が不足していることを意味します。たとえば、ディスク障害は簡単に検出できますが、ディスクに不良ブロックがある場合や、ディスクの速度が遅い場合は、それをすぐに監視する方法はありません。「複数」は、各層で監視と警報を行っていることを表していますが、警報同士は関連性がなく、これらの警報から真の問題点を特定することは困難であるため、現在のサブレベルを正確に見つけることは困難です。システム、健康上の問題。

第 2 に、サブヘルス上の問題が発見された後、迅速に診断する方法がありません。

データベース内で発生した問題は、DBAの経験に頼って診断や意思決定を行うことが多く、比較的高い運用保守能力が求められ、効率性は保証できません。

3つ目は回復力不足

現状では問題の根本原因を診断した上で復旧する必要がありますが、電流制限や過負荷など復旧機能が不十分であり、データベースパラメータのチューニングや不正なSQL最適化などを伴うため、深いデータベース機能と経験の蓄積が必要となります。

GaussDB の全体的な運用および保守アーキテクチャ 

GaussDB はこれらの問題をどのように処理するのでしょうか? GaussDB の全体的な運用と保守のアーキテクチャを見てみましょう。

GaussDB の統合運用保守プラットフォームは主に 5 つの部分に分かれています。

最初の部分はインスタンスの運用と保守です。これは主に、作成、変更、バックアップ、リカバリ、パラメーター調整など、GaussDB クラスターのライフサイクルの管理を担当します。

2 番目の部分は災害復旧管理で、主にストリーミング災害復旧、同一都市災害復旧、および 2 か所の 3 センター機能を提供します。

3 番目の部分は、GaussDB 運用保守システムの最も重要な部分であるインテリジェント運用保守であり、AI4DB の機能を使用して自律的な運用保守システムを構築しており、主に次の 4 つの層に分かれています。

  • 最初の層はデータ収集層であり、各層の監視データと上位層によって発行された操作指示を収集する役割を果たします。

  • 2 番目の層はデータ コンピューティング層であり、時系列データベース、アルゴリズム モデル ライブラリ、障害ルール ライブラリなど、収集されたデータのキャッシュ、永続化、およびデータ処理を担当します。

  • 3 番目の層は自律サービス層で、SQL の診断とチューニング、セキュリティ、データベースの運用と保守、その他の機能が含まれます。

  • 4 番目のレイヤーは、アラーム監視、完全な SQL、その他の機能を含むパノラマ監視です。

GaussDB は、一連のインテリジェントなオペレーションおよびメンテナンス センターを構築することにより、フルリンクのエンドツーエンドの自動運転エクスペリエンスを作成します。

 

GaussDB の障害を迅速に検出する

  •   パノラマデータベースモニタリングとシステム稼働状況のリアルタイム認識 

 GaussDB パノラマ モニタリング システムを見てみましょう。パノラマ モニタリングを通じて、維持しているデータベース クラスターのうち、どのクラスターが正常で、どのクラスターが異常で、どのクラスターが健全な状態にないのかを確認できます。例えば、アラーム統計モジュールを表示すると、クラスタ全体の現在のアラーム状態を分析して把握でき、緊急アラームや重要なアラームがある場合は優先的に処理することができます。また、リソース使用量のリスクを確認し、リソース使用量予測機能を使用して、ディスク領域の不足や CPU の不足など、今後のリソースのボトルネックを早期に警告して、タイムリーな方法で処理して回復できるようにすることもできます。インテリジェント診断の分野では、現在のデータベースのパフォーマンスのボトルネックを分析することで、ダッシュボードのカスタム監視もサポートし、ユーザーの主要なビジネスデータベースを選択し、主要な監視指標をカスタマイズし、主要なビジネスのカスタム次元のセキュリティ監視を実行します。 。

データベース パノラマは、まずフルリンクおよびオールラウンド モニタリングに依存します。データベースの運用・保守においてはデータベースの可観測性が非常に重要ですが、GaussDBフルリンク監視ではハードウェア、OS、DBなどを階層的に監視し、収集、送信、表示、分析、検査までのフルリンク機能を構築しています。ハードウェアからオペレーティング システム、データベースに至る監視チェーン全体を接続します。たとえば、クラウド上でハードウェア障害の問題が発生した場合、そのハードウェア障害は別の部門によって管理され、データベース部門はデータベース クラスターしか認識できません。オペレーティング システムに問題がある場合は、ハードウェア部門が協力して問題を解決する必要があります。ハードウェアからオペレーティング システムおよびデータベースへの通知メカニズムです。この層でサブヘルス問題が発生した場合、障害情報を通知できます。解決のために関連する運用保守部門に連絡します。

  • 完全な SQL データの収集と分析

次に、完全な SQL コレクション機能を見てみましょう。従来の完全な SQL 収集方法、つまりトラフィック キャプチャまたはログを通じて完全な SQL を取得する方法と比較して、GaussDB は軽量な方法で完全な SQL の洞察を構築します。収集プロセスは、データベースとのメモリ バッファ チャネルを確立し、メモリ チャネルから SQL 情報を直接収集して外部デバイスに転送します。このプロセスにはディスク IO 操作が必要なく、パフォーマンスへの影響は最小限に抑えられます。

従来の収集シナリオでは、完全な SQL を有効にする必要がある場合があり、これはビジネスに約 30% の影響を及ぼしますが、通常の状況では、ユーザーはそれを有効にする勇気はありません。GaussDB の完全な SQL により、リスクを最小限に抑えることができます。GaussDB が提供する完全な SQL ソリューションには、次の 4 つの特徴があります。

リスクが低い

GaussDB はメモリを介してすべてのログ情報を読み取り、それをサードパーティに転送します。これにより消費されるデータベースのパフォーマンスは 5% 未満です。

 低コスト

GaussDB は、SQL データの全量をローカル IO に転送せず、クラウド上の OBS などのサードパーティに直接転送し、比較的低コストで全 SQL データの圧縮をサポートします。

高拡張性

GaussDB のフル SQL はデフォルトでいくつかの情報を収集しますが、この情報が現在の要件を満たさない場合は、拡張することができます。

 高いセキュリティ

SQL の全量をサードパーティ デバイスに転送する必要がある場合、GaussDB は転送プロセス中にデフォルトのデータの感度解除を実行して、データのセキュリティを確保します。

フルリンク監視を通じて、GaussDB は高速な自動検査をサポートし、可用性、信頼性、パフォーマンス、リソース使用傾向などを検査し、検査レポートを出力することで、現在の問題を確認し、何らかの対応を行うことができます。したがって、前述の完全なリンクと自動検査機能により、GaussDB は迅速な認識を実現できます。

 GaussDB インテリジェント診断

GaussDB が障害診断においてどのような機能を備えているかを見てみましょう。

1. SQL自己診断

オフライン + オンラインのアプローチに基づいて SQL 診断を実行します。まず、SQL テキスト、SQL 実行時間、スキャンされた行数と返された行数など、SQL が遅いと考えられるシナリオを収集します。また、データベースに関連する重要な指標も収集します。 、オペレーティング システム、またはリソースを取得し、ビジネス SQL 情報と主要指標情報を通じてオフライン トレーニングを実施し、最終的に低速 SQL 機能ライブラリを取得します。

この機能ライブラリは何に役立ちますか? 運用環境で SQL の遅い問題が発生した場合、機能ライブラリと KNN アルゴリズムに基づいてオンライン推論を実行し、SQL の原因を診断して、根本原因に対する最適化の提案を行うことができます。

2. SQL フルリンク分析

これまでお客様から、SQL の実行が通常非常に速く、1 秒以内に返されるというフィードバックがありましたが、最近では実行が頻繁にタイムアウトするというフィードバックがありました。弊社業務担当者が各層の状況を確認し、クライアント、データベースCN、DN、OS等を逐次分析したところ、特定のシャードで時折発生する可能性があり、診断効率が非常に悪いことが分かりました。

GaussDB が提供する SQL フルリンクの監視および分析機能は、この問題をうまく解決します。フルリンク追跡と集計分析が含まれており、ビジネス SQL キーワードやクライアント トレース ID などの条件を通じてデータベース SQLID をクエリし、データベース クラスター内の SQL の解析プロセスと実行時間、およびそれぞれに費やされた時間を追跡します。クラスター内の SQL、データの転送と集計を行ってから、問題の原因を追跡します。

3. 多次元指標相関分析

データベースの運用および保守では、多数の指標を監視する必要があります。主要な指標の 1 つまたは複数に異常がある場合、運用および保守担当者は、次の手順を決定するために、異常の根本原因を迅速かつ正確に特定する必要があります。しかし、指標の数が多い場合、情報のフィルタリングの作業負荷も膨大になるため、この問題を解決する効率的なツールが必要です。

一部のデータベース指標間には強い相関関係があることがわかっており、方向性相関アルゴリズムにより、異常が発生した場合に同じ期間の指標を比較し、相関の強さに基づいて異常期間と指標を特定します。主要な指標に関連するものは除外されます。GaussDB は現在、グリッチ、継続的な増加、ドリフト、周期性などのシナリオの検出アルゴリズムをサポートしています。これにより、運用および保守担当者が問題を迅速に特定し、運用および保守担当者の作業負荷を軽減し、問題の根本原因を特定するのに役立ちます。

4. トレンド予測

日常的なシステムの運用と保守、および障害処理の実践では、負荷の変化には、現在のシステムのサブ健全性や障害の影響に関するフィードバックが含まれることが多く、従来のコンポーネント インジケーターの監視とアラームに基づいて、障害の異常をタイムリーに検出することは困難です。やり方。インスタンス レベルで主要な指標の監視を確立することで、GaussDB は履歴データと、タイミング予測や異常検出などの主要なアルゴリズムを使用して、ゴールデン KPI 指標を予測し、異常な情報を発見し、異常な状況によって引き起こされる深刻な結果を回避するための措置を講じるようユーザーに通知します。 。

5. インデックスの推奨事項

アプリケーション開発者が SQL を最適化する場合、インデックスの最適化は重要な最適化内容ですが、その複雑な分析とパフォーマンス分析、最適化手法などの実際的なしきい値により、SQL の最適化に課題が生じます。

インデックス推奨の中心的な方法は、ネイティブの字句解析と構文解析に基づいており、クエリ ステートメント内の単語と述語を分析および処理し、フィールドの選択性、集計条件、複数テーブルの結合関係などを組み合わせて、最適なインデックスの提案を出力します。GaussDB は、インデックス推奨機能を提供し、インデックス推奨リストと各インデックスの正および負の SQL リターンを提供し、現在のデータベース内の冗長インデックスと無駄なインデックスを特定し、データベース クエリ速度を最適化します。GaussDBはオプティマイザー評価機能も提供しています。実際にインデックスを作成せずに仮想インデックス機能を提供します。仮想インデックスは、インデックスの推奨結果が適切かどうかを評価するために使用されます。インデックス構成を継続的に最適化することで、ユーザーの負荷ドリフトを解決できます。 、不良なインデックスと冗長なインデックスを即座に検出し、障害を回避します。

6. SQL セッションのチェックと強制終了

アプリケーション開発の複雑なロジックにより、手動で発見するのが難しいロジックの問題が発生したり、異常な SQL が発生したりする場合があり、運用および保守担当者が異常なセッションを迅速に検出して制限できるようにするための対応手段が必要です。GaussDB アプリケーション プラットフォームはセッション管理機能を提供し、リアルタイム セッション ページでは、セッション統計、アクティブ セッション、セッション ロック分析、セッション キルなどの機能をサポートし、運用保守管理担当者がインスタンスのセッション情報を迅速に把握できるようにします。インスタンス セッションを管理し、手動で見つけるのが難しいデータベース セッション接続に関連する論理的な問題を効率的に特定します。

7. SQL電流制限と自律電流制限

データベースの通常の操作中に、特定のアプリケーションが新しい関数を起動するシナリオを想像できます。この新しい関数により、非常に悪い SQL が導入され、データベースが通常の外部サービスの状態から徐々にリソース使用量が増加する状態に徐々に変化します。大量の SQL 実行は、スレッドや CPU などのリソースを取得できないために速度が低下し、最終的にビジネスの異常につながります。異常な SQL (インデックス作成の不良など)、SQL の同時実行性の増加などのシナリオが発生した場合、データベース全体の保守性に大きな影響を及ぼします。このとき、正確な電流制限を通じて SQL を抑制できます。ビジネスが正常に運営できることを保証します。

GaussDB によって提供される SQL 電流制限は、次の機能を提供します。

  • グローバルな高速レーンと低速レーンいわゆるグローバル高速レーンと低速レーンは 2 つのリソース プールを定義します。1 つは通常のリソース プールで、これを高速レーンと呼びます。高速レーンは大量のリソースを提供します。通常の業務は高速レーンで実行されます。交通事故が発生した場合は、ここでの交通事故とは異常を指します。SQL ビジネスの場合、ページ上でワンクリックで異常な SQL を低速レーンに入れることができます。低速レーンはリソースの使用を制限するため、交通事故が処理された後、高速レーンは高速で走行し続けることができます。

  • 単一型 SQL の正確な管理と制御単一タイプの SQL の場合、このタイプの SQL のリソース占有を制御すると緊急電流制限効果が生じる可能性があるため、実行時間、IO 使用量などの観点から正確な制御が必要です。

  • メモリのメルトダウンメモリの上限と下限の構成を提供します。メモリ使用量が最大メモリ制限を超えると、新しい接続は禁止され、現在のセッションは強制終了されます。メモリがメモリの下限に戻った後、強制終了セッションは停止され、新しい接続が許可されます。

  • SQL の自律的な電流制限特定の SQL ルール、または CPU やメモリなどのリソース使用ルールに従って SQL のフローを自律的に制限し、対応する種類の SQL によってデータベース全体の速度が低下するのを防ぐ機能を提供します。

これが今日私が共有する主な内容です、皆さんありがとう! 

おすすめ

転載: blog.csdn.net/GaussDB/article/details/132871317