MySQLが初期ウェブでスケールした方法 — 現在も大規模で稼働し続ける理由

なぜMySQLは初期のウェブの基盤になったのか

MySQLが初期ウェブで選ばれた理由はシンプルです: 当時のウェブサイトが必要としていたものに合致していたからです—構造化されたデータを素早く保存・取得し、控えめなハードウェアで動き、小さなチームでも運用しやすいこと。

扱いやすさがありました。素早くインストールでき、一般的なプログラミング言語から接続でき、専任のDBAを雇わなくてもサイトを動かせました。「十分な性能」と低い運用コストの組み合わせが、スタートアップや趣味プロジェクト、中小のビジネスでのデフォルトにしました。

ここでいう“スケール”が実際に意味すること

人々がMySQLが「スケールした」と言うとき、それは通常以下の混合を指します:

• トラフィックの成長: 同時接続数や秒間クエリ数の増加
• データの成長: テーブルが数千行から数百万・数十億行に拡大
• 信頼性への期待: クラッシュやデプロイ、ハードウェア障害を通して稼働し続けること
• コスト制約: エンタープライズ専用の予算なしに上記を達成すること

初期のウェブ企業は単に速度だけでなく、インフラ費用を抑えつつ予測可能な性能と稼働時間を必要としていました。

この記事で振り返る主要なレバー

MySQLのスケーリングの物語は、実践的なトレードオフと再現可能なパターンの物語です:

• スキーマとクエリ設計（何を保存し、どう結合し、何を避けるか）
• インデックス（開発環境で動くか本番で動くかの差）
• キャッシング（ページビューごとにDBを叩かない）
• レプリケーションとリードレプリカ（読み取り負荷を分散）
• シャーディング／パーティショニング（単一DBで対応できなくなったときの分割）

範囲

これはMySQLを実際のウェブトラフィック下で性能を保つために使われたパターンのツアーです—完全なMySQLマニュアルではありません。目的は、データベースがウェブのニーズにどう合致したか、そして同じ考え方がなぜ現在の大規模なプロダクションシステムでも現れるのかを説明することです。

LAMP時代: シンプルさがMySQL普及の助けになった理由

MySQLのブレイクアウトは共有ホスティングと小規模チームが素早くウェブアプリを作る流れと密接に結びついていました。MySQLが「十分に良い」だけでなく、初期ウェブのデプロイや管理、支払いモデルに合致していたのです。

なぜLAMPが初期ホスティングに合っていたのか

LAMP（Linux, Apache, MySQL, PHP/Perl/Python）は、多くの人が手に入れられる標準的なサーバ構成（WebサーバとDBが同一マシンで動く）に合致していました。

ホスティング事業者はこのセットアップをテンプレート化して自動化し、安価に提供できました。開発者はどこでもほぼ同じ環境を想定でき、ローカルから本番へ移す際の驚きを減らせました。

配布戦略としてのシンプルさ

MySQLはインストール、起動、接続が簡単でした。馴染みのあるSQLを話し、シンプルなCLIクライアントがあり、当時の主要言語やフレームワークと統合しやすかった。

運用モデルも扱いやすく、主要プロセスが一つ、設定ファイルは少数、障害モードが明確でした。これにより専業のDBAでなくても一般的なシステム管理者（多くは開発者自身）がデータベースを運用できました。

コスト、アクセス性、コミュニティの勢い

オープンソースであることはライセンス面の障壁を取り除きました。学生プロジェクト、趣味のフォーラム、小さな事業サイトでも同じエンジンを使え、大きな会社と同じ技術基盤を利用できました。

ドキュメント、メーリングリスト、後のオンラインチュートリアルが勢いを生み、ユーザーが増えるほど事例やツール、トラブルシュートが増えていきました。

初期にMySQLがよく扱ったワークロード

多くの初期サイトは読み取り寄りで比較的単純でした: フォーラム、ブログ、CMSページ、小規模なECカタログなど。これらはIDによる高速なルックアップ、最新投稿、ユーザーアカウント、基本的な検索やフィルタリングを必要とし、控えめなハードウェアで効率よく処理できました。

