Your SlideShare is downloading. ×
  • Like
Windows Azure Storage:Best Practices and Internals
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Windows Azure Storage:Best Practices and Internals

  • 7,049 views
Published

http://kyrt.in/ …

http://kyrt.in/

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,049
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
17
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Windows Azure Storage: Best Practices and Internals 2013/11/4 R.1.0 kyrt Takekazu Omi takekazu.omi@kyrt.in @takekazuomi
  • 2. 自己紹介 近江 武一 • Windows Azure (特にTable)の構築支援 • アーキテクチャ設計、検証 twitter: @takekazuomi github: https://github.com/takekazuomi http://kyrt.in 2013/11/4 kyrt @takekazuomi 2
  • 3. Agenda • Introduction to Storage • Internals • Coding with Azure Table Storage • Azure Table and SQL Database • Appendix 2013/11/4 kyrt @takekazuomi 3
  • 4. Introduction to Storage Windows Azure Storageのご紹介 2013/11/4 kyrt @takekazuomi 4
  • 5. Windows Azure Storage • Cloud Storage – Anywhere and anytime access • Blob, Tables and Queue • Highly Durable, Available and Massively Scalable • 容易にinternet scaleのアプリケーションが構築可能 • 8.5 trillion stored objects • 900K request/sec on average (2.3+ trillion per month) • 従量課金 • 簡単でOPENなREST APIで公開 • 複数のクライアントライブラリのサポート .NET, Java, Node.js, Python, PHP, Ruby 2013/11/4 kyrt @takekazuomi 5
  • 6. Abstractions - Blob, Table, Queue Storageは3種類ある Table Blob REST file system • Block/Page • Data 共有- image, video … • Big Data - raw data/logs … • Backup – SQLDatabase, file backup • Disks – mount VHDs 2013/11/4 structure data • • • • key/value schema less scale partationed sorted set kyrt @takekazuomi Queue Reliable messaging system • component/role間結合 • 非同期タスクスケジュ ラーの実装 • process/work flowsの構 築 6
  • 7. Azure Storage 基盤 • 3つは、共通のAzure Storage基盤の上に構築 • Azure内でも諸々の用途に利用 Diagnostics Table CDN CloudDrive Blob OS/Data Disk Media Services Queue Azure Storage Clusters 2013/11/4 kyrt @takekazuomi 7
  • 8. Internals 2013/11/4 kyrt @takekazuomi 8
  • 9. Design Goals • 強い一貫性の元での高い可用性の実現(Highly Available with Strong Consistency) • 障害や分断に直面してもデータアクセスを提供 • 永続性(Durability) • データの複数の複製の保持、(regions を跨いた) • スケーラビリティ(Scalability) • zettabytes へのスケール • 世界中からアクセスできるglobal namespaceの提供 • meet peak traffic での、automatically scale out と load balance Additional details can be found in the SOSP paper: • “Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency”, ACM Symposium on Operating System Principals (SOSP), Oct. 2011 2013/11/4 kyrt @takekazuomi 9
  • 10. Windows Azure Storage Concepts Container Blobs https://<account>.blob.core.windows.net/<container> Account Table Entities https://<account>.table.core.windows.net/<table> Queue Messages https://<account>.queue.core.windows.net/<queue> 2013/11/4 kyrt @takekazuomi 10
  • 11. Storage Account単位のパフォーマンスター ゲット • Blob, Table ,Queueのpartition • Blobは、URL毎、Tableは、 partition key、Queueはqueue毎で別のpartition • partitionのパフォーマンスターゲット • 2,000 tran/s(queue/table) • 480Mbps/s (blob) • アカウント全体 • 20,000 tran/s(table,queue)※ • 受信 – 10GBps • 送信 – 15GBps 参照: http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windowsazure-s-flat-network-storage-and-2012-scalability-targets.aspx 2013/11/4 kyrt @takekazuomi 11
  • 12. partition ? • • • • • Azure Storageは分散ストレージ データはPartitionに分割して処理される Partitionへの分割はコードでコントロールできる 実際にpartitionがどのように分散されるかは負荷で変わる Partition=物理マシン1台ではない。パーテションの数を増やしても 性能务化しない(Consistent hashingのvirtual nodeの考えと似て る) • Partitionを跨いだ処理は一貫性が保証されない(分散トランザク ションはサポートしてない、読み取り一貫性も無い) • 内部的にIDC内で3重化、GEO-REPLICATIONで複製を選択すると6 重に保存される 2013/11/4 kyrt @takekazuomi 12
  • 13. Windows Azure Storageの アーキテクチャーコンポーネント DNS参照 blob, table, queueへ のアクセス ロケーション サービス アカウント管理 VIP DN S front end VIP front end partition layer s partition layer s stamp間リプリケーション stream layer stream layer stamp内リプリケーション stamp内リプリケーション storage stamp 2013/11/4 storage stamp kyrt @takekazuomi 13
  • 14. 3つのレイヤ - Architecture Layers inside Stamps • stream layer • このレイヤでデータをディスクに永続化。DFSのようなもの。stream と呼ば れるファイルを使い。保存方法とリプリケーションを実装する。streamは、 extentのordered list • このレイヤは、Blob, Tableなどの構造やセマンティックに依存しない。 • partition layer • 高レベルのデータ構造(blob, table, queue)を実装 • オブジェクトに対するトランザクションの順序付、一貫性の確保を実装 • オブジェクトデータのキャッシュ • front end • リクエストのpartition server へ転送 • serverと、 partitionの割り振りを管理するpartition mapを保持 2013/11/4 kyrt @takekazuomi 14
  • 15. stream layer • stream へのWriteは、Appendのみ • Open/Close/Delete/Rename/Read/Apped/Concat stream //bar pointer of extent E1 B1 1 B1 2 ・ ・ ・ extent E1 - sealed 2013/11/4 B1 x pointer of extent E2 B2 1 B2 2 ・ ・ ・ extent E2 - sealed B2 x pointer of extent E3 B3 1 B3 2 ・ ・ ・ B3 x extent E1 - sealed kyrt @takekazuomi pointer of extent E4 B4 1 B4 2 B4 3 extent E1 - unsealed 15
  • 16. sealed extentの最適化 • シールされたextentをreplication -> erasure codingで最適化 • リード・ソロモン符号を使って最適化 • 単純に3重にリプリケーションした場合3倍のコストだが1.3-1.5倍の コストに低減できる この辺りは日々改善 • Local Reconstruction Codes (LRCs) • LRCは3つの障害があっても100%の復元でき、3つのレプリカや 6+3リードソロモンより耐久性に優れている。 • LCRはリードソロモンより14%データオーバーヘッドが小さく、少な いデータフラグメントの読み込みで復旧することができる 2013/11/4 kyrt @takekazuomi 16
  • 17. partition layer architecture watch lease read front end partition map table update partition manager update lease assign partition partition server 1 paxos lock service partition server 1 partition server 1 partition layer stream layer 2013/11/4 kyrt @takekazuomi 17
  • 18. partition layer • Object Table • partition layerの主な仕事はOTの管理と運用 • OT内は、Range Partition( low-keyからhigh-keyまで)に分かれてい て、 Range Partitionは スタンプ内のパーティション サーバー 分散し ます • Range Partitionの範囲は負荷によって変動 • Range Partitionとpartition serverの割り振りは、 Partition Manager (クラスタ)が行い。調停にはPaxosロック サービス が使われます 2013/11/4 kyrt @takekazuomi 18
  • 19. range partition の処理 write read memory table row page cache bloom filter partition layer commit log stream meta data stream row data stream blob data stream stream layer 2013/11/4 kyrt @takekazuomi 19
  • 20. Dynamic Load Balancing – stream layer • 複数レプリカからのRead ロードバラン シング • レイテンシー/ロードをモニタリング してダイナミックにレプリカを選択 します。95% レイテンシーで追加の レプリカからのパラレル読み込みが 開始されます。 front end P • write load balancing • レイテンシー/ロードをモニタリング してレプリカセットをsealし、別の nodeの新しいextentを割り当てます • capacity load balancing • nodeが十分なDiskを持つように、レ プリカのデータの遅延移動が行われ ます。 partition layer M P P P stream layer P P
  • 21. Architecture Summary • Durability: 全てのデータは3つのレプリカに保存される • Consistency: 全てのコミットは3つのレプリカにわたって成功 したときに完了する • Availability: 3つのレプリカのどからでも読むことができる。 もし、書込み時になにか問題があった場合も新しいextentに追 記することができる • Performance/Scale: Retryの原因となるレイテンシーの95%は、 Auto scale out とload balance によるもの。(based on load/capacity) 2013/11/4 kyrt @takekazuomi 21
  • 22. Best Practices 2013/11/4 kyrt @takekazuomi 22
  • 23. Best Practices- 共通(1) • 1400byte未満の小さいメッセージでは Nagle Algorithm を無効 にする • ServicePointManager.UseNagleAlgorithm = false; • Expect 100-Continueを無効にする • ServicePointManager.Expect100Continue = false; • default connection limitを増やす • ServicePointManager.DefaultConnectionLimit = 100; (Or More) • Storage accountと、computing instance/userを近くに置く • computing instanceとstorage accountは同一データセンター内 2013/11/4 kyrt @takekazuomi 23
  • 24. Best Practices- 共通(2) • Accountのスケーラビリティターゲットを理解する • 必要なら複数のstorage accountを使う • partition分割を意識する • Cacheを上手く使う • Cacheミスのときだけstorageにfall backする • account/ partitionの限界を越えられる • 複数partitionに負荷を分散することでスパイクを排除する • HTTPSを使う 2013/11/4 kyrt @takekazuomi 24
  • 25. Best Practices- 共通(3) • 送受信を最適化する • Blob:range read, metadata, head request • Table:Upsert、Merge、Projection、Top • Queues:Update Message、Batch Size • アプリケーションレイヤーではparallelを使う • 無制限なparallelはレイテンシーの务化、スロットリングを引き起こす • storage serviceのLoggingと、Metricsを有効にする • API経由あるいは、Portalで有効にできます • clientのdebugやperformance問題の解決に役立ちます • 指定したretention intervalで自動的に削除されます 2013/11/4 kyrt @takekazuomi 25
  • 26. Blob Best Practice • read sizeと、write sizeを合わせる • 大きなblockのblobの小さなレンジを読むのは避ける • CloudBlockBlob.StreamMinimumReadSizeInBytes/ StreamWriteSizeInBytes • block blobは、blockのリストとして管理されるので • 複数のファイルをアップロードする良い方法は? • 同時に複数のファイルをアップしましょう • blobをアップロードするもっと速い方法は? • parallel block upload を使って下さい。 • single blob = one partition • 単一blobへのアクセスはpartition targetに制限される • 複数のblobへのアクセスはスケールする 2013/11/4 kyrt @takekazuomi 26
  • 27. Table Best Practice • hotspotを避けるようにPartitionKey, RowKey を選択する • Table Scanはコストが高い – レイテンシーが重要なシナリオでは避け る • Batchを使う:同一PartitionKeyでは複数のEntityを同時に更新 できる • Schema-less: 複数のTypeを同一のTableに入れる • Indexは1つだけ( PartitionKey, RowKey ):複数のIndexが必 要な場合は複合キーを検討する • Entity Locality:ソート順の近い場所に必要なものを置く • 関連するEntityを近い場所に置くことでIOが軽減されてPerformanceが 向上する 2013/11/4 kyrt @takekazuomi 27
  • 28. Queue Best Practice • messageの処理はidempotentに • もしwokerがmessageを削除出来ずに落ちた場合、messageは再度visibleに なる • Update Messageの利点 • visibility timeを延長やステートを保存できる • Message Count • queueの溜り具合を現す、 worker の scale の目処になる • Dequeue Count • poison messages の発見、invisibility time の妥当性確認に使える • 大きなメッセージはBlobs に • 大きなバッチ処理時等に throughput が向上する(大きなものはQueueに積ま ない) • 複数 Queuesの利用 • single queue = partition 、partition targetに制限される 2013/11/4 kyrt @takekazuomi 28
  • 29. Designing Azure Table Storage 2013/11/4 kyrt @takekazuomi 29
  • 30. Characteristics of Azure Table Storage 大きな特徴 1. 2. 3. 4. 5. 6. Schema less Partition Range Query Strong Consistency Hi Scalability Low cost RDB(SQL)に比べて5,6は優位、他のK/VSに比べると、3,4は特徴 的。 2013/11/4 kyrt @takekazuomi 30
  • 31. 仕様:Azure Table (1) • Table Names • 名前は3-63文字まで、case-insensitive • Property • Property 名は、case-sensitive で、最大 255 文字まで. Property 名は、 C# identifiers と XML specification 準拠(注:dashは使えない) • Propertyの数は、最大255個(system property 3個を含む) • データサイズは全 property の合計が最大で1MBまで • PartitionKey と RowKeyの Propertyで使えない文字、’/’, ’’, ’#’, ’? ’, U+0000 to U+001F, U+007F to U+009F • PartitionKeyとRowKeyは、最大1KBまで http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx 2013/11/4 kyrt @takekazuomi 31
  • 32. 仕様:Azure Table (2) - Property Types WCF Data Services type Common Language Runtime type Details Edm.Binary byte[] An array of bytes up to 64 KB in size. Edm.Boolean bool A Boolean value. Edm.DateTime DateTim A 64-bit value expressed as Coordinated Universal Time (UTC). The supported DateTime range begins from 12:00 midnight, January 1, 1601 A.D. (C.E.), UTC. The range ends at December 31, 9999. Edm.Double double A 64-bit floating point value. Edm.Guid Guid A 128-bit globally unique identifier. Edm.Int32 Int32 or int A 32-bit integer. Edm.Int64 Int64 or long A 64-bit integer. Edm.String String A UTF-16-encoded value. String values may be up to 64 KB in size. 2013/11/4 kyrt @takekazuomi 32
  • 33. Data Modeling Considerations for Azure Table Application • flexible schema • key 設計 • partition 設計 • Data Modeling Decisions • Embedding • Referencing • Atomicity • Operational Considerations • Data Lifecycle Management • Large Number of Collections 2013/11/4 kyrt @takekazuomi 33
  • 34. Entityの設計 • データ・モデルを考える際に • Partitionにどのようにデータを配置するかでトランザクションが使え るかが決まる • EntityのKeyを何にするかでQueryの可否(パフォーマンス)が決まる • Entityを分割する価値 • 正規化のメリットは限られている、同一Entityに入れられる物は入れてしまう • 集計等でPartitionを跨いた処理が必要 • システムの主たる目的が、OLTPかOLAPかの性格付けは初期段階でする。OLTP なら、Azure Tableは向いているがOLAP的に使うのはAzure Tableだけでは無理 でHadoop等の併用を検討する • アドホックな集計でなくある程度安定したものなら専用のINDEXデータをトラン ザクション時に生成する まずは、Partitionを考えてみよう 2013/11/4 kyrt @takekazuomi 34
  • 35. pattern of Table and Partition usage • Table分割の2つのPattern • Table : Class = 1:1 • Table : Class = 1:N • Partition は、Table+ PartitionKeyで決まる • Table : Class = 1:1では、 同一 Classしか同じPartitionに入れられない。 • Table : Class = 1:N では、複数のClassを同一 Partition に入れられる • その他(Table分けると便利なこと) • Table単位で削除できる(現在一括削除は、Storage Account単位と、 これだけ) 2013/11/4 kyrt @takekazuomi 35
  • 36. Table : Class = 1:1 • Single Class, Single Table mapping • 別Classのデータは同一 Partitionに入らない 2013/11/4 Person Inbox Outbox Friend kyrt @takekazuomi 36
  • 37. Table:Class = 1:N • データの粒度 を考えて Partition を分割 • 読込アクセス(Read)とトラ ンザクション(Write)に注目 Table Data インデックス Log kyrt @takekazuomi オブジェクトのデータ Index 2013/11/4 内容 ストレージの変更履歴ログ 37
  • 38. keyの設計 • Azure TableではKeyの設計が非常に重要 • PartitionKeyの選択 • 同一Partition内のものはEGTでAtomicに処理出来る • 複数PartitionのデータをAtomicに処理するような分散トランザクショ ンの仕組みは無い • Partitionには同時アクセス数の上限がある • 複数のEntiryの場合 • 基本的な考えは、Single RootのTreeになるようにする • 単一Entity依存関係無しの場合 2013/11/4 kyrt @takekazuomi 38
  • 39. Keyの採番 • 採番(=連番と考えない) • Uniq性 • Uniqであれば良いなら、GUIDなどを利用。クライアントの演算だけで採番できるの で非常に高速に採番可能です • Uniq性 + 時系列での増加(減少) • 時間を元にした値+乱数(あるいはGUID)を利用します。時間はTickを元にすると Longで表現することができます。またTickのリバースキー(例:Int64.MaxValue-Tick 等)を使うと逆順にもできます。乱数が必要なのは時間だけだと衝突する可能性が低 くないからです。採番速度は衝突の頻度次第です。乱数の代わりにGUIDを使えば上 記と同等の速度で採番可能です • Uniq性 + 連続の番号 • 連番を生成するのはAzure Tableだけだと楽観的ロックを使わざるえません。読んで 書かないといけないので、成功した場合でも100ms以上の時間が必要です。非常に遅 いので、使える場面が限定されます。 どの方法も重複した場合のリトライロジックを入れた方が無難 2013/11/4 kyrt @takekazuomi 39
  • 40. その他 • Embedded • one to one, one to manyのパターンはシリアライズしてプロパティに 埋め込む策がある • 正規化を崩すが読み込みPerformanceは良い。更新時を検討する 2013/11/4 kyrt @takekazuomi 40
  • 41. Windows Azure Storage Client Library 2.1 まず最初に • Introducing Storage Client Library 2.1 RC for .NET and Windows Phone 8 • http://blogs.msdn.com/b/windowsazurestorage/archive/2013/07/12 /introducing-storage-client-library-2-1-rc-for-net-and-windowsphone-8.aspx • Announcing Storage Client Library 2.1 RTM & CTP for Windows Phone • http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07 /announcing-storage-client-library-2-1-rtm.aspx 2013/11/4 kyrt @takekazuomi 41
  • 42. LastLogonDate TableEntity • Entityは、TableEntity から派生 して作成 • TableEntity Class は、3つのシ ステムプロパティ、ETag、シリ アライザ、デシリアライザが実 装 • https://github.com/WindowsAzure/azure-sdk-fornet/blob/master/microsoft-azureapi/Services/Storage/Lib/Common/Table/TableEntity.cs#L3 1 • ReadEntity/WriteEntityの overrideでプロパティへの保存 形式を変更可能 • ITableEntity を実装することで 自前実装可 2013/11/4 public class Person : TableEntity { public Person() { PartitionKey = "Customer"; RowKey = Guid.NewGuid().ToString(); } public string FirstName { get; set; } public string LastName { get; set; } public DateTime? LastLoginDate { get; set; } } kyrt @takekazuomi 42
  • 43. Write Operation • Entityを用意して var person = new Person() TableIOperation Class の { static method を呼んで操作の FirstName = "Harp", オブジェクトを作成して、 LastName = "Walter", LastLoginDate = DateTime.UtcNow.Date.AddDays(-10) Table Client の Executeを呼ぶ }; のが基本 • Batchの場合は、 var insertOperation = TableOperation.Insert(person); TableBatchOperation に table.Execute(insertOperation); TableIOperation を入れて Executeで実行 • TableIOperationでは、Entity として、ITableEntity を受け 入れる 2013/11/4 kyrt @takekazuomi 43
  • 44. Write Option Entityの更新系の操作は6種類 • Insert • • POST http://msdn.microsoft.com/en-us/library/windowsazure/dd179433.aspx • Update • • PUT If-Match有り http://msdn.microsoft.com/en-us/library/windowsazure/dd179427.aspx • Delete • • DELETE http://msdn.microsoft.com/en-us/library/windowsazure/dd135727.aspx • Merge • • MERGE If-Match有り http://msdn.microsoft.com/en-us/library/windowsazure/dd179392.aspx • Insert or Merge • • MERGE If-Match無し http://msdn.microsoft.com/en-us/library/windowsazure/hh452241.aspx • Insert or Replace • • 2013/11/4 PUT If-Match無し http://msdn.microsoft.com/en-us/library/windowsazure/hh452242.aspx kyrt @takekazuomi 44
  • 45. Read Operation var query = from ent in currentTable.CreateQuery<CustomerEntity>() where ent.PartitionKey == “users” && ent.RowKey = “joe” select ent; • LINQ式で書ける • 実は、1.xでは出来たけど、2.0で無くなって、2.1でLINQ復活 2013/11/4 kyrt @takekazuomi 45
  • 46. Query のコスト Queryのパターン 効率 1 PartitionKey == “SciFi” and RowKey == “Star Wars” Single entity lookup 、これは最も効率が良い 2 PartitionKey == “SciFi” and “Sphere” ≤ RowKey ≤ “Star Wars” single partition 内のエンティティScan レンジ内のエンティティ数に依存 3 “Action” ≤ PartitionKey ≤ “Thriller” 複数パーテション内のエンティティScan それぞれのパーテション内のエンティティ数に依存 4 PartitionKey == “Action” || PartitionKey == “Thriller” 2つのパーテションの中だけをScanするように最適化されて いない。Tableの全てをScanする。 この場合は、2つのQueryに分けて実行することを推薦する 5 “Cars” ≤ RowKey ≤ “Star Wars” PartitionKey が指定されていないので、Table内の全てのエン ティティをScanする 6 (PartitionKey == "..." && RowKey == "...") || (PartitionKey == "..." && RowKey == "...") この場合、1のようにならずに全てのpartition がScanされる。 つまり4と同じ 2013/11/4 kyrt @takekazuomi 46
  • 47. Query Options 3つしか無い • $top • 取得件数、1000件以下に制限 • $filter • 演算子で使えるのは、eq, gt, ge, lt, le, ne と and, not, or • $select • 取得するプロパティを指定 2013/11/4 kyrt @takekazuomi 47
  • 48. Retry Azure Storageではホットスポットが発生して動的負荷分散が動くと操作がエラー になる場合がある(これは規定の動作) そのような場合に備えて、アプリケーション側ではリトライロジックを用意が必 要。 デフォルトは、ExponentialRetry、3つのリトライ実装が用意。 • Linear • 固定の backoff periodの待ち時間で最大リトライ数までリトライする • Exponential • backoff period を、Math.Pow(2, retryCount) * backoff period +/- 20% の待ち時間で最大リ トライ数までリトライする • No Retry • リトライしない 参考:Windows Azure ストレージ サービスの構造とリトライ ポリシーの関係に ついて • http://msdn.microsoft.com/ja-jp/windowsazure/jj647756 2013/11/4 kyrt @takekazuomi 48
  • 49. HTTP Result Code と Retry の関係 • IRetryPolicyを実装してカスタムリトライを実装できる • retryable/Non-retryable なエラーという考えがある • 400番台と501, 505がNon-retryableなエラーコード • それ以外と、client side timeouts(408)は、retryable • http://blogs.msdn.com/b/windowsazurestorage/archive/2011/02/03/overviewof-retry-policies-in-the-windows-azure-storage-client-library.aspx • Azure Storage のエラーコード • http://msdn.microsoft.com/ja-jp/library/dd179357.aspx • 実際のコード • https://github.com/WindowsAzure/azure-sdk-for-net/blob/master/microsoftazureapi/Services/Storage/Lib/Common/RetryPolicies/ExponentialRetry.cs#L71 • Blob側とコードを共有しているので上記説明と少し違う 2013/11/4 kyrt @takekazuomi 49
  • 50. Entity Group Transaction entity group transaction (EGT)の要件 • トランザクション内の全てのエンティティは同一PartitionKey で無ければな らない(Tableも同じ) • entity は、 transaction 内に一回だけ出現できます。そして、1つだけの操作 がそれに対して許されます。 • transaction には、最大 100 のエンティティ、最大4MBのPayloadが許されま す。 • 全てのエンティティは、 Table Service Data Model に沿っていなければいけ ません。 • 上記の条件をクリアすれば、BatchOperationでまとめて処理できま す。 • EGTは、MultiPart MimeのRequestで一括で送られ、良いパフォーマ ンスが出ます(条件が良いと10倍以上早くなります) 2013/11/4 kyrt @takekazuomi 50
  • 51. Appendix 2013/11/4 kyrt @takekazuomi 51
  • 52. Azure Storage Client • .NET Framework • https://github.com/WindowsAzure/azure-sdk-for-net nuget • node.js • https://github.com/WindowsAzure/azure-sdk-for-node npm • java • https://github.com/WindowsAzure/azure-sdk-for-java maven • python • https://github.com/WindowsAzure/azure-sdk-for-python PyPI • ruby • https://github.com/WindowsAzure/azure-sdk-for-ruby gem • php • https://github.com/WindowsAzure/azure-sdk-for-php 2013/11/4 kyrt @takekazuomi PEAR 52
  • 53. 最後に • Internalの部分は、Azure Storage TeamがSOSPで発表した内容に基づい ています。 • 23rd ACM Symposium on Operating Systems Principles (SOSP) "Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency“ 翻訳もあります • Windows Azure ストレージ: 高可用性と強い一貫を両立する クラウド ス トレージ サービス • http://msdn.microsoft.com/ja-jp/windowsazure/dd439432#leaning • Best Practiceと追加の情報はBUILD 2013のセッションから拾っています • BUILD 2013 Windows Azure Storage: What’s Coming, Best Practices, and Internals • http://channel9.msdn.com/Events/Build/2013/3-541 • 全ての情報は2013/11/04時点のものです。 2013/11/4 kyrt @takekazuomi 53