クラウドデザイン パターンに見る クラウドファーストな アプリケーション設計 Data Management編
•Download as PPTX, PDF•
7 likes•4,338 views
クラウドデザイン パターンに見る クラウドファーストな アプリケーション設計 Data Management編 クラウド温泉4.0＠小樽 - The Return of F# のセッション資料 http://connpass.com/event/7177/
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to クラウドデザイン パターンに見る クラウドファーストな アプリケーション設計 Data Management編
Similar to クラウドデザイン パターンに見る クラウドファーストな アプリケーション設計 Data Management編 (20)
More from Takekazu Omi
More from Takekazu Omi (20)
クラウドデザイン パターンに見る クラウドファーストな アプリケーション設計 Data Management編
- 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
- 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
- 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
- 31. 基本戦略 •Caching •Data Partitioning •Data Consistency のコントロール kyrt @takekazuomi 31
- 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
- 39. スケーラビリティの改善 -2- In My Opinion •必要なスケーラビリティの目途を立てる • フェルミ推定 •利用するプラットフォームの性能を知る • 日頃から測定する癖を付ける • マイクロベンチマークはくそと思わない kyrt @takekazuomi 39
- 40. スケーラビリティの改善 -3- In My Opinion •物理ハードウェアの限界を越える条件を立てる • 物理ハードウェア＝ single partition •最初から分割を前提にするべきか • 分割前提だと検討事項が増える＝時間がかかる • 分割なしー＞分割ありで、作り直すコストを検討 kyrt @takekazuomi 40
- 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
- 45. 可用性の改善 -2- In My Opinion •パーテーション分割を持って、単一障害点 （SPOF)の排除といえるかどうかは、データ の配置次第 •パーテーション複製でパーテーション内の 整合性を保証するだけで良いシナリオでは、 複製するデータ量を削減でき分割は有効 kyrt @takekazuomi 45
- 51. 分割方式の選択 In My Opinion •シャーディングが一番面倒なシナリオが多い •垂直分割は、機能分割は、分割シナリオとして は問題点が少ない •複数の分割をまたぐようなトランザクションは 効率が悪く、サポートされていない場合もある kyrt @takekazuomi 51
- 53. スケーラビリティ -1- CDP本 • アプリケーションを分析。多くの場合、少数の主要なエ ンティティがリソースの大半を消費 • スケーラビリティターゲットの設定 • 水平分割ではshard keyの選定がデータ配置が決まる • ストレージの要件（容量、処理能力、ネットワーク帯域 幅等）を確認 • 稼働後は分散具合の確認 kyrt @takekazuomi 53
- 54. スケーラビリティ -2- In My Opinion •少数の主要なエンティティがリソースの大半を 消費していたら、そこは sharding を検討する •水平分割ではshard keyの選定が最も重要 • レンジ、ハッシュを検討する •分散結果の確認 • アプリケーション稼働後は shard key の分布を確認 kyrt @takekazuomi 54
- 56. クエリーパフォーマンス -2- In My Opinion •パーテーションのデータセットが小さい方が、 クエリーには有利 • 少ないExtentで済むので、Cacheも当たるし、オンメモリ で処理が済む場合が増える •パーテーションを跨ぐようなクエリは要注意 • Azure Tableだとパーテーション毎に別クエリーを同時に 投げた方が速い kyrt @takekazuomi 56
- 57. 問題点 -1- CDP • パーテーション跨ぎの処理は遅い • パラレルにクエリー実行する。依存関係のあるクエリーは同時には 実行できないので注意 • 静的なデータは、パーテーション内に複製することを検 討 • 分割した結果、パーテーションを跨いだ更新処理が整合 性に与える影響を検討する • 強い整合性より結果整合性が使われることが多い kyrt @takekazuomi 57
- 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
- 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
- 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
Editor's Notes
- コモディティ化された多数のハードウェアの上で実行される 多数の Server 多数の Storage Server（永続化レイヤー） こんな構成のイメージ 各ブロックの中は同じコードが複数のサーバーに展開されてる 状態はStorage Server（永続化レイヤー）だけに保存される
- Cloud Applicationでよく使われる機能
- Cache-Aside Pattern Command and Query Responsibility Segregation (CQRS) Pattern Event Sourcing Pattern Index Table Pattern Materialized View Pattern Sharding Pattern Static Content Hosting Pattern Valet Key Pattern Caching Guidance Data Consistency Primer Data Partitioning Guidance Data Replication and Synchronization Guidance
- Open Compute Project は、 facebook が始めた http://www.datacenterknowledge.com/archives/2014/01/27/closer-look-microsofts-cloud-server-hardware/ https://github.com/MSOpenTech/ChassisManager/wiki/copyright-license-header-for-source-files
- 量産品を高密度でラックに詰め込んで、DCに大量に並べてる構成。 これが安いて、美味しいところ
- 20 Rack 36 node / rack (4c x 12b x 2 = 96 blade/rack) Stamp = Cluster 20 rack/stamp 36 node/rack 合わせてみると 60 bladeは、JBOD blade 960 ノード入るはずなのに、900になっている Stamp のDISKは、30PB となっている 30PB / 60 / 20 = 2.5TB
- Front End 、Lock Manager 、Fabric Controller がいるはずなので、60全部じゃないはず。 Stream LayerとPartition Layerは同一ノード、Front Endは別 SOSP Paper - Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency から クラスターは通常、大容量のストレージ ノード 18 台をそれぞれ含むラック 10 ～ 20 個から構成されます。WAS の第 1 世代のストレージ スタンプは、それぞれ生データで 2 PB のストレージ容量を保持しています。次世代では、これを 30 PB にまで増大させる予定です WAS ではストレージ スタンプの容量、トランザクション、帯域幅それぞれにつき、約 70% 前後の使用率を目標としています。また、使用率が 80% を超えないようにしています。 実際、パーティション サーバー (パーティション レイヤーのデーモン プロセス) とストリーム サーバーは、スタンプの各ストレージ ノードに共存しています。 ここの訳がおかしい気がします。要検討。partition servers と、stream servers は、其々のstorage nodeにコロケーションしているらしい。
- storage account は、名前space を切る機能、DNS名が付きます
- 追加、Azure Storage ではスピンドル待ちがない
- 4428 190
- 5017
- した2つはスキップ
- 5060
- 4781
- し
- 500