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

読了目安 約4分

Aurora、Spanner、Aurora DSQL を前章の言葉で解剖し、マネージドな分散データベースが何を肩代わりし、どんな費用が残るかを見ます。

前章では、単一プライマリ構成では書き込みが増えないこと、単純なシャーディングでは境界をまたぐ処理が難しくなること、ネットワーク分断中は一貫性と可用性を同時に保証できないことを説明しました。 クラウドの分散データベースは、その実装と運用の一部を肩代わりします。

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

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

同じリージョンにある Aurora レプリカは共有ストレージを読むため、AWS の説明ではレプリケーション遅延は通常、数十ミリ秒です。 ゼロではありませんが、従来の論理レプリケーションより短く抑えやすく、レプリカの追加も速くなります。

通常の Aurora クラスターでは、書き込みを受ける DB インスタンスは 1 台のままです。 この構成で Aurora が肩代わりするのは、主に読み取りの拡張とレプリケーションの運用であり、書き込みを複数台へ水平分散することではありません。

ただし、Aurora PostgreSQL Limitless Database は別の構成です。 データを複数のシャードへ分け、ルーターが分散クエリと分散トランザクションを調停するため、複数のシャードで書き込みを並行処理できます。

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

Google Cloud Spanner と Amazon Aurora DSQL は、書き込みも複数台へ分散する SQL データベース（分散 SQL）です。 シャーディングを機械が自動でやり、しかも境界をまたぐトランザクションを守ります。 前章で説明した、シャードをまたぐ処理の実装と運用をデータベース側が引き受けます。

一方、書き込みのコミット経路には、複数ノードの合意や同期レプリケーションの通信が入ります。 台数を増やして全体の処理量を伸ばせても、1 回のコミットの遅延はネットワーク距離と配置の影響を受けます。

どちらも、複数の場所に同期複製しながら強い一貫性を提供します。 しかし、任意のネットワーク分断でもすべての場所から必ず読み書きできる、という意味ではありません。 一貫性を保つためにクォーラムを使う系では、クォーラムへ到達できない側の要求が失敗することがあります。

Spanner は、GPS と原子時計を使う分散時計 TrueTime によって、現在時刻を不確かさの幅とともに扱います。 書き込みトランザクションでは、割り当てたコミット時刻が確実に過去になったと判断できるまで待ってから結果を公開します。 これにより、あるトランザクションが完了したあとに別のトランザクションが始まったなら、その順序とコミット順序が一致する 外部一貫性を保証できます。

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

同じ行を同時に触ろうとしたときの既定の方式は、この 2 つで異なります。

Spanner は分離レベルと設定によって楽観的同時実行制御も選べます。 どちらの方式でもトランザクションが中止される場合はありますが、Aurora DSQL は競合をコミット時に検出し、SQLSTATE 40001 を返します。 アプリケーションは、処理を冪等にしたうえでトランザクション全体を再試行できるようにします。 ツールを選ぶことは、アプリの書き方を選ぶことでもあります。

物理は買い取れない

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

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

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

試してみよう

次の 3 つに、この章のツールを選んでください。

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