垂直スケールでも瞬断は避けられるのか？

これまでの記事では、OceanBaseが、ネイティブ分散アーキテクチャによってアプリケーションをシャーディングから解放する仕組みや、テナントのリソース構成を変更することでトラフィックの変動に秒単位で追従する仕組みを紹介してきました。

テナント（独立したリソース割り当てを持つDBインスタンスに相当）のリソース構成を変更する場合、既存の物理マシン上でCPUやメモリなどの割り当てを再配分するだけで済むため、ハードウェアの変更は不要です。業務時間中でも実行でき、アプリケーションからは完全に透過的で、サービス停止も発生しません。

ただし、この方法にも限界があります。単一マシンで利用できる物理リソースには上限があるためです。テナントへのリソース割り当てが1台のノードで利用できる上限に近づいた場合や、テナントのリソース構成変更だけではビジネス要件を満たせなくなった場合には、次の段階のスケーリングが必要になります。

それが、クラスター内の物理マシンをより高性能なものへ入れ替える垂直スケール（ノードのスペック変更）です。本記事では、この仕組みについて解説します。

OceanBaseのスケーリングアーキテクチャ

OceanBaseでは、リソースを調整する粒度に応じて、スケーリング手法を大きく3つに分類できます。

第1レイヤー：テナントのリソース構成変更

ノード内に十分な空きリソースがあることを前提に、テナントへ割り当てるリソース量だけを変更することで、トラフィックの急増へ秒単位で対応できます。物理マシンの追加や交換は不要で、反映も高速です。
これは最も手軽でコストの低いスケーリング方法であり、別の記事で詳しく解説しました。

第2レイヤー：マシンのスペック変更（垂直スケール）

テナントのリソース構成変更だけでは十分な性能を確保できなくなった場合は、クラスター内の物理マシンそのものを、より高性能なマシンへ入れ替える必要があります。例えば、ビジネスの成長に伴って処理負荷が増加し、32コア構成のノードを64コア構成へ変更するといったケースです。

ノードを追加する水平スケール（スケールアウト）とは異なり、垂直スケールではクラスターの論理トポロジー上のノード数は変わりません。あくまで既存ノードを、より高性能なマシンへ置き換えるアプローチです。

オンプレミス環境では、物理サーバーのハードウェアスペックは固定されています。実際の運用では、次のような手順でマシンを入れ替えます。

$$\text{ハイスペックな新ノードを追加} \rightarrow \text{新ノードへデータを同期} \rightarrow \text{旧ノードを切り離す}$$

一方、OceanBase Cloudでは、このノード追加・削除とデータ移行の一連の処理を、「構成変更」機能として提供しています。クラウド環境で構成変更を実施する場合は、要件に応じて次の2つの方式を選択できます。

1. マシンをまたぐ構成変更（別マシンへの移行）
   標準的な構成変更方式です。システムが高性能な新しいマシンを用意し、データ同期が完了した後に、旧マシンからシームレスに切り替えます。これは、オンプレミス環境で行う「新ノード追加 → データ移行 → 旧ノード切り離し」という一連の作業を自動化したものです。
2. インプレースでの構成変更
   ノード間でデータを移動することなく、既存ノードが利用するCPU・メモリ・ストレージのリソース割り当てを直接拡張する方式です。データ移行を伴わないため、最も短時間で構成変更を完了できます。

第3レイヤー：ノード数の変更（水平スケール）

単一ノードのコンピューティング性能やストレージ容量が限界に達し、より高いスループットやストレージ容量が必要になった場合は、ノードを追加する水平スケール（スケールアウト）によって対応します。
ノード数の増加に応じて読み書き性能をリニアに向上させる仕組みについては、別の記事で詳しく紹介します。

---

マシンの入れ替えによるスケールアップでも、なぜアプリケーションは影響を受けないのか？

より高性能な物理マシンへ入れ替える際には、大規模データ同期やノードの切り替えが発生します。それでも、オンラインサービスを止めずに移行できるのでしょうか。

MySQLでは、一般的には高性能なサーバーを新たなスタンバイとして追加し、レプリケーションによってデータを同期します。しかし、ノード全体のデータを同期するため時間がかかりやすいうえ、プライマリ・スタンバイ間でレプリケーション遅延が発生しやすくなります。

同期完了後はフェイルオーバーを実施しますが、この切り替え時にはコネクションの切断やリクエストエラーなど、瞬断が発生する可能性があります。多くの場合はアクセスの少ない深夜帯にメンテナンスを実施する必要があります。

OceanBaseでも、垂直スケールでは新しいマシンを追加してデータを移行します。しかし、その内部メカニズムはMySQLのような「ノード単位のプライマリ/スタンバイ同期」とは大きく異なります。

前回の記事「テナントのリソース変更」では、オフィスビルの例えで仕組みを説明しました。
物理マシンは「オフィスビル」、テナントへ割り当てられるリソースユニット（Unit）は「企業が借りるオフィス」と考えることができます。前回紹介したテナントのリソース構成変更は、オフィスを移動せずに机や椅子を増やし、より多くのリソースを利用できるようにするイメージです。

しかし、ビルが満室となり、これ以上オフィス内へ机を増やせなくなった場合は、より大きなビルへ移転するしかありません。OceanBaseでも同様です。システムは新しい物理マシン（新しいビル）上に、より大きなUnit（新オフィス）を作成し、既存Unit（旧オフィス）内のレプリカを順番に新しいUnitへ移行します。すべてのレプリカの移行が完了した後、旧Unitを切り離します。

