Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

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

クラウド温泉4.0@小樽 - The Return of F# のセッション資料
http://connpass.com/event/7177/

  • Login to see the comments

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

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

×