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

まず、なぜ人々がこの質問をするのかという理由について話し合いましょう。主に2つの重要な理由があります。

1. ClickHouseは非常に高い速度で開発されており、通常、年間に10回以上の安定版リリースがあります。これにより、選択肢が広がりますが、選ぶのは簡単ではありません。
2. 一部のユーザーは、自分のユースケースに最適なバージョンがどれかを考える時間を避け、他の誰かのアドバイスに従うことを望んでいます。

2つ目の理由はより根本的であるため、まずその点から始め、次にさまざまなClickHouseリリースを選ぶ方法に戻ります。

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

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

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

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

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

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

次のステップとして、開発の際に継続的に使用されるClickHouseのオープンソーステストインフラストラクチャに自動テストを貢献することも考えられます。これを実行する方法についてどのように実行するかを学び、その後、テストをこのフレームワークに適応させるためには、確かに追加の時間と労力が必要ですが、ClickHouseのリリースが安定版として発表された際に、すでにそれに対してテストされていることを保証することができ、問題を事後に報告し、それからバグ修正が実装され、バックポートされてリリースされるまでの時間を繰り返し浪費するのを防ぐことができます。いくつかの企業は、社内ポリシーとしてこのテスト貢献をインフラストラクチャに利用しています（Googleで呼ばれるビヨンセのルール）。

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

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

ご覧のとおり、上記のアプローチにはClickHouse特有のことは含まれておらず、本番環境を真剣に考慮する場合、人々は依存するすべてのインフラストラクチャでこれを行っています。

ClickHouseリリースの選択方法

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

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

これらの選択に関するガイダンスは以下のとおりです：

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

最初はltsが最適だと思っていた多くのチームは、重要な最近の機能のために結局stableに切り替えることになります。

ヒント

ClickHouseをアップグレードする際にもう一つ考慮すべきことがあります：リリース間の互換性には常に注意を払っていますが、時には合理的でない場合もあり、一部の細かな詳細が変更されることがあります。したがって、アップグレード前に変更履歴を確認し、後方互換性のない変更に関するメモがあるかどうかを確認してください。