データベースのレプリケーション設計 — 同期・非同期とリードレプリカの使い分け

レプリケーションは「張れば安全」ではなく、同期・非同期・準同期のどれを選ぶかが可用性とデータ整合性のトレードオフを決定づける。リードレプリカの追加も負荷分散の万能策ではなく、読み取り遅延の許容範囲とフェイルオーバー時のデータ欠損をどこまで受け入れるかを先に定義してから構成を確定する必要がある。設計の順番を誤ると、本番稼働後に不整合が表面化し、修正のために想定外の工数を費やすことになる。

レプリケーションを安易に張って不整合が出る構造

「とりあえずレプリカ」が引き起こす読み取り不整合

現場でよく聞く話として、プライマリへの書き込み直後にレプリカから読み取るクエリが古い値を返すという問題がある。非同期レプリケーションでは、プライマリへのコミットとレプリカへの反映の間に必ずラグが生じる。数十ミリ秒から数百ミリ秒の遅延は通常運用時には見えにくいが、書き込み直後に同一セッションで読み取りを行うアプリケーションでは確実に不整合として現れる。ECサイトの在庫更新やユーザー設定の即時反映のように、書き込み後の読み取り一貫性（Read-Your-Writes Consistency）を前提とした機能にレプリカを流用すると、ユーザー体験が不安定になる。

書き込みが分散してデータが壊れるパターン

マルチプライマリ構成（デュアルライト）を選択肢として持ち込んだ結果、同一レコードへの同時書き込みで競合が発生し、データが破損したケースが報告されている。マルチプライマリはグローバル分散や地理的冗長が明確な要件として存在する場合に限って検討すべき構成であり、単純な冗長性や負荷分散を目的に採用すると、競合解決ロジックの設計コストが跳ね上がる。プライマリは1台に絞り、読み取りをレプリカに逃がすシングルプライマリ構成のほうが、運用上の複雑性を大幅に抑えられる。

アプリケーション層との境界設計が抜ける落とし穴

データベース層でレプリケーションを設定しても、アプリケーション側でどのエンドポイントに接続するかを明示的に制御していなければ、意図せず書き込みをレプリカに送るミスが起きる。接続プールライブラリや中間プロキシを挟む構成では特に、プライマリとレプリカのルーティングロジックが複数箇所に散らばりやすい。設計段階でアプリケーション層との境界——どの種類のクエリはプライマリに向け、どれをレプリカに許容するか——を明文化しておかないと、後から追跡が困難なバグの温床になる。

同期レプリケーションと非同期の向き不向きの違い

同期が適する条件と代償

同期レプリケーションは、プライマリがコミットを完了する前に少なくとも1台のレプリカへの書き込み確認を待つ方式だ。これによりフェイルオーバー時のデータ欠損をゼロに近づけられる。金融系の決済処理や医療系の記録更新など、コミット済みデータが消えることが許されない業務領域では有力な選択肢になる。一方で、レプリカの応答待ちがプライマリの書き込みレイテンシに直接加算されるため、データセンター間をまたぐような構成では書き込みスループットが大幅に低下する。同一データセンター内、あるいはレイテンシが2〜5ms以内に収まるネットワーク上での運用を前提とすべき方式だ。

非同期が適する条件と代償

非同期レプリケーションは、プライマリがコミットを完了した後、バックグラウンドでレプリカへ変更を伝播させる。書き込みレイテンシをプライマリ単体のコミット時間に抑えられるため、スループット要件が高いシステムや、地理的に離れたデータセンター間の冗長構成に向いている。代償はフェイルオーバー時に伝播しきれていないトランザクションが失われる可能性だ。この失われ得るデータ量をRPO（Recovery Point Objective）として定義し、業務が許容できる範囲かを判断材料にする。ログ集約やアナリティクス基盤のように、数秒から数十秒の遅延を許容できる用途であれば、非同期が合理的な選択となる。

判断軸の整理

方式選択の判断軸は主に3点だ。第一に、フェイルオーバー時に失ってよいデータの時間幅（RPO）。第二に、書き込みレイテンシの要件——サービスレベルとして規定されたp99のレイテンシ値がある場合は、同期方式の影響を事前に試算する。第三に、プライマリとレプリカ間のネットワーク品質。この3点を整理せずに方式を選ぶと、後から「実は非同期で良かった」または「同期にすべきだった」という再設計が発生する。変更コストは構成確定後に跳ね上がるため、設計初期にこの軸を揃えておくことが重要だ。

比較表: 同期／非同期／準同期レプリケーション

