SAP-C02-089 · セクション 10 / タスク 2.5

ReplicaによるRead Scaling

Read Replica / Aurora Replica / DynamoDB / Read Scaling / Replication Lag / Read-heavy ワークロード

データベースの性能問題では、

データベースが遅い
↓
とりあえず大きくする

とは判断しません。

最初に確認するのは、

読み取りがボトルネックなのか
+
書き込みがボトルネックなのか

です。

読み取り中心ワークロード（Read-heavy Workload）では、読み取り処理をライターから別のレプリカへ分散することで、

ライターの読み取り負荷低減
+
合計読み取りスループット向上

を狙えます。

これが、

読み取りスケーリング
（Read Scaling）

の代表的な方法です。

ただし、

レプリカを追加する
=
すべてのデータベース性能問題が解決する

ではありません。

読み取りスケーリングでは、

読み取り負荷の割合
+
読み取りと書き込みを分離できるか
+
どの程度古いデータを許容できるか
+
レプリケーションラグ

まで確認します。

ゴール

次の判断ができるようにします。

Amazon RDS
+
読み取り中心
+
数秒程度の古さを許容
        ↓
リードレプリカを評価

Amazon Aurora
+
読み取り中心
+
複数の読み取り処理先
        ↓
Aurora Replica
+
リーダーエンドポイント

一方、

書き込みがボトルネック
        ↓
リードレプリカだけでは解決しない

ことも判断します。

さらに、

ReplicaLag
AuroraReplicaLag

などから、

読み取りスケーリング
と
データ鮮度

の両方が性能目標を満たしているか確認します。

1. 読み取り負荷と書き込み負荷を分離して考える

例えばデータベースCPU使用率が90%でも、

SELECT 95%
INSERT / UPDATE 5%

の場合と、

SELECT 5%
INSERT / UPDATE 95%

の場合では対策が違います。

前者なら、

読み取り処理
↓
レプリカへ分散

することでライター負荷を下げられる可能性があります。

一方、後者で、

リードレプリカを10台追加

しても、

INSERT
UPDATE
DELETE

などの書き込みは引き続きライターへ集中します。

したがって、

読み取り中心
→ レプリカを評価

書き込み中心
→ 別のボトルネック対策を評価

とします。

2. 読み取り中心ワークロードとは

読み取り中心ワークロードでは、処理の大部分が、

SELECT
検索
レポート
分析
参照API

などで構成されます。

例えば、

注文登録
100件 / 秒

注文参照
5,000件 / 秒

なら、

書き込み
と
読み取り

を同じDBインスタンスだけで処理する必要があるかを評価します。

特に、

レポート
ダッシュボード
商品参照
履歴照会

のような大量読み取りを別のレプリカへ送れるなら、ライターが書き込み処理へ使える計算資源を確保しやすくなります。

3. Amazon RDSのリードレプリカ

Amazon RDSでは、対応するデータベースエンジンで、

ソースDBインスタンス
        │
        │ 非同期レプリケーション
        ↓
リードレプリカ

を作成できます。

リードレプリカ（Read Replica）は、読み取り中心ワークロードをソースDBインスタンスから分離するために利用できます。

例えば、

アプリケーション
   │
   ├─ 書き込み
   │      ↓
   │   ソースDB
   │
   └─ 読み取り
          ↓
       リードレプリカ

とします。

これにより、

ソースDB
↓
書き込み処理を中心に担当

リードレプリカ
↓
大量の参照処理を担当

という役割分担ができます。

4. リードレプリカを作っただけでは読み取り負荷は移動しない

Amazon RDSでリードレプリカを作成しても、

アプリケーション
↓
従来のソースDBエンドポイント

へすべての読み取りを送り続ければ、ソースDBの読み取り負荷はほとんど変わりません。

必要なのは、

書き込み用接続
↓
ソースDB

読み取り用接続
↓
リードレプリカ

という接続経路の分離です。

複数のリードレプリカがある場合も、

リードレプリカ1
リードレプリカ2
リードレプリカ3

へ、アプリケーション側などで読み取り処理を適切に振り分けます。

つまり、

レプリカの作成

だけではなく、

読み取りトラフィックの振り分け

まで成立して初めて読み取りスケーリングになります。

5. RDSリードレプリカは非同期レプリケーション

Amazon RDSのリードレプリカでは、ソースDBインスタンスの変更がレプリカへ非同期に反映されます。

