이 가이드에서는 ClickHouse와 S3를 사용해 스토리지와 컴퓨트가 분리된 아키텍처를 구현하는 방법을 살펴봅니다.
스토리지와 컴퓨트를 분리한다는 것은 컴퓨팅 리소스와 스토리지 리소스를 서로 독립적으로 관리한다는 의미입니다. ClickHouse에서는 이를 통해 확장성, 비용 효율성, 유연성을 더욱 높일 수 있습니다. 필요에 따라 스토리지 리소스와 컴퓨트 리소스를 각각 별도로 확장할 수 있으므로 성능과 비용을 최적화할 수 있습니다.
S3 기반 ClickHouse는 특히 「콜드」 데이터에 대한 쿼리 성능이 덜 중요할 때 유용합니다. ClickHouse는 S3BackedMergeTree를 사용해 MergeTree 엔진의 스토리지로 S3를 사용할 수 있도록 지원합니다. 이 테이블 엔진을 사용하면 MergeTree 엔진의 삽입 및 쿼리 성능을 유지하면서도 S3의 확장성과 비용 이점을 활용할 수 있습니다.
스토리지와 컴퓨트를 분리한 아키텍처는 일반적인 ClickHouse 배포보다 구현과 관리가 더 복잡하다는 점에 유의하십시오. 이 가이드에서 설명하듯 자가 관리형 ClickHouse에서도 스토리지와 컴퓨트를 분리할 수 있지만, 구성 없이도 이 아키텍처로 ClickHouse를 사용할 수 있는 SharedMergeTree 테이블 엔진을 제공하는 ClickHouse Cloud 사용을 권장합니다.
이 가이드는 ClickHouse 버전 22.8 이상을 사용한다고 가정합니다.
AWS/GCS 수명 주기 정책은 구성하지 마십시오. 이는 지원되지 않으며 테이블이 손상될 수 있습니다.
1. S3를 ClickHouse 디스크로 사용
config.d 디렉터리에 만드십시오:
vim /etc/clickhouse-server/config.d/storage_config.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>
region을 지정하거나 사용자 지정 HTTP header를 보내는 경우) 관련 설정 목록은 여기에서 확인할 수 있습니다.
또한 access_key_id와 secret_access_key 대신 아래 항목을 사용할 수도 있으며, 이 경우 환경 변수와 Amazon EC2 메타데이터에서 자격 증명을 가져오려고 시도합니다:
<use_environment_credentials>true</use_environment_credentials>
chown clickhouse:clickhouse /etc/clickhouse-server/config.d/storage_config.xml
service clickhouse-server restart
CREATE TABLE my_s3_table
(
`id` UInt64,
`column1` String
)
ENGINE = MergeTree
ORDER BY id
SETTINGS storage_policy = 's3_main';
S3BackedMergeTree로 지정할 필요는 없습니다. ClickHouse는 테이블이 저장소로 S3를 사용한다고 감지하면 내부적으로 엔진 유형을 자동으로 변환합니다.
테이블이 올바른 정책으로 생성되었는지 확인하세요:
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.
3. 장애 허용을 위한 복제 구성(선택 사항)
AWS/GCS 수명 주기 정책은 구성하지 마십시오. 이는 지원되지 않으며 테이블이 손상될 수 있습니다.
ReplicatedMergeTree 테이블 엔진을 사용해 구성할 수 있습니다. 자세한 내용은 다음 가이드를 참조하십시오.
