ApsaraDB for ClickHouse:ApsaraDB for ClickHouse クラスターのスケーリング

制限事項

• ZooKeeper 仕様の変更は、2021 年 12 月 1 日以降に作成されたクラスターでのみサポートされています。価格については、「Community-Compatible Edition の ZooKeeper 仕様の価格」をご参照ください。

• ストレージ容量またはストレージタイプのアップグレードでは、クラスターは再起動しません (2021 年 12 月 1 日以降に作成されたクラスターにのみ適用されます)。クラスター仕様または ZooKeeper 仕様を変更すると、クラスターが再起動します。

• [サーバー仕様] または [ZooKeeper 仕様] は、[ストレージ容量] または [ストレージタイプ] の [アップグレード] と同時に変更することはできません。

• ピーク時に ZooKeeper 仕様を変更すると、テーブルのメタデータと実際のデータとの間に不整合が生じる可能性があります。この変更は、オフピーク時または書き込み操作が停止しているときに実行してください。

クラスタータイプ別の影響

操作手順

1. ApsaraDB for ClickHouse コンソールにログインします。

2. 左上隅で、ご利用のクラスターが存在するリージョンを選択します。

3. [クラスター] ページで、[Community-compatible Edition のクラスター] タブをクリックします。

4. 対象のクラスターを見つけます。[アクション] 列で、[変更] をクリックします。

5. [変更] ダイアログボックスで、[スケールアップ] または [スケールダウン] を選択し、[OK] をクリックします。

6. [スペックアップ/スペックダウン] ページで、目的の構成を選択します。デフォルトでは、クラスターには 4 コア、8 GB のメモリを持つ ZooKeeper サービスがあります。リソースのボトルネックを確認するには、[モニタリングとアラート] ページに移動し、[クラスターモニタリング] パネルで ZooKeeper のメトリックを表示します。デフォルトの仕様が不十分な場合は、ZooKeeper の仕様をアップグレードしてください。

7. [今すぐ購入] をクリックし、支払いを完了します。

8. [注文が完了しました] ページで、[コンソール] をクリックします。

9. [Community-compatible Edition のクラスター] リストの [ステータス] 列でクラスターのステータスを確認します。

   • [ストレージ容量] の変更はすぐに有効になります。クラスターのステータスは [実行中] のままです。

   • [サーバー仕様] または [ZooKeeper 仕様] の変更には 10～15 分かかります。操作が完了すると、ステータスは [仕様変更中] から [実行中] に変わります。

スケーリング後の動作

クラスターまたは ZooKeeper の仕様を変更した後、クラスターは再起動します。再起動の所要時間は、データベース、テーブルの数、およびコールドデータの量によって異なります。変更後、一定期間、高頻度のマージ操作が実行される可能性があり、I/O 使用量が増加し、リクエストのレイテンシーが増加する可能性があります。マージ期間の推定については、「移行後のマージ期間の計算」をご参照ください。

スケールアウト方法

スケールイン方法

移行範囲

データ移行を伴うスケールアウトまたは標準スケールイン中、以下のデータが新しいクラスター構成に移行されます。

サポート対象：

• データベース、ディクショナリ、マテリアライズドビュー

• Kafka および RabbitMQ エンジンテーブルを除くすべてのテーブルのテーブルスキーマ

• MergeTree エンジンファミリーテーブルのデータ (増分移行)

サポート対象外：

• Kafka および RabbitMQ エンジンテーブルとそのデータ

• MergeTree 以外のテーブル (外部テーブルや Log ファミリーエンジンテーブルなど) のデータ

制限事項

• スケールアウトまたはスケールインのプロセス全体で DDL 操作は禁止されています。

• 操作中に CPU とメモリの使用量が増加します。推定オーバーヘッド：ノードあたり 5 コア未満、メモリ 20 GB 未満。

• スケーリング後、一定期間、高頻度のマージ操作が続き、I/O 使用量が増加し、リクエストのレイテンシーが増加する可能性があります。マージ期間の推定については、「移行後のマージ期間の計算」をご参照ください。

• スケールアウト後、内部クラスターノードの IP アドレスが変更されます。ご利用のアプリケーションが特定のノード IP アドレスに接続している場合は、VPC CIDR ブロックを再度取得してください。詳細については、「クラスターの VPC CIDR ブロックの取得」をご参照ください。

ステップ 1：Kafka および RabbitMQ エンジンテーブルの処理

ご利用のクラスターに Kafka または RabbitMQ エンジンテーブルがない場合は、このステップをスキップしてください。

1. クラスターにログインします。接続手順については、「DMS を使用した ClickHouse クラスターへの接続」をご参照ください。

2. Kafka および RabbitMQ エンジンテーブルをクエリします：

      SELECT * FROM `system`.`tables` WHERE engine IN ('RabbitMQ', 'Kafka');

3. 各テーブルの CREATE TABLE 文をバックアップします：

      SHOW CREATE TABLE <table_name>;

