データ基盤

Amazon Auroraとは|写しの遅れが0.5秒だと、読みの77.6%が直前の書き込みを見られなかった

何が分かれている構成なのか読みを写しへ回すと何が起きるのか書いた直後の読みはどうなるのか

写しの遅れが0.5秒のとき、読みの77.6%は直前の書き込みが届いていない状態でした。

0.005秒なら1.5%です。書き込みが1秒に3件あるので、遅れが少し延びるだけで急に増えます。

この記事の要点

  • 遅れ0.005秒で1.5%
  • 0.05秒で13.9%
  • 0.5秒で77.6%
  • 書いた直後は0%か100%

計算と保管が分かれている

保管の器は1つで、そこに複数の実体がつながります。増やすのは計算の側だけです。

Amazon Auroraの構成は、公式が端的に述べています。AuroraのDBクラスターは、計算の能力と保管の分離を示すものであるという記述です。

保管は共通です。公式はAuroraのクラスター用の器とは、複数の可用性ゾーンにまたがる仮想のデータベース保管の器であり、各ゾーンがクラスターのデータの写しを持つと説明しています。

2種類の実体

  1. 書き込みを行う実体。1つだけ。保管の器への変更をすべて担う
  2. 読み取り専用の実体。最大15。同じ器につながる
  3. 保管の器。共通。実体を増やしてもデータは複製されない
  4. 入れ替わり。書き込み側が使えなくなると、読み取り側が引き継ぐ

3番目が、通常の写しと違う点です。読み取り専用の実体を足しても、データそのものは増えません

それでも遅れは生まれます。各実体が手元に持っている状態を、書き込みに合わせて更新する必要があるためです。

この形を選ぶ理由

読みを分けられます。PostgreSQLの記事で数えたように、読みと書きは索引の効く向きが逆です。分けられれば、それぞれに合わせられます。

ただし書き込みは1つの実体に集まります。書き込みの側は、実体を増やしても速くなりません

出典AWS ドキュメント「Amazon Aurora DB clusters」2026-08-18 確認
The Aurora DB cluster illustrates the separation of compute capacity and storage.
原文AWS ドキュメント「Amazon Aurora DB clusters」 この内容の有効期限2027-02-18

写しの遅れが0.5秒だと、読みの77.6%が直前の書き込みを見られなかった

遅れそのものより、書き込みの頻度が効きます。頻度が高いほど、短い遅れでも影響が広がります。

Amazon Auroraの読み取り専用の実体は、公式によれば書き込みを行う実体と同じ保管の器につながるが、読み取りの操作のみに対応するものです。

同じ器につながっていても、手元の状態が追いつくまでには時間があります。その影響を数えました。

写しの遅れを変える

6時間ぶんで、書き込み6.5万件・読み取り64.8万件です。1秒あたり3件の書き込みがあります。

text
6時間ぶん。書き込み 64,779件・読み取り 648,176件
写しに届くまでの遅れを変えて、古い内容を読んだ割合を見る

写しの遅れ         0.01秒後に読む        0.1秒後に読む          1秒後に読む  (直前の書き込みが届いていない読み)
0.005秒                  0.0%            0.0%            0.0%                      1.5%
0.05秒                 100.0%            0.0%            0.0%                     13.9%
0.5秒                  100.0%          100.0%            0.0%                     77.6%
2秒                    100.0%          100.0%          100.0%                     99.8%

右端の列を見てください。遅れ0.005秒なら1.5%ですが、0.5秒では77.6%です。

100倍の遅れで、割合は52倍になりました。比例ではありません。

書き込みの頻度が効く

この割合を決めているのは、遅れの間に書き込みが入るかどうかです。

1秒に3件の書き込みなら、0.5秒の間に1件以上入る確率は約0.78です。77.6%という測定値と一致します

つまり書き込みが少ない系では、同じ遅れでも影響が小さくなります。1秒に0.1件なら、0.5秒の遅れでも5%程度です。

遅れを100倍にすると、影響は52倍になる。

直前の書き込みが届いていない読み(%)写しの遅れ(秒)→1102.20.005秒0.05秒0.5秒2秒1秒あたり3件の書き込みでの実測。書き込みが少ない系では、同じ遅れでも割合は下がる。
図1 ── 写しの遅れと、届いていない読みの割合
出典AWS ドキュメント「Amazon Aurora DB clusters」2026-08-18 確認
Connects to the same storage volume as the primary DB instance but supports only read operations.
原文AWS ドキュメント「Amazon Aurora DB clusters」 この内容の有効期限2027-02-18

書いた直後の読みだけは、確率の話にならない

間隔が遅れより短ければ、必ず古いものを読みます。0%か100%のどちらかです。

Amazon Auroraの読み取り専用の実体は、負荷を分ける目的でも使えます。公式は読み取り専用の実体は、書き込みを行う実体から読みの作業負荷を引き受けることもできると述べています。

ただし、すべての読みを回してよいわけではありません。前の表の左側3列がそれを示しています。

0%か100%になる

書いた直後に読む場合、割合は0.0%か100.0%しかありません。中間がないのです。

間隔が遅れより短ければ必ず古く、長ければ必ず新しいものが読めます。運任せの部分がありません

だから対策も明確です。書いた直後に読む処理だけを、書き込み側へ向けることになります。

どれを回すか

  1. 一覧や集計。回せる。直前の1件が欠けても成り立つ
  2. 他人が書いたものを読む。回せる。もともと間隔が長い
  3. 登録した直後の確認画面。回さない。必ず古いものを読む
  4. 書いてから条件を確かめる処理。回さない。判断が変わる

3番目がいちばん起きます。登録して一覧に戻ると、登録したものが出てこないという形です。

1番目と2番目だけを回しても、読みの多くはそちらです。回せない処理を除いても、分ける効果は残ります

余談 この計測での注意

写しの遅れは一定の値として置いています。実際には書き込みの量や実体の負荷で変動し、遅れが大きくなる時間帯があります。書き込みと読み取りの時刻も一定の割合で引いており、実際には波があります。ここで見せているのは、影響の広さが遅れそのものではなく、遅れの間に書き込みが入る確率で決まるという関係です。その確率は、自分の系の書き込み頻度から計算できます。

出典AWS ドキュメント「Amazon Aurora DB clusters」2026-08-18 確認
Aurora Replicas can also offload read workloads from the primary DB instance.
原文AWS ドキュメント「Amazon Aurora DB clusters」 この内容の有効期限2027-02-18

よくある質問

Auroraは何が分かれていますか
計算と保管です。書き込みを行う実体と、読み取り専用の実体が、同じ保管の器につながります。
読みを写しへ回すと何が起きますか
直前の書き込みが届いていないことがあります。遅れ0.5秒では読みの77.6%が該当しました。
書いた直後に読む場合は
間隔と遅れの比較だけで決まります。間隔のほうが短ければ、必ず古いものを読みます。
どの読みを写しへ回せばよいですか
直前の書き込みに依存しない読みです。一覧や集計はここに当たります。

まとめ

  • 計算と保管が分かれている
  • 写しは読み取り専用
  • 遅れの分だけ古いものを読む
  • 書いた直後の読みは回さない

今日から始められること

  1. 1秒あたりの書き込み件数を測る
  2. 写しの遅れを記録する
  3. 書いた直後に読む処理を洗い出す
  4. その処理だけ書き込み側へ向ける

実務で組んだAmazon Auroraのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る