Upcoming SlideShare
![[Azure Deep Dive] クラウド デザイン パターン ～優...](http://cdn.slidesharecdn.com/ss_thumbnails/200151004madcdp-151216090016-thumbnail.jpg?cb=1450256520)
クラウドデザイン パターンに見る クラウドファーストな アプリケーション設計 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
- 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
Login to see the comments