初期のスケーリング圧力: ユーザーと読み取り・書き込みの増加

初期のMySQL導入はしばしば「1台のサーバ、1つのデータベース、1つのアプリ」から始まりました。趣味のフォーラムや小さな会社サイトでは十分でしたが、アプリが人気になると問題が表面化します。ページビューがセッションに、セッションが恒常的なトラフィックになり、データベースは静かな裏方ではなくなります。

なぜ読み取りが優勢になりやすいか

多くのウェブアプリは（今も）読み取りが多いです。ホームページ、商品一覧、プロフィールページは更新1回に対して何千回も閲覧されることがあります。その不均衡が初期のスケーリング判断を形作りました: 読み取りを速くするか、読み取りでDBを叩かないようにできれば、大量のユーザーに対応できます。

ただし、読み取りが多くても重要な書き込みは存在します。サインアップ、購入、コメント、管理者の更新は落とせません。トラフィックが増えると、リードの洪水と“必ず成功しなければならない”書き込みを同時にさばく必要があります。

最初に感じる痛み

トラフィックが増すと問題はシンプルな形で現れます:

• 遅いクエリ: レポート系クエリが多くの行を走査してページが遅くなる
• テーブルロック: 初期の設定では書き込みが読み取りをブロックし合う
• メモリ不足: インデックスやホットデータがメモリに収まらずディスクアクセスが増える

責務を早めに分離する

チームは責務を分けることを学びました: アプリはビジネスロジック、キャッシュは繰り返しの読み取りを吸収、データベースは正確な保存と必要なクエリに集中します。この考え方がクエリチューニング、適切なインデックス、レプリカによるスケールアウトなどの基礎になりました。

ストレージエンジン: 信頼性の大きな転換点

MySQLのユニークな点は、内部に複数のストレージエンジンを持てることです。

ストレージエンジンとは何か

大まかに言うと、ストレージエンジンは行をディスクにどう書くか、インデックスをどう維持するか、ロックをどう扱うか、クラッシュ後にどう振る舞うかを決める部分です。SQLは同じでも、エンジン次第で高速なノートのように振る舞うか、銀行の台帳のように振る舞うかが変わります。

MyISAMとInnoDB（平易な違い）

長い間、多くのMySQLセットアップはMyISAMを使っていました。読み取りに速いことが多い一方で:

• ロック: MyISAMはテーブルレベルロックを多用し、1つの書き込みが他の読み書きをより強くブロックする
• クラッシュ: 不正シャットダウン後にテーブル修復が必要になり、最近の変更を失う可能性がある
• トランザクション: トランザクションをサポートせず、複数ステップの更新の「全部成功か全部失敗か」が保証されない

InnoDBはこれらを覆しました:

• ロック: 行レベルロックで、異なる行を更新する多くのユーザーがいてもブロッキングが減る
• クラッシュリカバリ: より強い耐久性と自動復旧
• トランザクション: フルトランザクションサポートでアプリの振る舞いが予測可能になる

なぜInnoDBが本番デフォルトになったか

ウェブアプリが単なるページ閲覧からログイン、カート、決済、メッセージングなどの安全な書き込みを伴うようになると、正確性と復旧が速度と同じくらい重要になりました。InnoDBはリスタートやトラフィック急増でデータが壊れたりテーブルが塞がったりする恐怖を減らしました。

実務的な結論: エンジン選択は性能だけでなく安全性にも影響する。ロックモデルや障害時の振る舞い、アプリの保証が変わる重要な決定です。

インデックスとクエリ設計: 最初のスケーリング乗数

シャードやリードレプリカ、複雑なキャッシュの前に、多くの早期の勝利は一貫したシフトから来ました: クエリを予測可能にすること。インデックスとクエリ設計は最初の“乗数”で、リクエストごとにMySQLが触るデータ量を減らします。

Bツリーインデックス: 高速なルックアップと全表スキャンの違い