項目	同期レプリケーション	非同期レプリケーション	準同期レプリケーション
フェイルオーバー時のデータ欠損	ほぼゼロ	あり（数秒〜数十秒分）	低い（1トランザクション以内が目安）
書き込みレイテンシへの影響	大（レプリカ応答待ちが加算）	小（プライマリ単体で完結）	中（少なくとも1台の受信確認待ち）
適する地理的配置	同一DC内・低レイテンシ構成	DC間・広域分散	同一DC内〜近距離DC間
スループット要件への対応	低〜中（書き込み多い系は要注意）	高（スループット維持しやすい）	中〜高
典型的な用途	決済・医療記録・在庫確定	ログ集約・分析基盤・地理冗長	EC本体・基幹業務の標準冗長
運用複雑性	中（フェイルオーバー判断が明確）	低〜中（ラグ監視が必要）	中（タイムアウト設計が鍵）

準同期（セミシンクロナス）は、プライマリのコミット完了前に「少なくとも1台のレプリカがバイナリログを受信した」ことを確認してからクライアントに応答を返す方式だ。完全なディスク書き込みの保証ではない点に注意が必要で、実装によっては追加の設定で保証の強度を調整できる。データ欠損リスクと書き込みレイテンシのバランスを取る選択肢として、ECや基幹業務の標準冗長構成に採用されることが多い。

リードレプリカで負荷を逃がす判断とその限界

リードレプリカの効果が出る構成の条件

リードレプリカへの読み取り分散が効果を発揮するのは、プライマリのCPUやI/Oがレポートや集計クエリによって圧迫されており、かつその読み取りが数秒から数十秒の遅延を許容できる場合だ。ダッシュボードの集計、バッチ処理の参照クエリ、レコメンデーションの学習データ抽出など「最新でなくても業務が成立する」クエリ群をレプリカに分離することで、プライマリへの負荷を実測で30〜50%削減できるケースが報告されている。この分離を実現するには、アプリケーション側でクエリの性質を識別し、接続先を切り替える制御層が不可欠だ。

レプリカが追いつかない状況

大量のバルク書き込みが発生する時間帯——例えば夜間バッチが数千万件のレコードを更新するような構成——では、レプリカの適用遅延（レプリケーションラグ）が数十秒から数分に膨らむことがある。この状態でレプリカから読み取ったデータを業務判断に使うと、古い状態に基づいた処理が走る。ラグのしきい値を監視してアラートを出す仕組みを持たなければ、問題が顕在化するまで気づけない。構築段階でラグのSLO（例: 通常時は5秒以内）を定義し、それを超えた際にアプリケーションがどう振る舞うかを設計に織り込んでおく必要がある。

「全クエリをレプリカに逃がす」設計の誤り

負荷削減を急いだ結果、書き込み直後の読み取りも含めてすべてのSELECTをレプリカに向けてしまうアーキテクチャ判断は高リスクだ。ユーザー登録完了後のプロフィール表示、注文確定後の明細表示など、業務フロー上で「書いた直後に読む」パターンが存在する箇所では、レプリカのラグが直接的なデータ不整合として現れる。この問題を後から修正しようとすると、クエリ単位の振り分け制御をレトロフィットする工数が発生し、数週間規模の改修になることもある。設計初期にWrite-After-Readのパターンをリストアップし、それらはプライマリ固定とする方針を明示しておくべきだ。

フェイルオーバー時のデータ欠損をどこまで許容するか

RPOを定義しないまま構成を決めてしまう問題

フェイルオーバー設計においてRPOを数値で定義せずに構成を決めることは、後から収拾のつかない議論を生む。「データは消えてはいけない」という言葉は要件ではなく方針であり、それをゼロ秒のRPOとして同期レプリケーションで担保するのか、5秒のRPOを許容して非同期にするのかは、業務側と設計側が合意した数値として記録に残す必要がある。RPOが未定義のまま構成を決めると、フェイルオーバーが発生した際に「なぜデータが消えたのか」という議論が始まり、設計の根拠が問われる。

非同期レプリカへのフェイルオーバーで消えるデータ

プライマリ障害時に非同期レプリカを昇格させると、プライマリにコミット済みだがレプリカに伝播しきれていないトランザクションが失われる。この量はレプリケーションラグに依存し、平常時のラグが1秒であれば最大1秒分のトランザクションが消える計算になる。構築を任されたある担当者が、プライマリ故障時に非同期レプリカへ手動フェイルオーバーを行ったところ、直前の注文データ数件が失われ、業務側への説明と対応に数日を要したという事例が報告されている。設計段階でこのシナリオを業務担当者と共有し、許容可否を確認しておくことが後のトラブルを防ぐ最短路だ。

許容範囲の数値化と設計への反映

