LASSIC Media らしくメディア
リードレプリカの仕組み｜DB読み取りを分散する
「アクセスが増えると画面表示が重くなる」「夜間の集計処理を回すと日中のサービスまで遅くなる」——データベースの負荷にまつわる相談は、システムの成長とともに、遅かれ早かれ出てきます。その打ち手の定番として、開発会社から「リードレプリカを追加します」と提案を受けることがあります。
リードレプリカは、読み取りの負荷を複数のデータベースに分散させるための仕組みです。名前は聞いたことがあっても、何が解決できて何が解決できないのか、どんな注意点があるのかは掴みにくいものです。本記事では、発注担当者やプロジェクトマネージャーに向けて、仕組み・使いどころ・落とし穴を整理します。
目次
リードレプリカとは——読み取り専用の複製で負荷を分散する
リードレプリカとは、書き込みを受け付ける主系のデータベース（プライマリ）とは別に、その内容を複製した読み取り専用のデータベースを用意する仕組みです。多くのシステムでは、データの更新よりも参照のほうがはるかに多く発生します。そこで、参照の負荷をレプリカへ振り分ければ、プライマリの負担を軽くしながら全体でさばける読み取りの量を増やせます。
プライマリへの更新は、レプリケーションと呼ばれる仕組みでレプリカへ次々と反映されます*1。レプリカは複数台に増やせるため、読み取りが増えたぶんだけ台数を足して対応する、という拡張の仕方ができます。クラウドのマネージドデータベースでは、数クリックやコマンドでレプリカを追加できるものが多く、導入の敷居は下がっています*1*2。
この記事のポイント
- リードレプリカは、書き込み用のプライマリとは別に読み取り専用の複製を用意し、参照の負荷を分散する仕組みです。
- プライマリの更新がレプリカへ伝わるまでにわずかな遅延（レプリケーションラグ）があり、直後に読むと古い値が返ることがあります*3。
- 増えるのが書き込みの場合はレプリカでは解決しないため、パーティショニングなど別の打ち手を検討します。
何を解決できるか——読み取り負荷・可用性・分析の分離
リードレプリカが効果を発揮するのは、主に次のような場面です。
| 目的 | 内容 |
|---|---|
| 読み取り負荷の分散 | 参照のリクエストを複数のレプリカへ振り分け、プライマリの負担を下げる。 |
| 可用性の向上 | プライマリに障害が起きたとき、レプリカを昇格させて復旧に使える構成にできる。 |
| 分析クエリの分離 | 重い集計やレポート用のクエリをレプリカへ寄せ、日中のサービスへの影響を抑える。 |
| 地理的な近接 | 利用者に近い場所へレプリカを置き、遠隔地からの参照の応答を速くする。 |
いずれも「読み取り」を軸にした打ち手である点が共通しています。逆に言えば、書き込みの負荷を下げる用途には向きません。ここが判断の分かれ目です。
レプリケーションラグと整合性——「直後に読むと古い」問題
リードレプリカを理解するうえで欠かせないのが、レプリケーションラグです。プライマリへの更新がレプリカへ反映されるまでには、ごくわずかとはいえ時間差が生じます*3。多くの構成では、この反映を待たずに応答を返す非同期方式が採られており、応答は速い一方で、レプリカのデータは一瞬だけ古い状態になり得ます。
これが問題になりやすいのが、「書き込んだ直後に、その内容を読み返す」場面です。たとえば、利用者が投稿した内容を保存直後の画面で表示する、といったケースでは、レプリカを読むと反映前の古い状態が返り、「保存したのに反映されていない」と受け取られてしまう恐れがあります。対策としては、更新直後の読み取りや、常に最新であるべき処理はプライマリから読む、といった振り分けの設計が要ります。論点を整理すると次のとおりです。
| 論点 | 考え方 |
|---|---|
| 同期と非同期 | 非同期は速いがラグが出る。同期はラグを抑えるが書き込みの応答が遅くなりやすい。 |
| 直後の読み返し | 更新直後の参照はプライマリから読むよう振り分ける。 |
| 許容できる古さ | 一覧や集計など、多少古くても支障のない参照はレプリカに任せる。 |
仕組みと振り分け——読み取りと書き込みの経路を分ける
リードレプリカを使うには、「書き込みはプライマリ、読み取りはレプリカ」という振り分けをどこかで行う必要があります。方法は大きく二つあります。ひとつはアプリケーション側で接続先を使い分けるやり方、もうひとつはデータベースの手前に振り分け役（プロキシ）を置き、アプリからは一つの接続先に見せるやり方です。全体像は次の図のとおりです。
図のように、書き込みはプライマリへ、読み取りは複数のレプリカへ分散されます。プライマリからレプリカへは絶えず複製が流れており、この流れに遅延が生じるのが前述のラグです。振り分けをアプリで作り込むと柔軟な反面、実装が複雑になりがちです。プロキシに任せると導入は楽になりますが、その分の構成要素が増えます。どちらが向くかは、既存の作りや運用体制によって変わります。
よくある落とし穴——書き込みは速くならない・ラグ前提の設計
リードレプリカは便利な一方で、誤解されやすい点もあります。導入前に押さえておきたい落とし穴を整理します。
| 落とし穴 | 内容 | 備えの方向性 |
|---|---|---|
| 書き込みは速くならない | レプリカを増やしても、書き込みはプライマリに集中したまま。 | 書き込みが課題ならパーティショニングやシャーディングを検討する。 |
| ラグ前提の設計漏れ | 古い値が返り得ることを考えずに組むと、表示の不整合が起きる。 | 直後の読み返しはプライマリへ振り分ける方針を決めておく。 |
| 昇格時の切り替え | 障害でレプリカを昇格させる際、接続先の切り替えが要る。 | フェイルオーバーの手順と接続の切り替えを事前に設計・訓練する。 |
| コストの増加 | レプリカの台数だけ費用がかかる。 | 必要な読み取り量に見合う台数を見積もり、増減を検討する。 |
導入・運用の勘所と外注時の確認点
リードレプリカは、クラウドのマネージドデータベースなら比較的手軽に導入できます。ただし、活かせるかどうかは振り分けの設計とラグへの備えが鍵です。導入を検討する際は、まず「増えているのは読み取りか書き込みか」を切り分け、読み取りが課題であることを確かめるところから始めると、判断を誤りにくくなります。
外部へ委託する場合は、次の点をすり合わせておくとよいでしょう。読み取りと書き込みの振り分けをどこで行うか、更新直後の読み返しをどう扱うか、フェイルオーバー時の接続切り替えをどう設計するか、そしてレプリカの台数と費用の見積もりをどう置くか——このあたりを最初に整理しておくと、導入後の食い違いを防ぎやすくなります。
まとめ：リードレプリカで押さえる3つの判断軸
リードレプリカは、読み取りの負荷を分散し、システムの成長を支える定番の打ち手です。導入を考える際は、3つの軸で整理すると判断しやすくなります。第一に、課題が読み取りにあるかどうか。書き込みが課題なら、別の仕組みを検討する必要があります。第二に、レプリケーションラグへの備え。古い値が返り得ることを前提に、直後の読み返しの扱いを決めておきます。第三に、振り分けと運用の設計。どこで経路を分け、障害時にどう切り替えるかを最初に固めます。この3点を押さえれば、リードレプリカは負荷への有効な備えとして機能します。データベースの負荷や構成に迷いがあれば、現状整理の段階から外部の知見を借りるのもひとつの方法です。
よくある質問
リードレプリカを増やせば書き込みも速くなりますか。
いいえ。レプリカが担うのは読み取りで、書き込みはプライマリに集中したままです。書き込みの負荷が課題の場合は、データを分割して複数のデータベースに分けるパーティショニングやシャーディングなど、別の仕組みを検討します。
レプリケーションラグはどのくらいですか。
構成や負荷によって変わり、通常はごく短い時間ですが、書き込みが集中するとラグが広がることがあります。大切なのは長さを一律に見積もることより、「古い値が返り得る」前提で設計しておくことです。
書き込んだ直後に古いデータが表示されるのを防げますか。
更新直後の読み返しや、常に最新であるべき参照は、レプリカではなくプライマリから読むよう振り分けることで防げます。どの参照を最新扱いにするかを、設計の段階で決めておくことが大切です。
レプリカはいくつまで増やせますか。
利用するデータベースやサービスによって上限は異なります。台数を増やすほど読み取りはさばけますが、費用も台数に応じて増えます。必要な読み取り量に見合う台数を見積もることが現実的です。
外注する場合、何を確認すればよいですか。
読み取りと書き込みの振り分けをどこで行うか、更新直後の読み返しの扱い、フェイルオーバー時の接続切り替え、レプリカの台数と費用の見積もり——この4点を最初に確認しておくと、認識のずれを防ぎやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・データベース運用のご相談はLASSICへ
元請（プライムベンダー）として、負荷の切り分けから設計・実装・運用まで、貴社の課題に合わせてご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services「Working with DB instance read replicas」（Amazon RDS User Guide）（https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html）
- *2 出典：Google Cloud「About replication in Cloud SQL」（Cloud SQL for MySQL ドキュメント）（https://cloud.google.com/sql/docs/mysql/replication）
- *3 出典：PostgreSQL「High Availability, Load Balancing, and Replication」（PostgreSQL Documentation）（https://www.postgresql.org/docs/current/high-availability.html）
