モダンアプリケーションにおける分散トランザクションの動機と実装 @ AWS Dev Day 2023 Tokyo

© 2023, Amazon Web Services, Inc. or its affiliates. All
rights reserved. D E V D AY J U N E 2 3 , 2 0 2 3

rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. モダンアプリケーションにおける分散トランザクションの動機と実装パターン Yuji Nomura E - 1 Senior Solutions Architect, Enterprise Majority Focused Amazon Web Service Japan

rights reserved. 本セッションについて • 話すこと • トランザクションの分離についての俯瞰的な考察 • (ほとんど)話さないこと • 各パターンの具体的な AWS サービス実装 • 対象聴衆 • マイクロサービスの設計イメージについて知りたい⽅ • 分散トランザクションの最近の状況について俯瞰的に知りたい⽅

rights reserved. • デプロイの独⽴性とモダンアプリケーションの⽬的 • マイクロサービスの実装とトランザクションへの影響 • トランザクション分割の⽅針 • トランザクション分割実装パターン⽬次

rights reserved. ビジネスにおける価値原則プラクティスデプロイの独⽴性結果整合性トランザクションの分割俊敏性スケーラビリティ弾⼒性前半データレイヤーのプラクティスマイクロサービスアーキテクチャ

rights reserved. 後半コレオグラフィオーケストレーション同⼀ DB のトランザクション処理データの関係性補償要件・エラー要件⼀貫性 Saga パターン疎密緩い厳しい強い弱い分散合意系結果整合強整合 Event データ伝播

rights reserved. Independently Deployable （デプロイの独⽴性・独⽴デプロイ可能性・独⽴してデプロイ可能） • コード単位 • 開発プロセス単位 • リソース単位ビルド・デプロイ開発プロセス Int main(void) { printf(”Hello, world!”); printf(“Bye, world!”); return 0; } コード ---------- ---------- ---------- ---------- ---------- bin bin 本番環境リソース

rights reserved. Independently Deployable （デプロイの独⽴性・独⽴デプロイ可能性・独⽴してデプロイ可能） • メリット • チームの⾃律性 • 開発からリリースまでのスピード感 • 可⽤性・スケーラビリティ・弾⼒性

rights reserved. 現代のビジネス要求 • 俊敏性 • スケーラビリティ • 弾⼒性

rights reserved. 現代のビジネス要求 • 俊敏性 • スケーラビリティ • 弾⼒性モダンアプリケーションアーキテクチャによる原則化、プラクティス化マイクロサービスサーバーレスコンテナイベント駆動 AWS Lambda デプロイの独⽴性は原則として下⽀え

rights reserved. ⽬的の明確化 • 分割⾃体は⽬的ではない • 組織にとっての⽬標を指標化する

rights reserved. デプロイの独⽴性の実装 • マイクロサービスアーキテクチャ • ビジネスドメインでの分解 • ⼩さく、かつ1つの役割に専念 • ⾃律性（疎結合） • 独⽴した開発単位 • 独⽴した開発プロセス • 独⽴したリソース単位 • 組織論な⾯も⼤きい

rights reserved. デプロイの独⽴性とサービス分割の単位 • アーキテクチャ的な分離の観点は︖ • データレイヤーの分離は︖ サービス B サービス A サービス D サービス C ︖ RDB

rights reserved. データレイヤーも分離することサービス A サービス B A ⽤ B ⽤⾃分のエリアを跨いだやりとり同⼀トランザクション

rights reserved. サービス A サービス B A ⽤ B ⽤変更の影響が伝播データレイヤーも分離することスケールのしにくさ結合度が⾼まる危険性

rights reserved. A ⽤ B ⽤サービス A サービス B サービス API データレイヤーも分離すること変更の影響を受けにくい単独でスケール可能データの結合度の低下

rights reserved. A ⽤ B ⽤サービス A サービス B サービス API データレイヤーも分離することトランザクションの分割が発⽣

rights reserved. (参考) トランザクションによる安全の保証 • ACID特性 • Atomicity (原⼦性) • Consistency • Isolation (分離性) • Durability 時間 Commit 変更 B 変更 A Read 変更 A は⾒えない Write

rights reserved. 分散アプリケーションでは整合性の考え⽅が変わる Atomic かつ Isolated Atomic でも Isolated でもない

rights reserved. A ⽤ B ⽤サービス A サービス B サービス API マイクロサービスの分割の考え⽅ビジネスドメインの境界と同⼀にしたい

rights reserved. マイクロサービスの分割の考え⽅ • ビジネスドメインとサービスの分割境界を同⼀に • ⾼凝集・疎結合直販⼩売 SCM 製造発注

