1.
クラウドデザイン パターンに見る
クラウドファーストな
アプリケーション設計
Data Management編
kyrt / Takekazu Omi
http://kyrt.in
takekazu.omi@kyrt.in
@takekazuomi
2014/7/26 1.0.0

2.
クラウドデザインパターン
Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications
kyrt @takekazuomi 22014/7/26

3.
紹介
• 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 3

4.
内容
クラウドアプリケーション設計の頻出課題集
Software design pattern の Cloud Application 版
•24のパターン
•10のガイダンス
ポスター
• http://azure.microsoft.com/en-us/documentation/infographics/cloud-
design-patterns/
kyrt @takekazuomi 4

5.
回答集じゃない
課題が整理され、考慮点について記述されて
いる
•8つの問題領域
•9つのcode sample
kyrt @takekazuomi 5

6.
Design Patterns
kyrt @takekazuomi 62014/7/26
名称 Availability
Data
Management
Design and
Implementation
Messaging
Management
and
Monitoring
Performance
and Scalability
Resiliency Security Code samples
Cache-Aside Pattern ◯ ◯
Circuit Breaker Pattern ◯
Compensating Transaction Pattern ◯ ◯
Competing Consumers Pattern ◯ ◯
Compute Resource Consolidation Pattern ◯ ◯
Command and Query Responsibility Segregation Pattern ◯ ◯ ◯
Event Sourcing Pattern ◯ ◯
External Configuration Store Pattern ◯ ◯ ◯
Federated Identity Pattern ◯
Gatekeeper Pattern ◯
Health Endpoint Monitoring Pattern ◯ ◯ ◯
Index Table Pattern ◯ ◯
Leader Election Pattern ◯ ◯
Materialized View Pattern ◯ ◯
Pipes and Filters Pattern ◯ ◯ ◯
Priority Queue Pattern ◯ ◯ ◯
Queue-Based Load Leveling Pattern ◯ ◯ ◯
Retry Pattern ◯
Runtime Reconfiguration Pattern ◯ ◯ ◯
Scheduler Agent Supervisor Pattern ◯ ◯
Sharding Pattern ◯ ◯
Static Content Hosting Pattern ◯ ◯ ◯ ◯
Throttling Pattern ◯ ◯
Valet Key Pattern ◯ ◯ ◯

7.
Guidance
kyrt @takekazuomi 7
名称 Availability Data Management
Design and
Implementati
on
Messaging
Manageme
nt and
Monitoring
Performanc
e and
Scalability
Resiliency Security
code
samples
Guidance Asynchronous Messaging Primer ◯
Autoscaling Guidance ◯
Caching Guidance ◯ ◯
Compute Partitioning Guidance ◯
Data Consistency Primer ◯ ◯
Data Partitioning Guidance ◯ ◯
Data Replication and Synchronization Guidance ◯ ◯
Instrumentation and Telemetry Guidance
Multiple Datacenter Deployment Guidance ◯
Service Metering Guidance

8.
対象
Cloud Application ってなに？
なんでこんな話をしているのか
kyrt @takekazuomi 82014/7/26

9.
Cloud Application
対象ドメイン、クラウドアプリケーション
•コモディティ化されたハードウェアを利用
•個々のハードウェアには性能上限があり、
スケールアウトで対応
•予測できないワークロードに対応
kyrt @takekazuomi 9

10.
Infrastructure as Code
•CodeでInfrastructure が操作できるPlatform
•インスタンスのコストは低い
• ランニング
• 調達
•個々のインスタンスのスケールアップの選
択肢には制限
kyrt @takekazuomi 10

11.
構成
kyrt @takekazuomi 11
Web Front Layer Worker Layer Persistence Layer

12.
Cloud Platform Provider の視点
• 同じハードウェアを大量に提供
• 調達コスト
• 管理
• 運用
• 避けられないハードウェアの多様化
• 調達時期による違い（その時点でのベスト）
• ユーザー要求の多様化
• 標準インスタンス
• メモリ集中型インスタンス
• コンピューティング集中型インスタンス
• http://azure.microsoft.com/ja-jp/pricing/details/cloud-services/
• その他、GPU、ストレージの最適化など
• http://aws.amazon.com/jp/ec2/instance-types/
kyrt @takekazuomi 12

13.
Cloud Platform
• 前提となっている Cloud Platform の機能
• 非同期 messaging
• Resource Management
• 永続化
• Caching
• Deploy Management
• AWS、GCEなど、大体ある
kyrt @takekazuomi 13

14.
問題領域
• 可用性 Availability
• データ管理 Data Management
• 設計および実装 Design and Implementation
• メッセージング Messaging
• 管理及び監視 Management and Monitoring
• パフォーマンスおよびスケーラビリティ
Performance and Scalability
• 回復性 Resiliency
• セキュリティ Security
kyrt @takekazuomi 14

15.
Data Management
本資料は、
データ管理、永続化、Azure Table
kyrt @takekazuomi 152014/7/26

16.
データ管理
•8つのパターンと、4つのガイダンスに関連
「Performance and Scalability」と並ぶ大きな
課題
•インターネットスケールのアプリケーショ
ンをサービスするための最大の課題の１つ
kyrt @takekazuomi 16

17.
コモディティハードウェア
データ管理の足回り、Azure Storageのハードウェア例
kyrt @takekazuomi 172014/7/26

18.
Persistence Layer
•Data Management（データ管
理）の上で最も重要なこと
↓
•Persistence Layer （永続化
層）の特性
kyrt @takekazuomi 182014/7/26

19.
Rack構成例
• MSがサーバー設計をOpen Compute
Project にコントリビュート(2014/1/28)
• http://www.opencompute.org/wiki/Motherboard/
SpecsAndDesigns#Specs_and_Designs
• Rack(3 or 4c), Chassis(12U, 24sb), Server
blades(1U,)
• server blades (compute or storage)
• 最大96 server / rack
• 10 E5-2400 each compute blade
kyrt @takekazuomi 19
Microsoft’s Cloud Server Hardware
from Data Center Knowledge

20.
6G JBOD blade
http://www.opencompute.org/wiki/Motherboard/SpecsAndDesigns#Specs_and_Designs
Open CloudServer / JBOD Bladev1.0 Jan 28, 2014 Microsoft P6から
kyrt @takekazuomi 20

21.
6G JBOD blade
•シンプルなデザイン、最低限のパーツで構
成
•1U の半分の幅の form factor
•10 x 3.5” HDDs をサポート
kyrt @takekazuomi 21

22.
Quantum 10 v2
kyrt @takekazuomi 22
de:code 2014 SV-011 Microsoft Azure インターナル より
http://www.microsoftvirtualacademy.com/training-courses/decode-track2

23.
読み取れること
•storage stamp（ = Cluster）は、20 Rack で構
成
•Rackには、36 node / rack 入っている
•Rackには、4c x 12b x 2 = 96 blade/rack 入る
•96-36 = 60 で、Rack内に、JBOD blade が60
枚＝600個のHDD（概算）
kyrt @takekazuomi 23

24.
補足
•stamp のDISKは、30PB
• SOSP Paper - Windows Azure Storage: A Highly Available
Cloud Storage Service with Strong Consistency から
•30PB / 60 / 20 = 2.5TB
•Computeでは、960 ノード入るはずなのに、900
になっている
（残は予備？）
kyrt @takekazuomi 24

25.
Partitioning
Azure Storageは、stamp 内を storage
account/partition に分けて管理
•データ操作を複数のサーバーに分散させ、
ボトルネックを回避
•複数のパーテーションの操作は並列処理
•データは3重にリプリケーションして別
rackに配置
kyrt @takekazuomi 25

26.
Azure storage architecture components
• partition server と、stream
server は、同一ノード内に配
置
• partition server は、stamp 内
のすべてのstream server へア
クセス可
• stamp 内リプリケーションは
rack間で同期コピー
kyrt @takekazuomi 262014/7/26
s
front end
partition layer
stream layer
storage stamp
VIP
stamp内リプリケーション

27.
特性
•レイヤーが3つに分かれてる
• Layer 間は 10Gbps Ethernet 接続。つまりレイテン
シーが大きい（10ms程度）
•パーテーション分割が前提
• パーテーションのパフォーマンス(Table 1KB Entity)
• 単体：2,000 tx/sec, 複数：20,000 tx/sec
• http://msdn.microsoft.com/en-
us/library/azure/dn249410.aspx
kyrt @takekazuomi 27

28.
一般的なクラウドストレージの特性
•スピンドルが大量にある
• I/Oが並列処理能力が高い
•ネットワーク接続されたサーバーによるク
ラスターで実装
• レイテンシーが大きい（SAS HDDや、PCIe SSDなど
に比べて）
kyrt @takekazuomi 28

29.
言い換えると
•レイテンシーが大きい
• Azure Blob 16KB read/write 9ms 程度
• HDD 平均待ち時間 2ms (1万5000rpm)
•I/O 並列可度が高い
• Azure TableのSingle Partition Writeで24並列まで比例
• HDD だと、スピンドル数＝並列化数
kyrt @takekazuomi 29

30.
アプリケーション設計
kyrt @takekazuomi 302014/7/26

31.
基本戦略
•Caching
•Data Partitioning
•Data Consistency のコントロール
kyrt @takekazuomi 31

32.
Caching
kyrt @takekazuomi 322014/7/26

33.
何故Cacheを使うのか
•レイテンシー対策にCache は有効
• HDD時代アクセスタイムの対策は意味がない
• シーケンシャルリード、ライトは速くない
• 先行読み出し
• I/Oスケジューリングは逆効果
•ストレージの負荷軽減
• 変更が少ないデータの読込先として利用
kyrt @takekazuomi 33

34.
Caching：CDP本から
•Caching Guidance
• Cacheデータの不整合の扱い方
•Cache-Aside Pattern
• cache systemが、リードスルー方式、ライトスルー／
ライトバック方式をサポートしてない場合にアプリ
ケーションで実装するパターンの説明
kyrt @takekazuomi 34

35.
・・・
•更新が頻繁なものは、あまりキャッシュに適さ
ない等。普通の話なのでSKIP
•リードスルー、ライトスルー／ライトバックを
サポートしたcacheがメジャーではない
• 機能のリッチさより、低レイテンシーが重要
• 不一致を防ぎ切ることは難しい
•まず、ローカルCacheで足りるかを検討する。
共有Cacheはその次ぎ
kyrt @takekazuomi 35

36.
Data Partitioning
kyrt @takekazuomi 362014/7/26

37.
パーテーション分割する理由
CDP本より５つ
•スケーラビリティの改善
•パフォーマンスの改善
•可用性の改善
•セキュリティの改善
•運用の柔軟性
kyrt @takekazuomi 372014/7/26

38.
スケーラビリティの改善 -1-
CDP本
•スケールアップでは、物理ハードウェアの
限界に達する
•データを分割して別々のサーバーにホスト
することで、ほぼ無限にスケールアウトで
きる
kyrt @takekazuomi 38

39.
スケーラビリティの改善 -2-
In My Opinion
•必要なスケーラビリティの目途を立てる
• フェルミ推定
•利用するプラットフォームの性能を知る
• 日頃から測定する癖を付ける
• マイクロベンチマークはくそと思わない
kyrt @takekazuomi 39

40.
スケーラビリティの改善 -3-
In My Opinion
•物理ハードウェアの限界を越える条件を立てる
• 物理ハードウェア＝ single partition
•最初から分割を前提にするべきか
• 分割前提だと検討事項が増える＝時間がかかる
• 分割なしー＞分割ありで、作り直すコストを検討
kyrt @takekazuomi 40

41.
パフォーマンスの改善 -1-
CDP本
•パーテーションへのデータアクセスは、最適な
分割では効率化できる
•複数のパーテーションに対する操作は並列に実
行できる
•データの保存されているパーテーションをアプ
リケーションの近くに配置することでネット
ワーク遅延を最小にできる
kyrt @takekazuomi 41

