クラウドは代償をどう買い取るか

読了目安 約3分

Aurora、Spanner、Aurora DSQL を前章の言葉で解剖し、マネージドな分散データベースが何を肩代わりし、何を返してこないかを見ます。

前章の代償（読みしか増えない、境界をまたぐと万能型でなくなる、止まるかずれるか）は、クラウドのデータベースを高い順に眺めると、そのまま値札になっています。

Aurora: レプリケーションの面倒を消す

Amazon Aurora は、MySQL や PostgreSQL と互換のマネージドデータベースです。 計算（クエリ処理）と保存（ディスク）を分け、保存側を複数の場所へ複製された共有ストレージにしてあります。

レプリカは同じ共有ストレージを読むので、前章のレプリケーション遅延は数十ミリ秒まで縮みます（AWS の説明ではおよそ 10〜20 ミリ秒）。ゼロにはなりませんが、レプリカの追加も速くなります。 それでも、書き込みを受けるのは 1 台のままです。 Aurora が買い取るのは「読みを増やす作業」で、書き込みの上限は買い取りません。

Spanner と Aurora DSQL: 書き込みも分ける

Google Cloud Spanner と Amazon Aurora DSQL は、書き込みも複数台へ分散する SQL データベース（分散 SQL）です。 シャーディングを機械が自動でやり、しかも境界をまたぐトランザクションを守ります。 前章で「失う」と言った万能型の能力を、返してくれるわけです。

ただでは返ってきません。 複数台の合意を取ってからコミットを返すので、1 回のコミットに往復ぶんの時間が必ず乗ります。 台数を増やせば処理量は増えますが、1 コミットの速さは買えません。

CAP の言葉では、どちらも「止まる」側、つまり一貫性を選んだ設計です。 そのうえで Spanner は、Google 専用の回線でデータセンター間の分断そのものを起きにくくしています。 さらに GPS と原子時計（TrueTime）で、複数マシンの時刻のずれを常に数ミリ秒の幅として把握し、コミット時にはこの幅ぶん律儀に待ってから確定させます。 これにより、離れた場所のトランザクションでも実際に起きた順序どおりのタイムスタンプが保証されます（外部一貫性）。 時刻のずれ自体が消えるわけではなく、諦める場面の頻度と、ずれを待つコストを、お金で下げたと読むのが正確です。

同じ分散 SQL でも、衝突のさばき方が違う

同じ行を同時に触ろうとしたときの既定の設計が、この 2 つでは逆向きです（Spanner は選べば楽観的も使えます）。

楽観的な側では、衝突したら失敗してやり直すのはアプリの仕事です。 リトライを書いていないコードは、混んだときだけ壊れます。 道具を選ぶことは、アプリの書き方を選ぶことでもあります。

物理は買い取れない

整理すると、お金で買えるのは運用の作業で、物理は残ります。

• 合意には往復がかかる（コンピュータにおけるデータの操作とコスト感）
• 同じ行の奪い合いは、何台に分散しても直列に戻る（増やすほど遅くなることがある の競合）

だから、ここまでの理論はマネージドの上でもそのまま使えます。

試してみよう

次の 3 つに、この章の道具を選んでください。

1. 読みが 9 割の MySQL のサービス。運用の手間を減らしつつ読みを増やしたい
2. 3 つの地域から書き込みがあり、地域をまたぐ注文のトランザクションを守りたい
3. 全ユーザーが同じ 1 行のカウンタを更新する処理を、分散 SQL に載せたら速くなるか