MySQLのインデックスの多くはBツリーに基づいています。これは順序付けられた目録のようなものです: MySQLは正しい場所にジャンプして小さな連続領域を読むことができます。適切なインデックスがないとサーバは行を一つずつ走査することになり、低負荷では遅いだけでも、スケールするとCPU、ディスクI/O、ロック時間、全体のレイテンシが増幅します。

スケールで問題になるクエリのアンチパターン

繰り返し問題を起こしたパターン:

• SELECT *: 不要な列を引き、I/Oを増やし、カバリングインデックスの利点を消す
• 先頭ワイルドカード: WHERE name LIKE '%shoe'は通常のBツリーで効率的に使えない
• インデックス列での関数使用: WHERE DATE(created_at) = '2025-01-01'はインデックス利用を妨げることが多い。代わりに created_at >= ... AND created_at < ... のような範囲フィルタを使う

EXPLAINとスローログを日常ツールにする

どんな小賢しいテクニックよりも有効だった習慣が二つあります:

• **EXPLAIN**を実行して意図したインデックスが使われているか確認する
• スロークエリログを見て機能追加時の回帰を早期に発見する

インデックスは実際の機能に合わせるべき

インデックスはプロダクトの振る舞いに合わせて設計します:

• 検索: ワイルドカード走査の代わりに全文検索やプレフィックス戦略を検討する
• フィード: (user_id, created_at) のような複合インデックスで「最新アイテム」を高速化する
• チェックアウトフロー: 注文/決済識別子にユニークインデックスを張ると重複防止と検索が速くなる

良いインデックス設計は「インデックスを増やすこと」ではなく、重要な読み書きパスに合った少数の正しいインデックスを持つことです。

垂直スケール対水平スケール: 何が変わり、なぜ変わるのか

MySQLを使ったプロダクトが遅くなると、最初の大きな決断は垂直（up）か水平（out）かです。両者は異なる問題を解決し、運用面で大きく違います。

垂直スケール: 「より大きな箱」戦略

垂直スケールは一台のマシンにより多くのリソースを割り当てることです: 高速CPU、より多いRAM、高速ストレージ。

多くのボトルネックはローカルで起きるため意外と効果があります:

• CPU: 複雑なクエリ、ソート、ジョイン、非効率なWHERE句でコアが飽和する
• I/O: データがメモリに収まらないとランダムリード/ライトが増える
• バッファプール/メモリ: InnoDBではRAMを増やすとホットデータとインデックスをキャッシュできる
• 接続数の限界: 同時接続が多すぎるとスレッドやメモリ、コンテキストスイッチで問題が出る

垂直スケールは通常最も速い改善で、移行が比較的簡単な反面、上限がありアップグレードはダウンタイムやリスクを伴うことがあります。

水平スケール: 「より多くの箱」戦略

水平スケールはマシンを増やすことです。MySQLでは一般に:

• 読み取りをレプリカに分散する
• データを分割（シャード）して書き込みを分散するか、ワークフローを再構成する

レプリケーション遅延、フェイルオーバー動作、一貫性のトレードオフなど調整が必要になり、アプリ側もどのサーバに接続するかを知る（あるいはプロキシ層が必要）ようになります。

シャーディングに飛びつかないこと

多くのチームはまずシャーディングを必要としません。どこに時間がかかっているか（CPUかI/Oかロックか）を確認し、遅いクエリとインデックスを直し、メモリとストレージを適切にするのが先です。水平化は、良いチューニングの後でも単一マシンが書き込み率やストレージサイズ、可用性要件を満たせないときに意味を持ちます。

レプリケーションとリードレプリカ: 実務的な読み取りスケール手法

レプリケーションは成長を扱う実用的な方法の一つです: 1台のDBが全部をやる代わりに、データを他のサーバにコピーして作業を分散します。

平易に言えば: プライマリとレプリカ

プライマリ（旧称マスター）は変更を受け付けるDBです。1台以上のレプリカ（旧称スレーブ）がその変更を継続的に引き取り適用して、ほぼリアルタイムにコピーを保ちます。

アプリは通常:

• 書き込みをプライマリに送る
• 多くの読み取りをレプリカに送る

このパターンはウェブトラフィックが読み取り寄りに増える状況で広く使われました。