rights reserved. ドメイン駆動設計（DDD） • 設計における意思決定とドメイン設計の議論における技術的な⽤語の広義のフレームワークを提供 • ユビキタス⾔語ービジネスドメインエキスパートと開発者の間の意思疎通として利⽤される⽤語によってモデリングと設計を⾏う • 戦略的な設計のためのガイドラインー境界づけられたコンテキスト、蒸留、⼤規模な構造の考察「エリック・エヴァンスのドメイン駆動設計」︓エリック・エバンス著 2011/4/9 翔泳社「実践ドメイン駆動設計」︓ヴォーン・ヴァーノン著 2015/3/16 翔泳社

rights reserved. ドメイン駆動設計で定義される境界集約（Aggregate） • ⼀貫性（トランザクション）を保持する必要のある境界 • ⾃⼰完結した状態を管理する境界づけられたコンテキスト（Bounded Context） • 関連する集約のコレクション • より広い世界への明確なインターフェースを備える

rights reserved. ドメイン集約を跨ぐのであればトランザクションは切れているべき境界づけられたコンテキスト A 境界づけられたコンテキスト B 境界づけられたコンテキスト C 集約 A1 集約 A2 集約 B3 集約 C4 = マイクロサービスの単位〜

rights reserved. A ⽤ B ⽤サービス A サービス B サービス API トランザクション境界を意識した設計異なる集約同⼠はトランザクションを分割集約 1 集約 2

rights reserved. 開発者たちは、アトミックな変更が必須であると洗脳されているのが⼀般的だ。（しかし）ドメインエキスパートたちは整合性を保つのに時間がかかったとしても、それが合理的な遅延であれば受け⼊れてくれるものだ。実践ドメイン駆動設計 / Vaughn Vernon 第⼗章集約 10.5.「ルール︓境界の外部では結果整合性を⽤いる」

rights reserved. (参考) Consistency Model ⼀貫性モデル・整合性モデル • 強い整合性 • 例︓線形化可能性（Linearizability） • 変更が遅延なく伝わる • 評価順や読み取り順が仕組みによって制御される • 弱い整合性 • 例︓結果整合性（Eventual Consistency） • A であった変更が B にいつか伝わる • 過去の状態が⾒える • 全体として⼀致しない状態が制御できない形で表出する Consistencyって 200種類あんねん Linearizability External Consistency Quiescent Consistency Sequential Consistency Release Consistency Casual Consistency Processor Consistency PRAM Consistency Read Your Write Consistency Eventual Consistency Cache Consistency Slow Consistency Monotonic read Consistency Monotonic Write Consistency ……

rights reserved. まず結果整合性を検討する • DDDやマイクロサービスでなくても同じ⽂脈 • まずビジネスとシステムの関係を考えること • 分割におけるドメインエキスパートとの上流⼯程の重要性

rights reserved. 結果整合性が受け⼊れられない場合 • サービス境界の⾒直し • トレードオフを受け⼊れて結合度の⾼い⽅法を選択

rights reserved. ビジネスにおける価値原則プラクティスデプロイ独⽴性結果整合性トランザクションの分割俊敏性スケーラビリティ弾⼒性ここまでのまとめデータレイヤーのプラクティスマイクロサービスアーキテクチャ

rights reserved. トランザクションを分割するパターンコレオグラフィオーケストレーション同⼀ DB のトランザクション処理データの関係性補償要件・エラー要件⼀貫性 Saga パターン疎密緩い厳しい強い弱い分散合意系結果整合強整合 Event データ伝播

rights reserved. Saga パターン • もともと⻑命トランザクション（LLT）を扱うための⼿法 • 分散アプリケーションにおけるトランザクション管理の本命 • 失敗した時の補償トランザクションを含む • 考え⽅ • 分割されたトランザクションをそのまま順番に実⾏ • 失敗したらロールバックするまでを考える • サービスごとにトランザクションが決定するのが⾒える 1 2 -2 -1 3 OK OK OK NG NG rollback Commit

rights reserved. Saga パターン 1 2 -2 -1 3 OK OK OK NG NG rollback Commit オーケストレーションオーケストレーター状態ストア実⾏実⾏実⾏サービスA サービスB サービスC サービス A サービス B サービス D コレオグラフィ Done ⾮同期的なトリガーサービス C

rights reserved. Saga の上⼿な使い⽅ • トランザクションの境界に注意 • サービス間では Dirty Read が発⽣する • サービス内は ACID 特性を守ることができる • その他のテクニック • セマンティックロック（ロジック内のロック） • 冪等性サービス同⼠のトランザクション境界冪等性 A ⽤ B ⽤集約 1 集約 2 何回呼んでも同じ結果

rights reserved. Saga の利⽤例 • ビジネストランザクションを中⼼に分割と補償を考える • 予約の仕組み • 引き落としと振込 • 注⽂と在庫確保予約⽀払払戻予約解放確定 OK OK 実施完了キャンセル⽀払失敗オーケストレーター予約⽀払予約サービス⽀払サービス予約管理サービス予約状況確認予約解放払戻

