博士

ロボ子、今日のITニュースはAurora DSQLのStrong Consistencyについてじゃぞ！

ロボ子

Strong Consistencyですか。Eventual Consistencyとの違いは何でしょう？

博士

Eventual Consistencyだと、データが最終的には整合するものの、一時的に不整合が起こりうるんじゃ。例えば、「アプリケーションプログラマーは、データベースのAPIに対して、データが存在しないという奇妙な現象に対処する必要がある」みたいなことが起こるのじゃ。

ロボ子

なるほど。マイクロサービスでデータの不整合によるバグが発生する可能性もあるんですね。

博士

そうなんじゃ！それに、「Read-Modify-Write操作において、Read Replicaからの読み込みが期待どおりに値を変更しない可能性がある」という問題もあるぞ。

ロボ子

Strong Consistencyの利点は何ですか？

博士

Strong Consistencyなら、「アプリケーションプログラマーがデータの不整合に対処するための複雑なコードを書く必要がなくなる」んじゃ！

ロボ子

それは嬉しいですね。マイクロサービスでのバグも回避できると。

博士

そうじゃ！それに、「Read-Modify-Write操作において、クエリプロセッサが任意のレプリカから読み込めるため、スケーリングが容易になる」というメリットもあるぞ。

ロボ子

Aurora DSQLでは、どのようにStrong Consistencyを実現しているんですか？

博士

まず、「すべての読み込みはStrong Consistencyを持つ」んじゃ。そして、「各ストレージレプリカは、1つまたは複数のジャーナルから更新を受け取る」のじゃ。

ロボ子

ジャーナルから更新を受け取る、ですか。

博士

そうじゃ。「クエリプロセッサは、トランザクション開始時にタイムスタンプを選択し、レプリカにそのタイムスタンプまでのデータを要求する」んじゃ。レプリカは、「すべてのジャーナルからより高いタイムスタンプを確認した場合、データを提供する」のじゃ。

ロボ子

もし、レプリカがまだ追いついていない場合はどうなるんですか？

博士

「そうでない場合は、書き込みストリームが追いつくまで読み込みをブロックする」んじゃ。

ロボ子

なるほど、それでStrong Consistencyが保たれるんですね。

博士

そういうことじゃ！「Strong Consistencyは、アプリケーション開発者やエンドユーザーが複雑さを回避できるようにする」んじゃ。

ロボ子

Eventual Consistencyが適している場合もあるんですか？

博士

「Eventual Consistencyは、レイテンシーと接続性のトレードオフが存在する場合には適切だが、サービスやAPIには適していない」んじゃ。

ロボ子

勉強になります！

博士

ところでロボ子、Strong Consistencyと聞いて、私がいつも冷蔵庫のプリンをStrongにキープしていることを思い出したぞ。誰にも渡さん！

ロボ子

博士、それEventualにバレますよ…。