どのClickHouseバージョンを本番環境で使用すべきですか？
まず最初に、なぜ人々がこの質問をするのかについて話しましょう。主に二つの理由があります：
- ClickHouseは非常に高いスピードで開発されており、通常は年に10回以上の安定版リリースがあります。これにより選択肢が広がりますが、選ぶのは簡単ではありません。
- 一部のユーザーは、どのバージョンが自分のユースケースに最適かを調べる時間を避け、他の誰かのアドバイスに従いたいと考えます。
二つ目の理由はより根本的ですので、まずこちらについて述べ、その後様々なClickHouseリリースのナビゲーションに戻りましょう。
どのClickHouseバージョンをお勧めしますか？
コンサルタントを雇ったり、知られた専門家を信頼して本番環境の責任から解放されたいと考えるのは魅力的です。誰かが勧めた特定のClickHouseバージョンをインストールし、それに問題があれば、自分の責任ではなく他の人の責任と考えることでしょう。この考え方には大きな罠があります。外部の人間が自社の本番環境で何が起こっているのかをあなたよりよく知っていることはありません。
では、どのClickHouseバージョンにアップグレードするかを適切に選択するにはどうすればよいのでしょうか？あるいは、最初のClickHouseバージョンをどう選ぶべきでしょうか？まず最初に、現実的なプレプロダクション環境を設定するために投資する必要があります。理想的には、完全に同一のシャドーコピーであるべきですが、それは通常高額です。
コストをあまりかけずにプレプロダクション環境の合理的な忠実度を得るためのいくつかのポイントをご紹介します：
- プレプロダクション環境では、本番環境で実行する予定のクエリセットにできるだけ近いものを実行する必要があります：
- 固定データを使った読み取り専用にしないでください。
- 単にデータをコピーするだけの書き込み専用にしないでください。典型的なレポートを作成する必要があります。
- スキーマのマイグレーションを適用せずにクリンナップしないでください。
- 実際の本番データとクエリのサンプルを使用してください。
SELECTクエリが合理的な結果を返す代表的なサンプルを選択するようにします。データが機密で内部方針によって本番環境を離れられない場合は、難読化を使用してください。 - プレプロダクションが本番環境と同様の監視およびアラートソフトウェアでカバーされていることを確認してください。
- 本番環境が複数のデータセンターやリージョンに跨がる場合、プレプロダクションも同様にしてください。
- 本番環境でレプリケーション、分散テーブル、カスケーディングマテリアライズドビューなどの複雑な機能を使用している場合は、プレプロダクションでも同様に設定してください。
- プレプロダクションで本番環境とほぼ同数のサーバーやVMを使用するか、サイズは小さいが数は少ないものを使用するかのトレードオフがあります。最初のオプションは追加のネットワーク関連の問題をキャッチする可能性がありますが、後者は管理が容易です。
次に投資するべき領域は自動テストインフラです。ある種のクエリが一度成功裏に実行されたからといって、今後も永遠にそうなるとは限りません。ClickHouseがモックされたユニットテストを持つことは構いませんが、製品には実際のClickHouseに対して実行され、重要なユースケースが期待通りに動作していることを確認する合理的な自動テストのセットを持つことを確認してください。
一歩進んで、これらの自動テストをClickHouseのオープンソーステストインフラに貢献することも可能です。これは日常的な開発に継続的に使用されています。これを実行する方法を学び、そのフレームワークにテストを適応させるのには追加の時間と労力がかかりますが、ClickHouseのリリースが安定版と発表されたときに既にそれに対してテストされていることを保証することで、問題を報告した後の時間を無駄にすることを避けられます。一部の企業では、このようなテストのインフラへの貢献を内部方針として採用しており、(Googleのビヨンセの法則と呼ばれています)。
プレプロダクション環境とテストインフラが整ったら、最適なバージョンの選択は簡単です。
- 新しいClickHouseリリースに対して自動テストを定期的に実行します。
testingとマークされたClickHouseリリースに対しても実行できますが、次のステップに進むことは推奨されません。 - テストに合格したClickHouseリリースをプレプロダクションにデプロイし、すべてのプロセスが期待通りに動作していることを確認します。
- 発見した問題はClickHouse GitHub Issuesに報告します。
- 重大な問題がない場合は、ClickHouseリリースを本番環境にデプロイし始めても安全です。 カナリアリリースやグリーンブルーデプロイメントに似たアプローチを実装する段階的なリリース自動化に投資することで、本番での問題リスクをさらに軽減できます。
お分かりのように、上記で述べたアプローチにはClickHouse特有のものはありません。人々は本番環境を真剣に扱う場合、依存するインフラのすべてに対してこのようなことを行います。
ClickHouseリリースの選び方
ClickHouseパッケージリポジトリの内容を見ると、二種類のパッケージがあることが分かります：
stablelts（長期サポート）
これらを選ぶためのガイダンスは以下の通りです：
stableは、デフォルトで推奨されるパッケージの種類です。おおよそ月に一度リリースされ（それによって新機能が合理的な遅延で提供され）、最新の三つの安定版リリースは診断とバグ修正のバックポートのサポートがあります。ltsは年に二回リリースされ、初回リリースから一年間サポートされます。以下の場合には、stableよりもltsを好むかもしれません：- あなたの会社には頻繁なアップグレードや非LTSソフトウェアの使用を許可しない内部方針があります。
- ClickHouseを更新するためのリソースが十分でない、または複雑なClickHouseの機能を必要としない二次製品で使用しています。
最初はltsが良い考えだと思っていた多くのチームは、結局重要な機能が含まれているためstableに移行することが多いです。
ClickHouseをアップグレードするときにもう一つ覚えておいてほしいことがあります。リリース間の互換性には常に注意を払っていますが、時には保持するのが合理的でなく、若干の詳細が変更されることがあります。したがって、アップグレードする前にチェンジログを確認し、後方互換性のない変更についての注意事項がないか確認してください。