製品アップデート
製品お知らせ
インスタンス形態概要
TDSQL-C for MySQLは2種類のデータベースインスタンス形態をサポートしています。一方はプリセットリソース、もう一方はサーバーレスです。本稿では、TDSQL-C for MySQLのインスタンス形態の定義、2種類のインスタンス形態の比較、およびインスタンス形態の変換方法をご紹介します。
インスタンス形態の定義
プロビジョンドリソース
インスタンス形態がプリセットリソースであるインスタンスは、固定スペックを事前に割り当てる必要があることを示します。現在、プリセットリソースのクラスタには、1つの読み書きインスタンスと1～15個の読み取り専用インスタンスが存在します。読み取り専用インスタンスタイプに関しては、プリセットリソースのクラスタにプリセットリソースの読み取り専用インスタンスとServerlessの読み取り専用インスタンスの両方をマウント可能であり、さらにLibraDB読み取り専用分析エンジンのマウントもサポートしています。
Serverless
インスタンス形態がServerlessであるインスタンスは、固定スペックを事前に割り当てる必要がなく、実際の使用量に基づいて課金され、ビジネス負荷に応じて自動的にスケーリングされます。これにより、リソースの最大化利用とコストの最適化制御を実現できます。現在、Serverlessのクラスタには1つの読み書きインスタンスが存在します。Serverless単一ノード版の場合、当該クラスタには読み取り専用インスタンスがありません。Serverlessクラスタ版の場合、当該クラスタには1～15個の読み取り専用インスタンスをマウントでき、読み取り専用インスタンスのタイプはServerlessの読み取り専用インスタンスの設定のみをサポートします。
インスタンス形態の比較
適用シーン
プロビジョンドリソース（Serverless未启用）クラスタ | プリセットリソース（Serverless有効化）クラスタ | Serverlessクラスタ |
ビジネス負荷は比較的安定しています。 固定インスタンス仕様がビジネス負荷の変動を満たすことが可能です。 頻繁にロールバックを必要とするゲームプロジェクト。 PB級データストレージアクセスのシナリオ。 書き込みQPSの要求が高いシナリオ。 マスタースレーブ遅延に敏感なシナリオ。 | ビジネストラフィックのピークとボトムが顕著なシナリオ。 負荷が不確定なシナリオ。 既存のプロビジョニング済みリソースのインスタンス形態を維持しつつ、ビジネス変動に対応可能なシナリオ。 | 運用保守コストの削減と運用保守効率の向上を期待するシナリオ。 ビジネスピークは変動が大きいシナリオです。 データベースを低頻度で使用するシナリオ、例えば開発、テスト環境です。 |
ビジネス負荷の変動時のリソース利用
プロビジョニング済みリソースは固定スペックのため、実際のビジネス負荷変動が大きい場合、手動でインスタンスのスケールアップ/ダウンを実施しないと、リソースの浪費（ボトム時期）やリソース不足（ピーク時期）が発生する可能性があります。
Serverlessはダイナミックな弾性スケーリング機能を備えており、使用リソース（CCUとストレージ）はビジネスニーズに応じて適時調整可能です。これにより、全体的なリソースの浪費が少なく、リソース利用率を向上させます。設定されたコンピューティングパワー範囲に基づき、ピーク時には迅速なスケールアウトでビジネスニーズを十分に満たし、ボトム時には自動スケールインで使用コストを効果的に削減します。
プロビジョニング済みリソースとServerlessを比較すると、ビジネス負荷への適合性およびコストの観点から、ビジネス変動が大きいシナリオでは、Serverlessインスタンス形態の方がビジネスニーズに適合しています。
アーキテクチャ形式
コンピューティング
読み書きインスタンス（RW）と読み取り専用インスタンス（RO）は事前設定済みの固定仕様であり、手動でインスタンスのコンピューティング仕様やインスタンス数をスケーリング設定できます。
ストレージ
年/月単位サブスクリプションのストレージスペースは、お客様がビジネス状況に応じてサイズを自主的に選択でき、スケーリングをサポートします。
従量課金のストレージスペースは、お客様が選択したコンピューティング仕様によって上限が決定され、コンピューティング仕様をアップグレードすることでより大きなストレージスペース上限を取得できます。
コンピューティング
読み書きインスタンス（RW）は事前設定済みの固定仕様であり、手動でインスタンスのコンピューティング仕様をスケーリング設定できます。読み取り専用インスタンス（RO）には、プロビジョニング済みリソースの読み取り専用インスタンスとServerless読み取り専用インスタンスが含まれます。プロビジョニング済みリソース部分はビジネス負荷の変化に伴って変更されませんが、Serverless部分はビジネス負荷の変化に応じて弾性的にスケーリング（縦方向）されます。Serverless読み取り専用ノードがビジネス変動に応じてスケーリングするたびに、CCUコンピューティングパワーもそれに応じて増減します。初めて弾性範囲を設定する際は、最小容量を0.25 CCUに、最大容量をより高い値に設定することをお勧めします。
ストレージ
年/月単位サブスクリプションのストレージスペースは、お客様がビジネス状況に応じてサイズを自主的に選択でき、スケーリングをサポートします。
従量課金のストレージスペースは、お客様が選択したコンピューティング仕様によって上限が決定され、コンピューティング仕様をアップグレードすることでより大きなストレージスペース上限を取得できます。
コンピューティング
読み書きインスタンス（RW）と読み取り専用インスタンス（RO）はどちらもServerless形態であり、ビジネス負荷の変化に応じて弾性的にスケーリング（縦方向）されます。Serverless読み取り専用ノードがビジネス変動に応じてスケーリングするたびに、CCUコンピューティングパワーもそれに応じて増減します。お客様はServerless読み取り専用インスタンスの数とコンピューティングパワー範囲を手動で変更できます。
ストレージ
Serverlessクラスタのストレージスペース課金方式は従量課金です。作成時にストレージスペースを選択不要で、実際のデータ量が占有するストレージスペースのサイズに基づいて課金されます。各コンピューティング能力範囲に対応する最大ストレージスペース上限は異なります。詳細はサービスコンピューティング能力設定を参照してください。
デプロイおよび機能
比較項目 | プリセットリソースクラスタ | Serverlessクラスタ |
購入タイプ | 1つのクラスタには1つの読み書きインスタンスと最大15台の読み取り専用インスタンスが構成されます。 | シングルノード版：1台の読み書きインスタンス クラスタ版：1つの読み書きインスタンスと最大15台の読み取り専用インスタンス |
ストレージエンジン | InnoDB | InnoDB |
カーネル | TXSQL LibraDB | TXSQL |
バージョン | MySQL 5.7 MySQL 8.0 | MySQL 5.7 MySQL 8.0 |
インスタンス仕様 | CPUとメモリ、単一インスタンスあたり最大88コア710GB | コンピューティング能力範囲、CCU量、最小コンピューティング能力は0.25、最大コンピューティング能力は64 |
自動バックアップ | デフォルトで7日間保持され、最大1830日間の保持が設定可能です | デフォルトで7日間保持され、最大1830日間の保持が設定可能です |
手動バックアップ | 対応 | 対応 |
バックアップファイル形式 | 論理バックアップ スナップショットバックアップ | 論理バックアップ スナップショットバックアップ |
リストア | 対応 | 対応 |
インスタンスライフサイクル管理 | 対応 | 対応 |
クラスタ管理 | 対応 | 対応 |
モニタリングとアラーム | 対応 | 対応 |
アカウント管理 | 対応 | 対応 |
DMC | 対応 | 対応 |
データベースプロキシ | 対応 | 対応 |
最大テーブル作成数 | データベースの作成数とテーブルの作成数を制限しません。理論上、十分なスペースがあれば、より多くのデータベースとテーブルを作成できます。 | データベースの作成数とテーブルの作成数を制限しません。理論上、十分なスペースがあれば、より多くのデータベースとテーブルを作成できます。 |
読み書き分離 | 対応 | 対応 |
料金
インスタンス形態がプロビジョニングリソースの場合、課金方式は年/月単位サブスクリプションと従量課金をサポートし、課金項目にはコンピューティングとストレージが含まれます。Serverlessを有効にし、Serverless読み取り専用インスタンスがマウントされた場合、当該インスタンスの課金方式はServerlessとなり、クラスタの総費用には固定仕様部分の費用とServerlessの費用が含まれます。
インスタンス形態がServerlessの場合、課金方式はServerlessとなり、課金項目にはコンピューティングとストレージが含まれます。
2種類のインスタンス形態のクラスタを作成する方法
購入ページで異なるインスタンス形態のクラスタを作成できます：
インスタンス形態がプロビジョニングリソースのクラスタを作成する操作方法については、クラスタ作成を参照してください。
インスタンス形態がServerlessのクラスタを作成する操作方法については、Serverless版クラスタの作成を参照してください。
作成済みのクラスタはインスタンス形態の変換をサポートします。
説明：
以下の表は、インスタンス形態の変換シナリオと操作手順をまとめたものです。現在、プロビジョニングリソースのクラスタには、プロビジョニングリソースとServerlessの2種類の読み取り専用インスタンスをマウント可能です。全体としては、コンソール上でインスタンスタイプはプロビジョニングリソースクラスタとして扱われます。
インスタンス形態 | 変換シナリオ | 操作ガイド |
プリセットリソース | プロビジョニングリソースクラスタからServerlessクラスタへの変換 | |
| プロビジョニングリソースクラスタでServerlessを有効化します。 説明： Serverlessを有効化すると、1つのプロビジョニングリソースクラスタで、プロビジョニングリソース読み取り専用ノードとServerless読み取り専用ノードを同時にマウント可能となります。 | |
| プロビジョニングリソースインスタンスをServerlessに変換する。 説明： これは、プロビジョニングリソースクラスタ内のプロビジョニングリソース読み取り専用ノードをServerless読み取り専用ノードに変換することを指します。変換前後でインスタンスIPアドレス、インスタンス名、インスタンスIDは変更されず、この変換シナリオはインスタンスレベルの変換となります。 | |
Serverless | Serverlessからプロビジョニングリソースへの変換はサポートされていません。 | - |
フィードバック