書き込み
↓
ソースDBで完了
↓
アプリケーションへ成功
        │
        └─ 非同期
             ↓
          リードレプリカへ反映

したがって、

ソースDB
最新値 = 1,200円

リードレプリカ
まだ = 1,000円

という短時間の差が発生する可能性があります。

これは、

レプリケーションラグ
（Replication Lag）

として扱います。

6. 読み取りスケーリングでは鮮度要件を確認する

リードレプリカへ読み取りを分散できるかどうかは、

読み取り結果が
多少古くてもよいか

で変わります。

例えば、

昨日時点の売上レポート

なら数秒程度のラグが問題にならない場合があります。

一方、

パスワード変更直後の確認

注文確定直後の注文詳細

在庫更新直後の残数確認

などでは、

今書いた値を
直後の読み取りでも必ず確認したい

場合があります。

その場合、

更新直後の読み取り
↓
ライターへ送る

古さを許容できる読み取り
↓
リードレプリカへ送る

という設計を評価します。

7. リードレプリカは強い整合性を自動的に保証しない

誤った判断は、

同じデータベースのレプリカだから
常に最新データが読める

です。

非同期レプリケーションでは、

ライター
↓
最新

レプリカ
↓
反映途中

となる可能性があります。

そのため、

読み取り負荷を分散したい

だけではなく、

その読み取りで
どの程度の古さを許容できるか

を確認します。

読み取りスループットを増やしても、業務で許容できない古い値を返せば性能目標を満たしたことにはなりません。

8. RDSではReplicaLagを監視する

Amazon RDSでは、

ReplicaLag

CloudWatchメトリクスを使用して、リードレプリカがソースDBインスタンスからどの程度遅れているかを確認できます。

代表的には、

ReplicaLag
小さい
↓
ソースDBへの追従が良好

ReplicaLag
増加
↓
レプリカがソースDBへ
追いついていない可能性

と判断します。

ただし、ReplicaLagの具体的な計算方法はデータベースエンジンによって異なります。

したがって、

ReplicaLag = 5

という値だけを見るのではなく、

利用しているDBエンジン
+
メトリクスの意味
+
業務で許容できる古さ

を合わせて評価します。

9. レプリケーションラグが増えたら読み取り性能だけを見ない

読み取りレプリカ自体が大量のクエリを処理できていても、

ReplicaLag

が増えていれば、

読み取り性能

と、

データ鮮度

の両方を満たしているとは限りません。

例えば、

ソースDBへ大量の書き込み
↓
レプリカへの反映が追いつかない
↓
ReplicaLag増加

する場合があります。

また、レプリカ側の処理能力が不足している場合なども、レプリケーションが追いつきにくくなることがあります。

したがって、

クエリレイテンシー
+
読み取りスループット
+
レプリケーションラグ

を合わせて確認します。

具体的なリソースサイズの最適化は、読み取りスケーリングとは別のサイジング判断として扱います。

10. リードレプリカを増やしても書き込みは分散されない

RDSのリードレプリカを、

1台
↓
3台
↓
5台

へ増やせば、読み取り処理を分散できる範囲は広がります。

しかし、

INSERT
UPDATE
DELETE

が同じソースDBへ集中しているなら、

書き込みボトルネック

は残ります。

つまり、

リードレプリカ
→ 読み取りスケーリング

リードレプリカ
≠ 書き込みスケーリング

です。

「データベースCPUが高い」という情報だけではリードレプリカを選ばず、負荷の内訳を確認します。

11. レポート処理はリードレプリカへ分離しやすい

代表的なユースケースが、

OLTP
+
レポート

の分離です。

例えば、

ライター
↓
注文登録
注文更新
決済状態更新

を処理し、

リードレプリカ
↓
日次売上集計
管理画面
BI参照

を処理します。

レポートクエリが大量の行を読み取る場合でも、ライターから分離すれば、トランザクション処理への影響を抑えやすくなります。

ただし、レポートでも、

絶対に最新のトランザクションまで必要

ならレプリケーションラグを考慮します。

12. Amazon AuroraではAurora Replicaを使う

Amazon Auroraでは、

ライター
+
Aurora Replica

という構成で読み取りをスケールできます。

Aurora DBクラスターでは、最大15個のAurora Replicaを追加できます。

