> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 本番環境ではどの ClickHouse バージョンを使うべきですか？
> このページでは、本番環境で使用する ClickHouse バージョンの選び方に関するガイダンスを提供します
まず、この質問がなぜよく出てくるのかを整理しておきましょう。主な理由は 2 つあります。
1. ClickHouse は非常に速いペースで開発されており、通常、年間に 10 件以上の安定版リリースがあります。そのため選択肢となるリリースが非常に多く、どれを選ぶかはそう簡単ではありません。
2. 自分のユースケースに最適なバージョンを見極めるのに時間をかけたくなく、誰かの助言に従いたいと考えるユーザーもいます。
より本質的なのは 2 つ目の理由なので、まずはこちらから説明し、その後でさまざまな ClickHouse リリースの選び方に戻ります。
## どの ClickHouse バージョンを推奨しますか？
本番環境の責任を手放したくなって、コンサルタントを雇ったり、著名な専門家の意見を鵜呑みにしたりしたくなることがあります。誰かが勧めた特定の ClickHouse バージョンを導入しておけば、何か問題が起きても自分の責任ではなく、その人の責任だと考えられるからです。しかし、この考え方は大きな落とし穴です。自社の本番環境で何が起きているかを、あなた以上に理解している外部の人はいません。
では、アップグレード先の ClickHouse バージョンはどう適切に選べばよいのでしょうか。あるいは、最初に導入する ClickHouse バージョンはどう選べばよいのでしょうか。まず必要なのは、**現実に即したプレプロダクション環境**の構築に投資することです。理想を言えば、完全に同一のシャドーコピーを用意できればよいのですが、通常はコストがかかります。
それほど高いコストをかけずに、プレプロダクション環境の十分な再現性を確保するための重要なポイントを以下に示します。
* プレプロダクション環境では、本番で実行する予定のクエリにできるだけ近いものを実行できるようにする必要があります。
* 凍結したデータを置いただけの read-only 環境にしないでください。
* 典型的なレポートを作成せず、データをコピーするだけの write-only 環境にしないでください。
* スキーマ移行を適用せずに、環境をまっさらにしないでください。
* 実際の本番データとクエリのサンプルを使ってください。`SELECT` クエリが妥当な結果を返せる、代表性のあるサンプルを選ぶようにしてください。データに機密性があり、社内ポリシー上本番環境の外に持ち出せない場合は、難読化を利用してください。
* プレプロダクション環境も、本番環境と同様に監視およびアラートの対象になっていることを確認してください。
* 本番環境が複数の datacenter や region にまたがっているなら、プレプロダクションも同様にしてください。
* 本番環境で、レプリケーション、分散テーブル、連鎖する materialized view のような複雑な機能を使っているなら、プレプロダクションでも同様に設定されていることを確認してください。
* プレプロダクションで、本番とほぼ同じ台数の server や VM をより小さいサイズで使うか、あるいは台数を大幅に減らして同じサイズで使うかにはトレードオフがあります。前者はより多くのネットワーク関連の問題を検出できる可能性がありますが、後者のほうが管理は容易です。
次に投資すべき領域は、**自動テストのインフラストラクチャ**です。ある種のクエリが一度成功したからといって、それが今後も永続的に成功し続けると考えてはいけません。ClickHouse をモックした単体テストがいくつかあるのは問題ありませんが、実際の ClickHouse に対して実行され、重要なユースケースがすべて想定どおりに動作し続けていることを確認する、十分な自動テスト群を用意してください。
さらに一歩進めるなら、その自動テストを [ClickHouse のオープンソースのテストインフラストラクチャ](https://github.com/ClickHouse/ClickHouse/tree/master/tests) に提供することもできます。これは日々の開発で継続的に利用されています。[その実行方法](/ja/resources/develop-contribute/contribute/tests) や、そのフレームワークに合わせて自社のテストを適応させる方法を学ぶには、確かに追加の時間と労力が必要です。しかしその見返りとして、ClickHouse のリリースが stable として公開された時点で、すでにそれらに対するテストが実施済みであることを確保できます。問題が起きてから毎回報告し、その後にバグ修正の実装、backport、release を待つことに時間を費やすより、はるかに有益です。企業によっては、利用しているインフラストラクチャへのこの種のテスト提供を社内ポリシーにしているところさえあります (Google では [Beyonce's Rule](https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html#policies_that_scale_well) と呼ばれています) 。
プレプロダクション環境とテストのインフラストラクチャを整えたら、最適なバージョンの選定は明快です。
1. 新しい ClickHouse releases に対して、自動テストを定期的に実行します。`testing` とマークされている ClickHouse releases に対して実行することもできますが、それらを使って次の段階へ進むことは推奨されません。
2. テストに合格した ClickHouse release をプレプロダクションにデプロイし、すべてのプロセスが想定どおりに動作していることを確認します。
3. 発見した問題は [ClickHouse GitHub Issues](https://github.com/ClickHouse/ClickHouse/issues) に報告します。
4. 大きな問題がなければ、その ClickHouse release を本番環境にデプロイし始めても安全なはずです。[canary releases](https://martinfowler.com/bliki/CanaryRelease.html) や [green-blue deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html) に近いアプローチを実装した段階的リリース自動化に投資すれば、本番環境で問題が起きるリスクをさらに下げられる可能性があります。
お気づきかもしれませんが、上で説明したアプローチに ClickHouse 固有のものは何もありません。本番環境を真剣に考えている人たちは、自分たちが依存しているあらゆるインフラストラクチャに対して同じことをしています。
## ClickHouse リリースはどう選べばよいですか？
ClickHouse のパッケージリポジトリを見ると、2 種類のパッケージがあることがわかります。
1. `stable`
2. `lts` (長期サポート)
以下に、どちらを選ぶべきかの目安を示します。
* `stable` は、デフォルトで推奨しているパッケージです。おおむね毎月リリースされるため、新機能も過度に待たされることなく利用できます。また、直近 3 件の stable リリースについては、診断対応とバグ修正のバックポートがサポートされます。
* `lts` は年 2 回リリースされ、初回リリースから 1 年間サポートされます。次のような場合は、`stable` より `lts` のほうが適しているかもしれません。
* 会社の内部ポリシーで、頻繁なアップグレードや非 LTS ソフトウェアの使用が認められていない。
* ClickHouse を補助的な製品で利用しており、高度な ClickHouse 機能を必要としない、または継続的に更新するための十分なリソースがない。
最初は `lts` が適していると考えていたチームでも、製品にとって重要な新機能が必要になり、結局 `stable` に切り替えるケースは少なくありません。
***
ClickHouse のアップグレードにあたって、もう 1 つ覚えておいていただきたい点があります。私たちは常にリリース間の互換性に配慮していますが、それを維持するのが現実的でない場合もあり、細かな点が変更されることがあります。そのため、アップグレード前には必ず [changelog](/ja/resources/changelogs/oss/2026) を確認し、後方互換性のない変更に関する注意がないか確認してください。