SpannerとAurora DSQLの同時実行制御の違いに想いを馳せる

Google CloudのSpannerとAWSのAurora DSQLそれぞれの同時実行制御の違いと魅力を紹介しながらも、これらを開発した組織のカルチャーに想いを馳せます

Transcript

1. SpannerとAurora DSQLの 同時実行制御の違いに想いを馳せる 2025.03.25 LayerX SRE & Cloud Native Night! Masaki Kato
2. 自己紹介 2 Masaki Kato データベースとクラウドをこよなく愛するアプリケーションアーキテクト。 MasakiもKatoもよく被ります。会社では3人目のMasaki Kato ▪所属 • アクセンチュア株式会社 テクノロジーコンサルティング本部 • 金融・公共系プロジェクトのアプリアーキチームによくいます • Google Cloud Partner Top Engineer 2024-2025 • Jagu’e’r (Google Cloud User Community) エバンジェリスト ▪趣味 • 去年フルマラソンデビュー。今年もまた走りたいです • Clineで色々作るのにはまっています
3. データベース、使ってますか？ 3
4. データベースの意義 4 データを保存する
5. データベースの意義 5 データを保存する データを分析する
6. データベースの意義 6 データを保存する 安全に 高速に ペタバイト級の データを分析する キーバリュー 形式の 障害時のデータ ロスト無し 排他制御 一貫した データ アトミックな 変更 ベクトル 形式の グラフ 形式の 柔軟な スキーマ データ更新時 に通知を出す データ の結合 複雑な 検索条件
7. データベースの意義 7 データを保存する 安全に 高速に ペタバイト級の データを分析する キーバリュー 形式の 障害時のデータ ロスト無し サービス構築時に求められる要件のうち、 データに関わる部分を一手に引き受けてくれる存在 排他制御 一貫した データ アトミックな 変更 ベクトル 形式の グラフ 形式の 柔軟な スキーマ データ更新時 に通知を出す データ の結合 複雑な 検索条件
8. クラウド時代の分散SQLデータベース “NewSQL” 8 「マルチリージョンでの強整合性・高可用性」と「SQLライクなインターフェイス」を併せ持つDBへの 要望のため、GoogleはSpannerを開発。これらの特徴を持つDBはNewSQLと呼ばれる。 クラウド時代のRDBが抱える課題 • 可用性向上・負荷分散のためにはシステム を複数のサーバーに冗長化するしかないが、 分散することでデータの一貫性を保てない ジレンマ • 読み込み専用のレプリカを配置することで 読み込み負荷のみ分散 書き込み インスタンス 読み込み専用 レプリカ データコピー NewSQLによる解決策 • テーブルを複数の小さな単位に分割するこ とで負荷の分散。 • DBサーバー間で合意をとり同期しながら コミットを実行することで高可用性を実現。 DBサーバー群 相互に通信し 同期しながら書き込み
9. Spannerのアーキテクチャ 9 書き込み合意・排他制御を行うspanserverとデータの永続化を行うストレージ層である Colossusに分かれる。テーブルをtabletと呼ばれる小さな集合に分け、Paxosステートマシンを 利用してサーバー間での合意をとりながら更新を行う。 universemaster placement driver Zone 2 location proxy zone master span server Zone 3 location proxy zone master span server spanserver (Leader) lock table tx manager tablet tablet Paxos Paxos Zone 1 location proxy zone master span server Colossus spanserver (Replica) tablet tablet Paxos Paxos spanserver (Replica) tablet tablet Paxos Paxos Colossus Colossus コンピューティング層 ストレージ層 Spanner: Google’s Globally Distributed Database: ACM Transactions on Computer Systems: Vol 31, No 3
10. Spannerの魅力: BigQueryとのシームレスな連携 10 Google CloudのマネージドデータウェアハウスサービスBigQueryもSpannerと同じくColossus にデータを配置しているため、Spannerによって書き込まれたデータに対しBigQueryからクエリを 発行し分析することが可能。 3大クラウドが分散DBの開発で競う、老舗のGoogle「Spanner」を追撃へ | 日経クロステック（xTECH） Spanner BigQuery Colossus データ書き込み クエリ発行 This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.
11. Spannerの魅力: 高精度な時計によるデータの外部一貫性 11 Spannerは全てのコミット操作にタイムスタンプを割り当てる。システムは分散されているものの必 ずコミットされた順序とタイムスタンプ順序は一致し、コミットは直列可能となる。TrueTimeと呼ば れる誤差も含めた時刻の取り扱いによってこの仕組みを実現。 時刻t サーバーA サーバーB 現実の時刻 05秒に書き込み 操作&コミット 06秒にトランザク ション開始&読み込み
12. Spannerの魅力: 高精度な時計によるデータの外部一貫性 12 現実において分散システムそれぞれが持つ時計には誤差があり、データの一貫性の担保が難しい。 時刻t サーバーA サーバーB 現実の時刻 06秒にトランザクション開 始&読み込んだが、時刻の誤 差から05秒のコミットより 古いデータを読み込み 05秒に書き込み 操作&コミット
13. Spannerの魅力: 高精度な時計によるデータの外部一貫性 13 コミット時にサーバー間の時刻のゆらぎの分だけロックを持ち続けることで、すべてのサーバーにとって コミット時刻を過去にする。これによりデータが外部から見て一貫するようにコミットが可能。 時刻のゆらぎの分だけトランザクションのスピードはスローダウンする。 時刻t サーバーA サーバーB 現実の時刻 06秒に開始したトランザクションは、 ロック解放を待機する。 05秒にコミット →すべてのサーバーが05秒に なるまでロックを持ち続ける
14. Spannerの魅力: 高精度な時計によるデータの外部一貫性 14 この正確な時刻の扱いのために、GPSと小型の原子時計をデータセンターに配置。時刻の誤差を 通常1-7ms程度に抑え、外部一貫性と高速トランザクションを両立。 TrueTime | Kevin Sookocheff
15. 2023年 AWSは高精度時刻同期をサポートするハードウェアを発表 15 内部的にGPSと原子時計を利用したハードウェアを配置することで、高性能な時刻同期が可能に。 AWS re:Invent 2023 - Monday Night Live Keynote with Peter DeSantis
16. コンピューティング層 ストレージ層 AZ Endpoint Query Processor Adjudicator Storage Adjudicator Adjudicator Journal Journal Journal Storage Storage Storage Storage Query Processor AZ Endpoint AZ Endpoint Query Processor Query Processor クエリ処理 競合制御 永続化 読み取り最適化 AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube 2024年 AWSはNewSQLサービス “Aurora DSQL”を発表 16 サーバーレスなNewSQLサービスを発表。マルチリージョンでの強整合性と高速なトランザクションに 強みを持つ。クエリ処理、分散合意、永続化、クエリストレージの4レイヤー構成になっている。 データにタイムスタンプを付与する等の基本的な要素はSpannerと類似している様子。
17. コンピューティング層 ストレージ層 AZ Endpoint Query Processor Adjudicator Storage Adjudicator Adjudicator Journal Journal Journal Storage Storage Storage Storage Query Processor AZ Endpoint AZ Endpoint Query Processor Query Processor クエリ処理 競合制御 永続化 読み取り最適化 AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube Aurora DSQLの特徴的な同時実行制御 17 読み込み時にはQuery ProcessorがStorageへデータをクエリ。ロック操作なし。 Read Write Commit
18. コンピューティング層 ストレージ層 AZ Endpoint Query Processor Adjudicator Storage Adjudicator Adjudicator Journal Journal Journal Storage Storage Storage Storage Query Processor AZ Endpoint AZ Endpoint Query Processor Query Processor クエリ処理 競合制御 永続化 読み取り最適化 AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube Aurora DSQLの特徴的な同時実行制御 18 書き込みリクエストはQuery Processorで保持。ロック操作なし。 Read Write Commit
19. コンピューティング層 ストレージ層 AZ Endpoint Query Processor Adjudicator Storage Adjudicator Adjudicator Journal Journal Journal Storage Storage Storage Storage Query Processor AZ Endpoint AZ Endpoint Query Processor Query Processor クエリ処理 競合制御 永続化 読み取り最適化 AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube Aurora DSQLの特徴的な同時実行制御 19 コミット時にはじめてAdjudicatorにて競合が判断される楽観的ロックを採用。競合発生時に はトランザクションが失敗となるが、徹底的にロックの取得にともなうリージョン間の競合制御回数を 減らすことで高速化を狙う。 Read Write Commit
20. SpannerのMutationを使ったバッチ書き込み 20 Spannerは悲観的ロックを採用しているが、Mutationを用いたバッチ書き込みにて同様の高速化 を狙うことが可能。 通常のSQL Mutation Cloud Run Cloud Spanner Cloud Run 参照 更新 コミット 更新 参照 コミット 更新 更新 Spannerへの通信が 都度発生 変更をアプリ内に 蓄積 コミット時に一括 送信 Cloud Spanner This presentation makes reference to marks owned by third parties. Unless otherwise noted, all such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.
21. 同じNewSQLでなぜ違いが生まれるのか？ 21
22. ビジネスが変わればシステムも変わる 22 • 広告を中心に様々なサービスを持つ • プロダクトごとに多様なDBへのビジネスニー ズが想定される。 • ビジネスニーズに応じたアプリ開発者による 拡張余地を残すようなSpannerの設計思 想。 GoogleとAmazonのビジネスの差が強くあらわれているように見える。 • Amazon.comが中心。 • プライムデーの大量トラフィックの中で高速に レスポンスを返す必要あり。 • DynamoDBの運用を通じ楽観的ロックで システムを構築する知見を持つ。 • 「Simple」「Elastic」なサービスが多い。 悲観的ロック・Mutation書き込みの 選択肢を備えたデータベース 楽観的ロックに特化した シンプルかつ高速なデータベース Google Amazon
23. 我々はこのことから何を学ぶことができるか 23
24. ビジネス要求をシステムに反映させることの大切さ・難しさ 24
25. ビジネス要求をシステムに反映させることの大切さ・難しさ 25 データを保存する 安全に 高速に ペタバイト級の データを分析する キーバリュー 形式の 障害時のデータ ロスト無し 排他制御 一貫した データ アトミックな 変更 ベクトル 形式の グラフ 形式の 柔軟な スキーマ データ更新時 に通知を出す データ の結合 複雑な 検索条件
26. ビジネス要求をシステムに反映させることの大切さ・難しさ 26 データを保存する 安全に 高速に ペタバイト級の データを分析する キーバリュー 形式の 障害時のデータ ロスト無し 自社のビジネスにおいて、どの要素が大切でどの要素が不要か 理解できているか？ 排他制御 一貫した データ アトミックな 変更 ベクトル 形式の グラフ 形式の 柔軟な スキーマ データ更新時 に通知を出す データ の結合 複雑な 検索条件
27. ビジネス要求をシステムに反映させることの大切さ・難しさ 27 • 自分がAWSのエンジニアだったとして、楽観的ロックを採用することでトランザクション性能の向上が出来るという知 識があったか、性能向上を狙うビジネス判断とそのために悲観ロックを捨てる決断ができたか。 • 自分がGoogleのエンジニアだったとして、悲観ロックの性能を補うためのMutation機能が提供できたか。 • アーキテクチャ決定においては、ビジネスがシステムに求める機能とシステムへの深い理解の両方がないと良い選 択ができない。 • リスクが大きい判断はPoCしながら影響を見極める or 戻れるようなアーキテクチャにするようなアーキテクトとしての 力量も問われる。 エンジニア としての知識の 広さ・深さ ビジネス面の 理解度・知見
28. まとめ 28 • GoogleとAWSのNewSQLを紹介！両方とも美しいアーキテクチャだった。 • 発表を聞いてくださった皆さんも家に原子時計が欲しくなったはず。 • 同時実行制御の違いに両サービスのビジネス面での違いが見えるようで面白い。 • 自分が構築するサービスがサービスのビジネス面の特性を反映しているか、そのことをビジネス側 のメンバーは理解しているのか、考え直す機会になった。 エンジニア としての知識の 広さ・深さ ビジネス面の 理解度・知見
29. 参考資料 29 • Spanner: Google’s Globally Distributed Database: ACM Transactions on Computer Systems: Vol 31, No 3 • Cloud Spanner のロックについて • Spanner #ポエム – Qiita • Amazon Aurora DSQL の同時実行制御 | Amazon Web Services ブログ • AWS を活用した 2023 年のプライムデー – 数字が示す驚異的なメトリクス • AWS re:Invent 2023 - Monday Night Live Keynote with Peter DeSantis • AWS re:Invent 2024 - Get started with Amazon Aurora DSQL (DAT424) – YouTube • AWS re:Invent 2024 - Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW) – YouTube • DSQL Vignette: Transactions and Durability - Marc's Blog • TrueTime | Kevin Sookocheff • 【JAWS-UG朝会】今更ながら Amazon DynamoDB の論文を真面目に読んでみた • 3大クラウドが分散DBの開発で競う、老舗のGoogle「Spanner」を追撃へ | 日経クロステック（xTECH）
30. Thank You