Auroraライター
        │
        ├─ Aurora Replica 1
        ├─ Aurora Replica 2
        ├─ Aurora Replica 3
        │
        └─ ...

Aurora Replicaはライターと同じクラスターボリュームを利用し、読み取り処理をライターからオフロードします。

そのため、

読み取り要求増加
↓
Aurora Replica追加
↓
読み取り処理能力を拡張

という設計が可能です。

13. Aurora Replicaでもレプリケーションラグはゼロとは限らない

Aurora Replicaは同じクラスターボリュームを利用しますが、

ライターへ更新
↓
レプリカですぐ完全に同じ状態

と常に保証されるわけではありません。

AWSでは、同一リージョンのAurora Replicaのラグは通常非常に小さく、一般に100ミリ秒未満ですが、書き込み量などによって増えることがあります。

したがって、

Aurora
=
レプリカラグ 0

とは覚えません。

鮮度要件が厳しい処理では、Auroraでもレプリカラグを確認します。

14. Auroraではリーダーエンドポイントを使える

Auroraには、

クラスターエンドポイント

と、

リーダーエンドポイント

があります。

基本的には、

書き込み
↓
クラスターエンドポイント
↓
ライター

読み取り
↓
リーダーエンドポイント
↓
Aurora Replica

と使い分けます。

リーダーエンドポイントを使用すると、アプリケーション側で、

Aurora Replica 1
Aurora Replica 2
Aurora Replica 3

のアドレスを個別に管理せず、利用可能なAurora Replicaへ読み取り接続を分散できます。

15. Auroraリーダーエンドポイントは「接続」を分散する

重要なのは、

リーダーエンドポイント
↓
個々のSQLを毎回
別レプリカへ分散

ではないことです。

リーダーエンドポイントは、

接続要求

をAurora Replica間で分散します。

例えば、

接続A
↓
Aurora Replica 1

接続B
↓
Aurora Replica 2

接続C
↓
Aurora Replica 3

となります。

しかし、

接続A

を長時間維持すれば、その接続で実行する多数のクエリは同じレプリカへ送られます。

16. 接続プールによる偏りにも注意する

アプリケーションが、

少数のDB接続
+
長時間の接続プール

を利用している場合、Aurora Replicaを増やしても、

既存の接続

が自動的に新しいレプリカへ再配置されるわけではありません。

そのため、

レプリカを追加したのに
負荷が均等にならない

場合は、

接続の作られ方
+
接続プール
+
DNS解決

なども確認します。

つまり、

レプリカ数

だけではなく、

読み取り接続の分散

まで確認します。

17. AuroraのリーダーエンドポイントにAurora Replicaがない場合

AuroraクラスターにAurora Replicaが1台もなく、

ライターだけ

の場合、リーダーエンドポイントはライターへ接続します。

したがって、

リーダーエンドポイントを使っている
=
必ずAurora Replicaへ接続している

とは限りません。

読み取りスケーリングを目的とするなら、

Aurora Replicaが実際に存在するか

も確認します。

18. AuroraReplicaLagを監視する

Auroraでは、

AuroraReplicaLag

CloudWatchメトリクスによって、ライターから各Aurora Replicaへの更新反映の遅れを確認できます。

単位は、

ミリ秒

です。

また、

AuroraReplicaLagMaximum
AuroraReplicaLagMinimum

によって、クラスター内のレプリカ間の最大・最小ラグを確認できます。

読み取りスケーリング時は、

レプリカのCPU使用率
読み取りレイテンシー
読み取りスループット
AuroraReplicaLag

などを組み合わせて評価します。

19. Aurora Replicaの台数だけで性能を判断しない

例えば、

Aurora Replica
2台
↓
4台

へ増加しても、アプリケーションが、

インスタンスエンドポイント
↓
Aurora Replica 1だけ

へ接続し続けていれば、Aurora Replica 2〜4を読み取りスケーリングへ活用できません。

逆に、

リーダーエンドポイント
+
複数接続

で適切に読み取りを分散できれば、追加したレプリカを活用できます。

したがって、

レプリカの処理能力
+
接続の分散

を一緒に考えます。

20. リードレプリカとキャッシュを混同しない

キャッシュでは、

頻繁に再利用する
一部のデータや結果

を高速な場所へ保持します。

リードレプリカでは、

データベースのレプリカ

に読み取りクエリを分散します。

例えば、