リードレプリカが使われたケース

リードレプリカはページ表示を速くするだけでなく、以下のような用途で使われました:

• 読み取りスケーリング: 商品ページ、フィード、検索結果など
• 分析・レポーティング: 長時間のクエリをレプリカで走らせてプライマリへの影響を減らす
• バックアップ: ロジカルダンプやバックアップ処理をレプリカで行い本番への影響を減らす

受け入れるべきトレードオフ

レプリケーションはタダではありません。最も一般的な問題はレプリケーション遅延です—ピーク時にはレプリカが数秒以上遅れることがあります。

これによりアプリ側での「書いたものを直ちに読めるか（read-your-writes）」という問題が生じます。ユーザーがプロフィールを更新してすぐレプリカから読むと古いデータが返る可能性があります。多くのチームは更新直後はプライマリから読む、あるいは短時間だけプライマリ優先にする運用で対処します。

レプリケーションはフェイルオーバーではない

レプリケーションはデータをコピーする仕組みで、障害時の自動復旧とは別物です。フェイルオーバー（レプリカの昇格、トラフィックの切り替え、アプリの再接続）は別途ツールや手順、テストが必要です。

高可用性の基本: 障害を通じてオンラインを維持する

高可用性はデータベースサーバがクラッシュしたりネットワークが切れたり、メンテナンスが必要なときにアプリを動かし続けるための実践集合です。目的は明確: ダウンタイムを減らし、保守を安全にし、復旧を即興ではなく予測可能にすること。

一般的なHAパターン

初期のMySQL導入は多くが単一プライマリから始まりました。HAは典型的に2台目のマシンを追加して障害時の長い停止を防ぐところから始まります。

• プライマリ–スタンバイ（アクティブ–パッシブ）: 1台がトラフィックを扱い、スタンバイが昇格待ち
• マルチノードクラスタ: 複数ノードで協調して可用性を保つ（書き込みに関する厳格さあり）
• 自動フェイルオーバー: 監視がプライマリ障害を検出してスタンバイを昇格し、アプリの接続先を更新する

自動化は助けになりますが、検出ロジックを信頼できることと“スプリットブレイン”を防ぐ設計が必要です。

RPOとRTO、平易な説明

HAの意思決定を客観化する指標が二つあります:

• RPO（Recovery Point Objective）: どれだけのデータ損失を許容できるか。レプリカが10秒遅れていればRPOは最大約10秒です。
• RTO（Recovery Time Objective）: どれだけのダウンタイムを許容できるか。検出、昇格、アプリの再接続時間を含みます。

HAを現実にする運用

HAは単にトポロジーの問題ではなく実践です。

バックアップは定期的に行うだけでなく、復元テストが重要です: 実際に新しいサーバにすばやく復元できるかを確認する必要があります。

スキーマ変更も重要です。大きなテーブル変更は書き込みをロックしたりクエリを遅くする可能性があります。安全な手法としては、低トラフィック時間に変更を行う、オンラインスキーマ変更ツールを使う、常にロールバックプランを持つことです。

適切に実施すれば、HAは障害を緊急事態から計画された、リハーサル済みのイベントに変えます。

キャッシング戦略: ウェブトラフィック下でMySQLを速く保つ

キャッシュは初期のウェブチームがMySQLをレスポンシブに保つために使った最も単純で効果的な手段の一つです。基本は繰り返しのリクエストをデータベースではなくより高速な層から返し、必要なときだけMySQLを叩くことです。適切に設計すれば読み取り負荷を大幅に削減し、スパイクを滑らかにします。

一般的なキャッシュ層

アプリケーション/オブジェクトキャッシュ: プロファイルや商品詳細、権限チェックなど頻繁に参照するデータをキーで保存します。

ページ/フラグメントキャッシュ: レンダリング済みHTMLを保存（フルページやサイドバーなどの断片）。コンテンツ重視サイトで特に効果的です。

クエリ結果キャッシュ: 特定クエリの結果やエンドポイントの結果をキャッシュキーで保持します。

