『Architecting Distributed Transactional Applications』は、（おそらく）O'Reillyサブスク限定の短いレポートです。
著者ガイ ハリソンさんは、最近だと『CockroachDB: The Definitive Guide』を書かれた方で、20年以上前からデータベース関連の本を何冊も書かれています。
中でもOracleSQLチューニングは、新卒当初めちゃくちゃお世話になった本で、この本のおかげである程度のSQLが付きました。(ちなみに翻訳は、ひがさんだったりします)
分散トランザクションアプリケーション
このレポートでは分散トランザクションアプリケーションというお題目ですが、基本的には別々に分散アプリケーションと分散データベースについて語られています。
分散アプリケーション
分散アプリケーションは、いわゆるマルチリージョンにデプロイしたアプリケーションを意味し、グローバルロードバランサが、リクエストをリージョン毎のアプリケーションに振り分けるものをさしています。
多くの分散設計では、サービス間の一時的なメッセージはリージョンを跨ぐことはないが、リージョン全体のダウンも考慮して、マルチリージョンでレプリケーションするケースもちらほら見かけるようになった、としています。これは短いレポートなのでこの程度の言及具合ですが、実装のパターンは『Patterns of Distributed Systems』に結構詳しく載っています。
分散データベース
まず、CAP定理のトレードオフが変わってきているという話があります。
CAP定理(Brewerの定理)とは、分散システムでは3つの望ましい特性のうち、多くても2つしか持つことができないというものです。
- 一貫性
すべてのユーザーが同じデータベースの状態を見る。 - 可用性
分散システムのすべての要素に障害が発生しない限り、データベースは利用可能であり続ける。 - パーティション耐性
ネットワークパーティションによって分散システムが2つに分割されたり、ネットワーク上の2つのノードが通信不能になったりしても、システムは動作を継続できる。
以前は、ネットワークパーティションが問題だったので、一貫性を犠牲に、結果整合性を追い求めていました。が、大陸間ネットワークの冗長化によって、その発生確率が下がったので、分散型かつトランザクション一貫性を保証する方向に移行しつつある、というものです。GoogleのSpannerやCockroachDB、YugabyteDBがその代表例である、と。
なので、それらのデータベースではマルチリージョンでレプリケーションし、一貫性のために合意形成メカニズムを使います。ただ、レイテンシーと可用性の間にはトレードオフは残っていて、リージョンの存続が必要な場合、複数のリージョンがトランザクションの合意形成に参加する必要があるため、書き込みレイテンシが増加する、ということがあります。Writeヘビーなアプリケーションはそれを考慮して、結果整合性の方を選択する方がいいかもしれません。インフラ、ミドルウェアレイヤでは可用性+パーティション耐性か、一貫性+パーティション耐性かをプロダクションレディな状態で選択できるようになったので、具体的にどういうユースケースでどちらを選ぶべきかは、今後さらに議論されていくのではないかと思います。