SQLスロットリングは、データベースで実行されるSQLステートメントの同時実行性を制限します。 この機能により、異常なSQLステートメントの同時実行性が制限され、データベースが通常の方法でビジネスリクエストに応答し、ほとんどのサービスが期待どおりに実行されるようになります。 このようにして、ほとんどのサービスを適切に実行するために、少数の侵害されたサービスをトレードオフすることができます。
背景情報
テクノロジーの成長、特にクラウドデータベースの幅広い採用により、データベースシステムはますます安定し、保守が容易になりました。 バージョンのアップグレードやインスタンスの移行など、一部のO&Mタスクは自動的に完了し、上位層のサービスはほとんど影響を受けません。 ハードウェアデバイスまたはネットワーク障害が発生した場合、検査システムはサービスを移行し、データベースシステムを迅速に再起動して、サービスの安定性を確保できます。 ただし、サーバーの安定性を確保するために、既存のO&M方式のほぼすべてが使用されています。 ビジネスの異常な操作によって引き起こされる問題は、手動で処理する必要があります。 たとえば、ビジネスの変更中にスローSQL文が導入されたり、トラフィックの急増が発生したりします。 これらのビジネス例外が発生した場合、前述のO&Mメソッドを使用してこれらの例外を迅速に処理し、システム障害を防ぐことはできません。
課題
トラフィック: トラフィックの急増は、データベースの通常のサービスに影響します。 たとえば、キャッシュの侵入、異常な呼び出し、およびプロモーションは、SQLステートメントの同時実行性を急激に増加させます。
データ: SQL文の不均一な分散によって引き起こされるデータスキューは、データベースの通常のサービスに影響します。 たとえば、大量の注文を行ったユーザーから多数のSQL文が送信されます。 これらのSQL文は、多数のデータベースリソースを消費し、データベースの応答が遅くなります。
SQL文: リソース集約型のSQL文は、データベースの通常のサービスに影響します。 たとえば、インデックス付けされていないクエリテーブルには、多数のSQL文が送信されます。 この場合、多数のリソースが占有され、システム全体が影響を受ける。
よくある質問
例外が発生したときにすぐに識別するにはどうすればよいですか?
例外が特定された後にスロットリングを実装する必要があるSQL文を特定するにはどうすればよいですか?
サービスを復元し、サービスへの悪影響を最小限に抑えるためにスロットリングを実装する必要があるSQL文のキーワードを抽出するにはどうすればよいですか?
スロットリングの実装後、スロットリング操作が期待どおりに実行されるかどうかを判断するにはどうすればよいですか。
実際の状況では他の問題が発生する可能性があります。 たとえば、勤務中の担当者に連絡しない場合があります。 職員は、利用可能なコンピュータを有していない場合があり、大量の情報は、分析において重大な困難をもたらし、または高い圧力および不安のために不適切な操作が行われる場合がある。
これらの問題に対処するには、可能であればプロセス全体を自動化してください。 プロセス全体で、例外の検出、異常なSQL文の特定、SQLスロットリング、追跡、およびロールバックが行われます。
このニーズに対応するため、自動SQLスロットリングのソリューションがリリースされました。 このソリューションはAlibaba Group内で2年以上適用され、2020年2月にAlibaba Cloudでリリースされました。 このソリューションは、Database Autonomy Service (DAS) で使用できます。
解釈
プロセス全体: 
モニタリングメトリクスの収集: デフォルトでは、Alibaba CloudにデプロイされているApsaraDB RDSインスタンスのホストおよびエンジンパフォーマンスメトリクスが収集されます。 パフォーマンスメトリックには、CPU、1秒あたりの入力 /出力操作 (IOPS) 、1秒あたりのクエリ (QPS) 、およびアクティブセッションが含まれます。 リアルタイムのパフォーマンスデータは、その後の分析とアクションの基礎となります。
異常検出: DASは、機械学習アルゴリズムを使用して、データベースインスタンスの履歴パフォーマンスデータを使用してモデルをオフラインでトレーニングし、このモデルを使用してリアルタイムメトリックに基づいて例外を検出します。 しきい値ベースの検出と比較して、異常検出機能は、システムイベントがアラートをトリガーするときにリアルタイムの通知を提供します。 この機能の詳細については、次のトピックを参照してください。
根本原因分析: DASはデータベースインスタンスの各例外をサブスクライブし、例外が発生した場合に現在のセッションに関する情報を収集します。 次に、DASは、SQL監査の完全なリクエスト分析機能とperformance_schemaの統計を使用して、例外の根本原因を特定します。 DASは、異常なSQL文を根本原因に基づいて次の4つのタイプに分類します。
SQL文をブロックする: DASは、セッション、ロック、および実行中のトランザクションをリアルタイムで分析し、DDLの変更、ロックの待機、および大きなトランザクションを引き起こすSQL文を検出します。 また、SQL 文の影響を受けるセッションの数と SQL 文の実行時間もチェックされます。 多数のセッションが影響を受けたり、SQL文の実行時間が長すぎる場合、DASはSQL文にスロットリングを実装せずにセッションを閉じます。
リソース集約型SQL文: このタイプの同時SQL文の数は多くない場合があります。 ただし、このタイプのSQL文は、多数のCPU、I/O、またはネットワークリソースを消費し、継続的に送信されます。
トラフィック集中型SQL文: これらのSQL文は通常の文です。 しかし、このようなSQL文を多数同時に実行すると、データベース内の多数のリソースを消費する。 これにより、単純なキー値クエリへの応答が遅いなど、パフォーマンスのボトルネックや例外が発生します。
その他のSQL文: このタイプのSQL文は、データベース例外を引き起こすその他のSQL文です。
自動スロットリング: DASがリソース集約型およびトラフィック集約型のSQL文を検出すると、DASはこれらのSQL文の機能を自動的に抽出します。 DASに必要な権限を付与すると、DASはこれらの機能を持つすべてのSQL文に対して自動的にスロットリングを実装します。 このプロセス中の最大の課題は、サービス全体が危険にさらされるのを防ぐために、正確な調整のためにSQL文の正確な機能を抽出することです。
機能の抽出: スロットリングを実装する必要がある異常なSQL文をDASが検出するたびに、DASはSQL文の機能を抽出して正確にスロットリングします。 理想的なシナリオでは、抽出されたフィーチャは一意であり、スロットリングは識別された異常なSQL文に対してのみ実装されます。 DASは2種類のSQLスロットリングをサポートします。
SQLテンプレートベースのスロットリング: SQLテンプレートは、パラメーターに特定の値がないSQLステートメントです。 特定のSQLテンプレートを使用する多数のSQL文を同時に実行すると、パラメーターの値に関係なく例外が発生する可能性があります。 したがって、実行する必要があるのは SQL テンプレートの機能の抽出のみです。
SQL文ベースのスロットリング: このタイプのスロットリングは、データスキューが検出されるシナリオに適用できます。 特定の SQL テンプレートを使用している一部の SQL 文が原因となり例外が発生している場合、SQL テンプレートおよび特定のパラメーター値を含む SQL 文から機能を抽出する必要があります。
SQL テンプレートベースのスロットリングでは、DAS は SQL 文から問題のあるテンプレート ID を抽出し、テンプレート ID を持つ文にスロットリングを実装します。 テンプレート ID は、データベースミドルウェアによって自動生成される SQL ID であるか、または開発者によって SQL テンプレートに追加される SQL ヒントである場合があります。
これにより、正確なスロットリングが可能になり、他のテンプレートを使用するSQL文が影響を受けないようになります。 ただし、テンプレートIDを含まない同じSQL文 (コマンドラインで送信されたものなど) は、スロットリングの影響を受けません。 これらの文は引き続き実行できます。
したがって、SQL文にテンプレートIDが含まれていない場合は、SQL文からフィーチャを抽出する必要があります。 SQL テンプレートは、分析プロセス中の計算に基づいて生成されます。 次の例では、SQLテンプレート1はSQLステートメント1に基づいて生成され、SQLテンプレート2はSQLステートメント2に基づいて生成されます。 SQL テンプレート 1 を SQL スロットリングに使用すると仮定します。 SQLテンプレート1の機能は、id、名前、学生の年齢を選択します。
/* SQL Statement 1 */ select id,name,age from students where name='Bob'; /* SQL Template 1 */ select id,name,age from students where name=? /* SQL Statement 2 */ select id,name,age from students where name='Bob' and sid='Unique ID'; /* SQL Template 2 */ select id,name,age from students where name=? and sid=?これらの機能をスロットリングに使用する場合、送信方法に関係なく、これらの機能を持つSQL文に対してスロットリングが実装されます。 欠点は、予期しない方法で一部のSQL文にスロットリングが実装される可能性があることです。 たとえば、SQL テンプレート 2 には SQLテンプレート 1 のすべての機能があります。 したがって、DAS は、SQL テンプレート 1 に基づいて、SQL テンプレート 2 にスロットリングを実装します。 これはあなたの期待に応えられないかもしれません。
自動最適化: DASが根本原因分析中に最適化できる異常なSQLステートメントを検出した後、DASは緊急応答としてスロットリングを実装します。 DASは、SQL文も自動的に最適化します。 DASは、最適化のために関連するテーブルのインデックスを自動的に作成します。 詳細については、次のトピックを参照してください。
追跡とロールバック: DASが自動SQLスロットリングを開始した後、DASはデータベースのパフォーマンスを追跡し続けます。 データベースのワークロードが減少しない場合、またはトラフィックが想定どおりに減少しない場合、DAS はスロットリング操作をロールバックします。 その後、根本原因を再度特定します。