42.
パフォーマンスの改善 -2-
In My Opinion
• 最適な分割であっても、分割にはオーバーヘッドがある
• 最適な分割とは何か
• 複数のパーテーションのパフーマンスメリット享受には操作並
列が必須
• Cloud Applicationでは自然と並列操作になるが、Batch系は要注意
• アプリケーションとデータのパーテーションの位置関係を最適
化するには、どちらかのmobilityが必要
• パーテーションの移動。Blobはあるけど、Tableは無い
• Globalに配置されるようなアプリケーション固有の問題（今のところ）
kyrt @takekazuomi 42

43.
パフォーマンスの改善 -3-
In My Opinion
• パフォーマンス改善の話は、スケーラビリティと裏
表の関係にある
• パーテーション間の依存性が少なければ比例定数は
１。多くなると1未満になる
• 依存性はパーテーション間の通信と言い換えても良い
• Azure Table ではパーテーション間の通信が発生するのは
「partition serverがどのpartitionを担当するかが変更される時に、
paxos cluster で合意を取る時だけ」
kyrt @takekazuomi 43

44.
可用性の改善 -1-
CDP本
•データを複数のサーバーに分けることで単
一障害点を作らない
•パーテーション停止時の影響は限定的
•パーテーション複製で停止の影響をさらに
減らすことが可能
kyrt @takekazuomi 44

45.
可用性の改善 -2-
In My Opinion
•パーテーション分割を持って、単一障害点
（SPOF)の排除といえるかどうかは、データ
の配置次第
•パーテーション複製でパーテーション内の
整合性を保証するだけで良いシナリオでは、
複製するデータ量を削減でき分割は有効
kyrt @takekazuomi 45

46.
パーテーション分割の設計
３つの分割方針
kyrt @takekazuomi 462014/7/26

47.
３つの分割方針
CDP本
•水平分割 （シャーディング）
•垂直分割
•機能分割
kyrt @takekazuomi 47

48.
水平分割 （シャーディング）
kyrt @takekazuomi 48

49.
垂直分割
kyrt @takekazuomi 49

50.
機能分割
kyrt @takekazuomi 50

51.
分割方式の選択
In My Opinion
•シャーディングが一番面倒なシナリオが多い
•垂直分割は、機能分割は、分割シナリオとして
は問題点が少ない
•複数の分割をまたぐようなトランザクションは
効率が悪く、サポートされていない場合もある
kyrt @takekazuomi 51

52.
パーテーション設計
CDP本
3つの視点
•スケーラビリティ
•クエリーパフォーマンス
•可用性
kyrt @takekazuomi 52

53.
スケーラビリティ -1-
CDP本
• アプリケーションを分析。多くの場合、少数の主要なエ
ンティティがリソースの大半を消費
• スケーラビリティターゲットの設定
• 水平分割ではshard keyの選定がデータ配置が決まる
• ストレージの要件（容量、処理能力、ネットワーク帯域
幅等）を確認
• 稼働後は分散具合の確認
kyrt @takekazuomi 53

54.
スケーラビリティ -2-
In My Opinion
•少数の主要なエンティティがリソースの大半を
消費していたら、そこは sharding を検討する
•水平分割ではshard keyの選定が最も重要
• レンジ、ハッシュを検討する
•分散結果の確認
• アプリケーション稼働後は shard key の分布を確認
kyrt @takekazuomi 54

55.
クエリーパフォーマンス -1-
CDP本
•小さなデータセットを使うことやクエリの
並列実行で改善
•パーテーションがデータセット全体の小さ
な部分の場合、データ量削減のメリットが
得られる
kyrt @takekazuomi 55

56.
クエリーパフォーマンス -2-
In My Opinion
•パーテーションのデータセットが小さい方が、
クエリーには有利
• 少ないExtentで済むので、Cacheも当たるし、オンメモリ
で処理が済む場合が増える
•パーテーションを跨ぐようなクエリは要注意
• Azure Tableだとパーテーション毎に別クエリーを同時に
投げた方が速い
kyrt @takekazuomi 56

