メインコンテンツまでスキップ
メインコンテンツまでスキップ

ClickHouse と Google Cloud Storage の統合

注記

ClickHouse Cloud を Google Cloud 上で使用している場合、このページは適用されません。すでにサービスが Google Cloud Storage を使用しています。GCS からデータを SELECT または INSERT したい場合は、gcs テーブル関数 を参照してください。

ClickHouse は、GCS がストレージとコンピュートを分離することを求めるユーザーにとって魅力的なストレージソリューションであることを認識しています。この実現を助けるために、GCS を MergeTree エンジンのストレージとして使用するサポートが提供されています。これにより、ユーザーは GCS のスケーラビリティとコストの利点、ならびに MergeTree エンジンの挿入およびクエリ性能を活用できます。

GCS に基づく MergeTree​

ディスクの作成​

GCS バケットをディスクとして利用するためには、まず ClickHouse の conf.d フォルダー内の設定ファイルにそれを宣言する必要があります。以下に示すのは GCS ディスク宣言の例です。この設定には、GCS "ディスク"、キャッシュ、およびテーブルが GCS ディスクに作成される際に DDL クエリで指定されるポリシーを構成するための複数のセクションが含まれています。それぞれについて以下に説明します。

storage_configuration > disks > gcs​

この設定の一部はハイライトされたセクションに示されており、以下の内容を指定しています。

  • バッチ削除は実行されません。GCS は現在バッチ削除をサポートしていないため、自動検出はエラーメッセージを抑制するために無効にされています。
  • ディスクのタイプは s3 です。なぜなら、S3 API が使用されているからです。
  • GCS によって提供されたエンドポイント
  • サービスアカウント HMAC キーとシークレット
  • ローカルディスク上のメタデータパス

storage_configuration > disks > cache​

以下に示すハイライトされた例の設定では、ディスク gcs に対して 10Gi のメモリキャッシュが有効になります。

storage_configuration > policies > gcs_main​

ストレージ構成ポリシーにより、データの保存先を選択できます。以下にハイライトされたポリシーは、gcs ディスクにデータを保存することを許可するポリシー gcs_main を指定しています。例えば、CREATE TABLE ... SETTINGS storage_policy='gcs_main' という形で使用します。

このディスク宣言に関連する設定の完全なリストは、ここで見つけることができます。

テーブルの作成​

書き込みアクセス権を持つバケットを使用するようにディスクを構成した場合、以下の例のようにテーブルを作成できるはずです。簡潔さのために、NYC タクシーのカラムのサブセットを使用し、データを GCS に基づくテーブルに直接ストリーミングします：

ハードウェアによっては、この 100 万行のインサートは数分かかる場合があります。進行状況は、system.processes テーブルを通じて確認できます。行数を 1000 万まで調整して、サンプルクエリをいくつか試してみてください。

レプリケーションの取り扱い​

GCS ディスクを使用したレプリケーションは、ReplicatedMergeTree テーブルエンジンを使用して実行することができます。GCS を使用した 2 つの GCP リージョン間での単一シャードの複製ガイドを参照してください。

詳細を学ぶ​

Cloud Storage XML API は、Amazon Simple Storage Service (Amazon S3) などのサービスで機能する一部のツールやライブラリと相互運用可能です。

スレッドの調整に関する詳細は、パフォーマンスの最適化を参照してください。

Google Cloud Storage (GCS) の使用​

ヒント

ClickHouse Cloud ではデフォルトでオブジェクトストレージが使用されています。ClickHouse Cloud で実行している場合は、この手順に従う必要はありません。

デプロイの計画​

このチュートリアルは、Google Cloud でレプリケーションされた ClickHouse デプロイメントを説明するために書かれており、Google Cloud Storage (GCS) を ClickHouse のストレージディスク "タイプ" として使用します。

このチュートリアルでは、Google Cloud Engine の VM に ClickHouse サーバーノードをデプロイし、それぞれにストレージ用の GCS バケットが関連付けられます。レプリケーションは、VM としてデプロイされた ClickHouse Keeper ノードのセットによって調整されます。

高可用性のためのサンプル要件：

  • 2 つの ClickHouse サーバーノード、2 つの GCP リージョンで
  • 2 つの GCS バケット、2 つの ClickHouse サーバーノードと同じリージョンに配置
  • 3 つの ClickHouse Keeper ノード、そのうちの 2 つは ClickHouse サーバーノードと同じリージョンに配置します。3 番目のノードは、最初の 2 つの Keeper ノードのいずれかと同じリージョンに配置できますが、異なるアベイラビリティゾーンに配置する必要があります。

