TDSQL-C for MySQLは、企業の特定業務シナリオにおけるデータベースサービス要件を満たすためにServerlessサービスを提供し、企業のコスト削減と効率向上を支援します。本ドキュメントではServerlessサービスの主な特長を紹介します。
|
| 調整可能なCCUのエラスティックスケーリング範囲。Serverlessクラスタはこの範囲内で実際の業務負荷に応じてCCUを自動的に増減します。 |
| ServerlessクラスタはユーザーのCPU、メモリなどのワークロード負荷状況を継続的に監視し、一定のルールに基づいて自動スケーリングポリシーをトリガーします。 |
| Serverlessサービスはインスタンスの自動一時停止時間をカスタマイズ可能です。接続がない場合、インスタンスは自動的に一時停止します。タスク接続が発生した場合、インスタンスは秒単位で中断なく自動的に再開します。 |
リソースのスケーリング範囲(CCU)
CCU(TDSQL-C Compute Unit)はServerlessのコンピューティング課金単位であり、1つのCCUはおおよそ1CPUと2GBメモリのコンピューティングリソースに相当します。各課金サイクルにおけるCCU使用量は、データベースが使用するCPUコア数とメモリサイズの1/2のうち、最大値を採用します。
Serverlessサービスにはスケーリング範囲の設定が必要です。詳細なスケーリング範囲については、コンピューティング設定を参照してください。 Serverlessサービスは最小キャパシティ設定を0.25 CCUまでサポートします。初めてスケーリング範囲を設定する際は、最小キャパシティを1 CCUに、最大キャパシティを高い値に設定することを推奨します。小さいキャパシティ設定により、クラスタが完全にアイドル状態の時に最大限の縮小が可能となり、追加費用の発生を回避できます。大きいキャパシティ設定により、クラスタの負荷が高まった際に最大限の拡張が行われ、安定的に業務ピークを乗り切ることができます。
説明
業務シナリオで非常に高いキャパシティまで迅速に拡張する必要がある場合、最小キャパシティをやや大きめの値に設定することをご検討ください。
リソースのスケーリング範囲を変更する必要がある場合、コンソールにログインし、実際のビューモードに応じて変更できます。
対象のクラスタ管理ページで、右上のServerless設定をクリックします。ポップアップウィンドウでコンピューティング設定の変更を行います。調整後はすぐに有効になり、業務に影響を与えません。
対象のクラスタ管理ページ>インスタンスリストの操作列でその他>設定調整をクリックします。調整後はすぐに有効になり、業務に影響を与えません。
エラスティックポリシー
Serverlessサービスのスケーリングポリシーは監視コンピューティングレイヤーで実装されます。ビジネス負荷状況を監視し、システムがコンピューティングリソースを自動的にスケーリングし、その時点で消費されたリソースに対して課金します。データベースリクエストがない場合、監視サービスはコンピューティングリソースの回収をトリガーし、接続層に通知します。ユーザーが再度アクセスすると、接続層はクラスタを再開し、アクセスを再提供します。
Serverlessサービスのスケーリングポリシーは、最初にユーザーが購入時に選択したキャパシティ範囲に基づき、CPUおよびメモリリソースを最大仕様に制限します。これにより、CPUやメモリの拡張に伴う時間的影響や使用制限を大幅に低減します。クラスタが自動スケーリングの負荷閾値に達すると、バッファプールは監視データに基づき秒単位で事前調整を行います。この方式により、ユーザーはデータベース利用時にCPU拡張を意識せず、接続急増によるインスタンスのOOM発生も防止できます。
説明:
Serverlessを使用する場合、その柔軟なスケーリング能力により、クロスマシンスケーリングが発生する可能性があります。クロスマシンスケーリングがビジネスに与える影響を回避するため、Serverlessクラスタを使用する際にはデータベースプロキシを追加することを推奨します。これにより、クロスマシン接続断による接続切断問題を防止できます。同時に、ビジネスアプリケーションに再接続メカニズムを実装し、クロスマシン影響を最小限に抑えることをお勧めします。 リードオンリーノードは現在、単一ノードの垂直スケーリングのみサポートしており、リードオンリーノード数の水平スケーリング能力はまだサポートしていません。
自動起動・停止
業務ニーズに応じて、自動一時停止設定をオンまたはオフにすることができます。この設定はコンソールで変更可能です。 注意:
Serverlessサービスの自動一時停止の判断条件はユーザー接続の有無です。ビジネスシナリオでevent_schedulerを使用したSQLの定期トリガー操作が必要な場合、自動一時停止の有効化は推奨しません。
自動一時停止設定の有効化または無効化が必要な場合、実際のビューモードに応じて対応する操作を行ってください。
対象のクラスタ管理ページで、右上のServerless設定をクリックし、ポップアップウィンドウで自動一時停止のチェックを入れるか外します。
対象クラスタ管理ページのインスタンスリストで、操作列のその他>設定調整をクリックし、ポップアップウィンドウで自動一時停止のチェックを入れるか外します。
有効状態では、自動一時停止時間を設定する必要があり、デフォルトは1時間です。データベースがこの時間内に接続がなく、CPU使用も発生しない場合、自動的に一時停止します。一時停止後はコンピューティング課金が発生せず、ストレージは引き続き実際の使用量に基づいて課金されます。
無効状態では、データベースは継続的に稼働し続け、接続やCPU使用がない場合、ユーザーが設定した最小CCU演算能力に基づいて課金されます。これは、ビジネスでハートビート接続を必要とするアプリケーションシナリオに適しています。
手動一時停止
指定データベースに対し、コンソールで実際のビューモードに基づいて手動一時停止操作を実行することも可能です。
一時停止後の手動起動
一時停止状態のデータベースではコンソール機能が利用できません。操作が必要な場合は、データベースが自動起動した後に操作するか、実際のビューモードに応じてコンソールで手動的にServerlessデータベースを起動してください。 継続的な接続とリクエスト転送能力
接続アクセスがある場合、システムは秒単位で一時停止状態のデータベースを自動的に起動します。ユーザーが再接続メカニズムを設定する必要はありません。
TDSQL-C for MySQLのアクセス層には、リクエスト転送を実現するための回復感知モジュール(略称:パーセプトロン)が追加されています。パーセプトロンはクライアントとのハンドシェイク後、クライアントからクラスタへの接続を切断しません。クラスタを回復した後、TDSQL-C for MySQLとハンドシェイクを行い、以降のレイヤ4パケットを転送します。
全体のプロセス設計では、2つのチャレンジ乱数を使用した認証を採用し、中継モジュールであるパーセプトロンがユーザー名とパスワードを保存せずともユーザー認証を完了できるようにしています。これによりユーザーパスワードの安全性が保証され、パスワード保存の不一致問題も発生しません。
TDSQL-C for MySQLのインスタンスが一時停止状態にある場合、接続が開始されると、MySQLクライアントはまずパーセプトロン(perceptron)とTCPハンドシェイク(P0)を行います。TCPハンドシェイク完了後、パーセプトロンはクライアントに「ランダム値A」を送信してチャレンジ(P1)を発行します。MySQLクライアントは自身のアカウントパスワードと「ランダム値A」を使用して計算を行い、「ログイン解答A」(P2)を返答します。パーセプトロンはユーザーのアカウントパスワードを保存していないため、「ログイン解答A」の正否を検証できませんが、クライアントがMySQLクライアントか他のタイプのクライアントかを判別可能です(パーセプトロンは機械学習分野における分類器であり、異なるタイプのクライアントを区別できることが名称の由来の一つです)。「ログイン解答A」の検証はTDSQL-C for MySQLのコンピューティング層(以下TDSQL-C)が担当し、パーセプトロンが管理制御を通じてTDSQL-Cを起動(P3)した後、次のログイン検証プロセスに進みます。
パーセプトロンとのTCPハンドシェイク後(P4)、TDSQL-Cにとってパーセプトロンも通常のMySQLクライアントであるため、「ランダム値B」のチャレンジ(P5)をパーセプトロンに送信します。パーセプトロンの応答は特殊なMySQLパケット(P6)であり、まず「ランダム値B」とパーセプトロン自身の認証メカニズムを使用して「ログイン解答B」を計算しパケットに格納します。さらに「ランダム値A」と「ログイン解答A」もこのパケットに付加的に含めます。TDSQL-Cはこの特殊な解答パケットを受信すると二段階の検証を行います:第一段階で「ランダム値B」と「ログイン解答B」の正当性およびパーセプトロンの身元を確認し、通過後第二段階で「ランダム値A」と「ログイン解答A」の正当性を検証します。両方の検証を通過するとユーザーとしてログインし、パーセプトロンにログイン成功(P7)を通知します。これを受けてパーセプトロンはユーザーにログイン成功(P8)を返答します。
クラスタが一時停止状態の場合、パーセプトロンのルーティングのみを保持します。クラスタが回復すると、システムはパーセプトロンのルーティングとTDSQL-Cのルーティングを同時に保持し、パーセプトロンのルーティング重みを0に設定します。これにより、新規接続はTDSQL-Cに直接接続されると同時に、パーセプトロンとの確立済み接続も引き続き通信可能となります。