レガシーSQLがスケーリングのタイムボムである理由：分散型SQLが将来のリスクを回避する方法

※このブログは2025年7月24日に公開された英語ブログ「Why Legacy SQL Is a Scaling Time Bomb: How Distributed SQL Defuses Future Risks」の拙訳です。

ピーク時の障害は決して手加減してくれません。2015年には、ターゲットのウェブサイトがサイバーマンデーに機能停止し、買い物客のカートは処理されずに放置されました。デルタ航空では、単一のソフトウェア障害が重要なシステム全体に波及し、1,300便が欠航しました。アナリストの分析では、わずか100ミリ秒のレイテンシ増加が収益の約1%を減少させることが示されており、グーグルは0.5秒の遅延だけでトラフィックが20%減少するのを確認しています。

こうした大きなニュースの騒ぎの裏で、しばしば静かな破壊者が潜んでいます。それは、1980年代の設計思想を遥かに超えて引き延ばされ、限界に達したレガシーなシングルノードSQLデータベースです。

レガシーSQLエンジンが壁にぶつかる理由

従来のOracle、MySQL、PostgreSQLは、単一サーバーでの給与バッチ処理や支店の端末処理のために設計されました。これらは以下の前提に基づいています。

1. 垂直スケール – より大きなハードウェアを購入する。
2. 稀なフェイルオーバー – アクティブ/パッシブ構成とポケットベル (ページャー) での対応。
3. 固定スキーマ – トランザクションは軽量だが、マイグレーション (スキーマ変更) は大変である。

現在、これらの前提は崩壊しています。マイクロサービスは何百万もの書き込みを吐き出し、ユーザーはシドニーからサンパウロまで、1秒未満の応答時間を期待し、ハードウェア、コンテナ、さらにはアベイラビリティゾーン (AZ) 全体が日常的に障害を起こします。単一のプライマリノードは、今やボトルネックであると同時に単一障害点となっています。

レガシーSQLデータベースに潜む隠れた損益

コスト要因	財務的損害	根本原因
収益損失	1億ドルのEコマースサイトで、ブラックフライデーのわずか5分間のダウンタイムで35万ドルが消失。	垂直スケールする単一プライマリがバーストするトラフィックを吸収できない。
顧客の離脱	+100ミリ秒の遅延 → 売上高が1％減少	レプリカの遅延、スキーマ変更が処理をブロックする。
コンプライアンスの落とし穴	GDPR / CPRAによる罰金。	単一リージョンアーキテクチャでは地域性を保証できない。
イノベーションの停滞	エンジニアリング予算の30〜40%がシャーディング、緊急修正、緊急対応訓練に費やされる。	「最初にすべてを正しく設計する」という固定スキーマと、シャーディング再構築に費やされる週末。

分散型SQL：レガシーSQLの次なる進化

単一の強力なサーバーの代わりに、分散型SQLデータベースは、多数のノードによって支えられた単一の論理的なSQLエンドポイントを提供します。その核となる部分で、これらのデータベースは、従来のSQLデータベースの持つ一貫性と、NoSQLの持つスケーラビリティを組み合わせています。

内部では、各データのシャードが独自のRaftコンセンサスグループ、あるいはマルチRaftアーキテクチャによって管理されています。これにより、多数のシャードが強力な一貫性を維持しながら書き込みを並行して処理することが可能になり、大規模な水平スケーラビリティを実現します。この設計は、Google SpannerやオープンソースのTiDBといったプラットフォームの基盤となっています。

レガシーSQL	分散型SQL
手動シャーディング：再シャーディング時にダウンタイムが発生	柔軟な水平スケール – ノードを追加するだけで拡張可能
結果整合性のあるレプリカ	コンセンサスによる強力な一貫性
アクティブ/パッシブによる高可用性	マルチリージョン、自己修復機能を数秒で実現
OLTP (オンライントランザクション処理) またはOLAP (オンライン分析処理)	ハイブリッドトランザクション + リアルタイム分析

How Distributed SQL Works

エグゼクティブ・サマリー：データは自動的にパーティショニングされ、安全にレプリケーションされるため、単一ノードやリージョン全体の損失が顧客からは見えません。

より具体的な状況を把握するために、土曜の夜の忙しいレストランを想像してみましょう。

このシナリオにおいて、レガシーSQLシステムはシェフが一人だけのキッチンのようなものです。すべての一皿 (前菜、メイン、デザート) がその一人を通過します。注文が少ない時は問題ありませんが、注文が急増すると、そのシェフがボトルネックになってしまいます。シェフが疲弊したり、怪我をしたりすれば、サービスは停止し、客は店を去ってしまいます。

一方、分散型SQLシステムを想像してみてください。それは、グリル担当、ソテー担当、パティシエ、冷製料理担当など、専門のステーションを持つキッチン旅団 (専門部署に分かれたチーム) です。それぞれのステーションが個別に注文を並行処理し、調整役 (それがRaftコンセンサス) が、すべての構成要素が整っているかをチェックしてからテーブルに出します。もし一人の調理人が抜けても、別の調理人がその代わりを務めます。顧客は一切サービスの中断に気づきません。

