クラウドデザインパターンに見るクラウドファーストなアプリケーション設計 Data Management編

クラウドデザインパターンに見るクラウドファーストなアプリケーション設計Data Management 編

kyrt / Takekazu Omi

http://kyrt.in

[email protected]

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

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

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 4

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




回答集じゃない

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

•8 つの問題領域•9 つの code sample

kyrt @takekazuomi 5

Design Patterns


名称 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 ってなに？なんでこんな話をしているのか


Cloud Application

対象ドメイン、クラウドアプリケーション

•コモディティ化されたハードウェアを利用•個々のハードウェアには性能上限があり、スケールアウトで対応•予測できないワークロードに対応

kyrt @takekazuomi 9

Infrastructure as Code

•Code で Infrastructure が操作できるPlatform•インスタンスのコストは低い•ランニング•調達

•個々のインスタンスのスケールアップの選択肢には制限

kyrt @takekazuomi 10

構成


Web Front Layer Worker Layer Persistence Layer


Cloud Platform Provider の視点• 同じハードウェアを大量に提供

• 調達コスト• 管理• 運用

• 避けられないハードウェアの多様化• 調達時期による違い（その時点でのベスト）• ユーザー要求の多様化

• 標準インスタンス• メモリ集中型インスタンス• コンピューティング集中型インスタンス• http://azure.microsoft.com/ja-jp/pricing/details/cloud-services/• その他、 GPU 、ストレージの最適化など• http://aws.amazon.com/jp/ec2/instance-types/

http://azure.microsoft.com/ja-jp/pricing/details/cloud-services/


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


データ管理

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


コモディティハードウェアデータ管理の足回り、 Azure Storage のハードウェア例


Persistence Layer

•Data Management （データ管理）の上で最も重要なこと

↓•Persistence Layer （永続化層）の特性



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

http://www.opencompute.org/wiki/Motherboard/SpecsAndDesigns#Specs_and_Designs



6G JBOD blade

http://www.opencompute.org/wiki/Motherboard/SpecsAndDesigns#Specs_and_DesignsOpen CloudServer / JBOD Bladev1.0 Jan 28, 2014 Microsoft P6から





6G JBOD blade

•シンプルなデザイン、最低限のパーツで構成•1U の半分の幅の form factor

•10 x 3.5” HDDs をサポート


Quantum 10 v2


de:code 2014 SV-011 Microsoft Azure インターナルよりhttp://www.microsoftvirtualacademy.com/training-courses/decode-track2

http://www.microsoftvirtualacademy.com/training-courses/decode-track2

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 （概算）


補足

•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

http://blogs.msdn.com/b/windowsazurestorage/archive/2011/11/20/windows-azure-storage-a-highly-available-cloud-storage-service-with-strong-consistency.aspx



Partitioning

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



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


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



一般的なクラウドストレージの特性

•スピンドルが大量にある• I/O が並列処理能力が高い

•ネットワーク接続されたサーバーによるクラスターで実装•レイテンシーが大きい（ SAS HDD や、 PCIe SSDなどに比べて）


言い換えると

•レイテンシーが大きい• Azure Blob 16KB read/write 9ms 程度•HDD 平均待ち時間 2ms (1万 5000rpm)

• I/O 並列可度が高い• Azure Table の Single Partition Write で 24 並列まで比例•HDD だと、スピンドル数＝並列化数


アプリケーション設計


基本戦略

•Caching•Data Partitioning•Data Consistency のコントロール


Caching


何故 Cache を使うのか

•レイテンシー対策に Cache は有効•HDD 時代アクセスタイムの対策は意味がない•シーケンシャルリード、ライトは速くない•先行読み出し• I/O スケジューリングは逆効果

•ストレージの負荷軽減•変更が少ないデータの読込先として利用


Caching ： CDP 本から

•Caching Guidance• Cache データの不整合の扱い方

•Cache-Aside Pattern• cache system が、リードスルー方式、ライトスルー／ライトバック方式をサポートしてない場合にアプリケーションで実装するパターンの説明


・・・

•更新が頻繁なものは、あまりキャッシュに適さない等。普通の話なので SKIP•リードスルー、ライトスルー／ライトバックをサポートした cache がメジャーではない•機能のリッチさより、低レイテンシーが重要•不一致を防ぎ切ることは難しい

•まず、ローカル Cache で足りるかを検討する。共有Cache はその次ぎ


Data Partitioning


パーテーション分割する理由

CDP 本より５つ•スケーラビリティの改善•パフォーマンスの改善•可用性の改善•セキュリティの改善•運用の柔軟性


スケーラビリティの改善 -1-

CDP 本•スケールアップでは、物理ハードウェアの限界に達する•データを分割して別々のサーバーにホストすることで、ほぼ無限にスケールアウトできる



In My Opinion

