ClickHouse Cloud における Make Before Break (MBB) 操作

ClickHouse Cloud は、クラスターのアップグレードおよびクラスターのスケーリングを Make Before Break（MBB）アプローチで行います。このアプローチでは、古いレプリカをクラスターから削除する前に、新しいレプリカをクラスターに追加します。これは、まず古いレプリカを削除してから新しいレプリカを追加する break-first アプローチとは対照的です。

MBB アプローチにはいくつかの利点があります。

容量が削減される前に新しい容量がクラスターに追加されるため、break-first アプローチとは異なり、クラスター全体の容量が低下しません。もちろん、ノードやディスク障害などの予期せぬ事象はクラウド環境では依然として発生し得ます。
このアプローチは、クラスターに高い負荷がかかっている状況で特に有用であり、break-first アプローチとは異なり、既存レプリカへの過負荷を防止します。
先にレプリカの削除完了を待つ必要がなく、レプリカを迅速に追加できるため、より高速かつ応答性の高いスケーリング体験を実現します。

以下の図は、サービスを垂直スケーリングする 3 レプリカ構成のクラスターで、これがどのように行われるかを示しています。

全体として、MBB は、従来使用されていた break-first アプローチと比較して、よりシームレスで影響の少ないスケーリングおよびアップグレード体験をもたらします。

MBB を利用する場合、ユーザーが押さえておくべき重要な挙動がいくつかあります。

MBB オペレーションでは、現在のレプリカ上で動作している既存ワークロードが終了するまで、レプリカの終了（削除）を待機します。この待機時間は現在 1 時間に設定されており、スケーリングやアップグレードは、レプリカ上で実行中の長時間クエリが終了してレプリカが削除されるまで、最大 1 時間待機する場合があります。さらに、バックアップ処理がレプリカ上で実行中の場合、そのレプリカはバックアップが完了するまで保持されてから終了されます。
レプリカが終了される前に待機時間が存在するため、クラスターに設定された最大レプリカ数を一時的に超える状況が発生する可能性があります。たとえば、合計 6 個のレプリカを持つサービスがあり、MBB オペレーションが進行中の場合に、古いレプリカが引き続きクエリを処理している間に追加で 3 個のレプリカがクラスターに追加され、合計 9 個のレプリカになることがあります。これは、一定期間にわたってクラスターが想定しているレプリカ数を上回ることを意味します。さらに、複数の MBB オペレーションが互いに重なって実行され、レプリカが蓄積される可能性もあります。これは、たとえば複数の垂直スケーリング要求が API 経由でクラスターに送信されるシナリオで発生し得ます。 ClickHouse Cloud には、クラスターに蓄積され得るレプリカ数を制限するためのチェックが用意されています。
MBB オペレーションでは、system テーブルのデータは 30 日間保持されます。これは、クラスターで MBB オペレーションが発生するたびに、30 日分の system テーブルデータが古いレプリカから新しいレプリカへ複製されることを意味します。

MBB オペレーションのメカニズムについてさらに詳しく知りたい場合は、ClickHouse エンジニアリングチームによるこちらのブログ記事をご覧ください。