同じ商品情報を
何度も取得
+
多少古くてもよい
+
マイクロ秒級が必要

ならキャッシュが有力な場合があります。

一方、

多様なSQL
+
大量の読み取り
+
キャッシュヒットを前提にできない

ならリードレプリカが有力です。

キャッシュ戦略そのものは別途設計し、ここでは読み取り処理をレプリカへ分散する判断に集中します。

21. リードレプリカと高可用性も同じ目的ではない

レプリカには、

読み取りスケーリング

と、

可用性 / 復旧

の両方に関係する機能があります。

しかし、

レプリカがある
=
すべて同じ役割

ではありません。

ここでの判断は、

通常時の読み取りトラフィックを
どのように分散するか

です。

フェイルオーバー、昇格、RTO/RPOなどは、可用性・継続性要件として別に判断します。

22. DynamoDBはRDS型のリードレプリカを追加するモデルではない

Amazon DynamoDBで読み取り負荷が増えた場合、

RDSと同じように
リードレプリカDBインスタンスを追加する

とは考えません。

DynamoDBはサーバーレスの分散データベースで、スループットキャパシティをサービス側で管理します。

したがって、

DynamoDB
+
読み取りスループット増加

では、

キャパシティモード
+
必要な読み取りキャパシティ

を評価します。

23. DynamoDBオンデマンドは読み取り量に合わせて自動スケールする

DynamoDBオンデマンドキャパシティモードでは、アプリケーションのトラフィック量に応じてスループットキャパシティが自動的に調整されます。

特に、

トラフィック量が予測しにくい
+
大きく増減する
+
キャパシティ管理を減らしたい

場合に有力です。

読み取りトラフィック増加
↓
RDS型リードレプリカ追加

ではなく、

DynamoDB
↓
オンデマンドキャパシティ

というサービス固有のスケーリング方式を評価します。

24. DynamoDBプロビジョンドモードではAuto Scalingを利用できる

DynamoDBをプロビジョンドキャパシティモードで使用する場合は、

読み取りキャパシティユニット
書き込みキャパシティユニット

を設定します。

DynamoDB Auto Scalingを使用すると、実際のトラフィックパターンに応じて、

テーブル
または
グローバルセカンダリインデックス

のプロビジョンドキャパシティを調整できます。

したがって、

DynamoDBの読み取りスケーリング

と、

RDS / Auroraのレプリカによる読み取りスケーリング

は同じ仕組みではありません。

25. DynamoDBグローバルテーブルを単純な同一リージョンリードレプリカとして扱わない

DynamoDBにはグローバルテーブルがありますが、

読み取りが増えた
↓
同じリージョンに
リードレプリカとして追加

というRDS型のモデルではありません。

グローバルテーブルは、

複数リージョン

でのデータ利用・継続性などを扱う機能です。

したがって、単一リージョンでDynamoDBの読み取りスループットを増やしたい場合は、まず、

キャパシティモード
+
スループット

を確認します。

26. 読み取りスケーリングが有効な条件

レプリカによる読み取りスケーリングが有効なのは、例えば、

読み取り負荷が高い
+
読み書きを分離できる
+
レプリカ側の古さを許容できる

場合です。

逆に、

ほとんどが書き込み

すべての読み取りで
直前の書き込みを必ず反映する必要がある

読み取りトラフィックを
レプリカへ振り分けられない

なら、レプリカ追加だけでは要件を満たせない可能性があります。

27. 読み取り台数を増やした後も監視する

読み取りレプリカを増やしたら、

導入完了

ではありません。

確認するのは、

ライターのCPU使用率
ライターの`ReadIOPS`
ライターの読み取りレイテンシー

レプリカのCPU使用率
レプリカの`ReadIOPS`
レプリカの読み取りレイテンシー

レプリケーションラグ

などです。

期待する状態は、

ライターの読み取り負荷
↓
低下

レプリカの読み取り負荷
↓
適切に分散

レプリケーションラグ
↓
許容範囲

です。

レプリカだけが高負荷になっていたり、ラグが許容値を超えていたりすれば、まだ性能目標を満たしていません。

28. 読み取りレプリカが増えれば必ず線形に性能が増えるわけではない

例えば、

レプリカ1台
↓
レプリカ2台

にしたからといって、

読み取りスループット
必ず2倍

になるわけではありません。

実際の性能は、