ClickHouse Keeper は 2 つのノードが必要なため、高可用性のために 3 つのノードが必要です。

VM の準備​

3 つのリージョンに 5 つの VM をデプロイします：

リージョンClickHouse サーバーバケットClickHouse Keeper
1chnode1bucket_regionnamekeepernode1
2chnode2bucket_regionnamekeepernode2
3 *keepernode3

* これは、1 または 2 と同じリージョンの異なるアベイラビリティゾーンにすることができます。

ClickHouse のデプロイ​

サンプル構成では chnode1 と chnode2 という名前が付けられた 2 つのホストに ClickHouse をデプロイします。

chnode1 を 1 つの GCP リージョンに、chnode2 を別のリージョンに配置します。このガイドでは、計算エンジンの VM と GCS バケットに us-east1 および us-east4 を使用しています。

注記

設定が完了するまで clickhouse server を起動しないでください。インストールだけを行ってください。

ClickHouse サーバーノードでのデプロイ手順を実行する際は、インストール手順を参照してください。

ClickHouse Keeper のデプロイ​

3 つのホストに クリックハウスキーパーをデプロイし、サンプル構成では keepernode1、keepernode2、keepernode3 と名付けます。keepernode1 は chnode1 と同じリージョンにデプロイし、keepernode2 を chnode2 と一緒に配置し、keepernode3 はどちらかのリージョンに配置できますが、そのリージョンの ClickHouse ノードとは異なるアベイラビリティゾーンに配置する必要があります。

ClickHouse Keeper ノードのデプロイ手順を実行する際は、インストール手順を参照してください。

2 つのバケットを作成​

2 つの ClickHouse サーバーは、異なるリージョンに配置されて高可用性を実現します。各サーバーには同じリージョンに GCS バケットがあります。

Cloud Storage > Buckets で CREATE BUCKET を選択します。このチュートリアルでは、us-east1 と us-east4 のそれぞれに 2 つのバケットが作成されます。バケットは単一リージョン、標準ストレージクラスで、非公開として作成します。プロンプトが表示されたら、パブリックアクセス防止を有効にします。フォルダを作成しないでください。ClickHouse がストレージに書き込むときに作成されます。

バケットを作成し、HMAC キーを生成するための手順を詳しく知りたい場合は、Create GCS buckets and an HMAC key を展開して手順に従ってください：

GCSバケットとHMACキーを作成する

ch_bucket_us_east1​

US East 1 にGCSバケットを作成する

ch_bucket_us_east4​

US East 4 にGCSバケットを作成する

アクセスキーを生成​

サービスアカウントのHMACキーとシークレットを作成​

Cloud Storage > 設定 > 相互運用性を開き、既存のアクセスキーを選択するか、サービスアカウントのキーを作成します。このガイドでは、新しいサービスアカウント用の新しいキーを作成する手順を説明します。

GCSでサービスアカウントのHMACキーを生成する

新しいサービスアカウントを追加​

このプロジェクトに既存のサービスアカウントがない場合は、新しいアカウントを作成します。

GCSで新しいサービスアカウントを追加する

サービスアカウントを作成するには3つのステップがあります。最初のステップでは、アカウントに意味のある名前、ID、説明を付けます。

GCSで新しいサービスアカウント名とIDを定義する

相互運用性設定ダイアログでは、IAMロールStorage Object Adminロールが推奨されます。ステップ2でそのロールを選択してください。

GCSでIAMロールStorage Object Adminを選択する

ステップ3はオプションであり、このガイドでは使用しません。ポリシーに基づいてユーザーにこれらの権限を付与することができます。

GCSで新しいサービスアカウントの追加設定を構成する

サービスアカウントHMACキーが表示されます。この情報を保存してください。ClickHouseの設定で使用されます。

GCSで生成されたHMACキーを取得する

ClickHouse Keeper の設定​

すべての ClickHouse Keeper ノードは、server_id 行（以下の最初にハイライトされた行）を除いて同じ設定ファイルを持っています。ファイルを ClickHouse Keeper サーバーのホスト名で修正し、各サーバーで server_id を raft_configuration の適切な server エントリと一致させるように設定します。この例では server_id が 3 に設定されているため、raft_configuration 内の一致する行もハイライトしています。

  • ホスト名でファイルを編集し、ClickHouse サーバーノードと Keeper ノードから解決できることを確認してください。
  • 各 Keeper サーバーの上にファイルをコピーします（ /etc/clickhouse-keeper/keeper_config.xml）。
  • raft_configuration のエントリ番号に基づいて、各マシンの server_id を編集します。