rights reserved. AWS Step Functions 1 2 -2 -1 3 OK OK OK NG NG rollback Commit オーケストレーションのフルマネージドサービスオーケストレーター状態ストア実⾏実⾏実⾏サービス A サービス B サービス C

rights reserved. イベント駆動トランザクションを分割するパターンコレオグラフィオーケストレーション同⼀ DB のトランザクション処理データの関係性補償要件・エラー要件⼀貫性 Saga パターン疎密緩い厳しい強い弱い分散合意系結果整合強整合 Event データ伝播

rights reserved. 参照的にデータを共有する⽅法 • バッチ処理でのレプリケーション • APIやVIEWを使ったデータ公開 • イベント駆動アーキテクチャ

rights reserved. event [i-’vent] 名詞状態が変更されたことを⽰すシグナル

rights reserved. イベントは観察可能であり、指⽰ではないコマンドの指⽰請求書を発⾏してください。承知しましたイベントの観察 Xさんが今⼩物を注⽂しました請求書を送りますセールスレポートに追加します。

rights reserved. イベント駆動アーキテクチャ注⽂サービス請求サービス⼊⾦サービス販売予測サービスプロデューサコンシューマイベントルータールーティング/ フィルタ/ ルールキューキューキュー

rights reserved. Saga パターンにおけるコレオグラフィサービス A サービス B サービス D Done サービス C イベントイベントルーティング

rights reserved. イベントソーシングドメイン（アプリケーション）で発⽣したイベントを他のドメインに供給するためのデザインパターンイベント1 イベント2 イベント3 イベント4 プロセスプロセスプロセス

rights reserved. サービスA サービスB A⽤ B⽤変更の影響が伝播同⼀DBのトランザクション処理スケールのしにくさ結合度が⾼まる危険性 • サービスがDBを共有する場合かなり注意が必要

rights reserved. （参考）モジュラーモノリス A B C D E A, B C D E

rights reserved. 分散合意とはネットワーク的に分離している参加者間で全体として⼀つの結論を選択できるのか︖ 故障しない故障がすぐわかる故障がそのうちわかる故障するが復旧する邪悪な⼈が邪魔をする故障モデル難しい

rights reserved. 分散合意の使⽤例 in AWS Amazon DynamoDB の Multi-Paxos https://www.usenix.org/system/files/atc22-elhemali.pdf より Amazon Aurora のクォーラムシステム AWS Summit Tokyo 2018 セッションより

rights reserved. アプリケーションへの応⽤（分散コミット） • ⼆相コミット（2PC）のリスクロックの待ち時間によるレイテンシーの増加通信障害などによるロック状態の固定調停者調停者第1フェーズ第2フェーズ commit OK? OK! commit! 更新更新 commit OK? OK! commit! ロックロック故障しない故障がすぐわかる故障がそのうちわかる故障するが復旧する邪悪な⼈が邪魔をする故障モデル難しいここの障害に弱い

rights reserved. アプリケーションへの応⽤（分散コミット） • ⼆相コミットはアンチパターンになってしまった • クラウドの⽂脈で親和性が低い • ハードとの関わりの強い冗⻑構成になる • そもそも故障しないことが前提で⼿動オペレーションによる復旧を想定

rights reserved. 新たな分散コミットの例故障しない故障がすぐわかる故障がそのうちわかる故障するが復旧する邪悪な⼈が邪魔をする故障モデル難しいサービス調停者群 Paxos Commit DB1 DB2

rights reserved. 分散コミットのアプリケーション利⽤への是⾮ • トレードオフを考える • アルゴリズムが複雑で厳密性が必要であること • 典型的には過半数のノードが⽣きていることが前提 • 調停ノード群の⾦銭的なコスト • パフォーマンスへの影響

rights reserved. ビジネスにおける価値原則プラクティスデプロイの独⽴性結果整合性トランザクションの分割俊敏性スケーラビリティ弾⼒性まとめデータレイヤーのプラクティスマイクロサービスアーキテクチャ

rights reserved. 参考⽂献デプロイの独⽴性・マイクロサービスアーキテクチャ • マイクロサービスアーキテクチャ / Sam Newman ドメイン駆動設計 • エリック・エヴァンスのドメイン駆動設計 / Eric Evans • 実践ドメイン駆動設計 / Vaughn Vernon ⼀貫性モデル • データ指向アプリケーションデザイン / Martin Kleppman • 詳説データベース / Alex Petrov • The Art of Multiprocessor Programming / Maurice Herlihy Saga パターン • ソフトウェアアーキテクチャ・ハードパーツ / Neal Ford 他

モダンアプリケーションにおける分散トランザクションの動機と実装 @ AWS Dev Day 2...

モダンアプリケーションにおける分散トランザクションの動機と実装 @ AWS Dev Day 2023 Tokyo

More Decks by Yuji Nomura

Other Decks in Technology

Featured

Transcript