技術解説
データベースの負荷分散を実現する「リードレプリカ」
2019年2月7日
データベース（以下、DB）の規模が大きくなると、アクセスに時間がかかるようになる場合があります。そのため、「MySQL」や「PostgreSQL」などのオープンソース系のRDB（Relational Database/リレーショナルデータベース）には、データをリアルタイムにコピーし、別のシステム上に作成する「レプリケーション」による負荷分散のための機能「リードレプリカ」が用意されています。
ここでは、リードレプリカの概要とメリットを説明します。
リードレプリカは何を複製しているのか？
「リードレプリカ」とは、読み出し専用のDBで、レプリケーション機能でマスターDBから作成されたレプリカ（複製）DBのことです。読み込み専用なのでDBへの書き込みやマスターDBへの反映は行われませんが、複数のリードレプリカDBを作成することができます。
例えば、DBの規模が大きくアクセス頻度が高い場合、DBへのアクセスが全体のパフォーマンスのクリティカルパスになる恐れがあります。
このようなケースでは、DBのアクセス目的は書き込みよりも読み込みが主ですから、複数の読み込み専用のDB「リードレプリカ」を用意すればDBへの負荷を分散させられ、全体のパフォーマンスの向上につながります。
DBへのアクセスの特長をうまく利用して、負荷分散を実現する仕組みがリードレプリカです。
リードレプリカを使うメリットは？
リードレプリカを使用する最大のメリットは、柔軟にスケールアウトが実現できる点です。
DBの読み出しの負荷が高いシステムの場合、1台のDBサーバーでは読み書きの限界に達してしまうようなアクセスがあると、サービスが遅延したり停止したりしてしまう恐れがあります。
しかし、読み出しの負荷をリードレプリカに逃がすことで、DBサーバーの負荷を軽減が可能になります。リードレプリカは負荷に合わせて多数並べられますので、柔軟にスケールアウトが実現できます。
リードレプリカによる負荷分散には、いくつかの方法があります。
| 方法1 | アプリケーション側で更新用DBと参照用DB（リードレプリカ）を使い分けることにより、負荷分散を実現します。 |
|---|---|
| 方法2 | 複数のフロントエンドサーバーにそれぞれリードレプリカを用意しておけば、アクセス数が増えても応答速度を低下させずに運用できます。 |
| 方法3 | 一時的なDBへのアクセス増加などにも、リードレプリカを増やすことでパフォーマンスを維持しながらの対応が可能になります。 |
また、リードレプリカの使用には、負荷分散以外にも次のようなメリットもあります。
| メリット1 | データ解析用途などでマスターDBに負荷をかけずに処理したいときにも、リードレプリカは有効です。また、DBのオブジェクトを変更するなどの処理に時間がかかる作業をリードレプリカで行い、処理が終了したところでマスターDBに昇格させるといった運用も可能です。 |
|---|---|
| メリット2 | バックアップについてもリードレプリカが有効です。リードレプリカを使えば、マスターDBの更新に影響を与えずに、バックアップを行うことが可能です。 |
リードレプリカを使用する場合の注意点は？
ここまで見てきたとおり、メリットが多いリードレプリカですが、運用時にはいくつか注意すべき点もあります。
まず、リードレプリカを作成するためには、リードレプリカ用のサーバーの構築とメインDBとの連携などの設定やメンテナンスが必要になります。
また、レプリケーションの手法が「非同期」や「準同期」のいずれかの場合、下記の点に注意しておきましょう。
- 非同期レプリケーション：マスターDBとリードレプリカは非同期なので、同期のタイミングに注意が必要。トラブル時に最新の変更が残らない可能性あり。
- 準同期レプリケーション：マスターDBを更新すると、変更点がスレーブに転送される。このときの転送待ちにより処理速度が低下する可能性あり。
サービスが急成長して予想を超えてデータベースの規模が拡大した場合や一時的なアクセス増加に対応するための負荷分散、DBバックアップをスムーズに行いたい場合など、「守り」の運用に加えて、データ解析によるDB活用などの「攻め」の運用にもリードレプリカは有効です。リードレプリカを切り口にしてDBの運用を見直してみるのも良いかもしれません。
なお、ニフクラではリードレプリカを簡単に利用できるサービスとして、MySQL、MariaDB、PostgreSQLに対応した「RDB」を提供しています。
