ストレージとコンピュートの分離
概要
このガイドでは、ClickHouseとS3を使用してストレージとコンピュートを分離したアーキテクチャの実装方法を探ります。
ストレージとコンピュートの分離は、計算リソースとストレージリソースが独立して管理されることを意味します。ClickHouseでは、これによりスケーラビリティ、コスト効率、および柔軟性が向上します。必要に応じてストレージとコンピュートリソースを別々にスケールさせることができ、パフォーマンスとコストを最適化できます。
S3をバックエンドとして使用するClickHouseは、「コールド」データに対するクエリパフォーマンスがそれほど重要でないユースケースに特に有用です。ClickHouseは、MergeTree
エンジンに対してS3をストレージとして使用するためのサポートを提供し、S3BackedMergeTree
を使用します。このテーブルエンジンを使用することで、ユーザーはS3のスケーラビリティとコストメリットを享受しながら、MergeTree
エンジンの挿入およびクエリパフォーマンスを維持できます。
ストレージとコンピュートアーキテクチャを実装および管理することは、標準的なClickHouseデプロイメントと比較してより複雑であることに注意してください。セルフマネージドのClickHouseでは、このガイドで説明したようにストレージとコンピュートの分離が可能ですが、設定なしでこのアーキテクチャでClickHouseを使用できるClickHouse Cloudの利用をお勧めします。このサービスでは、SharedMergeTree
テーブルエンジンを使用します。
このガイドは、ClickHouseのバージョン22.8以上を使用していることを前提としています。
AWS/GCSのライフサイクルポリシーを構成しないでください。これはサポートされておらず、テーブルが壊れる可能性があります。
1. ClickHouseディスクとしてS3を使用する
ディスクの作成
ClickHouseのconfig.d
ディレクトリに新しいファイルを作成して、ストレージ構成を保存します:
新しく作成したファイルに以下のXMLをコピーし、BUCKET
、ACCESS_KEY_ID
、SECRET_ACCESS_KEY
をデータを保存したいAWSバケットの詳細に置き換えます:
S3ディスクの設定をさらに指定する必要がある場合、たとえばregion
を指定したりカスタムHTTPheader
を送信したりする場合は、関連する設定のリストをこちらで見つけることができます。
次のようにaccess_key_id
とsecret_access_key
を置き換えることもでき、環境変数やAmazon EC2メタデータから認証情報を取得しようとします:
構成ファイルを作成した後、ファイルの所有者をclickhouseユーザーとグループに更新する必要があります:
これで、ClickHouseサーバーを再起動して変更を適用します:
2. S3によるバックアップテーブルの作成
S3ディスクが正しく構成されたかをテストするために、テーブルの作成とクエリを試みることができます。
新しいS3ストレージポリシーを指定してテーブルを作成します:
S3BackedMergeTree
としてエンジンを指定する必要がなかったことに注意してください。ClickHouseは、テーブルがS3をストレージとして使用していることを検出すると、エンジンタイプを内部的に自動的に変換します。
テーブルが正しいポリシーで作成されたことを示します:
次の結果が表示されるはずです:
次に、新しいテーブルにいくつかの行を挿入します:
行が挿入されたことを確認しましょう:
AWSコンソールで、データがS3に正常に挿入された場合、ClickHouseが指定したバケットに新しいファイルを作成したことが確認できるはずです。
すべてが正常に機能した場合、ClickHouseを使用してストレージとコンピュートを分離した状態になっています!

3. フォールトトレランスのためのレプリケーションの実装 (オプション)
AWS/GCSのライフサイクルポリシーを構成しないでください。これはサポートされておらず、テーブルが壊れる可能性があります。
フォールトトレランスを実現するために、複数のAWSリージョンに分散された複数のClickHouseサーバーノードを使用し、各ノードにS3バケットを持つことができます。
S3ディスクを使用したレプリケーションは、ReplicatedMergeTree
テーブルエンジンを使用することで実現できます。詳細については、次のガイドを参照してください: