JAZUG 第2回 CDP 勉強会 Compensating Transaction, Index Table パターン

JAZUG 第 2 回クラウドデザインパターン勉強会

Compensating TransactionIndex Table パターン

kyrt / Takekazu Omi

http://kyrt.in

[email protected]

@takekazuomi

2014/8/20 1.0.1

クラウドデザインパターンCloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications

kyrt @takekazuomi 22014/8/20

自己紹介

近江　武一JAZUG Azure Storage 担当（自称）

Microsoft MVP for Azure

kyrt @takekazuomi 3

kyrt.in

github.com/takekazuomiwhite

paper

kyrt @takekazuomi 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本と記述

http://msdn.microsoft.com/en-us/library/dn568099.aspx


http://ec.nikkeibp.co.jp/item/books/P98330.html

内容

クラウドアプリケーション設計の頻出課題集

Software design pattern の Cloud Application 版

•24 のパターン•10 のガイダンスポスター• http

://azure.microsoft.com/en-us/documentation/infographics/cloud-design-patterns/

kyrt @takekazuomi 5

http://azure.microsoft.com/en-us/documentation/infographics/cloud-design-patterns/




JAZUG で監訳

•翻訳と監訳のはざまに悩みつつも de:code で出せるように奮闘

kyrt @takekazuomi 6

回答集じゃない

課題が整理され、考慮点について記述されている

•8 の問題領域•10 の code sample

kyrt @takekazuomi 7


前振りData Management の一般的な課題

2014/8/20 kyrt @takekazuomi 9

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.aspxkyrt @takekazuomi 10






Data Management 3 課題 Scalabilit

yPerforma

nce

Partitioning

Consistency

•Scalability/Performance•スケールが上がった時に

もパフォーマンスを維持

•Partitioning/Sharding•分割する

•Consistency•一貫性 / 整合性


必要

発生

悪影響

Performance と Partitioning

•パフォーマンスを維持してスケール•物理ハードウェアの限界• CPU, メモリ , ネットワーク

•分割• Partitioning, Sharding で対応

背景： Infrastructures as Code kyrt @takekazuomi 12

Partitioning と Consistency

• Partition 間のトランザクションコストは高い• 分散トランザクションの未サポート

•結果整合性（ Eventual Consistency ）の導入• 分散トランザクションはコストが高いので、一時的な不整合は受け入れて、

結果的に整合性がとれた状態になればいいことにしよう＝結果整合性• エラーなどで、不整合な状態になってしまった処理を回復するのが、補正

トランザクション

•しかし、やっぱりパフォーマンスへの悪影響• それにコードが複雑になるなど問題がある

kyrt @takekazuomi 13

今回説明する２つのパターン

•Compensating Transaction パターン•補正トランザクション／補償トランザクション•トランザクションが失敗した場合に、トランザクションを取り消す•結果整合性のコンテキストで説明

•Index Table パターン• RDBMS でいう Index の話• Partitioning されたデータの Index • Azure Table のコンテキストで説明



右に青帯が付いているのは CDP 本に対する補足コメントのページ

2014/8/20


Compensating Transaction パターン補正トランザクション（補償トランザクション）


課題と背景

•結果整合性•分散環境で競合を回避してパフォーマンスを改善するには「強い整合性」ではなく「結果整合性」を実装すべき•このモデルでは、トランザクションの実行中は整合性が無いビューになる場合がある


時間

整合不整合整合

m1 m2

結果整合性の課題

1. トランザクションの実行中に整合性に欠けるビューとなる期間がある

2. トランザクションの失敗時に回復（ロールバック）する処理が必要

2 が「 Compensating Transaction パターン」の話


役割と課題 -1-

•結果整合性モデルで、失敗した場合の回復モデルの提供•複数の手順を戻す必要がある•単純に書き戻すようなロールバックは例外的


役割と課題 -2-

•操作が他のサービスを呼び出している場合もある•回復の処理はアプリケーションに依存する•複雑なコード•高い実行コスト


解決策 -1-

•ワークフローの利用が、一般的なアプローチ•元の手順をキャプチャーして、取り消しに関する情報を記録•ワークフローを使って一連の手順を巻き戻す•厳密に逆順で作業を戻す必要はない•補正トランザクションが失敗する場合もあることを考慮し、補正トランザクション自身も idempotent （べき等）であることが望ましい


解決策 -2-

•ワークフローと元手順のキャプチャー•トランザクションの識別子を時系列で生成する•処理毎にトランザクションログデータを生成•アプリケーション依存の RDB のトランザクションログと類似処理•補正トランザクションの対象となるような処理（＝失敗したトランザクション）を識別する方法が必要


解決策 -3-

•高いレベルにおいては、失敗した場合に走る別の処理（トランザクション）と考えた方が良い• 走った結果はもとに戻る（ Rollback する）わけではなく、整合性が

取れた別の状態に遷移する

•低レベル（ビジネスロジックが関与しない）では、本来なるべき状態に持っていく• 処理が idempotent ならば再度実行して完了させる• 規定回数再試行しても失敗するならば、不整合を通知してデータを

ロックするなどの処理をするkyrt @takekazuomi 24

問題点と検討事項•失敗の判定は簡単ではない•補正ロジックはアプリケーション固有•補正トランザクションは idempotent （べき等）が良い•補正トランザクションには回復性が必要• 再実行、進行状況