つまり、
$$\text{新しいUnitを追加する} \rightarrow \text{データを同期する} \rightarrow \text{旧Unitを削除する}$$
という一連の処理をシームレスに実行しています。

手順だけを見ると複雑に思えるかもしれません。しかし、OceanBaseのネイティブ分散アーキテクチャによって、データ同期とトラフィック切り替えという2つの重要なフェーズが効率化されているため、アプリケーションからはほぼ無停止で移行できます。

① データ同期の粒度が細かい

OceanBaseでは、データ同期をログストリーム（Log Stream）単位で行います。各ログストリームは、複数のパーティションを管理しており、MySQLのようにノード全体を単位として同期するわけではありません。そのため、同期処理のスケジューリングをより柔軟に行うことができ、MySQLでノード全体の更新順序を維持するために発生しやすい性能上のボトルネックを避けられます。

また、最後のLeader切り替えもログストリーム単位で実施されます。ノード全体を一度に切り替えるのではなく、ログストリームごとに順次切り替えることで影響範囲を局所化できるため、アプリケーションから見ても変化をほとんど意識する必要がありません。

② 同期する物理ログが軽量

MySQLのプライマリ・スタンバイ同期は、論理ログ（binlog）を利用します。スタンバイ側では、受信したbinlogをリレーログへ書き込み、その後に論理リプレイを実行するため、処理経路が長く、オーバーヘッドも大きくなります。

一方、OceanBaseが同期するのは物理ログ（clog）です。物理ログはデータ量が少なく、リプレイも高速です。さらに、前述したログストリーム単位での同期と組み合わせることで、新しいノードは旧ノードへ短時間で追従できます。
その結果、MySQLで発生しやすいレプリケーション遅延の蓄積（追いつかないこと）も抑えられます。

③ Leaderの切り替えをスムーズに実施できる

最終的なトラフィック切り替えでは、OceanBaseはMulti-Paxosプロトコルに基づくLeader Transferを実行します。旧Leaderは、コミット済みトランザクションをすべて完了した後、自律的にLeaderの役割を新しいレプリカへ引き継ぎます。運用者が手動でフェイルオーバーを実施する必要はありません。

さらに、OceanBase Database Proxy（ODP）がルーティングテーブルを自動更新するため、アプリケーションからのリクエストは透過的に新Leaderへ転送されます。

切り替えの瞬間には、ごく少数のリクエストで短時間のリトライが発生する場合があります。しかし、そのリトライはODPが内部で吸収するため、アプリケーション側から見れば、瞬断やエラーとして意識する場面はほとんどありません。

---

ここまでの解説で、アプリケーションから見て瞬断がほとんど発生しないことは分かりました。では、ノードの入れ替え中に、オンラインサービスの性能が大きく変動することはないのでしょうか。

データ移行で業務処理のリソースは圧迫されないのか？

データ同期はバックグラウンドタスクとして実行されます。OceanBaseでは、業務処理とバックグラウンドタスクのリソースを分離する仕組みを備えており、運用者はデータ同期で利用できるCPUやI/Oなどのリソース量を必要に応じて制御できます。データ移行によってオンライン業務のリソースが大きく圧迫されることを防げます。詳細については、「水平スケール」の記事でさらに紹介します。

Leader切り替え時にレイテンシの揺らぎは発生しないのか？

Leader Transferの実行中は、ごく一部のリクエストがLeader切り替えのタイミングと重なる場合があります。ただし、それらのリクエストがエラーになるわけではありません。ODPがバックグラウンドで自動的にリトライやルーティングの更新を行うため、アプリケーション側で特別な対応は不要です。

また、Leaderが担当するのはデータベース全体ではなく、複数のパーティション単位です。切り替えの瞬間に一部リクエストのレスポンスタイムがわずかに増加する可能性はありますが、その影響は局所的であり、システム全体としては安定したサービスを継続できます。

まとめ

より高性能なマシンへ入れ替える垂直スケールでは、大量のデータ同期やノード切り替えが発生します。

OceanBaseは、ログストリーム単位の同期とLeader Transferによるスムーズな切り替えを組み合わせることで、スケールアップ中もサービス継続性を維持しながら、安全にノードを置き換えることができます。

これにより、従来のフェイルオーバーで問題になりやすかった瞬断を大幅に抑えられるだけでなく、深夜などの固定メンテナンス時間に依存せず、必要なタイミングでリソースを拡張できるようになります。

さらに、一部のクラウド環境では、OceanBase Cloudが自動構成変更機能を提供しています。急激なアクセス増加やトラフィックの変動が発生した場合でも、ユーザーが手動で操作することなく、必要に応じてコンピューティングリソースを自動的に拡張できます。

コンピューティングリソースの自動スケールアップを有効にすると、システムはノードのCPU使用率を継続的に監視し、設定したしきい値（例：70%）を一定時間超えた場合、あらかじめ設定した上限に達するまで自動的にリソースを拡張します。

---

もちろん、単一ノードの性能だけでは対応しきれなくなるケースもあります。その場合は、次のステップである水平スケール（スケールアウト）の出番です。OceanBaseがどのようにノードを追加し、ノード数に応じたリニアな性能向上を実現しているのかについては、この記事で詳しく紹介します。