サービス機能
ダウンロード
フォーカスモード
フォントサイズ
TDSQL-C for MySQLは、企業の特定業務シナリオにおけるデータベースサービス要件を満たすためにServerlessサービスを提供し、企業のコスト削減と効率向上を支援します。本ドキュメントではServerlessサービスの主な特長を紹介します。
機能項目 | 説明 |
リソースのスケーリング範囲（CCU） | 調整可能なCCUのエラスティックスケーリング範囲。Serverlessクラスタはこの範囲内で実際の業務負荷に応じてCCUを自動的に増減します。 |
エラスティックポリシー | ServerlessクラスタはユーザーのCPU、メモリなどのワークロード負荷状況を継続的に監視し、一定のルールに基づいて自動スケーリングポリシーをトリガーします。 |
自動起動・停止 | Serverlessサービスはインスタンスの自動一時停止時間をカスタマイズ可能です。接続がない場合、インスタンスは自動的に一時停止します。タスク接続が発生した場合、インスタンスは秒単位で中断なく自動的に再開します。 |
リソースのスケーリング範囲（CCU）
CCU（TDSQL-C Compute Unit）はServerlessのコンピューティング課金単位であり、1つのCCUはおおよそ1CPUと2GBメモリのコンピューティングリソースに相当します。各課金サイクルにおけるCCU使用量は、
データベースが使用するCPUコア数とメモリサイズの1/2のうち、最大値を採用します。Serverlessサービスは最小キャパシティ設定を0.25 CCUまでサポートします。初めてスケーリング範囲を設定する際は、最小キャパシティを1 CCUに、最大キャパシティを高い値に設定することを推奨します。小さいキャパシティ設定により、クラスタが完全にアイドル状態の時に最大限の縮小が可能となり、追加費用の発生を回避できます。大きいキャパシティ設定により、クラスタの負荷が高まった際に最大限の拡張が行われ、安定的に業務ピークを乗り切ることができます。
説明：
業務シナリオで非常に高いキャパシティまで迅速に拡張する必要がある場合、最小キャパシティをやや大きめの値に設定することをご検討ください。
リソースのスケーリング範囲を変更する必要がある場合、コンソールにログインし、実際のビューモードに応じて変更できます。
対象のクラスタ管理ページで、右上のServerless設定をクリックします。ポップアップウィンドウでコンピューティング設定の変更を行います。調整後はすぐに有効になり、業務に影響を与えません。
対象のクラスタ管理ページ>インスタンスリストの操作列でその他>設定調整をクリックします。調整後はすぐに有効になり、業務に影響を与えません。
エラスティックポリシー
説明：
Serverlessを使用する場合、その柔軟なスケーリング能力により、クロスマシンスケーリングが発生する可能性があります。クロスマシンスケーリングがビジネスに与える影響を回避するため、Serverlessクラスタを使用する際にはデータベースプロキシを追加することを推奨します。これにより、クロスマシン接続断による接続切断問題を防止できます。同時に、ビジネスアプリケーションに再接続メカニズムを実装し、クロスマシン影響を最小限に抑えることをお勧めします。
リードオンリーノードは現在、単一ノードの垂直スケーリングのみサポートしており、リードオンリーノード数の水平スケーリング能力はまだサポートしていません。
1CCUは1コア2GBのリソースに相当します。
Serverlessサービスのスケーリング戦略は、モニタリングコンピューティング層を利用して実現されます。業務負荷状況をモニタリングし、スケールアウトまたはスケールイン戦略がトリガーされると、システムはコンピューティングリソースに対して自動スケールアウトまたはスケールインを実行し、その時点で消費されたリソースに対して課金を行います。TDSQL-C for MySQLのServerlessサービスのスケーリングモードは、CPUスケーリングとメモリBuffer Poolスケーリング（略称：メモリBPスケーリング）の2種類に分けられます。以下でそれぞれご紹介します。
CPUスケーリング：CPU使用量が現在のインスタンス仕様の閾値を超えると、システムは直ちにスケールアウトをトリガーします。このスケーリングモードはサブ秒レベルのスケーリングであり、即時フルロードでも無視できる程度です（負荷が急増した場合でも迅速にリソースのスケールアウトを完了でき、スケーリング時間は無視できます）。
メモリBPスケーリング：このスケーリングモードは、CPU使用量とスケーリング時間に基づいてスケーリングを行います。ここで、CPU使用量 = インスタンスのコンピューティングリソース上限に対応するコア数 × インスタンスの現在のCPU使用率、スケーリング時間 = 検出時間（スケールアウト時は2秒、スケールイン時は60秒）+ 実行時間（約3秒）となります。
スケーリングをトリガーするCPU使用量の閾値、対応するインスタンス仕様のサイズ、および対応するBPサイズは以下の表の通りです。
CPU使用量閾値 | 対応インスタンス仕様 | 対応BPサイズ |
0.5コア | 0.5コア1GB | 0.5GB |
1コア | 1コア2GB | 1GB |
2コア | 2コア4GB | 2.4GB |
4コア | 4コア8GB | 5.6GB |
8コア | 8コア16GB | 11.2GB |
16コア | 16コア32GB | 22.4GB |
32コア | 32コア64GB | 51.2GB |
異なるスケーリングモードに対応するスケーリング戦略の説明は、以下の表の通りです。
弾性モード | スケールアウト戦略 | スケールイン戦略 |
CPUエラスティシティ | 策略：インスタンスのCPU使用量が現在のインスタンス仕様に対応するCPU使用量閾値を超えた場合、スケールアップをトリガーします。 例：例えば、現在のインスタンス仕様が2コア4GBで、現在のCPU使用量が1.5コアの場合、次の1秒間のCPU使用量が2.4コアになると、そのインスタンスは直ちにフルロード状態で4コア8GB仕様にスケールアップします。 | 策略：インスタンスのCPU使用量が現在のインスタンス仕様に対応するCPU使用量閾値の1/2を下回った場合、スケールダウンをトリガーします。 例：例えば、現在の仕様が8コア16GBで、現在のCPU使用量が4.6コアの場合、次の1秒間のCPU使用量が3.2コアになると、そのインスタンスは直ちに4コア8GB仕様にスケールダウンします。 |
メモリBPエラスティシティ | 策略：インスタンスのCPU使用量が現在のインスタンス仕様に対応するCPU使用量閾値を2秒間超えた場合、スケールアップをトリガーします。各スケールアップの増分は、現在のインスタンス仕様の2倍となります。 例：例えば、現在のインスタンス仕様が2コア4GBで、現在のCPU使用量が1.5コアの場合、次のモニタリング周期のCPU使用量が2.4コアになると、BPは4コア8GBに対応するサイズにスケールアップされます。 | 策略：インスタンスのCPU使用量が現在のインスタンス仕様に対応するCPU使用量閾値を60秒間下回った場合、スケールダウンをトリガーします。スケールダウン後のインスタンス仕様は現在のインスタンス仕様の1/2となり、スケールダウンごとの増分は0.5CCU（すなわち0.5コア1GB）です。 例：例えば、現在のインスタンス仕様が8コア16GBで、現在のCPU使用量が4.6コアの場合、次のモニタリング周期のCPU使用量が3.2核になると、BPは4コア8GBに対応するサイズにスケールダウンされます。 |
自動起動・停止
注意：
Serverlessサービスの自動一時停止の判断条件はユーザー接続の有無です。ビジネスシナリオでevent_schedulerを使用したSQLの定期トリガー操作が必要な場合、自動一時停止の有効化は推奨しません。
自動一時停止設定の有効化または無効化が必要な場合、実際のビューモードに応じて対応する操作を行ってください。
対象のクラスタ管理ページで、右上のServerless設定をクリックし、ポップアップウィンドウで自動一時停止のチェックを入れるか外します。
対象クラスタ管理ページのインスタンスリストで、操作列のその他>設定調整をクリックし、ポップアップウィンドウで自動一時停止のチェックを入れるか外します。
有効状態では、自動一時停止時間を設定する必要があり、デフォルトは1時間です。データベースがこの時間内に接続がなく、CPU使用も発生しない場合、自動的に一時停止します。一時停止後はコンピューティング課金が発生せず、ストレージは引き続き実際の使用量に基づいて課金されます。
無効状態では、データベースは継続的に稼働し続け、接続やCPU使用がない場合、ユーザーが設定した最小CCU演算能力に基づいて課金されます。これは、ビジネスでハートビート接続を必要とするアプリケーションシナリオに適しています。
手動一時停止
指定データベースに対し、コンソールで実際のビューモードに基づいて手動一時停止操作を実行することも可能です。
一時停止後の手動起動
一時停止状態のデータベースではコンソール機能が利用できません。操作が必要な場合は、データベースが自動起動した後に操作するか、実際のビューモードに応じてコンソールで手動的にServerlessデータベースを起動してください。
継続的な接続とリクエスト転送能力
接続アクセスがある場合、システムは秒単位で一時停止状態のデータベースを自動的に起動します。ユーザーが再接続メカニズムを設定する必要はありません。
TDSQL-C for MySQLのアクセス層には、リクエスト転送を実現するためのリカバリ感知器（略称perceptron）モジュールが追加されています。perceptronはクライアントとのハンドシェイク後、クライアントからクラスタへの接続を切断しません。クラスタが復旧した後、TDSQL-C for MySQLとハンドシェイクを行い、その後レイヤ4パケットを転送します。
全体のプロセス設計では、二つのチャレンジ乱数を使用した認証を採用しています。これにより、中継モジュールperceptronがユーザー名とパスワードを保存しなくてもユーザー名・パスワード検証を完了でき、ユーザーパスワードのセキュリティを保証し、保存パスワードの不一致問題も発生しません。
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）を返答します。
クラスタが一時停止状態の場合は、perceptronのルーティングのみを保持します。クラスタが復旧した場合、システムはperceptronのルーティングとTDSQL-Cのルーティングを同時に保持し、perceptronのルーティング重みを0に設定します。これにより、追加の接続はTDSQL-Cに直接接続され、既存のperceptronとの接続も引き続き通信可能となります。
フィードバック