ClickHouse サーバーの設定​

best practice

このガイドの一部の手順では、/etc/clickhouse-server/config.d/ に設定ファイルを置くことを促されています。これは、Linux システムでの設定オーバーライドファイルのデフォルトの場所です。これらのファイルをそのディレクトリに配置すると、ClickHouse はデフォルトの設定と内容をマージします。これにより、アップグレード中に設定が失われることを避けることができます。

ネットワーキング​

デフォルトでは、ClickHouse はループバックインターフェースでリッスンしますが、レプリケートされたセットアップではマシン間のネットワーキングが必要です。すべてのインターフェースでリッスンします：

リモート ClickHouse Keeper サーバー​

レプリケーションは ClickHouse Keeper によって調整されます。この設定ファイルは、ホスト名とポート番号で ClickHouse Keeper ノードを識別します。

  • ホスト名を Keeper ホストに一致させて編集します。

リモート ClickHouse サーバー​

このファイルは、クラスター内の各 ClickHouse サーバーのホスト名とポートを設定します。デフォルトの設定ファイルにはサンプルのクラスター定義が含まれていますが、完全に構成されたクラスターのみを表示するために、remote_servers エントリに replace="true" タグが追加されており、この設定がデフォルトとマージされたときに remote_servers セクションを追加するのではなく、置き換えます。

  • ファイルをホスト名で編集し、ClickHouse サーバーノードから解決できることを確認してください。

レプリカの識別​

このファイルは、ClickHouse Keeper パスに関連する設定を構成します。具体的には、データがどのレプリカに属しているかを識別するために使用されるマクロです。1 台のサーバーではレプリカが replica_1 と指定され、もう 1 台のサーバーでは replica_2 と指定されるべきです。名前は変更可能で、例えば一方のレプリカがサウスカロライナに保存され、もう一方がノースバージニアに保存されると仮定すると、値は carolina と virginia にすることができます。ただし、各マシンで異なることを確認してください。

GCS におけるストレージ​

ClickHouse のストレージ構成には disks と policies が含まれます。以下で構成されているディスクは gcs という名前で、type は s3 です。このタイプは、ClickHouse が GCS バケットにアクセスする際に AWS S3 バケットのように扱うためです。この構成は、各 ClickHouse サーバーノード用に 2 回必要になります。

以下の構成の中でこれらの置換を行う必要があります。

これらの置換は 2 つの ClickHouse サーバーノード間で異なります：

  • REPLICA 1 BUCKET は、サーバーと同じリージョンにあるバケットの名前に設定する必要があります。
  • REPLICA 1 FOLDER は、1 台のサーバーでは replica_1 に、もう 1 台では replica_2 に変更する必要があります。

これらの置換はどちらのノードでも共通です：

  • access_key_id は、前述の HMAC キーに設定します。
  • secret_access_key は、前述の HMAC シークレットに設定します。

ClickHouse Keeper の開始​

お使いのオペレーティングシステムに応じたコマンドを使用します。例えば：

ClickHouse Keeper のステータスを確認​

netcat を使用して ClickHouse Keeper にコマンドを送信します。例えば、mntr は ClickHouse Keeper クラスターの状態を返します。このコマンドを各 Keeper ノードで実行すると、1 つがリーダーで、他の 2 つがフォロワーであることが確認できます。

ClickHouse サーバーの起動​

chnode1 と chnode2 で以下を実行します：

検証​

ディスク構成の確認​

system.disks には、各ディスクに関するレコードが含まれているはずです：

  • default
  • gcs
  • cache

クラスターで作成されたテーブルが両方のノードに作成されていることを確認​

データが挿入できることを確認​

テーブルに使用されているストレージポリシー gcs_main を確認​

Google Cloud Console での確認​

バケットを見てみると、ストレージ設定ファイルで使用された名前のフォルダが各バケットに作成されているのがわかります。フォルダを展開すると、多くのファイルがデータパーティションを表しているのがわかります。

レプリカ1 用のバケット​

Google Cloud Storage におけるレプリカ 1 のバケット

レプリカ2 用のバケット​

Google Cloud Storage におけるレプリカ 2 のバケット