Downloaded 41 times
Uploaded byTakekazu Omi
JAZUG 第2回 CDP 勉強会 Compensating Transaction, Index Table パターン
JAZUG 第2回 クラウドデザインパターン勉強会 Compensating Transaction Index Table パターン
![[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用](https://cdn.slidesharecdn.com/ss_thumbnails/withesmsmartphoneapplicationandcyclonecodename1000-111207215903-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
JAZUG 第2回 CDP 勉強会 Compensating Transaction, Index Table パターン
- 1. JAZUG 第2回 クラウドデザインパターン勉強会 CompensatingTransaction Index Table パターン kyrt / Takekazu Omi http://kyrt.in takekazu.omi@kyrt.in @takekazuomi 2014/8/20 1.0.1
- 2. クラウドデザインパターン Cloud Design Patterns:Prescriptive Architecture Guidance for Cloud Applications kyrt @takekazuomi 22014/8/20
- 3. 自己紹介 近江 武一 JAZUG AzureStorage 担当（自称） Microsoft MVP for Azure kyrt @takekazuomi 3 kyrt.in github.com/takekazuomi white paper
- 4. 本の紹介 • Microsoft patterns& practices • Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications • http://msdn.microsoft.com/en- us/library/dn568099.aspx • 翻訳が、2014年6月に出ました • クラウドデザインパターン Azureを例とし たクラウドアプリケーション設計の手引き • http://ec.nikkeibp.co.jp/item/books/P98330.html • 日経BP 以下、CDP本と記述 kyrt @takekazuomi 4
- 5. 内容 クラウドアプリケーション設計の頻出課題集 Software design patternの Cloud Application 版 •24のパターン •10のガイダンス ポスター • http://azure.microsoft.com/en-us/documentation/infographics/cloud- design-patterns/ kyrt @takekazuomi 5
- 6.
- 7.
- 8.
- 9. 前振り Data Management の一般的な課題 2014/8/20kyrt @takekazuomi 9
- 10. Data Management -CDP本 •8の問題領域の１つ http://msdn.microsoft.com/en-us/library/dn589772.aspx •４のガイダンスが関連 • Caching ガイダンス • Data Consistency 入門 • Data Partitioning ガイダンス • Data Replication and Synchronization ガイダンス http://msdn.microsoft.com/en-us/library/dn600216.aspx kyrt @takekazuomi 10
- 11. Data Management 3課題 Scalability Performance PartitioningConsistency •Scalability/Performance •スケールが上がった時に もパフォーマンスを維持 •Partitioning/Sharding • 分割する •Consistency • 一貫性/整合性 kyrt @takekazuomi 112014/8/20 必要 発生 悪影響
- 12. Performance と Partitioning •パフォーマンスを維持してスケール •物理ハードウェアの限界 •CPU, メモリ, ネットワーク •分割 • Partitioning, Shardingで対応 背景：Infrastructures as Code kyrt @takekazuomi 12
- 13. Partitioningと Consistency • Partition間の トランザクションコストは高い • 分散トランザクションの未サポート • 結果整合性（Eventual Consistency）の導入 • 分散トランザクションはコストが高いので、一時的な不整合は受け 入れて、結果的に整合性がとれた状態になればいいことにしよう＝ 結果整合性 • エラーなどで、不整合な状態になってしまった処理を回復するのが、 補正トランザクション • しかし、やっぱりパフォーマンスへの悪影響 • それにコードが複雑になるなど問題がある kyrt @takekazuomi 13
- 14. 今回説明する２つのパターン •Compensating Transaction パターン •補正トランザクション／補償トランザクション • トランザクションが失敗した場合に、トランザク ションを取り消す • 結果整合性のコンテキストで説明 •Index Table パターン • RDBMSでいうIndexの話 • PartitioningされたデータのIndex • Azure Tableのコンテキストで説明 kyrt @takekazuomi 14
- 15.
- 16.
- 17.
- 18. 課題と背景 •結果整合性 • 分散環境で競合を回避してパフォーマンスを改善す るには「強い整合性」ではなく「結果整合性」を実 装すべき • このモデルでは、トランザクションの実行中は整合 性が無いビューになる場合がある kyrt@takekazuomi 18 時間 整合 不整合 整合 m1 m2
- 19. 結果整合性の課題 1. トランザクションの実行中に整合性に欠 けるビューとなる期間がある 2. トランザクションの失敗時に回復（ロー ルバック）する処理が必要 2が「CompensatingTransaction パターン」の話 kyrt @takekazuomi 19
- 20.
- 21. 役割と課題 -2- •操作が他のサービスを呼び出している場合 もある •回復の処理はアプリケーションに依存する • 複雑なコード •高い実行コスト kyrt @takekazuomi 212014/8/20
- 22. 解決策 -1- • ワークフローの利用が、一般的なアプローチ •元の手順をキャプチャーして、取り消しに関する情 報を記録 • ワークフローを使って一連の手順を巻き戻す • 厳密に逆順で作業を戻す必要はない • 補正トランザクションが失敗する場合もあることを 考慮し、補正トランザクション自身も idempotent （べき等）であることが望ましい kyrt @takekazuomi 22
- 23. 解決策 -2- •ワークフローと元手順のキャプチャー • トランザクションの識別子を時系列で生成する •処理毎にトランザクションログデータを生成 • アプリケーション依存のRDBのトランザクションロ グと類似処理 • 補正トランザクションの対象となるような処理（＝ 失敗したトランザクション）を識別する方法が必要 kyrt @takekazuomi 23
- 24. 解決策 -3- • 高いレベルにおいては、失敗した場合に走る別の処 理（トランザクション）と考えた方が良い •走った結果はもとに戻る（Rollbackする）わけではなく、整合 性が取れた別の状態に遷移する • 低レベル（ビジネスロジックが関与しない）では、 本来なるべき状態に持っていく • 処理が idempotent ならば再度実行して完了させる • 規定回数再試行しても失敗するならば、不整合を通知してデー タをロックするなどの処理をする kyrt @takekazuomi 24
- 25. 問題点と検討事項 • 失敗の判定は簡単ではない • 補正ロジックはアプリケーション固有 •補正トランザクションは idempotent （べき等）が良い • 補正トランザクションには回復性が必要 • 再実行、進行状況 • 元に戻すではなく整合性のとれた状態にすると考える • 補正トランザクションの手順は元の逆順で無くても良い • リソースのタイムアウト付きロックを検討する • 補正トランザクションを最小にするためにリトライを入 れる kyrt @takekazuomi 25
- 26.
- 27.
- 28.
- 29. 旅行プラン作成 kyrt @takekazuomi 292014/8/20 CompensatingTransaction Pattern http://msdn.microsoft.com/en-us/library/dn589804.aspx 1. シアトル発ロンドン着のフライトF1予約 2.ロンドン発パリ着のフライトF2予約 3. パリ発シアトル着のフライトF3予約 4. ロンドンのホテルH1予約 5. パリのホテルH2予約
- 30. Starbucks Does NotUse Two-Phase Commit グレゴー・ホーペ Gregor Hohpe Enterprise Integration Pattern の人、 2004/11/9 • http://www.eaipatterns.com/ramblings/18_starbucks.html • https://code.google.com/p/gregors-ramblings-ja/wiki/18_starbucks kyrt @takekazuomi 30 スループット最大化
- 31.
- 32. Correlation （誰の注文か？） •非同期的なアプローチによって問題が発生 •注文の順番と飲み物を手渡す順番が違う • CorrelationIdentifier （相関識別子）として カップに書いた名前を呼ぶ（US) • 日本では、お客が飲み物の種類から相関を判断 kyrt @takekazuomi 32
- 33. 例外処理 (Exception Handling) •Write-off（損金処理） 注文は受けたけど支払い出来ない場合等 なにか不具合があって最後まで処理出来ない場合、なにもしない、あるいは処 理を破棄して損金として計上する • Retry（やり直し） 間違った飲み物を出してしまった場合等 一連の処理の一部が失敗した場合、再度実行する。処理が、idempotent ならば 全体を再試行する • Compensating Action （補償行為） 機械が壊れていて注文が処理できない場合等 これまで完了した全ての処理を取り消して元に戻す kyrt @takekazuomi 33
- 34.
- 35. リアル・ワールドは非同期だ • 現実世界はけっこう非同期で動いている • 日常生活の多くの部分は、協調こそ必要だが非同期に行 われる相互作用（電子メールを読んで返事を書いたり、 コーヒーを買ったりなど）で成り立っている •現実世界の相互作用をモデリングするには、非同期メッ セージングのアーキテクチャが自然な手段になる • 日常生活を見ていく中から、メッセージングによる上手 な解決法を設計するヒントが見出せる kyrt @takekazuomi 35
- 36. 分散アーキテクチャにおいて一貫性と交 換でスケーラビリティを手に入れる eBayでは、複数の物理的リソースに及ぶトランザク ションや、分散トランザクションは使わない Trading Consistency forScalability in Distributed Architectures by Floyd Marinescu & Charles Humble on Mar 04, 2008 • http://www.infoq.com/news/2008/03/ebaybase • http://www.infoq.com/jp/news/2008/03/ebaybase kyrt @takekazuomi 36
- 37.
- 38. Index Table パターン kyrt@takekazuomi 382014/8/20
- 39. 課題と背景 •多くのNoSQLシステムでは、RDBMSのセカ ンダリーインデックスが未サポート • プライマリーキー以外の検索が必要な場合 •RDBMSにおいても shardingをした場合、 shard 間 index はサポートされていない Index Table パターンを検討 kyrt @takekazuomi 392014/8/20
- 40. 解決策 ー 完全非正規化 •元のデータを完全にコピー して持つ • 更新が少ない場合は有効 kyrt @takekazuomi 40
- 41. 解決策 ー Indexキーのみ • Index Tableには Keyだけを持つ • 更新のコストが 低い • 参照時には２重 のルックアップ が必要 kyrt @takekazuomi 41
- 42. 解決策 ー 准非正規化 •頻繁に参照されるものをIndex Tableに収容 • 前２つの中間的な方法 kyrt @takekazuomi 42
- 43. 解決策 ー 複合キー •参照が特定の値の組み合 わせで頻繁に行われる場 合 • 複数のプロパティを結合 してKeyを作成するのが 有効 • セパレータには注意 BBB,AAA BBBA,AAA BBBA|AAA BBB|AAA kyrt @takekazuomi 43
- 44. 解決策 ー シャード間Index •シャードを跨いだ検索 が効率化 • 更新はシャード間更新 になるのでコストが高 い • global index • 複数のshard のデータを含む • 結果整合性モデル • 補正トランザクションが必要 • local index • 特定のshard 内だけのデータを 保持する kyrt @takekazuomi 44
- 45. 問題と検討事項 -1- • セカンダリーインデックスをメンテするオーバーヘッド は大きい •insert/update/deleteでindexも更新する • インデックステーブルに複製データを持つとストレージ コストとコピーの管理コストが増える • Index テーブル → Fact テーブルではルックアップコスト が２倍になる • 大規模なデータセットで複数のIndex テーブルだと整合性 を保つのが難しくなる kyrt @takekazuomi 45
- 46. 問題と検討事項 -2- •shard /partition 内Indexと、間Indexは分けて 考える • 同一shard / partitionに作成するIndexは扱い易い • 複数のshard / partition のデータを扱うIndexは結果整 合、補正トランザクションのモデルが必要 •Azure Tableでは、同一partition の場合は、エ ンティティグループトランザクションを利 用して整合性を補償できる kyrt @takekazuomi 46
- 47. 問題と検討事項 -3- •この機能の更新、参照のパフォーマンス問 題は、一般的なSQL データベースのイン デックスやカバリングインデックスの問題 と類似 •トレードオフも同等だが、実装をアプリ ケーションでする必要がある部分は大きく 違う kyrt @takekazuomi 47
- 48.
- 49.
Editor's Notes
- #14 ２PCは
- #19 強い整合性では、不整合の期間をシリアライズ、リソースのロックという方法を使って消している。 それが強い整合性がスケールしない理由になっている
- #30 個々の予約はアトミックな処理 全体で結果整合を構成している 処理毎に補正ロジックがある どこまで進んでいるかでキャンセルしなければいけない処理が変わる 補正ロジックはシリアルに実行する必要はない
- #35 2フェーズコミットは物事を大いに単純化してくれるのだが、同時にメッセージの自由な流れ（と結果としてスケーラビリティ）を制限することにもなる。 非同期に活動する複数の流れを遮って、状態をもったトランザクション資源を保持しなければならないからだ。
- #36 リアルな世界をモデリングする話は、オブジェクト指向でもあった
- #40 global index
- #42 本体をFact Tableと呼ぶ
- #44 カンマは、0x2bでAより前 BBB,AAA BBBA,AAA |は、7cでzより大きい BBBA|AAA BBB|AAA