一般にインメモリのK/Vストア、HTTPキャッシュ、またはフレームワーク内蔵のキャッシュを使います。重要なのは一貫したキー設計、TTL（有効期限）、責任範囲の明確化です。

難しい点: キャッシュの失効

キャッシュは鮮度と速度をトレードオフします。少し古くても良いデータ（ニュース、閲覧数）もあれば即時性が必須のデータ（決済合計、権限）があります。一般的に選ぶ手法は:

• 時間ベースの期限（TTL）（単純、短い古さを許容）
• イベントベースの無効化（正確だが実装で間違いやすい）

失効が失敗するとユーザーに古い内容が見えるし、過度に厳密だとキャッシュ効果が失われDBが再び叩かれます。

なぜスパイクを緩和できるか

トラフィックが急増したとき、キャッシュは繰り返しの読み取りを吸収し、MySQLは書き込みやキャッシュミス、複雑なクエリに専念できます。これによりキューイングが減り、遅延の連鎖を防ぎ、安全にスケールする時間を稼げます。

シャーディングとパーティショニング: 単一DBが足りなくなったとき

「より大きなハードウェア」や丁寧なクエリチューニングで伸びしろが尽きたとき、データを分割することを検討します。

パーティショニングとシャーディングの違い（なぜ違うのか）

パーティショニングは同一MySQLインスタンス内でテーブルを小さな断片に分割します（例えば日付で）。削除やアーカイブ、特定のクエリが速くなりますが、サーバのCPU/RAM/IOの限界を超えることはできません。

シャーディングはデータを複数のMySQLサーバに分散します。各シャードは行のサブセットを保持し、アプリ（またはルーティング層）がどのサーバにアクセスするか決めます。

シャーディングが必要になるとき

シャーディングは通常次の状況で必要になります:

• インデックスやキャッシュ、クエリ最適化してもプライマリの書き込みが飽和する
• ストレージの増加でバックアップ・リストアやスキーマ変更が遅すぎる
• ノイジーなワークロードが他を不安定にする

よく使われるシャードキー

シャードキーはトラフィックを均等にし、ほとんどのリクエストが単一シャードで完結するように選びます:

• user_id: 消費者向けアプリでユーザーのデータをまとめる
• tenant_id: SaaSで顧客ごとに隔離するのに有効
• 地域: レイテンシやデータ所在地の要件に合うが、大都市などでホットスポットができる可能性あり

真のコスト

シャーディングは単純さを犠牲にしてスケールを得ます:

• シャード間クエリは難しくなり、ファンアウト＋集約で処理することが多い
• シャード間トランザクションは制限され、多くのチームが最終的整合性パターンに移行する
• マイグレーションとリバランスは運用的に重い（レンジ移動、ルーティング更新）

段階的アプローチ（コミット前に）

まずはキャッシュとリードレプリカでプライマリの負荷を下げます。次に最も重いテーブルやワークロードを分離（機能やサービスで分割）します。それからシャーディングへ進む—可能であれば段階的にシャードを追加できる設計にして一度に全てを作り替えないようにします。

大規模運用: 監視、保守、インシデント対応

忙しいプロダクトのMySQL運用は巧妙な機能よりも規律あるオペレーションに依存します。多くの障害は劇的な故障ではなく、小さなシグナルを誰も結びつけられなかったことから始まります。

実際にチームが監視するもの

スケールで早期に問題を予測する主要な4つ:

• クエリ遅延（p50/p95/p99）: 平均よりもテールが重要
• ロックとロック待ち: ホットな行、インデックス欠如、長いトランザクションの兆候
• レプリケーション遅延: リードスケールやフェイルオーバーに影響
• ディスク成長とIO圧迫: ディスク満杯の前にIO飽和が先に来ることが多い

ダッシュボードはトラフィック、エラー率、接続数、バッファプールヒット率、上位クエリとの文脈を示すべきです。目的は「変化を見つける」ことです。

なぜスロークエリは本番負荷でしか現れないか

多くのクエリはステージングや閑散時は問題を起こしません。負荷がかかるとキャッシュの効きが落ち、同時リクエストでロック競合が増え、少し非効率なクエリが大量の読み込みやテンポラリテーブル、巨大なソートを誘発します。

