はじめに
ビジネスのトラフィックは日々変動します。真に厄介なのは、規模そのものより「いつ跳ね上がるか分からない」こと。キャンペーンや新製品発売、セール、ゲームリリースなどは一瞬で巨大なスパイクを生みます。しかし、事前にDBキャパシティを厳密に見積もるのは難しく、従来のスケールアップ／アウトは時間がかかり、ダウンタイムのリスクも避けづらいのが現実です。
よくある“深夜メンテ”の流れ
インフラやSREチームの皆さんには、こんな経験があるはずです。
● 翌日の大型イベントに備え、前夜の深夜帯にデータベースをスケールアップ
● MySQLのような単一ノード型だと、インスタンスタイプ変更＝「新マシン起動」→「データ同期」→「フェイルオーバー」という手順が必要。
● 日本主流のクラウドネイティブDBでも、コンピュート拡張時の再起動やフェイルオーバーで瞬断は発生する。アプリケーションへの影響を最小化するには、ユーザーのアクセスが少ない深夜を選ぶしかありません。しかもピークに合わせて過剰にリソースを確保した後は、また深夜にスケールダウン……。非効率と疲弊が積み重なります。
OceanBaseの答え：テナントレベルのエラスティックスケーリング
OceanBaseが提供する「テナント単位のスケーリング」は、このペインポイントを正面から解決します。ポイントは次の3つです。
- いつでも：日中の稼働時間中でも実行可能
- 速い：反映は秒単位
- 透過的：アプリケーション無停止（既存コネクションを維持）
OceanBaseのリソースモデルを理解する
OceanBaseはネイティブ分散DBであり、複数の物理マシンを束ねて1つの「クラスター」を形成します。その上に「テナント」という論理的に独立したDBインスタンスを作り、テナントごとに独立したデータとリソース割当（クォータ）を持ち、互いに完全に分離されています。
● テナント（Tenant）：独立したDBインスタンス相当（MySQL/Oracle互換の“接続先”のイメージ）
● リソース仕様（Unit Config）：CPU、メモリ、IOPS、ログディスクなどのサイズ定義
● リソースユニット（Unit）：実際の割り当て単位。各ノードに分散配置される
● リソースプール（Resource Pool）：ユニットの集合体。テナントは対応するプールから計算・ストレージリソースを得る
比喩で言えば、クラスターは「大規模なオフィスパーク」です。各物理マシンは「ビル」、テナントは「入居企業」。プールが「まとめて借りる部屋のパッケージ」で、ユニットが「各部屋」、そしてUnit Configが「部屋の広さやデスク数の仕様」に当たります。
最短ルートのスケール：リソース仕様調整
テナントのキャパシティ強化には、大きく2つのアプローチがあります。
- リソース仕様（Unit Config）の調整（単一ノード内でのリソース割当増減）
- ノード／データセンター追加などの水平拡張（ユニット数増加やPrimary Zoneの変更）
※物理マシンのスペックアップなど、クラスター基盤自体の拡張については後述します。
本記事の主役は 1)の「リソース仕様の調整」 です。テナントの仕様を変更すると、各ノード上でそのテナントに割り当てられたCPU・メモリ・IOPS等が即時に増減します。先ほどの比喩で言えば「部屋数は増やさず、今ある部屋にデスクを足す」という動きです。データ移行を伴わないため、設定後すぐ（秒単位）に反映されます。突発的なピークが発生しても、日中の運用中に仕様を上げて処理能力をサッと引き上げることができます。
「追加リソース」はどこから？
魔法のようにCPUが生まれるわけではありません。前提として「ユニットが載っているノードに、増分を受け止める空きがある」ことが必要です。その空きは主に次から捻出します。
● ノードの予約リソース：初期設計でリソースを100%使い切らず、緊急スケール用に確保しておく分。
● マルチテナントのタイムシェア（ピークシフト）：ピーク時間帯がズレる業務（＝テナント）間で、一時的に余力を融通し合い、システム全体の効率を向上させる。
ノイジーネイバー（他のテナントへの影響）は大丈夫？
クラスター全体に十分な余力がある前提において、テナントAの割当増は「未割当リソースをAの枠に組み込む」だけの操作です。テナントBの既存の割当は常に保護されており、他の業務に干渉することはありません（※マルチテナントのリソース分離の詳細は別記事にて解説します）。
物理限界という現実
もちろん、単一ノード内で「これ以上デスクを置けない（物理リソースの上限）」状態はいつか訪れます。その場合は基盤側でのスケールが必要です。
● 垂直スケール：より大きいインスタンスタイプへの変更、オンプレミスでのプロセス割当増など
● 水平スケール：物理ノードの追加
これらクラスターレベルの拡張については、次回の記事で掘り下げます。
なぜ「秒単位反映 × 無停止」が可能なのか
従来DBのスケールアップが遅く、リスクフルな理由は、それが「物理レイヤーの操作」だからです。通常、スケールアップには以下のようなステップが必要です。
- ハイスペック機の追加：より大きな規格のサーバーをスタンバイノードとして追加する。
- データ同期待ち：既存データの同期完了を待つ（データ量によっては数時間以上かかることも）。
- フェイルオーバー：スタンバイ機をマスターに昇格させる。この際、ダウンタイムが発生する。
一方、OceanBaseのテナントスケーリングは「スケジューリング層での論理的な変更」です。リソースの空き容量チェックを行い、クォータを書き換えるだけで完了します。物理マシンの交換・データ移動・フェイルオーバーは一切不要で、既存のコネクションは維持されます。だからこそ「深夜のメンテ時間待ち」から解放され、日中に安全にリソースの上げ下げができるのです。
事例：POP MARTの「ジェットコースター」なトラフィックへの対応
デザイナーズトイ大手「POP MART」のオンライン抽選機能は、本番環境での良い検証例です。
人気商品の発売時には約100万人が同時アクセスします。かつては「極端なピーク予測で過剰にリソースを確保 → 前夜にスケールアップ → イベントが終わったらまた深夜にスケールダウン」という疲弊する運用を強いられていました。
そこで同社は多数の独立DBを、3つのOceanBaseクラスター（マルチテナント）に統合しました。現在では、発売日に入ってからでも、日中オンラインのままテナントのクォータを調整し、ピーク後は即座にワンクリックでスケールダウンしています。POP MARTの導入事例によれば、DBのスケーリング時間は従来比で約90%短縮。アプリ側の改修なしに、大規模セール級の高並行アクセス下でも 99.999% のシステム連続性を達成しています。中小規模のトラフィック変動であれば、「部屋にデスクを足す（仕様調整）」だけで十分にさばけるようになりました。
まとめ
● OceanBaseのテナントスケーリングは、キャパシティ運用を「深夜の計画停止」から「日中のオンライン調整」に変える。
● マシン交換・フェイルオーバー・アプリ改修が不要で、秒単位で反映される。ノイジーネイバーもリソース分離によって回避。
● 物理限界に達したら、クラスターレベルの拡張（垂直／水平）へ段階的に移行できる。
これにより、運用の負担を劇的に減らし、夜間対応の疲弊ではなく「ビジネスの成長そのもの」に時間を使える体制へとシフトできます。もちろん、ビジネス規模がさらに拡大し、単一ノードのボトルネックを突破する必要が生じた場合には、クラスターレベルの水平拡張やマシンのスケールアップといった、より上位の拡張手段が求められます。これらについては今後の記事で詳しく解説します