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.

Azure Storage Partition Internals

2,494 views

Published on

.NET Fringe Japan 2016 Azure Storage の Partation の実装

Published in: Technology
  • Be the first to comment

Azure Storage Partition Internals

  1. 1. Azure Storage Partition Internals Takekazu Omi takekazu.omi@kyrt.in 2016/10/1 R.1.0.NET Fringe Japan 2016
  2. 2. 自己紹介 近江 武一 JAZUG Azure Storage 担当(自称) Microsoft MVP for Azure http://www.slideshare.net/takekazuomi kyrt @takekazuomi 2 kyrt.in github.com/takekazuom i white paper 監訳 2016/10/1
  3. 3. Deep ・・・ ・・・ ・・・ Drive ・・・Zzzzzzz kyrt @takekazuomi 32016/10/1
  4. 4. Partitionは、スケーラビリティ対策の基本であり鬼門  Range Partition では、 Partition Keyに悩み  水平分割(Sharding)と聞くと、ムムと思い  Partition リバランス、Split, Merge とか聞くと、リ ソースの心配しか出てこない そんな人々に、Azure StorageのPartitionの話を kyrt @takekazuomi 42016/10/1
  5. 5. 元ネタ Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency 23rd ACM Symposium on Operating Systems Principles で、2011年に公開 翻訳:Windows Azure ストレージ: 高可用性と強い一貫を両 立する クラウド ストレージ サービス kyrt @takekazuomi 52016/10/1
  6. 6. Design Goals  Highly Available with Strong Consistency ⇨ 障害時やネットワークパーテーショニング時にもデータアクセス を提供  Durability ⇨ データセンター内、あるいはDCに跨ったリプリケーション  Scalability ⇨ Exabyte以上へのスケール ⇨ 世界中のデータへのグローバルなネームスペースでのアクセ ス ⇨ トラフィックに応じた自動的なロードバランシング kyrt @takekazuomi 62016/10/1
  7. 7. Azure Storage アーキテクチャ概要 kyrt @takekazuomi 72016/10/1 Storage Stamp LB Front-Ends Partition Layer Stream Layer intra-stamp replication Storage Location Service Storage Stamp LB Front-Ends Partition Layer Stream Layer intra-stamp replication Inter-stamp replication
  8. 8. Storage Stamp Storage Stampは、複数のstorage nodeが配置 された N 個のラックで構成されるクラスター 各ラックがネットワークと電源が冗長化された、 個別の障害ドメイン クラスターは通常、大容量のストレージ ノード 18 台をそれぞれ含むラック 10 ~ 20 個から構 成(2011年時点) kyrt @takekazuomi 82016/10/1
  9. 9. ラックってどんな感じ? kyrt @takekazuomi 92016/10/1 Storageはがどうなっているのかは未公開なのでわからないが・・・・
  10. 10. Open CloudServer OCS V2.1 Specification Open Compute Project ⇨MSのOpen Source 傾倒ぶりはハードに至る ⇨2016/2/9、最新 OSC V2.1を確認! ⇨参照 http://www.opencompute.org/wiki/Server/Spec sAndDesigns kyrt @takekazuomi 102016/10/1
  11. 11. kyrt @takekazuomi 112016/10/1 Open CloudServer OCS V2.1 Specification Blade spec update P10 より http://www.opencompute.org/wiki/Server/SpecsAndDesigns
  12. 12. 汎用ラックに最大4chassisが搭載可 chassis に、12 tray。trayにblade 各2で、最大24 OSC bladeが搭載可 blade 例↓ kyrt @takekazuomi 122016/10/1 Open CloudServer OCS V2.1 Specification Blade spec update P11 より http://www.opencompute.org/wiki/Server/SpecsAndDesigns
  13. 13. Three Layers within a Storage Stamp ストレージスタンプ内の3つのレイヤー 2016/10/1 kyrt @takekazuomi 13
  14. 14. Stream Layer append onlyなdistributed file system 全てのデータは、 Stream Layer に保存 Stream は、extentsのリストで構 extentsは、3重に保存 kyrt @takekazuomi 142016/10/1 Extents SM SM SM Extents Extents Extents Extents Extents Extents Paxos
  15. 15. Partition Layer  高レベルなデータ抽象化 (BLOB、テーブル、キュー)  オブジェクトに対するトランザクションと一貫性の確保  Stream layer へのオブジェクト データの保存  スケーラブルなインデックス(stream layer内の場所を保持)  stamp間のリプリケーション kyrt @takekazuomi 152016/10/1 Partition Server Partition Server Partition Server Partition Server Lock Service PM
  16. 16. Storage Stamp Architecture kyrt @takekazuomi 162016/10/1 Massive Scale Out & Auto Load Balancing Index Layer Distributed Replication Layer FE REST Front End Layer Partition Layer Stream Layer FE REST FE REST FE REST FE REST FE REST FE REST FE REST PS PS PS PS PS PS PS write request read request
  17. 17. read request flow  FE は、リクエスト からのパーテーション情報と Partition layer のpartition mapを参照してPSへ routing。ステートレスなレイヤー  PSは、リクエストからStream layer上のどこにデー タがあるかをindex情報から判断してStream Layer から読む  Stream layer は、データを3重に保存してあり、どこ からでも読める kyrt @takekazuomi 172016/10/1
  18. 18. ざっくり言うと 実データは、Stream layer に保存 Stream layer の何処にObjectがあるかの IndexをPartition layerで保持 FE layerは、Objectを操作するリクエストの受 け口 それぞれのレイヤーがクラスター構成 kyrt @takekazuomi 182016/10/1
  19. 19. Partition Layer 2016/10/1 kyrt @takekazuomi 19
  20. 20. 課題 膨大な数のパーテーションをどう扱うか ⇨stamp内には数千億規模のパーテーションを収 容 ⇨大きく変わるトラフィックパターンにどのように対 応するか kyrt @takekazuomi 202016/10/1
  21. 21. Partition layer architecture kyrt @takekazuomi 212016/10/1 partition map table partition manager partition server 1 partition server 1 partition server 1 paxos lock service front end stream layer partition layer update read update lease watch lease assign partition
  22. 22. 主要コンポーネント PM: Partition Manager ⇨OTのメンテナンス PS: Partition Server ⇨パーテーションの処理 Lock Service ⇨パーテーション分割の調停ロック管理 kyrt @takekazuomi 222016/10/1
  23. 23. 主要 Data model OT: Object Table OTは、ObjectのStream layer上の位置を保持 するindex、メタ情報 数 PB まで拡張可 OTは、トラフィック負荷に基づいて複数の RangePartitionに動的に分割される 分割されたOTには、それぞれ1つのPartition Serverが割当てられる kyrt @takekazuomi 232016/10/1
  24. 24. OT: Object Table の種類 1. Account table: スタンプに割り当てられている各ストレー ジ アカウントのメタデータと構成を格納 2. Blob Table: Blob オブジェクトを格納 3. Entity table: Table entityを格納 4. Message table: Queue のすべてのメッセージを格納 5. Schema table: すべての OT のスキーマを保持 6. Partition map table: すべての OT の現在の RangePartition と、各rangeを処理しているPSをトラック。 FEはこのテーブルを使用して、要求を適切なPSにルー ティングする kyrt @takekazuomi 242016/10/1
  25. 25. PM: Partition Manager  PM は、スタンプ内でOTを N 個のRangePartitionに分割  割り当て情報は partition map tableに格納  複数の RangePartition 間で重複が発生しないように調整  RangePartitionが割り当てられたPS間の負荷分散をする  Stamp内では、PM のインスタンスは複数実行されており、 ロック サービス でリースを取れたPMのインスタンスが partition layer を制御するアクティブな PMとなる kyrt @takekazuomi 252016/10/1
  26. 26. PS: Partition Server  PS は、PMに割り当てられた RangePartition に対する要 求を処理する。PS は、パーティションのすべての永続状 態をストリームに格納し、パーティション状態をメモリ キャッシュに保持  RangePartition を処理するPS は1つだけ。 RangePartitionで、同時実行されるトランザクションの一 貫性とシリアライズが可  単一のPS は、異なる OT の複数のRangePartitionを同 時に処理可能。現在の WASでは、PS により、常に平均 10 個のRangePartitionが処理されている(2011) kyrt @takekazuomi 262016/10/1
  27. 27. account container blob ssss sssss sssss ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ zzzzz zzzzz zzzzzz account container blob lllll lllll lllllll ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ rrrrr rrrrrr rrrrrr 例 kyrt @takekazuomi 272016/10/1 account container blob aaaa aaaa aaaa ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ ・・・・・・ kkkk kkkk kkkk Partition map A-K : PS1 K`-R: PS2 R`-Z:PS3 PS1 A-K : PS1 PS2 K`-R: PS2 PS3 R`-Z:PS3 Blob Index(RangePartition) Partition layer FE Cache A-K : PS1 K`-R: PS2 R`-Z: PS3
  28. 28. OTの永続化 2016/10/1 kyrt @takekazuomi 28
  29. 29. RangePartition – Log Structured Merge-Tree commit log stream meta data stream row data stream blob data stream stream layer partition layer memory table row page cache bloom filter read/querywrite 2016/10/1 kyrt @takekazuomi 29 index cache
  30. 30. RangePartitionのフロー  OTは、各RangePartition 毎にstreamに永続化される  永続化には、 Log Structured Merge-Tree を使う  書き込み ⇨ commit log のstream と、commit logに書けた時点でFEに完 了を返し、 memory tableを更新する。 ⇨ memory tableが溢れた場合、データをblobは、blob stream へ、それ以外は row streamに書く  読み込み ⇨ memory tableを参照し無い場合は、stream layerから読む kyrt @takekazuomi 302016/10/1
  31. 31. RangePartitionの動的な変更 2016/10/1 kyrt @takekazuomi 31
  32. 32. RangePartitionの動的変更  Load Balance トラフィックが集中している PS を特定し、RangePartition を負荷の少な い PS に移動  Split 負荷が集中している RangePartitionを特定して 2 つ以上のより小さな分 離したRangePartitionに分割し、2 つ以上の PS 間で負荷を分散 (再割 り当て)  Merge 連続するキー範囲を持ち、かつコールド状態や低負荷な状態になってい る複数のRangePartitionを結合。結合を使用することで、境界内の RangePartitionの数とスタンプ内の PS 数を調整する kyrt @takekazuomi 322016/10/1
  33. 33. 負荷状況の確認、heartbeats  PMは、各 RangePartitionの負荷を追跡  PM は各 PS とのheartbeat を保持  テレメトリは、 heart beatの応答 A) transactions/second B) average pending transaction count C) throttling rate D) CPU usage E) network usage F) request latency G) RangePartition のデータ サイズ kyrt @takekazuomi 332016/10/1 PM PS1 R1 R3 R4 PS2 R2 R5 R8 PS3 R6 R7 R9 heartbeat
  34. 34. Load Balance  PS に過負荷が発生して いるが、個々の RangePartitionごとの負 荷は正常である場合  PM はその PS から RangePartitionを選択し、 より負荷の少ない PS に 再割り当てする kyrt @takekazuomi 342016/10/1 PM PS1 R1 R3 R4 PS2 R2 R5 R8 PS3 R6 R7 R9 heartbeat R4をPS2へ移動
  35. 35. Load Balance 操作  PM はオフロード コマンドを PS に送信  PSは、RangePartition の現在のチェックポイントを書き込ん だ後にオフロードを実行。  完了後、PS はPMにオフロード完了を通知  PM はRangePartitionを新しい PS に割り当て、Partition map table を更新  新しい PS がRangePartitionを読み込み、トラフィック処理を 開始 kyrt @takekazuomi 352016/10/1
  36. 36. Split kyrt @takekazuomi 362016/10/1 PM PS1 R1 R3 R4 PS2 R2 R5 R8 PS3 R6 R7 R9 heartbeat R4’ R4を分割R4’をPS2へ 指標に対して高すぎる負荷の RangePartition を PM が発見 PM はパーティションの分割を 決定し、split を実行するコマン ドを PS に送信
  37. 37. Split 操作  RangePartitionの分割するのは、負荷が高い場合と、行データ ストリームまたは BLOB データ ストリームのサイズが大きい場合  状況を特定した PM は、該当のRangePartitionを処理する PS に対して負荷ま たはサイズに基づく分割を指示  パーティションの分割位置を示すキー (アカウント名, パーティション名) は PS が 選択  サイズに基づく分割の場合、RangePartitionは、パーティション内のオブジェクト の合計サイズと、パーティションのサイズが約半分になる位置の分割キー値を保 持し、PS はこれらを使用して分割位置を示すキーを選択  負荷に基づく分割の場合、PS は Adaptive Range Profiling ※を使用してキー を選択し分割 kyrt @takekazuomi 372016/10/1 ※ S. Mysore, B. Agrawal, T. Sherwood, N. Shrivastava, and S. Suri, "Profiling over Adaptive Ranges," in Symposium on Code Generation and Optimization, 2006.
  38. 38. RangePartition (B) split (C、D) 1. PM が、PS に対して、B を C と D に分割するよう指示 2. B を所有する PS は、B をチェックポイント。以下のステップ 3 の実行中はトラフィックの処 理を一時的に停止 3. PS は、特別なストリーム操作 “MultiModify” を使用して、B の各ストリーム (メタデータ、コ ミット ログ、データ) を基に、C および D 用の新しいストリームのセットを作成。ストリームは 単なるエクステントへのポインターのリストなので、処理はすぐに完了する。その後、PS は、 C および D の新しいパーティション キー範囲を、それぞれのメタデータ ストリームに追加 する 4. PS は、2 つの新しいパーティション C および D をそれぞれ分離したRangePartition範囲 で扱い、これらに対する要求の処理を開始する 5. PS は、分割の完了を PM に通知。PM は パーティション マップ テーブルとメタデータ情報 を適切に更新した後、分割されたパーティションのうち 1 つを別の PS に移動する kyrt @takekazuomi 382016/10/1
  39. 39. Merge操作 1. PM は、同じ PS によって処理されるよう C と D を移動し、その PS に対して、C と D を結 合するよう指示 2. PS は、C と D をチェックポイント。以下3ステップの実行中はこれらに対するトラフィックを 一時的に停止 3. PS は、”MultiModify” ストリーム コマンドを使用して、E 用の新しいコミット ログおよびデー タ ストリームを作成する。(C とD のストリームのすべてのエクステントを連結) 4. PS は、E 用のメタデータ ストリームを作成します。このメタデータ ストリームには、新しいコ ミット ログおよびデータ ストリームの名前、結合された E のキー範囲、C と D から継承さ れた E のコミット ログにおける各コミット ログ領域の最初と最後を示すポインター (エクステ ント + オフセット)、そして、E のデータ ストリームのデータ インデックスのルートを含む 5. 5. この時点で、E 用の新しいメタデータ ストリームが正常に読み込まれ、PS は、新たに結 合された E というRangePartitionの処理を開始 6. 6. PM は、結合を反映するよう、パーティション マップ テーブルとメタデータ情報を更新す る kyrt @takekazuomi 392016/10/1
  40. 40. RangePartition変更のコスト WASでは、 RangePartitionの変更は、Index 情報の切り替えだけで、実データの移動は発 生しない Stream layer 内では、extent(実データ)の移 動を伴わずにStreamの分割、結合出来る Extentに対して、複数のStreamからリンクで きるのでSplitしてもExtentの移動は必要ない kyrt @takekazuomi 402016/10/1
  41. 41. kyrt @takekazuomi 412016/10/1 Massive Scale Out & Auto Load Balancing Index Layer Distributed Replication Layer Partition Layer Stream Layer PS PS1 PS PS PS2 PS PS PSは、すべてのStreamにアクセス可
  42. 42. Stream Layer Concepts kyrt @takekazuomi 422016/10/1 Extent • リプリケーション単位 • blockのシーケンス • 最大サイズあり( 1GB) • Sealed/unsealed Block • read/writeの最小単位 • Checksum • 最大N byte(4MB) Stream • 階層的なnamespace • extentのordered list • Append/Concatenate pointer of extent E1 B1 1 B1 2 ・・・ B1 x extent E1 - sealed pointer of extent E2 B2 1 B2 2 ・・・ B2 x extent E2 - sealed pointer of extent E3 B3 1 B3 2 ・・・ B3 x extent E1 - sealed pointer of extent E4 B4 1 B4 2 B4 3 extent E1 - unsealed stream //bar/kinmugi.data
  43. 43. おまけ 2016/10/1 kyrt @takekazuomi 43
  44. 44. Range vs. Hash Partition  Partition layerのOTには、ハッシュベースのインデックス作成 キーのハッシュ値ではなく範囲ベースのパーティション分割/イン デックス作成を使用  範囲ベースのパーティション分割の場合、アカウントのオブジェクト がRangePartitionのセットの中にまとめて格納されるため、テナン トの毎にパフォーマンス分離できる(ストレージアカウント単位での パフォーマンスターゲットがあります)  アカウント内のオブジェクトの列挙が効率化される  ハッシュベースの方法ではサーバー間の負荷分散を簡素化でき ますが、オブジェクトのローカリティが失われ、分離と効率的な列 挙を実現できないという欠点がある kyrt @takekazuomi 442016/10/1
  45. 45. Range vs. Hash Partition(2)  RangePartitionが不利になるのは、アクセスが一部のRangeに集 中する場合  例えば、ユーザーが、テーブルのキー範囲の最後にすべてのデー タを書き込もうとする場合 (例: 2011-06-30:12:00:00、2011-06- 30:12:00:02、2011-06:30-12:00:10 のキーを順番に挿入)や、 Blobのファイル名が時系列で変わるような命名規則になっている 場合  この場合、特定の(最後のRangePartition)に、すべての書き込み が送られることになり、WAS のシステムが提供するパーティション 分割と負荷分散を活用できない  この関連の課題は、 ログ系のデータを書くときに発生する kyrt @takekazuomi 452016/10/1
  46. 46. コンピューティングリソースとストレージの分離  Windows Azure では、ユーザーの VM ベースのコンピューティングをス トレージから分離している  ユーザー サービスのコードを実行するノードと、それらにストレージを提 供するノードが切り離され、ネットワーク経由で接続している  メリット ⇨ コンピューティングのコア部分とストレージをそれぞれ個別にスケールアウト して、各データ センターにおけるユーザーの需要に対応できる ⇨ コンピューティングとストレージの間に独立したレイヤーが確保され、マルチ テナント運用にあたり両方のシステムの負荷分散を個別に実行できる  デメリット ⇨ コンピューティングのコア部分とストレージの接続がネットワーク経由なので、 レイテンシが大きい。(帯域はそれなりになりつつあるが) kyrt @takekazuomi 462016/10/1
  47. 47. kyrt @takekazuomi 472016/10/1
  48. 48. kyrt @takekazuomi 482016/10/1 終

×