•元に戻すではなく整合性のとれた状態にすると考える•補正トランザクションの手順は元の逆順で無くても良い•リソースのタイムアウト付きロックを検討する•補正トランザクションを最小にするためにリトライを入れる



補正トランザクションは実行コストが高く複雑最小になるように設計


例


旅行プラン作成


Compensating Transaction Patternhttp://msdn.microsoft.com/en-us/library/dn589804.aspx

1. シアトル発ロンドン着のフライト F1予約

2. ロンドン発パリ着のフライト F2予約

3. パリ発シアトル着のフライト F3予約

4. ロンドンのホテル H1予約

5. パリのホテル H2予約

Starbucks Does Not Use 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


スループット最大化

http://www.eaipatterns.com/ramblings/18_starbucks.html



https://code.google.com/p/gregors-ramblings-ja/wiki/18_starbucks

スループット最大化•非同期処理•Queue base messageing•結果整合性•補正トランザクション


Correlation （誰の注文か？）

•非同期的なアプローチによって問題が発生•注文の順番と飲み物を手渡す順番が違う• Correlation Identifier （相関識別子）としてカップに書いた名前を呼ぶ（ US)•日本では、お客が飲み物の種類から相関を判断


例外処理 (Exception Handling)

• Write-off（損金処理）注文は受けたけど支払い出来ない場合等なにか不具合があって最後まで処理出来ない場合、なにもしない、あるいは処理を破棄して損金として計上する

• Retry（やり直し）間違った飲み物を出してしまった場合等一連の処理の一部が失敗した場合、再度実行する。処理が、 idempotent ならば全体を再試行する

• Compensating Action （補償行為）機械が壊れていて注文が処理できない場合等これまで完了した全ての処理を取り消して元に戻す


Two-Phase Commit でやったら•レジで注文する•お金を財布から出し、レジに置く•飲み物が出来るまで待つ•飲み物が出来きたら、レジに置く•お金と飲み物を交換

店舗で処理できる注文数が減り売上が…kyrt @takekazuomi 34

リアル・ワールドは非同期だ

•現実世界はけっこう非同期で動いている•日常生活の多くの部分は、協調こそ必要だが非同期に行われる相互作用（電子メールを読んで返事を書いたり、コーヒーを買ったりなど）で成り立っている•現実世界の相互作用をモデリングするには、非同期メッセージングのアーキテクチャが自然な手段になる•日常生活を見ていく中から、メッセージングによる上手な解決法を設計するヒントが見出せる


分散アーキテクチャにおいて一貫性と交換でスケーラビリティを手に入れるeBay では、複数の物理的リソースに及ぶトランザクションや、分散トランザクションは使わない

Trading Consistency for Scalability 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


http://www.infoq.com/news/2008/03/ebaybase

http://www.infoq.com/news/2008/03/ebaybase

http://www.infoq.com/jp/news/2008/03/ebaybase





Index Table パターン

2014/8/20

課題と背景

•多くの NoSQL システムでは、 RDBMS のセカンダリーインデックスが未サポート•プライマリーキー以外の検索が必要な場合

•RDBMS においても sharding をした場合、shard 間 index はサポートされていない

Index Table パターンを検討kyrt @takekazuomi 392014/8/20

解決策ー完全非正規化

• 元のデータを完全にコピーして持つ• 更新が少ない場合は有効


解決策ー Index キーのみ• Index Table に

は Keyだけを持つ• 更新のコストが低い• 参照時には２重

のルックアップが必要


解決策ー准非正規化

• 頻繁に参照されるものを Index Table に収容• 前２つの中間的な方法


解決策ー複合キー• 参照が特定の値の組み合わせで頻繁に行われる場合• 複数のプロパティを結合

して Key を作成するのが有効• セパレータには注意

BBB,AAABBBA,AAABBBA|AAABBB|AAA


解決策ーシャード間 Index• シャードを跨いだ検索

が効率化• 更新はシャード間更新

になるのでコストが高い• global index

• 複数の shard のデータを含む • 結果整合性モデル• 補正トランザクションが必要

• local index• 特定の shard 内だけのデータ

を保持する


問題と検討事項　 -1-

•セカンダリーインデックスをメンテするオーバーヘッドは大きい• insert/update/delete で index も更新する

•インデックステーブルに複製データを持つとストレージコストとコピーの管理コストが増える• Index テーブル → Fact テーブルではルックアップコストが２倍になる•大規模なデータセットで複数の Index テーブルだと整合性を保つのが難しくなる



•shard / partition 内 Index と、間 Index は分けて考える•同一 shard / partition に作成する Index は扱い易い•複数の shard / partition のデータを扱う Index は結果整合、補正トランザクションのモデルが必要

•Azure Table では、同一 partition の場合は、エンティティグループトランザクションを利用して整合性を補償できる



•この機能の更新、参照のパフォーマンス問題は、一般的な SQL データベースのインデックスやカバリングインデックスの問題と類似•トレードオフも同等だが、実装をアプリケーションでする必要がある部分は大きく違う


いつパターンを使うか

•プライマリーキー以外のキーでデータを参照する頻度が高い場合•データの高い頻度で更新され揮発性が高い場合は、 Index テーブルが古くなるのが早い。メンテナンスのコストと効果のバランスを検討する• Index テーブルのキーのカーディナリティが低い場合は有効ではない



終