Contents
ClickHouse Cloud の概要と AWS 向け提供形態
ClickHouse Cloud は、AWS 上でフルマネージドの高速列指向データベースを即座に利用できる SaaS サービスです。本セクションでは、Marketplace 経由と公式セルフサービス UI からの契約方法の違いを整理し、導入時にどちらが自社の要件に合致するか判断できるようにします。
Marketplace とセルフサービス UI の特徴比較
Marketplace とセルフサービス UI はそれぞれ異なる利用シーンに最適化されています。以下の表は、主要な機能と運用上のメリットをまとめたものです。
| 項目 | Marketplace | セルフサービス UI |
|---|---|---|
| 請求統合 | AWS の請求書へ自動集計できるため、コスト管理が一元化されます。 | 個別課金になるため、試用や短期 PoC に向きます。 |
| プロビジョニング方式 | IAM ロールを利用した自動プロビジョニングが可能です（※公式ドキュメントでサポート対象のサービスプリンシパルを必ず確認してください）。 | UI クリックだけでインスタンス作成でき、設定項目は最小限に抑えられます。 |
| 契約管理 | AWS コンソール上で更新・キャンセルが完結します。 | ClickHouse Cloud ポータル内で操作します。 |
| 推奨シーン | 大規模導入・既存の AWS ガバナンスと統合したい場合 | PoC、段階的拡張、開発環境構築 |
結論：既存の AWS 請求・IAM 基盤を活用したい組織は Marketplace を、迅速な試験導入や小規模プロジェクトはセルフサービス UI を選択すると効果的です。
AWS 環境の事前準備：アカウント・IAM ロール・ポリシー
ClickHouse Cloud へ安全に接続するためには、最小権限で動作可能な IAM ロールを用意する必要があります。本セクションでは、ロール作成時のポイントと CloudFormation による自動化手順を解説します。
IAM ロール作成の基本方針
以下は「最低限必要な権限」と「AssumeRole のサービスプリンシパル」に関する公式ドキュメントで示されている推奨設定です（実際に使用する前に最新ドキュメントをご確認ください）。
- AssumeRole プリンシパル：
clickhouse-cloud.amazonaws.comもしくはec2.amazonaws.com等、ClickHouse Cloud が明示しているサービスプリンシパルを利用します。 - 最小権限：ネットワークインターフェイスの取得やロードバランサー設定に必要な API（例：
ec2:DescribeNetworkInterfaces、elasticloadbalancing:*）のみを許可します。
CloudFormation テンプレート例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
AWSTemplateFormatVersion: "2010-09-09" Description: IAM role for ClickHouse Cloud integration (最小権限) Resources: ClickHouseCloudRole: Type: AWS::IAM::Role Properties: RoleName: ClickHouseCloudIntegration AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: clickhouse-cloud.amazonaws.com # 公式で確認したサービスプリンシパルを使用 Action: sts:AssumeRole Policies: - PolicyName: ClickHouseNetworkAccess PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - ec2:DescribeNetworkInterfaces - elasticloadbalancing:* - logs:CreateLogGroup - logs:PutLogEvents Resource: "*" |
実装手順
- 上記内容を
clickhouse-iam.yamlとして保存。 - AWS コンソール → CloudFormation → 「スタックの作成」からテンプレートをアップロードし、任意のスタック名でデプロイ。
- 作成されたロール ARN をコピーし、ClickHouse Cloud の組織設定画面に登録します。
ポイント：コード化した IAM 設定は変更履歴が残り、チーム間で再利用できるため、導入時のヒューマンエラーを大幅に削減できます。
ネットワーク設定：VPC・サブネット・PrivateLink・Security Group
プライベート接続と最小権限のセキュリティグループで構成されたネットワークは、外部からの不正アクセスを防ぎつつ高いパフォーマンスを維持します。本セクションでは、PrivateLink が SaaS 版で必須かどうかの確認手順と、実際にエンドポイントを作成する流れを示します。
PrivateLink の導入要否は公式ドキュメントで確認
ClickHouse Cloud の最新リリースでは、PrivateLink がオプション として提供されているケースもあります。そのため、導入前に以下のページで「必須かオプションか」を必ずチェックしてください。
- https://clickhouse.com/docs/jp/manage/security/aws-privatelink
この確認作業を自動化したい場合は、定期的（例：月1回）に URL の有効性と内容をスクリプトで取得し、変更があれば Slack 等へ通知する仕組みを構築すると便利です。
PrivateLink エンドポイント作成手順（オプション版の場合）
- サービス名取得
- ClickHouse Cloud コンソール → 組織設定 → 「PrivateLink Service Name」をコピー。
- VPC エンドポイントの作成（コンソール）
- VPC ダッシュボード → エンドポイント → エンドポイントの作成。
- カテゴリは「カスタム」、取得した Service name を貼り付けて「Interface」タイプを選択。
- 接続先サブネット（プライベート）と使用する Security Group を指定。
- DNS 名の有効化
- 「エンドポイント DNS 名」の自動生成にチェックし、内部 DNS で
*.privatelink.clickhouse.cloudが解決できるようにします。 - ClickHouse 側で承認
- エンドポイント ID をコンソールの「Endpoint ID」欄に入力し、接続許可を完了させます。
Security Group のベストプラクティス
最小限のポートだけを開放することで、攻撃対象領域を狭められます。ClickHouse Cloud が使用する標準ポートは TCP 8123（HTTP） と TCP 9000（Native TCP） のみです。
| 方向 | プロトコル/ポート | 許可対象 |
|---|---|---|
| インバウンド | TCP 9000 | VPC CIDR（例：10.0.0.0/16） |
| インバウンド | TCP 8123 | 同上 |
| アウトバウンド | - (全て) | デフォルトで許可 |
設定手順
- EC2 コンソール → セキュリティグループ → 「作成」ボタンをクリック。
- 上記表のインバウンド規則を追加し、送信元は自社 VPC の CIDR に限定。
- 作成した SG を PrivateLink エンドポイントに紐付けます。
結論：PrivateLink（オプション）と最小権限 Security Group の組み合わせで、外部からの不正アクセスリスクを実質的に排除しつつ安全な通信が確保できます。
ClickHouse Cloud クラスタ構築と接続設定
本セクションでは、コンソール上でクラスタを作成する具体的手順と、取得したエンドポイント情報を各種クライアント言語で利用する方法を示します。数クリックでプロビジョニングが完了し、すぐにデータ分析を開始できる点が大きな利点です。
コンソールでのクラスタ作成フロー
- ClickHouse Cloud ポータルにサインインし、左メニューから 「Create Cluster」 を選択。
- リージョン：利用したい AWS リージョン（例：ap-northeast-1）を指定。
- インスタンスタイプ：
c6i.large～r6g.xlargeなど、CPU とメモリのバランスで選択。 - ストレージ：SSD（GP3）を推奨し、容量はデータ量＋20% の余裕を持たせます。
- ノード数：最小 2 ノードで冗長化し、後述のスケール手順で増減可能です。
- 必要項目を入力後、「Create」 をクリックすると数分でクラスタが起動します。
作成完了画面には JDBC/ODBC エンドポイント と 認証トークン が表示されますので、メモしておきましょう。
接続情報の取得と主要クライアント言語別設定例
| 項目 | 内容 |
|---|---|
| Host | <cluster-id>.privatelink.clickhouse.cloud（PrivateLink DNS） |
| Port | 9000（Native TCP）または 8123（HTTP） |
| User | default（もしくは事前に作成したユーザー） |
| Password | コンソールで発行されたトークン |
Python（clickhouse‑driver）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
from clickhouse_driver import Client client = Client( host='mycluster.privatelink.clickhouse.cloud', port=9000, user='default', password='YOUR_TOKEN', secure=True # TLS が有効な場合は True ) print(client.execute('SELECT now()')) |
Java（ClickHouse JDBC）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
String url = "jdbc:clickhouse://mycluster.privatelink.clickhouse.cloud:8123/default"; Properties props = new Properties(); props.setProperty("user", "default"); props.setProperty("password", "YOUR_TOKEN"); props.setProperty("ssl", "true"); // TLS が必要な場合 try (Connection conn = DriverManager.getConnection(url, props); Statement stmt = conn.createStatement()) { ResultSet rs = stmt.executeQuery("SELECT now()"); while (rs.next()) { System.out.println(rs.getString(1)); } } |
clickhouse-client（CLI）
|
1 2 3 4 5 6 7 |
clickhouse client \ --host mycluster.privatelink.clickhouse.cloud \ --port 9000 \ --user default \ --password YOUR_TOKEN \ --secure |
ポイント：エンドポイントは PrivateLink DNS を利用することで、インターネット経由のトラフィックを完全に排除できます。
運用・最適化：モニタリング・スケーリング・コスト管理・障害対策
導入後は可観測性と自動スケールが運用の鍵となります。本セクションでは、CloudWatch 連携、オンデマンド／スポットインスタンスを組み合わせたコスト最適化手法、および一般的な障害シナリオへの対処フローをまとめます。
CloudWatch メトリクスと ClickHouse システムテーブルの活用
ClickHouse Cloud は CloudWatch カスタムメトリクス を標準で提供し、CPU・メモリ・ディスク I/O などを外部から可視化できます。また system.metrics テーブルからは詳細な内部指標が取得可能です。
- CloudWatch 連携有効化
- コンソール → 「Monitoring」タブで「Enable CloudWatch Integration」をオンにします。自動的に以下のメトリクスが送信されます。
| メトリクス名 | 説明 |
|---|---|
| ClickHouseCPUUtilization | CPU 使用率（%） |
| ClickHouseMemoryUsage | メモリ使用量（Bytes） |
| ClickHouseReadLatency | ディスク読み取り遅延（ms） |
| ClickHouseQueryCount | 秒間クエリ数 |
- システムテーブルから取得例（Python）
|
1 2 3 4 5 6 |
rows = client.execute( "SELECT metric, value FROM system.metrics WHERE metric IN ('CPUUsage', 'MemoryRSS')" ) for metric, value in rows: print(f'{metric}: {value}') |
- アラート設定
- CloudWatch コンソールで「Alarm」作成し、例として CPUUtilization が 80% 超過時に SNS 通知を送るよう構成します。
スケーリング手順とコスト最適化ポイント
| 操作 | 手順概要 | コスト観点 |
|---|---|---|
| スケールアウト（ノード追加） | コンソール → 対象クラスタ → 「Scale」→ 追加ノード数・インスタンスタイプ選択 → オンデマンド or スポットを指定して適用。 | ベースラインはオンデマンド、余剰分はスポットで割安に確保。 |
| スケールイン（ノード削除） | 同上の「Scale」画面で削減したいノード数を入力し適用 → データは自動リバランスされます。 | 不要なリソースを速やかに削除し、課金停止。 |
ハイブリッド構成の推奨
- ベースライン：常時オンデマンドで最低限必要なノード数を確保。
- ピーク時：スポットインスタンスで追加ノードを投入し、最大約 60% のコスト削減が可能です（ただしスポット回収リスクあり）。
障害シナリオと対処フロー
| 障害 | 主な原因 | 推奨対策 |
|---|---|---|
| 接続タイムアウト | PrivateLink の DNS 解決失敗、Security Group でポート遮断 | nslookup <endpoint> で名前解決確認 → SG に TCP 9000/8123 を許可 |
| 認証エラー | トークン期限切れ、ユーザー設定ミス | コンソールで新トークン発行 → クライアント側に即時反映 |
| 高レイテンシ | VPC ピアリング過負荷、サブネット帯域制限 | CloudWatch の NetworkOut/NetworkIn をモニタし、必要に応じて ENI 増設または CIDR 拡張 |
緊急対応ステップ
- ログ確認：ClickHouse Cloud コンソール → 「Logs」からエラーメッセージ取得。
- AWS 側チェック：VPC フローログ、Security Group 変更履歴を CloudTrail で追跡。
- 再現テスト：
telnet <endpoint> 9000でポート到達性を手動確認。
まとめ：ネットワーク設定と認証情報の不整合が多くの障害原因となります。定期的なチェックリスト実施と自動化された監視・アラートにより、問題を早期に検知し迅速に復旧できます。
追加留意点：公式情報の確認とリンク管理
- PrivateLink 必須性はバージョンや契約形態によって変わる可能性があるため、導入前に必ず最新の ClickHouse Cloud ドキュメント（https://clickhouse.com/docs/jp/manage/security/aws-privatelink）で確認してください。
- IAM ロールの AssumeRole プリンシパルは公式ガイドに記載されたサービスプリンシパルを使用します。本文中の例は2024 年 10 月時点の情報ですので、変更があればドキュメントで最新情報をご確認ください。
- 外部リンクの有効性は時間とともに変わることがあります。URL の定期チェック（例：月次）を自動化し、エラーが検出されたら担当者へ通知する仕組みを構築すると運用負荷が低減します。
これらのポイントを踏まえて準備・導入・運用を行えば、ClickHouse Cloud を安全かつコスト効率よく活用できるでしょう。