本番環境ではどの ClickHouse バージョンを使うべきか？

まず最初に、そもそもなぜこの質問が挙がるのかについて説明します。主な理由は 2 つあります。

1. ClickHouse は開発スピードが非常に速く、通常 1 年に 10 回以上の安定版リリースが行われます。そのため選択肢となるリリースが幅広く、どれを選ぶかはそれほど単純ではありません。
2. 一部のユーザーは、自分のユースケースに最適なバージョンを見極めるのに時間をかけたくないため、誰か他の人の推奨に従いたいと考えています。

2 つ目の理由の方がより本質的なので、まずはこちらから説明し、その後でさまざまな ClickHouse リリースの中からどれを選ぶべきかを見ていきます。

本番環境ではどの ClickHouse バージョンがおすすめですか？

本番環境の責任を回避するために、コンサルタントを雇ったり、よく知られた専門家を信頼したくなることがあります。誰かに勧められた特定の ClickHouse バージョンをインストールしておけば、問題が起きても自分の責任ではなく、その人の責任だと考えられます。しかし、このような考え方は大きな落とし穴です。外部の人間は、あなたの会社の本番環境で何が起きているかを、あなた以上に理解していることはありません。

では、どの ClickHouse バージョンにアップグレードすべきか、あるいは最初の ClickHouse バージョンをどう選べばよいのでしょうか。まず最初に行うべきなのは、現実的なプレプロダクション環境の構築に投資することです。理想を言えば、本番環境と完全に同一のシャドウコピーにできればよいのですが、通常はコストがかかりすぎます。

以下は、プレプロダクション環境でそれほど高いコストをかけずに、妥当な精度を確保するための重要なポイントです。

• プレプロダクション環境では、本番で実行する予定のクエリとできるだけ近いクエリセットを実行する必要があります:
  • 固定されたデータを使った読み取り専用環境にしないでください。
  • データをコピーするだけで典型的なレポートを作らないような、書き込み専用環境にもしてはいけません。
  • スキーママイグレーションを適用せずに環境を一度リセットするようなことは避けてください。
• 実際の本番データとクエリのサンプルを使用します。SELECT クエリが妥当な結果を返すような、代表性のあるサンプルを選ぶようにしてください。データが機密であり、社内ポリシー上、本番環境の外に持ち出せない場合は、難読化を利用します。
• プレプロダクション環境も、本番環境と同様に、監視およびアラートソフトウェアの対象に含めていることを確認してください。
• 本番環境が複数のデータセンターまたはリージョンにまたがっている場合は、プレプロダクション環境も同様に構成してください。
• 本番環境でレプリケーション、分散テーブル、カスケードするマテリアライズドビューのような複雑な機能を使用している場合、プレプロダクションでも同様に設定されていることを確認してください。
• プレプロダクションで、本番とほぼ同じ台数だがより小さなサイズのサーバーや VM を使うか、あるいは台数は少ないが同じサイズのものを使うかはトレードオフになります。前者はネットワーク関連の問題を追加で検知できる可能性があり、後者は管理が容易です。

次に投資すべき領域は、自動テストインフラストラクチャです。ある種のクエリが一度成功したからといって、それが今後ずっと成功し続けると決めつけてはいけません。ClickHouse をモック化したユニットテストを持つこと自体は問題ありませんが、実際の ClickHouse を対象として実行され、重要なユースケースがすべて期待どおりに動作していることを確認できる、妥当なセットの自動テストをプロダクトに用意しておいてください。

さらに一歩進めるなら、そうした自動テストを ClickHouse のオープンソーステストインフラストラクチャ にコントリビュートすることもできます。これは日々の開発で継続的に利用されているものです。テストの実行方法 を学び、そのフレームワークに自分たちのテストを適合させるには、追加の時間と労力がかかるのは確かです。しかしそのおかげで、安定版としてアナウンスされる際には、そのテスト群に対して ClickHouse のリリースがすでに検証されている状態になり、問題が発生してから毎回レポートを書き、バグ修正が実装・バックポート・リリースされるのを待つという時間の浪費を避けられます。企業によっては、このようなテストのインフラストラクチャへのコントリビュートを、インフラ利用に関する社内ポリシーとして定めているところもあります（Google では Beyonce's Rule と呼ばれています）。

プレプロダクション環境とテストインフラストラクチャが整ったら、最適なバージョンの選択は単純になります。

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

お気付きかもしれませんが、上で説明したアプローチには ClickHouse 固有のものは何もありません。本番環境を真剣に扱う人たちは、依存しているあらゆるインフラストラクチャについて、同じことを行っています。

ClickHouse のリリースをどう選べばよいですか？

ClickHouse のパッケージリポジトリの内容を見ると、次の 2 種類のパッケージがあることが分かります。

1. stable
2. lts (long-term support)

どちらを選ぶかの目安は次のとおりです。

• stable は、デフォルトで推奨するパッケージです。おおよそ毎月リリースされるため（比較的短い遅延で新機能が利用可能になる）、直近 3 つの stable リリースについては、診断およびバグ修正のバックポートがサポートされます。
• lts は年に 2 回リリースされ、最初のリリースから 1 年間サポートされます。次のような場合には、stable よりも lts を選ぶ方が適しているかもしれません。
  • 社内ポリシーにより、頻繁なアップグレードや LTS 以外のソフトウェアの利用が許可されていない。
  • ClickHouse を、複雑な ClickHouse 機能を必要としない、あるいは継続的にアップデートするだけのリソースがない二次的なプロダクトやサービスで利用している。

当初は lts が適切だと考えていた多くのチームも、自分たちのプロダクトにとって重要な新機能が最近のリリースで提供されるため、結局 stable に切り替えるケースがよくあります。

ヒント

ClickHouse をアップグレードする際に、もう 1 点覚えておいてほしいことがあります。ClickHouse では常にリリース間の互換性を注視していますが、互換性を維持することが妥当でない場合もあり、細かな動作が変わることがあります。アップグレードする前に、changelog に後方互換性のない変更に関する記載がないか必ず確認してください。