クエリ特性
+
接続分散
+
各レプリカの処理能力
+
共有する依存先
+
レプリケーションラグ

などに影響されます。

したがって、

レプリカ数

ではなく、

実際の読み取りスループット
+
読み取りレイテンシー
+
ライター負荷
+
レプリカラグ

で効果を確認します。

29. 混同ポイント

混同	正しい判断
DB CPUが高ければリードレプリカ	読み取り負荷がボトルネックか確認する
リードレプリカを作れば自動的に読み取りが移る	読み取り接続をレプリカへ振り分ける必要がある
リードレプリカは常に最新	非同期レプリケーションではラグを考慮する
リードレプリカを増やせば書き込みも分散する	主な目的は読み取りスケーリング
Aurora Replicaは常にラグ0	通常は小さいがラグは発生し得る
Auroraリーダーエンドポイントは個別クエリを分散する	接続単位でAurora Replicaへ分散する
リーダーエンドポイントを使えば必ずAurora Replicaへ接続する	Aurora Replicaが存在しなければライターへ接続する
DynamoDBにもRDS型リードレプリカを追加する	DynamoDBはキャパシティモードなどサービス固有方式でスケールする
レプリカとキャッシュは同じ	DBコピーへの読み取り分散と再利用データの高速保存は異なる
レプリカ数が2倍なら読み取り性能も必ず2倍	接続分散やクエリ、各リソースの能力も影響する

30. SAP-C02での判断フロー

データベース性能問題
        ↓
主な負荷は読み取り？
        │
        ├─ いいえ
        │    ↓
        │  リードレプリカ以外を評価
        │
        └─ はい
             ↓
読み取りと書き込みを
分離できる？
        │
        ├─ いいえ
        │    ↓
        │  別の性能改善を評価
        │
        └─ はい
             ↓
どのDBサービス？
        │
        ├─ Amazon RDS
        │      ↓
        │  リードレプリカ
        │
        ├─ Amazon Aurora
        │      ↓
        │  Aurora Replica
        │  +
        │  リーダーエンドポイント
        │
        └─ Amazon DynamoDB
               ↓
           キャパシティモード
           Auto Scaling等

        ↓

レプリカ利用時
古い読み取り結果を許容できる？

        │
        ├─ いいえ
        │    ↓
        │  最新値が必要な読み取りは
        │  ライターへ送る
        │
        └─ はい
             ↓
          レプリカへ読み取りを分散

        ↓

ReplicaLag /
AuroraReplicaLag

        ↓

読み取りレイテンシー
+
読み取りスループット
+
ライター負荷
を確認

        ↓

性能目標を満たすか

まとめ

レプリカによる読み取りスケーリングでは、

データベースが遅い
↓
レプリカ追加

とは判断しません。

まず、

読み取り負荷
か
書き込み負荷
か

を確認します。

読み取り中心であれば、

Amazon RDS
→ リードレプリカ

Amazon Aurora
→ Aurora Replica
→ リーダーエンドポイント

を評価できます。

ただし、

非同期レプリケーション
↓
古いデータを読む可能性

があるため、

ReplicaLag
AuroraReplicaLag

も確認します。

さらに、

レプリカを作る

だけではなく、

読み取りトラフィックを
実際にレプリカへ分散する

ことが必要です。

一方DynamoDBでは、

RDS型リードレプリカ

ではなく、

オンデマンドキャパシティ
プロビジョンドキャパシティ
Auto Scaling

など、サービス固有の方式で読み取りスループットを拡張します。

最終的には、

読み取り中心
+
読み取り / 書き込みを分離可能
+
許容できるデータ鮮度
+
適切な接続分散
+
レプリカラグが許容範囲

を満たすときに、レプリカによる読み取りスケーリングを選択します。

主要AWS公式資料

AWS Certified Solutions Architect - Professional 試験ガイド
Amazon RDS — リードレプリカの使用
Amazon RDS — リードレプリケーションのモニタリング
Amazon Aurora — パフォーマンスとスケーリング
Amazon Aurora — Aurora Replica
Amazon Aurora — リーダーエンドポイント
Amazon Aurora — CloudWatchメトリクス
Amazon DynamoDB — スループットキャパシティ
Amazon DynamoDB — オンデマンドキャパシティモード
Amazon DynamoDB — Auto Scaling

理解確認

このページの内容を9問で確認します。

理解確認9問へ →