これがデータベースにとって具体的に何を意味するかというと：

• ステーション ＝ 複数のノードに分散されたデータのシャード。
• 各ステーションは独立して書き込みを処理できるため、スループットが需要に応じて線形にスケールします。
• 調整役 ＝ Raftコンセンサス。すべてのトランザクションが一貫性を保ち、安全にコミットされることを保証します。
• 調理人の交代 ＝ 自動フェイルオーバーとリバランス。ノード障害がユーザーからは見えません。

あなたは (レガシーSQLと同じように) 強力な一貫性を引き続き得られますが、それに加えて大規模な水平スケールと真の耐障害性が手に入ります。これは、ラッシュ時でもサービスを提供し続ける、完全に機能するレストランのキッチンのようなものです。

導入事例

ベンチマークよりも、実際の導入事例がその力を雄弁に物語ります。先進的な企業はすでに、分散型SQLがいかに大規模環境におけるレガシーの制約を排除できるかを実証しています。例えば：

• Flipkartは、700台ものMySQLクラスタを廃止し、オープンソースでMySQL互換の分散型SQLデータベース (TiDB) に統合しました。これにより、メガセールイベント中に毎秒数十万の読み書きを処理しています。
• Catalystは、中核となるSaaSプラットフォームのアーキテクチャを再構築し (PostgreSQL + ElasticsearchからTiDBへ)、クエリパフォーマンスを60倍に高速化し、同時に運用/ストレージコストと複雑性を軽減しました。
• Zhihu (データ量500TB、13億行) は、単一のTiDB分散型SQLクラスタを運用しながら、大規模データセットに対してミリ秒レベルのクエリ時間を維持しています。

これらは、クエリの失敗が即座に収益の損失に繋がる、最重要の本番ワークロードです。

既存のレガシーSQLスタックは時限爆弾なのか？

もしあなたのチームが、新機能をリリースする代わりに障害対応に追われているとしたら、あなたのレガシーSQLスタックが足かせになっているのかもしれません。以下の点をご確認ください。

1. スキーマ変更やキャパシティ不足への回避策に、開発サイクルの20%を費やしていませんか？
2. 書き込み増幅を抑えるためだけに、「コールドデータ」をアーカイブしていませんか？
3. 地域展開プロジェクトの期間を、四半期単位で測定していませんか？
4. 4分間のサービス停止は5万ドル以上の損失につながりますか？
5. データの地域性に関する罰金が、取締役会レベルのリスクとなっていますか？

もし二つ以上当てはまるなら、分散型SQLデータベースを検討する時が来ています。

自由への第一歩

データベースのマイグレーションは、リスクの高い全面的な作り直しを必要としません。小さなところから着手し、効果を実証し、自信をもってスケールさせることが必要です。開始にあたってのヒントをいくつかご紹介します。

1. 最も負担の大きいサービスを選定する。ホットなシャーディング、グローバルな機能、または分析用の補助サービスなどから選びましょう。
2. ライブマイグレーション訓練を実施する。ほとんどのプラットフォームは、バルクロードと変更ストリームのツールを提供しており、ほぼゼロダウンタイムで切り替えが可能です。
3. 測定可能な目標を設定する。(例：2倍のTPSでp99が100ミリ秒未満、30秒未満のフェイルオーバー)
4. 共存を計画する。分散型SQLはMySQLまたはPostgresのワイヤープロトコルで通信するため、ビッグバン方式ではなく、段階的に導入してください。

戦略的見返り

取り組み	レガシーSQLのコスト	分散型SQLの成果
グローバル展開	3〜6か月にわたるシャーディングプロジェクト	1行の配置ルール：無停止での地理的リバランス
プロダクト分析	ETLのラグ + データウェアハウスのコスト	同じデータでOLTPとリアルタイムOLAPを実行
SREの燃え尽き	レプリカラグによる夜間の呼び出し	自己修復アーキテクチャによるSLAの達成
クラウド・ロックイン	ベンダーの乗り換えコスト	オープンソースコア、マルチクラウドの柔軟性

まとめ

安定した決済処理は拍手喝采を浴びるわけではありませんが、静かに収益を成長させます。シームレスなデプロイがSNSで話題になることはありませんが、それによりエンジニアが本来の構築作業に集中できます。そして、トラフィックが急増する一方でデータベースの支出が横ばいになったとき、CFOはそれに気づくでしょう。

待機するということは、レガシーSQLという時限爆弾を、ピークイベントが爆発させるまでスケールし続けることを意味します。分散型SQLへアップグレードすることは、その時限爆弾を継続的なイノベーションのための基盤へと変えるのです。

従来のMySQLのような一般的なレガシーSQLデータベースと分散型SQLがどのように比較されるかを知るために、比較資料をぜひダウンロードしてください。