ビジネス要件の変化に応じて、ApsaraDB for ClickHouse Community-Compatible Edition クラスターの構成と規模を調整できます。ApsaraDB for ClickHouse は、垂直スケーリング、スケールアウト、スケールイン操作をサポートしており、コストとパフォーマンスの最適なバランスを実現するのに役立ちます。
スペックアップ、スペックダウン、スケールアウト、スケールインの概要
スペックアップまたはスペックダウンは、スケールアウトまたはスケールインよりも高速で、ビジネスへの影響が少ないです。したがって、クラスターのパフォーマンスがビジネスニーズを満たさない場合は、まずスペックアップまたはスペックダウンを検討してください。
変更タイプ | シナリオ | 原則 | 影響 | 操作 |
スケールアップ/スケールダウン | CPU、メモリ、またはディスクリソースが不足または冗長な場合に、各ノードのリソースを増減させます。 | Community-Compatible Edition クラスターのノード仕様、ストレージ容量、および ZooKeeper 仕様を増減させます。これにより、クラスターの計算能力、ストレージ容量、および分散協調機能がスケールアップします。 説明 ストレージ容量をスケールダウンすることはできません。ストレージ容量を削減するためのソリューションは次のとおりです。
| Community-Compatible Edition クラスターのストレージタイプをアップグレードするか、ストレージ容量を増やすことは、インスタンスに影響しません (2021 年 12 月 1 日以降に作成されたインスタンスのみ)。ただし、クラスター仕様または ZooKeeper 仕様を変更すると、クラスターが再起動します。 重要
| |
スケールアウト |
重要 ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree などのテーブルエンジンを持つテーブルを含むクラスターには、シンプルなスケールアウトを使用しないでください。これらのタイプのテーブルのデータは、同じノード上でのみマージできます。シンプルなスケールアウトは、マージする必要があるデータを異なるノードに分散させ、マージできなくします。 | 移行を伴うスケールアウト: Community-Compatible Edition クラスターのノード数を増やして、計算能力を水平にスケールします。また、既存の既存データを移行および再配布します。 シンプルなスケールアウト: Community-Compatible Edition クラスターのノード数を増やして、計算能力を水平にスケールします。データはローカルテーブルに直接書き込まれ、スケールアウトの前後でノード間のデータバランスは必要ありません。 |
| |
スケールイン |
| Community-Compatible Edition クラスターのノード数を減らしてコストを削減します。 |
|
前提条件
クラスターは Community-Compatible Edition クラスターです。
クラスターは実行中のステータスです。
クラスターに未払いの更新注文がありません。
説明ApsaraDB for ClickHouse コンソールにログインします。ページの右上隅で、[請求] > [費用とコスト] を選択します。左側のナビゲーションウィンドウで、[注文管理] をクリックします。その後、注文の支払いまたはキャンセルができます。
注意事項
垂直スケーリング: 2021 年 12 月 1 日以降に作成された ApsaraDB for ClickHouse Community-Compatible Edition クラスターのみが ZooKeeper 仕様の変更をサポートします。ZooKeeper 仕様の価格設定については、「Community-Compatible Edition の ZooKeeper 仕様の価格設定」をご参照ください。
スケールアウト/スケールイン:
MergeTree エンジンテーブルを持つクラスターがスケールアウトされた後、既存の既存データは新しいクラスターに移行され、自動的に再配布されます。
移行でサポートされている項目は次のとおりです:
データベース、データディクショナリ、マテリアライズドビュー。
テーブルスキーマ: Kafka または RabbitMQ エンジンを使用するテーブルを除くすべてのテーブルスキーマ。
データ: MergeTree ファミリーテーブルからのデータの増分移行。
移行でサポートされていない項目は次のとおりです:
Kafka または RabbitMQ エンジンを使用するテーブルとそのデータ。
重要構成を変更すると、データは新しいインスタンスに移行され、最終的にトラフィックは新しいインスタンスに切り替えられます。Kafka と RabbitMQ のデータが分割されないようにするには、まずソースクラスターから Kafka と RabbitMQ のエンジンテーブルを削除します。変更が完了したら、それらを再作成します。
外部テーブルや Log テーブルなど、MergeTree タイプではないテーブルのデータ。
重要スケールアウトまたはスケールイン操作中に、指定されたプロシージャに従って、サポートされていない項目を手動で処理する必要があります。
スケールアウトまたはスケールイン操作中は、データ定義言語 (DDL) 操作を実行しないでください。そうしないと、データ検証が失敗し、操作全体が失敗する原因となります。
スケールアウト操作後、内部ノードの IP アドレスが変更されます。アプリケーションがデータの書き込みとアクセスにノードの IP アドレスに依存している場合は、クラスターの VPC CIDR ブロックを再度取得する必要があります。詳細については、「クラスターの VPC CIDR ブロックを取得する」をご参照ください。
ローカルディスクを使用するクラスターのみが、ノードを指定したスケールインをサポートします。このモードでは、オフラインになったノードのデータは失われます。標準のスケールインモードでは、データは失われずに再配布されます。
クラスター構成を変更した後、一定期間、頻繁なマージ操作が発生します。これらの操作は I/O 使用量を増加させ、ビジネスリクエストのレイテンシが増加する可能性があります。このレイテンシ増加の潜在的な影響を計画する必要があります。マージ操作の期間を計算する方法については、「移行後のマージ期間を計算する」をご参照ください。
クラスター構成の変更中、クラスターの CPU とメモリ使用量が増加します。ノードあたりの推定リソース使用量は、5 コア未満、メモリ 20 GB 未満です。
コスト
クラスター構成を変更すると、コストも変更されます。実際のコストはコンソールに表示されます。詳細については、「構成変更の課金」をご参照ください。
スケールアップとスケールダウン
ApsaraDB for ClickHouse コンソールにログインします。
ページの左上隅で、クラスターが存在するリージョンを選択します。
[クラスター] ページで、[Community-Compatible Edition インスタンス] タブをクリックします。
対象の [クラスター ID] について、[アクション] 列の [構成の変更] をクリックします。
[構成の変更] ダイアログボックスで、[スケールアップ] または [スケールダウン] を選択し、[OK] をクリックします。
[アップグレード] または [ダウングレード] ページで、目的の構成を選択します。
説明[仕様] を [ストレージ容量] または [ストレージタイプ] の [アップグレード] 中に変更することはできません。
デフォルトでは、クラスターには 4 コアと 8 GB のメモリを持つ ZooKeeper サービスがプロビジョニングされます。[モニタリングとアラート] ページで、[クラスターモニタリング] パネルの ZooKeeper メトリックを表示して、リソースのボトルネックを確認できます。デフォルトの仕様がビジネスニーズに不十分な場合は、サービスを速やかにアップグレードしてください。
[今すぐ購入] をクリックし、支払いプロセスを完了します。
[支払い完了] ページで、[管理コンソール] をクリックします。
[Community-Compatible Edition インスタンス] リストの [ステータス] 列で、ターゲットクラスターのステータスを表示できます。
説明[ストレージ容量] の変更はすぐに適用され、クラスターのステータスは [実行中] になります。
[仕様] と [ZooKeeper 仕様] を変更した後、スケールアップまたはスケールダウン操作には約 10〜15 分かかります。操作は、クラスターのステータスが [アップグレード中/ダウングレード中] から [実行中] に変わると完了します。
スケールアウトとスケールイン
ステップ 1: Kafka および RabbitMQ エンジンを持つテーブルの処理
Kafka または RabbitMQ エンジンを使用するテーブルの移行はサポートされていません。これらのテーブルは手動で処理する必要があります。
クラスターにログインし、次のステートメントを実行して、処理する必要があるテーブルをクエリします。詳細については、「DMS を使用して ClickHouse クラスターに接続する」をご参照ください。
SELECT * FROM `system`.`tables` WHERE engine IN ('RabbitMQ', 'Kafka');各ターゲットテーブルの `CREATE TABLE` ステートメントを表示してバックアップします。
SHOW CREATE TABLE <aim_table_name>;Kafka および RabbitMQ エンジンを使用するテーブルを削除します。
重要Kafka テーブルを削除するときは、それを参照するマテリアライズドビューも削除する必要があります。そうしないと、スケールアウトまたはスケールイン操作が失敗します。
ステップ 2: 非 MergeTree テーブルからビジネスデータをバックアップする
クラスターにログインし、次のステートメントを実行して、データの移行が必要な非 MergeTree テーブルを特定します。
SELECT `database` AS database_name, `name` AS table_name, `engine` FROM `system`.`tables` WHERE (`engine` NOT LIKE '%MergeTree%') AND (`engine` != 'Distributed') AND (`engine` != 'MaterializedView') AND (`engine` NOT IN ('Kafka', 'RabbitMQ')) AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')) AND (`database` NOT IN ( SELECT `name` FROM `system`.`databases` WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL', 'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite') ))データをバックアップします。
特定した非 MergeTree テーブルからデータをバックアップする必要があります。詳細については、「OSS にデータをバックアップする」をご参照ください。
ステップ 3: コンソールでスケールアウトまたはスケールイン操作を実行する
ApsaraDB for ClickHouse コンソールにログインします。
ページの左上隅で、クラスターが存在するリージョンを選択します。
[クラスター] ページで、[Community-Compatible Edition インスタンス] タブを選択します。
対象の [クラスター ID] について、[アクション] 列の [構成の変更] をクリックします。
[構成の変更] ダイアログボックスで、[スケールアウト] または [スケールイン] を選択し、[OK] をクリックします。
スケールアウトまたはスケールインのチェックウィンドウで、チェックステータスを表示します。
説明[スケールアウト] ウィンドウを開くと、デフォルトで [移行を伴うスケールアウト] メソッドが選択されます。[シンプルなスケールアウト] を選択するには、[前へ] をクリックします。[スケールアウトの選択] ダイアログボックスで、[シンプルなスケールアウト] を選択し、[次へ] をクリックして、[アップグレード] ページに進みます。
チェックが成功した場合は、[次へ] をクリックします。
チェックが失敗した場合は、ページに表示されるプロンプトに従って変更を加え、[再試行] をクリックします。チェックが成功したら、[次へ] をクリックします。
スケールアウト操作中のチェック失敗の主な理由は次のとおりです。
一意の分散テーブルが見つからない: ローカルテーブルに対応する分散テーブルがありません。作成する必要があります。
対応する分散テーブルが一意でない: ローカルテーブルに複数の分散テーブルがあります。余分な分散テーブルを削除し、1 つだけ保持してください。
Kafka/RabbitMQ エンジンテーブルはサポートされていません: Kafka または RabbitMQ エンジンテーブルが存在します。それらを削除してください。
プライマリレプリカインスタンスに非レプリケートの
*MergeTreeテーブルがある: レプリカ間でデータが不整合です。これにより、スケールアウトまたはスケールイン操作のデータ移行中に例外が発生します。分散テーブルとローカルテーブルの列が不整合: 分散テーブルとローカルテーブルの列が一致していることを確認する必要があります。そうしないと、スケールアウトまたはスケールイン操作のデータ移行中に例外が発生します。
一部のノードでテーブルが見つからない: 異なるシャードに同じ名前のテーブルを作成する必要があります。マテリアライズドビューの内部テーブルについては、内部テーブルの名前を変更し、名前を変更した内部テーブルを指すようにマテリアライズドビューを再構築します。詳細については、「マテリアライズドビューの内部テーブルがシャード間で不整合」をご参照ください。
[アップグレード] または [ダウングレード] ページで、要件に応じて [サーバーノード数] と書き込み中断時間を設定できます。
説明クラスターのスケールインまたはスケールアウトにはデータ移行が含まれます。移行を成功させるには、書き込み中断時間が次の要件を満たす必要があります:
書き込み中断時間を少なくとも 30 分に設定します。
スケールアウトまたはスケールイン操作は、構成変更が作成されてから 5 日以内に完了する必要があります。したがって、ソースクラスターの [書き込み中断時間] の終了日は、
現在の日付 + 5以下でなければなりません。操作がビジネスに与える影響を軽減するために、書き込み中断時間をオフピーク時の期間に設定します。
[今すぐ購入] をクリックし、プロンプトに従って支払いを完了します。
[購入完了] ページで、[管理コンソール] をクリックします。
[Community-Compatible Edition インスタンス] リストの [ステータス] 列で、ターゲットクラスターのステータスを確認できます。スケールアウトまたはスケールイン操作は、クラスターのステータスが [スケーリング中] から [実行中] に変わると完了します。
スケールアウトまたはスケールイン操作には 30 分以上かかると予想されます。正確な期間はデータ量によって異なります。コンソールに表示されるクラスターのステータスは、実際のタスク実行ステータスを反映しています。
ステップ 4: Kafka および RabbitMQ エンジンを持つテーブルを再作成する
クラスターにログインし、ステップ 1: Kafka および RabbitMQ エンジンを持つテーブルの処理 でバックアップした `CREATE TABLE` ステートメントを実行します。詳細については、「DMS を使用して ClickHouse クラスターに接続する」をご参照ください。
ステップ 5: 非 MergeTree テーブルからビジネスデータを移行する
クラスターにログインし、OSS を使用して ステップ 2: 非 MergeTree テーブルからビジネスデータをバックアップする でバックアップしたデータを移行します。詳細については、「OSS からデータをインポートする」をご参照ください。