Date post: | 10-May-2015 |
Category: |
Software |
Upload: | takekazu-omi |
View: | 1,582 times |
Download: | 1 times |
クラウドデザイン パターンに見るクラウドファーストなアプリケーション設計Data Management 編
kyrt / Takekazu Omi
http://kyrt.in
@takekazuomi
2014/7/26 1.0.0
クラウドデザインパターンCloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications
kyrt @takekazuomi 22014/7/26
kyrt @takekazuomi 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本と記述
内容
クラウドアプリケーション設計の頻出課題集
Software design pattern の Cloud Application 版
•24 のパターン•10 のガイダンスポスター• http
://azure.microsoft.com/en-us/documentation/infographics/cloud-design-patterns/
kyrt @takekazuomi 4
回答集じゃない
課題が整理され、考慮点について記述されている
•8 つの問題領域•9 つの code sample
kyrt @takekazuomi 5
Design Patterns
kyrt @takekazuomi 62014/7/26
名称 AvailabilityData
Management
Design and Implementa
tion
Messaging
Management and
Monitoring
Performance and
ScalabilityResiliency 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 ◯ ◯ ◯
Guidance
kyrt @takekazuomi 7
名称 AvailabilityData Management
Design and Implementation
Messaging
Management and Monitoring
Performance and Scalability
Resiliency Securitycode 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
対象Cloud Application ってなに?なんでこんな話をしているのか
kyrt @takekazuomi 82014/7/26
Cloud Application
対象ドメイン、クラウドアプリケーション
•コモディティ化されたハードウェアを利用•個々のハードウェアには性能上限があり、スケールアウトで対応•予測できないワークロードに対応
kyrt @takekazuomi 9
Infrastructure as Code
•Code で Infrastructure が操作できるPlatform•インスタンスのコストは低い•ランニング•調達
•個々のインスタンスのスケールアップの選択肢には制限
kyrt @takekazuomi 10
構成
kyrt @takekazuomi 11
Web Front Layer Worker Layer Persistence Layer
kyrt @takekazuomi 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 13
Cloud Platform
•前提となっている Cloud Platform の機能
•非同期 messaging•Resource Management•永続化•Caching•Deploy Management
•AWS 、 GCE など、大体ある
問題領域• 可用性 Availability
• データ管理 Data Management
• 設計および実装Design and Implementation
• メッセージングMessaging
• 管理及び監視 Management and Monitoring
• パフォーマンスおよびスケーラビリティPerformance and Scalability
• 回復性 Resiliency
• セキュリティ Securitykyrt @takekazuomi 14
Data Management本資料は、データ管理、永続化、 Azure Table
kyrt @takekazuomi 152014/7/26
データ管理
•8 つのパターンと、 4 つのガイダンスに関連「 Performance and Scalability 」と並ぶ大きな課題•インターネットスケールのアプリケーションをサービスするための最大の課題の1つ
kyrt @takekazuomi 16
コモディティハードウェアデータ管理の足回り、 Azure Storage のハードウェア例
kyrt @takekazuomi 172014/7/26
Persistence Layer
•Data Management (データ管理)の上で最も重要なこと
↓•Persistence Layer (永続化層)の特性
kyrt @takekazuomi 182014/7/26
kyrt @takekazuomi 19
Rack 構成例
• MS がサーバー設計を Open Compute Project にコントリビュート (2014/1/28)• http://www.opencompute.org/wiki/Mot
herboard/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
Microsoft’s Cloud Server Hardware from Data Center Knowledge
6G JBOD blade
http://www.opencompute.org/wiki/Motherboard/SpecsAndDesigns#Specs_and_DesignsOpen CloudServer / JBOD Bladev1.0 Jan 28, 2014 Microsoft P6から
kyrt @takekazuomi 20
6G JBOD blade
•シンプルなデザイン、最低限のパーツで構成•1U の半分の幅の form factor
•10 x 3.5” HDDs をサポート
kyrt @takekazuomi 21
Quantum 10 v2
kyrt @takekazuomi 22
de:code 2014 SV-011 Microsoft Azure インターナル よりhttp://www.microsoftvirtualacademy.com/training-courses/decode-track2
読み取れること
•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
補足
•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
Partitioning
Azure Storage は、 stamp 内を storage account/partition に分けて管理•データ操作を複数のサーバーに分散させ、ボトルネックを回避•複数のパーテーションの操作は並列処理•データは 3 重にリプリケーションして別 rackに配置
kyrt @takekazuomi 25
kyrt @takekazuomi 26
Azure storage architecture components
• partition server と、 stream server は、同一ノード内に配置• partition server は、 stamp 内 のすべての stream server へアクセス可• stamp 内リプリケーションはrack 間で同期コピー
2014/7/26
s
front end
partition layer
stream layer
storage stamp
VIP
stamp 内リプリケーション
特性
•レイヤーが 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
一般的なクラウドストレージの特性
•スピンドルが大量にある• I/O が並列処理能力が高い
•ネットワーク接続されたサーバーによるクラスターで実装•レイテンシーが大きい( SAS HDD や、 PCIe SSDなどに比べて)
kyrt @takekazuomi 28
言い換えると
•レイテンシーが大きい• Azure Blob 16KB read/write 9ms 程度•HDD 平均待ち時間 2ms (1万 5000rpm)
• I/O 並列可度が高い• Azure Table の Single Partition Write で 24 並列まで比例•HDD だと、スピンドル数=並列化数
kyrt @takekazuomi 29
アプリケーション設計
kyrt @takekazuomi 302014/7/26
基本戦略
•Caching•Data Partitioning•Data Consistency のコントロール
kyrt @takekazuomi 31
Caching
kyrt @takekazuomi 322014/7/26
何故 Cache を使うのか
•レイテンシー対策に Cache は有効•HDD 時代アクセスタイムの対策は意味がない•シーケンシャルリード、ライトは速くない•先行読み出し• I/O スケジューリングは逆効果
•ストレージの負荷軽減•変更が少ないデータの読込先として利用
kyrt @takekazuomi 33
Caching : CDP 本から
•Caching Guidance• Cache データの不整合の扱い方
•Cache-Aside Pattern• cache system が、リードスルー方式、ライトスルー/ライトバック方式をサポートしてない場合にアプリケーションで実装するパターンの説明
kyrt @takekazuomi 34
・・・
•更新が頻繁なものは、あまりキャッシュに適さない等。普通の話なので SKIP•リードスルー、ライトスルー/ライトバックをサポートした cache がメジャーではない•機能のリッチさより、低レイテンシーが重要•不一致を防ぎ切ることは難しい
•まず、ローカル Cache で足りるかを検討する。共有Cache はその次ぎ
kyrt @takekazuomi 35
Data Partitioning
kyrt @takekazuomi 362014/7/26
パーテーション分割する理由
CDP 本より5つ•スケーラビリティの改善•パフォーマンスの改善•可用性の改善•セキュリティの改善•運用の柔軟性
kyrt @takekazuomi 372014/7/26
スケーラビリティの改善 -1-
CDP 本•スケールアップでは、物理ハードウェアの限界に達する•データを分割して別々のサーバーにホストすることで、ほぼ無限にスケールアウトできる
kyrt @takekazuomi 38
スケーラビリティの改善 -2-
In My Opinion
•必要なスケーラビリティの目途を立てる•フェルミ推定
•利用するプラットフォームの性能を知る•日頃から測定する癖を付ける•マイクロベンチマークはくそと思わない
kyrt @takekazuomi 39
スケーラビリティの改善 -3-
In My Opinion
•物理ハードウェアの限界を越える条件を立てる•物理ハードウェア= single partition
•最初から分割を前提にするべきか•分割前提だと検討事項が増える=時間がかかる•分割なしー>分割ありで、作り直すコストを検討
kyrt @takekazuomi 40
パフォーマンスの改善 -1-
CDP 本•パーテーションへのデータアクセスは、最適な分割では効率化できる•複数のパーテーションに対する操作は並列に実行できる•データの保存されているパーテーションをアプリケーションの近くに配置することでネットワーク遅延を最小にできる
kyrt @takekazuomi 41
パフォーマンスの改善 -2-
In My Opinion
• 最適な分割であっても、分割にはオーバーヘッドがある• 最適な分割とは何か
• 複数のパーテーションのパフーマンスメリット享受には操作並列が必須• Cloud Application では自然と並列操作になるが、 Batch系は要注意
• アプリケーションとデータのパーテーションの位置関係を最適化するには、どちらかのmobility が必要• パーテーションの移動。 Blob はあるけど、 Table は無い• Global に配置されるようなアプリケーション固有の問題(今のところ)
kyrt @takekazuomi 42
パフォーマンスの改善 -3-
In My Opinion
•パフォーマンス改善の話は、スケーラビリティと裏表の関係にある•パーテーション間の依存性が少なければ比例定数は1。多くなると 1未満になる• 依存性はパーテーション間の通信と言い換えても良い• Azure Table ではパーテーション間の通信が発生するのは
「 partition server がどの partition を担当するかが変更される時に、 paxos cluster で合意を取る時だけ」
kyrt @takekazuomi 43
可用性の改善 -1-
CDP 本•データを複数のサーバーに分けることで単一障害点を作らない•パーテーション停止時の影響は限定的•パーテーション複製で停止の影響をさらに減らすことが可能
kyrt @takekazuomi 44
可用性の改善 -2-
In My Opinion•パーテーション分割を持って、単一障害点( SPOF) の排除といえるかどうかは、データの配置次第•パーテーション複製でパーテーション内の整合性を保証するだけで良いシナリオでは、複製するデータ量を削減でき分割は有効
kyrt @takekazuomi 45
パーテーション分割の設計3つの分割方針
kyrt @takekazuomi 462014/7/26
3つの分割方針
CDP 本
•水平分割 (シャーディング)•垂直分割•機能分割
kyrt @takekazuomi 47
水平分割 (シャーディング)
kyrt @takekazuomi 48
垂直分割
kyrt @takekazuomi 49
機能分割
kyrt @takekazuomi 50
分割方式の選択
In My Opinion•シャーディングが一番面倒なシナリオが多い•垂直分割は、機能分割は、分割シナリオとしては問題点が少ない•複数の分割をまたぐようなトランザクションは効率が悪く、サポートされていない場合もある
kyrt @takekazuomi 51
パーテーション設計
CDP 本3 つの視点•スケーラビリティ•クエリーパフォーマンス•可用性
kyrt @takekazuomi 52
kyrt @takekazuomi 53
スケーラビリティ -1-
CDP 本•アプリケーションを分析。多くの場合、少数の主要なエンティティがリソースの大半を消費•スケーラビリティターゲットの設定•水平分割では shard key の選定がデータ配置が決まる•ストレージの要件(容量、処理能力、ネットワーク帯域幅等)を確認•稼働後は分散具合の確認
kyrt @takekazuomi 54
スケーラビリティ -2-
In My Opinion
•少数の主要なエンティティがリソースの大半を消費していたら、そこは sharding を検討する•水平分割では shard key の選定が最も重要•レンジ、ハッシュを検討する
•分散結果の確認•アプリケーション稼働後は shard key の分布を確認
クエリーパフォーマンス -1-
CDP 本•小さなデータセットを使うことやクエリの並列実行で改善•パーテーションがデータセット全体の小さな部分の場合、データ量削減のメリットが得られる
kyrt @takekazuomi 55
クエリーパフォーマンス -2-
In My Opinion•パーテーションのデータセットが小さい方が、クエリーには有利•少ない Extent で済むので、 Cache も当たるし、オ
ンメモリで処理が済む場合が増える•パーテーションを跨ぐようなクエリは要注意• Azure Tableだとパーテーション毎に別クエリーを
同時に投げた方が速いkyrt @takekazuomi 56
問題点 -1-
CDP
•パーテーション跨ぎの処理は遅い• パラレルにクエリー実行する。依存関係のあるクエリーは同時には実行できないので注意
•静的なデータは、パーテーション内に複製することを検討•分割した結果、パーテーションを跨いだ更新処理が整合性に与える影響を検討する• 強い整合性より結果整合性が使われることが多い
kyrt @takekazuomi 57
問題点 -2-
CDP•複数パーテーションにアクセスするトランザクションはなるべく避ける•補正トランザクションを検討する
kyrt @takekazuomi 58
問題点 -3-
In My Opinion
•複数パーテーションを含んだトランザクションは避ける•分散トランザクションはコストが高い
•上記が必要な場合、結果整合性を使う•補正トランザクションを用意する
kyrt @takekazuomi 59
Data Consistencyデータ整合性
kyrt @takekazuomi 602014/7/26
2 つの整合性
CDP 本
•強い整合性 ( strong consistency )•結果整合性 ( eventual consistency )
kyrt @takekazuomi 612014/7/26
強い整合性
•すべての変更は atomic•トランザクション実行中のデータは不可視•強い整合性モデルの目標は、アプリケーションが整合性の無いデータに触れる機会を最小限にすること•強い整合性モデルはコストが高い=ノード間の通信が多い
kyrt @takekazuomi 62
結果整合性
•データの整合性において比較的、実用性の高いアプローチ•一時的に整合性が取れていないように見える期間があるが、最終的には整合性が取れた状態になる( IMO)
kyrt @takekazuomi 63
整合性In My Opinion
• strong consistency を実装するには、ロックで保護したり、Rollback処理をしたりする必要がある• クラウドのシナリオではコストが高い=ノード間の通信
• リソースによって、 Rollback の定義、動作が違う場合がある• 補正トランザクションはアプリケーション要件に依存する• パーテーション内は、 strong consistency 、パーテーション間は、
eventual consistency
• eventual consistencyでは、補正トランザクションを用意
kyrt @takekazuomi 64
補正トランザクションCompensating Transaction Pattern
kyrt @takekazuomi 652014/7/26
役割と課題
•結果整合性モデルで、失敗した場合の回復モデルの提供•手順すべてを戻す必要がある•単純に書き戻すようなロールバックは例外的•操作が他のサービスを呼び出している場合もある
kyrt @takekazuomi 662014/7/26
解決策 -1-
•一般的なアプローチはワークフローを使うことです。•元の手順をキャプチャーして、取り消しに関する情報を記録し、補正トランザクションでは、ワークフローを使って手順を巻き戻します•補正トランザクションでは、厳密に逆順で作業を戻す必要はありません•補正トランザクションが失敗する場合もあることを考慮し、補正トランザクション自身も idempotent であることが望ましい
kyrt @takekazuomi 67
解決策 -2-
In My Opinion
•ワークフローと元の手順をキャプチャーする話•トランザクションの識別子を時系列で生成する•トランザクションログと似てるが、複雑すぎて汎用的な
実装は困難•補正トランザクションの対象となるような処理を識別す
る方法が必要
kyrt @takekazuomi 68
解決策 -3-
In My Opinion
• 高いレベルにおいては、失敗した場合に走る別の処理(トランザクション)と考えた方が良い• 走った結果はもとに戻る( Rollback する)わけではなく、整合性が取れた別
の状態に遷移する
• 低レベル(ビジネスロジックが関与しない)では、本来なるべき状態に持っていく• 処理が idempotent ならば再度実行して完了させる• 規定回数再試行しても失敗するならば、不整合を通知してデータをロックす
るなどの処理をするkyrt @takekazuomi 69
Special Thanks
•この資料のフォントは、 Source Han Sans を使っています• https://github.com/adobe-fonts/source-han-sans/
kyrt @takekazuomi 70
kyrt @takekazuomi 71
終2014/7/26