> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> ClickHouse Cloud における Make before break（MBB）の操作を説明するページ
# ClickHouse Cloud における Make before break（MBB）の操作
export const Image = ({img, alt, size}) => {
return
;
};
ClickHouse Cloud は、**Make Before Break** (MBB) アプローチを用いて、クラスターのアップグレードとスケーリングを実行します。
このアプローチでは、古いレプリカをクラスターから削除する前に、新しいレプリカをクラスターに追加します。
これは、先に古いレプリカを削除してから新しいレプリカを追加する break-first アプローチとは対照的です。
MBB アプローチには、いくつかの利点があります。
* 削除前にクラスターへ容量が追加されるため、break-first アプローチとは異なり、**クラスター全体の容量は低下しません**。もちろん、ノード障害やディスク障害などの予期しない事象は、クラウド環境では引き続き発生し得ます。
* このアプローチは、クラスターに高い負荷がかかっている状況で特に有効です。break-first アプローチで起こり得るような、**既存のレプリカへの過負荷を防げる**ためです。
* 先にレプリカを削除するのを待たずに新しいレプリカをすばやく追加できるため、このアプローチでは**より高速で応答性の高い**スケーリングを実現できます。
以下の画像は、サービスを垂直スケーリングする際に、レプリカが 3 つあるクラスターでこれがどのように発生するかを示しています。
全体として、MBB は、従来の break-first アプローチと比べて、シームレスで影響の少ないスケーリングおよびアップグレードを実現します。
MBB では、把握しておくべき重要な挙動がいくつかあります。
1. MBB 操作では、現在のレプリカ上で実行中の既存のワークロードが完了するのを待ってから、そのレプリカを終了します。
この待機期間は現在 1 時間に設定されています。つまり、スケーリングやアップグレードの際には、レプリカを削除する前に、そのレプリカ上で長時間実行されているクエリの完了を最大 1 時間待つ場合があります。
また、レプリカ上でバックアップ処理が実行中の場合は、その処理が完了してからレプリカを終了します。
2. レプリカが終了されるまでに待機時間があるため、クラスターのレプリカ数が、設定されている最大レプリカ数を一時的に上回ることがあります。
たとえば、合計 6 個のレプリカを持つサービスで MBB 操作が進行中の場合、追加で 3 個のレプリカがクラスターに加わり、古いレプリカが引き続きクエリを処理している間は、合計 9 個のレプリカになる可能性があります。
つまり、一定期間は、クラスターのレプリカ数が想定される数を上回ることになります。
さらに、複数の MBB 操作が重なることで、レプリカが蓄積される場合もあります。これは、たとえば API 経由でクラスターに複数の垂直スケーリング要求が送信された場合に発生し得ます。
ClickHouse Cloud には、クラスターに蓄積されるレプリカ数を制限するためのチェック機構があります。
3. MBB 操作では、system table のデータが 30 日間保持されます。つまり、クラスターで MBB 操作が発生するたびに、30 日分の system table データが古いレプリカから新しいレプリカへ複製されます。
MBB 操作の仕組みについてさらに詳しく知りたい場合は、ClickHouse エンジニアリングチームによるこちらの[ブログ記事](https://clickhouse.com/blog/make-before-break-faster-scaling-mechanics-for-clickhouse-cloud)をご覧ください。