だからチームはスロークエリログ、クエリダイジェスト、本番のヒストグラムに依存します。

驚きのない保守

安全な変更手順はあえて地味です: マイグレーションは小分けに、最小ロックでインデックスを追加、EXPLAINで検証、現実的なロールバック策を用意します。変更は計測可能であるべきです: 前後のレイテンシ、ロック待ち、レプリケーション遅延を比較する。

インシデントの基本: 診断・緩和・予防

インシデント時は: 影響を確認し、最大の原因（クエリ、ホスト、テーブル）を特定、緩和する—トラフィックを絞る、暴走クエリを切る、一時的なインデックスを追加、読み書きを分散するなど。事後には起きたことを記録し、早期警告を追加し、同じ障害が再発しないように再発防止を実行します。

なぜMySQLは今でも大規模システムを支えるのか

MySQLはトランザクション境界が明確で、読み書きが多い日常的なアプリデータの形に合致しています。SaaS、EC、マーケットプレイス、マルチテナントプラットフォームのようなOLTP中心のプロダクトでは、エンティティ中心のデータ設計とフォーカスしたトランザクションがあれば今でも非常に適しています。

「昔のMySQL」とは異なる現代のMySQL

今日のMySQLエコシステムは多くの教訓を取り入れ、より安全なデフォルトと運用習慣が普及しています。実務で頼られる要素:

• 標準のストレージエンジンとしてのInnoDB（強力なクラッシュリカバリとトランザクション保証）
• より良くなったオプティマイザ、より速いレプリケーションオプション、予測可能な並行性挙動
• 有効化しやすい観測性: スロークエリログ、Performance Schema、メトリクスエクスポーター、ボトルネックを示すダッシュボード
• スキーマ変更、バックアップ、フェイルオーバーの自動化—スケーリングが人の英雄的作業に依存しない仕組み

マネージドMySQLが運用負荷を減らす

多くの企業はマネージドサービスでMySQLを運用し、パッチ適用、自動バックアップ、暗号化、ポイントインタイムリカバリ、大きなインスタンスやリードレプリカの追加といった定常作業をプロバイダに任せています。スキーマやクエリ、データアクセス設計は自分たちで管理しますが、保守や復旧訓練に費やす時間は減ります。

これらのパターンを現代のアプリ提供に取り入れる

“MySQLスケーリングのプレイブック”が今でも有益なのは、これが単なるデータベース問題ではなくアプリケーションアーキテクチャの問題だからです。読み書き分離、キャッシュキーと無効化、安全なマイグレーション、ロールバック計画はプロダクト設計と一緒に行うほうがうまく働きます。

新しいサービスを構築し、これらの決定を早くに組み込みたい場合は、vibe-codingのワークフローが助けになります。例えばKoder.aiはプレーンランゲージの仕様（エンティティ、トラフィック想定、一貫性要件）からアプリのスキャフォールド（典型的にはウェブはReact、サービスはGo）を生成するのを支援し、データレイヤ設計のコントロールを保ちながら作業できます。Planning Mode、スナップショット、ロールバックはスキーマやデプロイ変更を反復する際に特に有用です。

Koder.aiの各利用プラン（Free, Pro, Business, Enterprise）を確認したい場合は /pricing を参照してください。

今日MySQLを選ぶかどうかの要件優先チェックリスト

MySQLを選ぶ理由: 強力なトランザクション、リレーショナルモデル、成熟したツール、予測可能な性能、大きな人材プールが必要なときに適します。

代替を検討すべきケース: 大量の書き込みファンアウトや柔軟なスキーマが必須（いくつかのNoSQL）、グローバルに整合した複数リージョン書き込み（専門の分散DB）、分析重視のワークロード（カラム型ウェアハウス）など。

実務的な結論: 要件（レイテンシ、一貫性、データモデル、成長率、チームスキル）から出発し、それを満たす最も単純なシステムを選びましょう。多くの場合、MySQLはいまだにその役割を果たします。