ClickHouse/docs/ja/faq/operations/production.md

---
slug: /ja/faq/operations/production
title: 本番環境で使用するべき ClickHouse バージョンは？
toc_hidden: true
toc_priority: 10
---

# 本番環境で使用するべき ClickHouse バージョンは？ {#which-clickhouse-version-to-use-in-production}

まず最初に、なぜこの質問がよくあるのかを考えてみましょう。主な理由は2つあります。

1.  ClickHouseは非常に高い速度で開発されており、通常1年に10以上の安定版リリースがあります。そのため、選択肢が多く、単純ではない選択肢となります。
2.  一部のユーザーは、自分のユースケースに最適なバージョンを見つけるための時間を節約し、他の人のアドバイスに従いたいと考えています。

2番目の理由はより根本的なものなので、まずそれについて話し、その後でさまざまなClickHouseリリースをどうナビゲートするかを解説します。

## 推奨する ClickHouse バージョンは？ {#which-clickhouse-version-do-you-recommend}

コンサルタントを雇ったり、知られた専門家を信頼して本番環境の責任をなくすことは、魅力的な方法です。誰かが推奨した特定のClickHouseバージョンをインストールし、それに問題があれば、それはあなたの責任ではなく、他の人の責任です。この考え方は大きな罠です。外部の人物があなたの会社の本番環境で何が起こっているかをあなたよりも知っていることはありません。

では、どうやって適切にクリックハウスのバージョンを選んでアップグレードすれば良いのでしょうか？または初めてのClickHouseバージョンをどうやって選ぶべきなのでしょうか？まず第一に、**現実的なプレプロダクション環境**を設定するために投資する必要があります。理想的な世界では、それは完全に同一のシャドウコピーである可能性がありますが、それは通常高価です。

以下は、それほど高くないコストでプレプロダクション環境に合理的な忠実度を持たせるための重要なポイントです：

- プレプロダクション環境は、本番で実行する予定のクエリセットにできるだけ近いものを実行する必要があります：
    - 固定データで読み取り専用にしないでください。
    - 単にデータをコピーして典型的なレポートを作成せずに書き込み専用にしないでください。
    - スキーママイグレーションを適用する代わりにデータを削除しないでください。
- 実際の本番データとクエリのサンプルを使用してください。代表的であり、`SELECT`クエリが合理的な結果を返すようなサンプルを選んでください。あなたのデータが機密であり、内部ポリシーが本番環境から離れることを禁じている場合は、難読化を使用してください。
- プレプロダクションが、本番環境と同様に監視およびアラートソフトウェアでカバーされていることを確認してください。
- 本番が複数のデータセンターや地域にまたがっている場合は、プレプロダクションでも同様にしてください。
- 本番がレプリケーションや分散テーブル、マテリアライズドビューの連鎖などの複雑な機能を使用している場合は、プレプロダクションでも同様に設定してください。
- プレプロダクションで本番とほぼ同じ数のサーバーやVMを使用するか、より小さいが同じサイズのものを使用するかについてのトレードオフがあります。前者はネットワーク関連の問題をさらに検出する可能性がありますが、後者の方が管理が容易です。

次に投資するべき分野は、**自動テストインフラストラクチャ**です。ある種類のクエリが1回実行に成功したからといって、それが永遠に成功し続けるとは思わないでください。ClickHouseがモックされたユニットテストをいくつか持つことは問題ありませんが、製品が実際のClickHouseに対して実行され、すべての重要なユースケースが期待通りに動作しているかを確認する合理的な自動テストセットを持っていることを確認してください。

さらに一歩進めて、その自動テストを[ClickHouseのオープンソーステストインフラストラクチャ](https://github.com/ClickHouse/ClickHouse/tree/master/tests)に貢献することもできます。これらは日常的な開発で継続的に使用されます。[実行方法](../../development/tests.md)を学び、そのフレームワークにテストを適用するのに追加の時間と労力が必要になりますが、リリースが安定版として発表される前から既にそれらに対してテストされていることを保証し、問題報告とその後のバグフィックスの報告に時間を無駄にすることを避けることができます。いくつかの企業では、（Googleでは[Beyonce’s Rule](https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html#policies_that_scale_well)と呼ばれる）そういったテスト貢献を内部ポリシーとしていることもあります。

プレプロダクション環境とテストインフラストラクチャを整えたら、最適なバージョンの選択は簡単です：

1.  新しいClickHouseリリースに対して自動テストを定期的に実行します。それを`testing`としてマークされたClickHouseリリースに対して行うこともできますが、それで今後のステップに進むことは推奨されません。
2.  テストに合格したClickHouseリリースをプレプロダクションにデプロイし、すべてのプロセスが期待通りに動作しているかを確認します。
3.  発見した問題を[ClickHouse GitHub Issues](https://github.com/ClickHouse/ClickHouse/issues)に報告してください。
4.  重大な問題がなければ、そのClickHouseリリースを本番環境にデプロイし始めるのが安全です。[カナリアリリース](https://martinfowler.com/bliki/CanaryRelease.html)や[ブルーグリーンデプロイメント](https://martinfowler.com/bliki/BlueGreenDeployment.html)のようなアプローチを実装するための漸進的なリリース自動化に投資すると、本番環境での問題のリスクをさらに軽減できます。

お気づきかもしれませんが、上記のアプローチにはClickHouseに特有のものはありません。人々は本番環境を真剣に考える場合、依存するインフラの任意の部分に対してこれを行います。

## クリックハウスのリリースを選択する方法は？ {#how-to-choose-between-clickhouse-releases}

ClickHouseのパッケージリポジトリの内容を見てみると、2種類のパッケージがあります：

1.  `stable`
2.  `lts` (長期サポート)

どちらを選ぶかのガイドラインは以下の通りです：

- `stable`はデフォルトで推奨するパッケージです。おおよそ毎月リリースされ、新機能を合理的な遅延で提供し、最新の安定版リリースのうち3つが診断とバグフィックスのバックポーティングのサポートを受けます。
- `lts`は半年に一度リリースされ、初期リリースから1年間サポートされます。以下のような場合には、`stable`よりも`lts`を優先するかもしれません：
    - 会社の内部ポリシーが頻繁なアップグレードや非LTSソフトウェアの使用を認めていない。
    - ClickHouseを使用する製品が特に複雑な機能を必要としていなかったり、更新を続けるためのリソースが不足している。

多くのチームは最初は`lts`が適していると考えていても、製品にとって重要な最近の機能のために`stable`に切り替えることがよくあります。

:::tip    
ClickHouseをアップグレードする際に覚えておくべきことがあります：リリース間の互換性は常に注意していますが、時には互換性を保つことが合理的でない場合があり、いくつかの小さな詳細が変更されることがあります。アップグレード前に[Changelog](/docs/ja/whats-new/changelog/index.md)を確認して、後方互換性のない変更についての注意点があるかどうかを確認してください。
:::