57.
問題点 -1-
CDP
• パーテーション跨ぎの処理は遅い
• パラレルにクエリー実行する。依存関係のあるクエリーは同時には
実行できないので注意
• 静的なデータは、パーテーション内に複製することを検
討
• 分割した結果、パーテーションを跨いだ更新処理が整合
性に与える影響を検討する
• 強い整合性より結果整合性が使われることが多い
kyrt @takekazuomi 57

58.
問題点 -2-
CDP
•複数パーテーションにアクセスするトラン
ザクションはなるべく避ける
•補正トランザクションを検討する
kyrt @takekazuomi 58

59.
問題点 -3-
In My Opinion
•複数パーテーションを含んだトランザク
ションは避ける
• 分散トランザクションはコストが高い
•上記が必要な場合、結果整合性を使う
•補正トランザクションを用意する
kyrt @takekazuomi 59

60.
Data Consistency
データ整合性
kyrt @takekazuomi 602014/7/26

61.
2つの整合性
CDP本
•強い整合性 ( strong consistency )
•結果整合性 ( eventual consistency )
kyrt @takekazuomi 612014/7/26

62.
強い整合性
•すべての変更はatomic
•トランザクション実行中のデータは不可視
•強い整合性モデルの目標は、アプリケー
ションが整合性の無いデータに触れる機会
を最小限にすること
•強い整合性モデルはコストが高い＝ノード
間の通信が多い
kyrt @takekazuomi 62

63.
結果整合性
•データの整合性において比較的、実用性の
高いアプローチ
•一時的に整合性が取れていないように見え
る期間があるが、最終的には整合性が取れ
た状態になる（IMO)
kyrt @takekazuomi 63

64.
整合性
In My Opinion
• strong consistency を実装するには、ロックで保護したり、Rollback処理
をしたりする必要がある
• クラウドのシナリオではコストが高い＝ノード間の通信
• リソースによって、 Rollback の定義、動作が違う場合がある
• 補正トランザクションはアプリケーション要件に依存する
• パーテーション内は、 strong consistency 、パーテーション間は、
eventual consistency
• eventual consistencyでは、補正トランザクションを用意
kyrt @takekazuomi 64

65.
補正トランザクション
Compensating Transaction Pattern
kyrt @takekazuomi 652014/7/26

66.
役割と課題
•結果整合性モデルで、失敗した場合の回復
モデルの提供
•手順すべてを戻す必要がある
•単純に書き戻すようなロールバックは例外
的
•操作が他のサービスを呼び出している場合
もある
kyrt @takekazuomi 662014/7/26

67.
解決策 -1-
• 一般的なアプローチはワークフローを使うことです。
• 元の手順をキャプチャーして、取り消しに関する情報を
記録し、補正トランザクションでは、ワークフローを
使って手順を巻き戻します
• 補正トランザクションでは、厳密に逆順で作業を戻す必
要はありません
• 補正トランザクションが失敗する場合もあることを考慮
し、補正トランザクション自身も idempotent であること
が望ましい
kyrt @takekazuomi 67

68.
解決策 -2-
In My Opinion
•ワークフローと元の手順をキャプチャーする話
• トランザクションの識別子を時系列で生成する
• トランザクションログと似てるが、複雑すぎて汎用的な
実装は困難
• 補正トランザクションの対象となるような処理を識別す
る方法が必要
kyrt @takekazuomi 68

69.
解決策 -3-
In My Opinion
• 高いレベルにおいては、失敗した場合に走る別の処理（トラン
ザクション）と考えた方が良い
• 走った結果はもとに戻る（Rollbackする）わけではなく、整合性が取れた別の
状態に遷移する
• 低レベル（ビジネスロジックが関与しない）では、本来なるべ
き状態に持っていく
• 処理が idempotent ならば再度実行して完了させる
• 規定回数再試行しても失敗するならば、不整合を通知してデータをロックす
るなどの処理をする
kyrt @takekazuomi 69

70.
Special Thanks
•この資料のフォントは、Source Han Sans を
使っています
• https://github.com/adobe-fonts/source-han-sans/
kyrt @takekazuomi 70

71.
kyrt @takekazuomi 712014/7/26