4. Kafka および RabbitMQ エンジンテーブルを削除します。> 重要： Kafka テーブルを削除する際は、それを参照するマテリアライズドビューも削除してください。そうしないと、スケールアウトまたはスケールイン操作が失敗します。

ステップ 2：MergeTree 以外のテーブルからのデータバックアップ

保持する必要のあるデータを持つ MergeTree 以外のテーブルがクラスターにない場合は、このステップをスキップしてください。

1. 移行が必要なデータを持つ 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')
        ))

2. 特定されたテーブルからデータをバックアップします。手順については、「OSS へのデータバックアップ」をご参照ください。

ステップ 3：コンソールからのスケールアウトまたはスケールイン

1. ApsaraDB for ClickHouse コンソールにログインします。

2. 左上隅で、ご利用のクラスターが存在するリージョンを選択します。

3. [クラスター] ページで、[Community-compatible Edition のクラスター] タブを選択します。

4. 対象のクラスターを見つけます。[アクション] 列で、[変更] をクリックします。

5. [変更] ダイアログボックスで、[スケールアウト] または [スケールイン] を選択し、[OK] をクリックします。

6. チェックウィンドウで、チェックステータスを確認します。[スケールアウト] ウィンドウでは、デフォルトで [移行拡張] が選択されています。[シンプル拡張] を使用するには、[前へ] をクリックし、[スケールアウト] ダイアログボックスで [シンプル拡張] を選択して、[次へ] をクリックします。一般的なチェック失敗の理由：

   • チェックに合格した場合は、[次へ] をクリックします。

   • チェックに失敗した場合は、報告された問題を修正し、[再試行] をクリックします。チェックに合格した後、[次へ] をクリックします。

   失敗	解決策
   一意の分散テーブルが見つからない	ローカルテーブルに対応する分散テーブルがありません。作成してください。
   対応する分散テーブルが一意でない	ローカルテーブルに複数の分散テーブルがあります。1 つだけ保持してください。
   Kafka/RabbitMQ エンジンテーブルが存在する	最初にこれらのテーブルを削除してください (ステップ 1 を参照)。
   マスターレプリカインスタンスに非レプリケートの *MergeTree テーブルがある	レプリカ間でデータが不整合です。不整合を解決してください。
   分散テーブルとローカルテーブルの列が不整合	列定義を揃えてください。
   一部のノードでテーブルが見つからない	すべてのシャードに一致するテーブルを作成してください。マテリアライズドビューの内部テーブルについては、内部テーブルの名前を変更し、マテリアライズドビューを再構築してください。詳細については、「マテリアライズドビューの内部テーブルがシャード間で不整合」をご参照ください。

7. [スペックアップ/スペックダウン] ページで、[サーバーノード] の数と書き込み中断ウィンドウを設定します。書き込み中断ウィンドウの要件：

   • 書き込み中断時間を少なくとも 30 分に設定してください。

   • 操作は 5 日以内に完了する必要があります。ソースクラスターの [データ書き込みの停止] の終了日は、現在の日付から 5 日以内でなければなりません。

   • ビジネスへの影響を減らすため、書き込み中断ウィンドウをオフピーク時に設定してください。

8. [今すぐ購入] をクリックし、支払いを完了します。

9. [注文が完了しました] ページで、[コンソール] をクリックします。

10. [Community-compatible Edition のクラスター] リストの [ステータス] 列でクラスターのステータスを確認します。ステータスが [スケーリング中] から [実行中] に変わると、操作は完了です。スケールアウトまたはスケールイン操作には少なくとも 30 分かかります。正確な所要時間はデータ量によって異なります。

ステップ 4：Kafka および RabbitMQ エンジンテーブルの再作成

ステップ 1 で Kafka または RabbitMQ エンジンテーブルを削除しなかった場合は、このステップをスキップしてください。

クラスターにログインし、ステップ 1 でバックアップした CREATE TABLE 文を実行します。接続手順については、「DMS を使用した ClickHouse クラスターへの接続」をご参照ください。

ステップ 5：MergeTree 以外のテーブルへのデータ復元

ステップ 2 で MergeTree 以外のテーブルデータをバックアップしなかった場合は、このステップをスキップしてください。

クラスターにログインして、手順 2 でバックアップしたデータをインポートします。詳細については、「OSS からのデータのインポート」をご参照ください。

スケーリング後の動作

• マージ操作：操作後、一定期間、高頻度のマージ操作が続き、I/O 使用量が増加し、リクエストのレイテンシーが増加する可能性があります。マージ期間の推定については、「移行後のマージ期間の計算」をご参照ください。

• IP アドレス：スケールアウト後、内部クラスターノードの IP アドレスが変更されます。ご利用のアプリケーションが特定のノード IP に接続している場合は、アプリケーション構成を更新してください。詳細については、「クラスターの VPC CIDR ブロックの取得」をご参照ください。

• データの検証：操作が完了し、クラスターのステータスが [実行中] に戻ったら、データとテーブルが無傷であることを確認してください。