•必要なスケーラビリティの目途を立てる•フェルミ推定

•利用するプラットフォームの性能を知る•日頃から測定する癖を付ける•マイクロベンチマークはくそと思わない


http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%83%AB%E3%83%9F%E6%8E%A8%E5%AE%9A

http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%83%AB%E3%83%9F%E6%8E%A8%E5%AE%9A


In My Opinion

•物理ハードウェアの限界を越える条件を立てる•物理ハードウェア＝ single partition

•最初から分割を前提にするべきか•分割前提だと検討事項が増える＝時間がかかる•分割なしー＞分割ありで、作り直すコストを検討


パフォーマンスの改善 -1-

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



In My Opinion

• 最適な分割であっても、分割にはオーバーヘッドがある• 最適な分割とは何か

• 複数のパーテーションのパフーマンスメリット享受には操作並列が必須• Cloud Application では自然と並列操作になるが、 Batch系は要注意

• アプリケーションとデータのパーテーションの位置関係を最適化するには、どちらかのmobility が必要• パーテーションの移動。 Blob はあるけど、 Table は無い• Global に配置されるようなアプリケーション固有の問題（今のところ）



In My Opinion

•パフォーマンス改善の話は、スケーラビリティと裏表の関係にある•パーテーション間の依存性が少なければ比例定数は１。多くなると 1未満になる• 依存性はパーテーション間の通信と言い換えても良い• Azure Table ではパーテーション間の通信が発生するのは

「 partition server がどの partition を担当するかが変更される時に、 paxos cluster で合意を取る時だけ」


可用性の改善 -1-

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


可用性の改善 -2-

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


パーテーション分割の設計３つの分割方針


３つの分割方針

CDP 本

•水平分割（シャーディング）•垂直分割•機能分割


水平分割（シャーディング）


垂直分割


機能分割


分割方式の選択

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


パーテーション設計

CDP 本3 つの視点•スケーラビリティ•クエリーパフォーマンス•可用性



スケーラビリティ -1-

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


スケーラビリティ -2-

In My Opinion

•少数の主要なエンティティがリソースの大半を消費していたら、そこは sharding を検討する•水平分割では shard key の選定が最も重要•レンジ、ハッシュを検討する

•分散結果の確認•アプリケーション稼働後は shard key の分布を確認

クエリーパフォーマンス -1-

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


クエリーパフォーマンス -2-

In My Opinion•パーテーションのデータセットが小さい方が、クエリーには有利•少ない Extent で済むので、 Cache も当たるし、オ

ンメモリで処理が済む場合が増える•パーテーションを跨ぐようなクエリは要注意• Azure Tableだとパーテーション毎に別クエリーを

同時に投げた方が速いkyrt @takekazuomi 56

問題点 -1-

CDP

•パーテーション跨ぎの処理は遅い• パラレルにクエリー実行する。依存関係のあるクエリーは同時には実行できないので注意

•静的なデータは、パーテーション内に複製することを検討•分割した結果、パーテーションを跨いだ更新処理が整合性に与える影響を検討する• 強い整合性より結果整合性が使われることが多い


問題点 -2-

CDP•複数パーテーションにアクセスするトランザクションはなるべく避ける•補正トランザクションを検討する


問題点 -3-

In My Opinion

•複数パーテーションを含んだトランザクションは避ける•分散トランザクションはコストが高い

•上記が必要な場合、結果整合性を使う•補正トランザクションを用意する


Data Consistencyデータ整合性


2 つの整合性

CDP 本

•強い整合性 ( strong consistency )•結果整合性 ( eventual consistency )


強い整合性

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


結果整合性

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


整合性In My Opinion

• strong consistency を実装するには、ロックで保護したり、Rollback処理をしたりする必要がある• クラウドのシナリオではコストが高い＝ノード間の通信

• リソースによって、 Rollback の定義、動作が違う場合がある• 補正トランザクションはアプリケーション要件に依存する• パーテーション内は、 strong consistency 、パーテーション間は、

eventual consistency

• eventual consistencyでは、補正トランザクションを用意


補正トランザクションCompensating Transaction Pattern


役割と課題

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


解決策 -1-

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


解決策 -2-

In My Opinion

•ワークフローと元の手順をキャプチャーする話•トランザクションの識別子を時系列で生成する•トランザクションログと似てるが、複雑すぎて汎用的な

実装は困難•補正トランザクションの対象となるような処理を識別す

る方法が必要


解決策 -3-

In My Opinion

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

の状態に遷移する

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

るなどの処理をするkyrt @takekazuomi 69

Special Thanks

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


https://github.com/adobe-fonts/source-han-sans/




終2014/7/26

Software

クラウドデザイン パターンに見るクラウドファーストなアプリケーション設計 Data Management編

クラウドデザインパターンに見るクラウドファーストなアプリケーション設計 Data Management編