概要
このガイドでは、ClickHouse と S3 を使用して、ストレージとコンピュートを分離したアーキテクチャを実装する方法を説明します。
ストレージとコンピュートの分離とは、コンピュートリソースとストレージリソースをそれぞれ独立して管理することを意味します。ClickHouse では、これによりスケーラビリティ、コスト効率、柔軟性が向上します。必要に応じてストレージリソースとコンピュートリソースを個別にスケールできるため、パフォーマンスとコストを最適化できます。
S3 をバックエンドストレージとして利用する ClickHouse は、特に「コールド」データに対するクエリ性能がそれほど重要ではないユースケースで有効です。ClickHouse は、S3BackedMergeTree を使用して、MergeTree engine のストレージとして S3 を利用する機能をサポートしています。このテーブルエンジンにより、MergeTree engine の insert とクエリ性能を維持しながら、S3 のスケーラビリティとコスト面での利点を活用できます。
ストレージとコンピュートを分離したアーキテクチャの実装と運用は、標準的な ClickHouse デプロイメントに比べて複雑になる点に注意してください。このガイドで説明するように、セルフマネージドの ClickHouse でもストレージとコンピュートの分離は可能ですが、設定不要でこのアーキテクチャで ClickHouse を利用できる SharedMergeTree テーブルエンジン を備えた ClickHouse Cloud の利用を推奨します。
このガイドは、ClickHouse バージョン 22.8 以降を使用していることを前提としています。
S3 を ClickHouse のディスクとして使用する
ディスクの作成
ストレージ構成を保存するため、ClickHouse の config.d ディレクトリに新しいファイルを作成します。
vim /etc/clickhouse-server/config.d/storage_config.xml新しく作成したファイルに次の XML をコピーし、BUCKET、ACCESS_KEY_ID、SECRET_ACCESS_KEY を、データの保存先となる AWS バケット の詳細に置き換えます。
<clickhouse>
<storage_configuration>
<disks>
<s3_disk>
<type>s3</type>
<endpoint>$BUCKET</endpoint>
<access_key_id>$ACCESS_KEY_ID</access_key_id>
<secret_access_key>$SECRET_ACCESS_KEY</secret_access_key>
<metadata_path>/var/lib/clickhouse/disks/s3_disk/</metadata_path>
</s3_disk>
<s3_cache>
<type>cache</type>
<disk>s3_disk</disk>
<path>/var/lib/clickhouse/disks/s3_cache/</path>
<max_size>10Gi</max_size>
</s3_cache>
</disks>
<policies>
<s3_main>
<volumes>
<main>
<disk>s3_disk</disk>
</main>
</volumes>
</s3_main>
</policies>
</storage_configuration>
</clickhouse>S3 ディスクの設定をさらに細かく指定する必要がある場合は、たとえば region を指定したり、カスタム HTTP header を送信したりできます。関連する設定の一覧はこちらを参照してください。
また、access_key_id と secret_access_key は以下のものに置き換えることもできます。これにより、環境変数と Amazon EC2 メタデータから認証情報の取得が試行されます。
<use_environment_credentials>true</use_environment_credentials>設定ファイルを作成したら、ファイルの所有者を clickhouse ユーザーおよびグループに変更する必要があります:
chown clickhouse:clickhouse /etc/clickhouse-server/config.d/storage_config.xmlこれで、変更を反映するために ClickHouse server を再起動できます:
service clickhouse-server restartS3 をバックエンドにするテーブルを作成する
S3 ディスクが正しく設定されていることを確認するため、テーブルを作成してクエリできるか試します。
新しい S3 ストレージポリシーを指定して、テーブルを作成します。
CREATE TABLE my_s3_table
(
`id` UInt64,
`column1` String
)
ENGINE = MergeTree
ORDER BY id
SETTINGS storage_policy = 's3_main';エンジンを S3BackedMergeTree として指定する必要がなかったことに注意してください。テーブルがストレージに S3 を使用していることを検出すると、ClickHouse は内部的にエンジンタイプを自動的に変換します。
テーブルが正しいポリシーで作成されたことを確認します:
SHOW CREATE TABLE my_s3_table;以下の結果が表示されるはずです:
┌─statement────────────────────────────────────────────────────
│ CREATE TABLE default.my_s3_table
(
`id` UInt64,
`column1` String
)
ENGINE = MergeTree
ORDER BY id
SETTINGS storage_policy = 's3_main', index_granularity = 8192
└──────────────────────────────────────────────────────────────それでは、新しいテーブルにいくつかの行を挿入してみましょう:
INSERT INTO my_s3_table (id, column1)
VALUES (1, 'abc'), (2, 'xyz');行が挿入されていることを確認しましょう:
SELECT * FROM my_s3_table;┌─id─┬─column1─┐
│ 1 │ abc │
│ 2 │ xyz │
└────┴─────────┘
2 rows in set. Elapsed: 0.284 sec.AWS コンソールで、データが正常に S3 に挿入されていれば、指定したバケット内に ClickHouse が新しいファイルを作成していることを確認できます。
すべて正常に動作していれば、これでストレージとコンピュートを分離した ClickHouse を利用できています!

フォールトトレランスのためにレプリケーションを実装する(任意)
耐障害性を確保するには、複数の AWS リージョンに分散配置した複数の ClickHouse server ノードと、各ノードに対応する S3 バケットを使用できます。
S3 ディスクでのレプリケーションは、ReplicatedMergeTree テーブルエンジンを使用することで実現できます。詳細は次のガイドを参照してください。