どの ClickHouse バージョンを本番環境で使用するべきですか？

まず最初に、なぜ人々がこの質問をするのかについて話しましょう。主に二つの理由があります。

1. ClickHouse は非常に高い速度で開発されており、通常、年間に 10 回以上の安定版リリースがあります。これは選択肢が非常に多くなることを意味し、決して trivial な選択ではありません。
2. 一部のユーザーは、自分のユースケースに最適なバージョンを見つけるために時間をかけたくなく、他の誰かのアドバイスに従うことを望んでいます。

二つ目の理由はより根本的なものであるため、まずそれについて説明し、その後さまざまな ClickHouse リリースのナビゲーションに戻ります。

どの ClickHouse バージョンを推奨しますか？

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

それでは、どのようにして適切に ClickHouse のバージョンを選ぶのでしょうか？ また、どのようにして最初の ClickHouse バージョンを選べばよいのでしょうか？ まず第一に、現実的なプリプロダクション環境の構築に投資する必要があります。理想的な世界では、完全に同一なシャドーコピーを作成できますが、通常は高価です。

低コストで現実に近いプリプロダクション環境を得るための重要なポイントは次の通りです。

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

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

一歩進んだステップとして、ClickHouse のオープンソーステストインフラストラクチャ にその自動テストを貢献することが考えられます。このインフラは ClickHouse の日常的な開発で継続的に使用されています。どのように実行するかを学ぶためには追加の時間と労力が必要ですどうやって実行するかを確認し、次にそのテストをこのフレームワークに適応させる方法を学ぶ必要がありますが、ClickHouse のリリースが安定版として発表されるときにはすでにそれらのテストを通過していることを確認できるため、問題を報告した後に時間を無駄にし、バグ修正を実施してもらうのを待つのではなく、価値があります。一部の企業では、内部ポリシーとしてこのようなテストの貢献を持つことが一般的です（Google では Beyonce の法則 と呼ばれています）。

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

1. 定期的に新しい ClickHouse リリースに対して自動テストを実行します。testing とマークされた ClickHouse リリースに対しても行うことができますが、それらに対して次のステップに進むことは推奨されません。
2. テストに合格した ClickHouse リリースをプリプロダクションにデプロイし、すべてのプロセスが期待通りに機能していることを確認します。
3. 発見した問題を ClickHouse GitHub Issues に報告します。
4. 重大な問題がなければ、ClickHouse リリースを本番環境にデプロイし始めるのが安全です。 カナリアリリース や 青緑デプロイメント に類似したアプローチを実装する段階的リリースの自動化に投資することで、本番環境での問題のリスクをさらに軽減できます。

ご覧のとおり、上記のアプローチには ClickHouse に特有のものは何もありません。人々は、本番環境を真剣に考慮するならば、自分たちが依存するインフラのためにそれを実行します。

ClickHouse リリースの選び方

ClickHouse パッケージリポジトリの内容を調べると、二種類のパッケージがあることがわかります。

1. stable
2. lts （長期サポート）

それらの間で選択する方法についてのガイダンスは次のとおりです。

• stable はデフォルトで推奨されるパッケージの種類です。これらはおおよそ月ごとにリリースされ（したがって新機能を合理的な遅延で提供し）、最新の三つの安定版リリースは診断やバグ修正のバックポートに関してサポートされています。
• lts は年に二回リリースされ、初回リリースから一年間サポートされます。以下の場合には lts を stable より優先することがあるかもしれません：
  • あなたの会社に頻繁なアップグレードや非 LTS ソフトウェアの使用を許可しない内部ポリシーがある。
  • あなたが ClickHouse を、複雑な ClickHouse 機能を必要としないか、更新を維持するための十分なリソースがない他の二次製品で使用している。

最初は lts の方が良いと考えているチームも、最終的には自分たちの製品にとって重要な最近の機能のために stable に切り替えることが多いです。

ヒント

ClickHouse をアップグレードするときに考慮すべきもう一つのことは、リリース間の互換性を常に確認しているものの、合理的に維持できない場合や、一部の詳細が変更されることがあるということです。アップグレードする前に、変更履歴 を確認して、後方互換性のない変更についての注記がないかを確認してください。