RPOが決まれば、それを満たすためにどの方式を選択するかが自ずと絞られる。RPO=0秒であれば同期または準同期、RPO=5秒以内であれば非同期でラグ監視を組み合わせる、といった対応関係を設計書に記載しておくと、後のレビューやインシデント対応時の根拠になる。複数のデータ種別でRPOが異なる場合——決済データはRPO=0秒、ログデータはRPO=60秒など——は、テーブル単位やサービス単位でレプリケーション方式を分けることも検討に値する。要件が混在するシステムほど、データ種別ごとのRPOマッピングを早期に整理することが設計効率を高める。

レプリカを増やしすぎて遅延・運用が破綻する境界

レプリカ台数と遅延の関係

レプリカを増やすほど読み取りスケールが上がると単純に考えると、運用上の問題が潜む。プライマリはすべてのレプリカにバイナリログを送信し続けるため、台数が増えるとプライマリのネットワーク帯域とI/Oに対する負荷が増加する。非同期レプリカを5台以上並べる構成では、プライマリのバイナリログ送信負荷が無視できなくなるケースが報告されており、個々のレプリカが抱えるラグが増大し始める境界としてこの台数前後が目安になることが多い。レプリカが多いほど個々のラグを監視・管理する運用コストも増加していく点も見落とせない。

運用コストが跳ね上がる境界

レプリカ3台程度までは1人の担当者が監視・パッチ適用・スキーマ変更の伝播を管理できる規模感だが、5台を超えると作業の並列化が難しくなり、スキーマ変更時の手順検証だけで半日から1日の工数が必要になることがある。レプリカごとにOSやDBのバージョンがずれ始めると、パッチ適用の計画がさらに複雑化する。台数を増やせば読み取りスケールは上がるが、それが運用として回せるかどうかは台数とは別の軸で評価する必要がある。

「減らす設計」への転換

レプリカ台数を抑えながら読み取りスケールを確保する設計として、アプリケーション層にキャッシュ層（インメモリKVS）を設けてデータベースへの読み取りクエリ自体を削減する手法がある。キャッシュで吸収できる読み取りが全体の60〜70%に達するシステムでは、レプリカ1〜2台の構成で十分なスループットを確保できることが多い。レプリカを追加する前にキャッシュ戦略との比較検討を行うことが、運用負荷を抑えた設計判断の一つになる。追加するコンポーネントが増えるほど障害点も増えるため、シンプルな構成を保つ判断は長期の安定運用につながる。

レプリケーション設計チェックフレーム

以下のチェックリストは、レプリケーション構成を確定する前に設計・判断すべき項目を整理したものだ。上から順に答えが出れば、方式選択・レプリカ台数・フェイルオーバー方針がほぼ決まる。

1. RPOの合意取得: プライマリ障害時に失ってよいデータの時間幅を業務側と数値（秒・分）で合意し、記録に残しているか。
2. RTOの確認: フェイルオーバー完了までに許容される時間を定義し、自動昇格か手動切り替えかを決定しているか。
3. 書き込み後読み取りパターンの洗い出し: 書き込み直後に同一データを読み取る業務フローをリストアップし、それらをプライマリ固定にしているか。
4. レプリカに向けるクエリの性質確認: レプリカに分散させるクエリが「遅延を許容できる読み取り」に限定されているか。
5. ネットワーク遅延の実測: プライマリとレプリカ間のレイテンシを実測し、同期方式を選ぶ場合の書き込みレイテンシへの影響を試算しているか。
6. ラグ監視のSLO設定: レプリケーションラグのしきい値と、超過時のアラートおよびアプリケーション側の振る舞いを設計しているか。
7. レプリカ台数と運用体制の確認: 想定するレプリカ台数をチームの運用体制（人数・スキル・監視ツール）で回せるかを評価しているか。
8. フェイルオーバー手順の文書化とテスト: 切り替え手順を文書化し、本番想定のデータ量で切り替えテストを実施しているか。
9. スキーマ変更の伝播戦略: スキーマ変更がレプリカに与える影響（ロック・ラグ増大）を考慮した適用手順を持っているか。
10. キャッシュ戦略との比較検討: レプリカを追加する前に、キャッシュ層による読み取り削減を選択肢として評価したか。

この10項目をすべて「はい」で埋められる状態で構成を確定すれば、本番稼働後に設計の根拠を問われる場面でも答えられる。特に1〜3番は業務側との合意が必要な項目であり、エンジニア単独で決めてしまうと後のインシデント時に責任の所在が曖昧になる。具体的なパラメータ設定や運用手順の詳細は、各DBMSのドキュメントや実地研修で確認するのが確実だ。