Windows Azure Storage:Best Practices and Internals
Upcoming SlideShare
Loading in...5
×
 

Windows Azure Storage:Best Practices and Internals

on

  • 2,317 views

http://kyrt.in/

http://kyrt.in/

Statistics

Views

Total Views
2,317
Views on SlideShare
2,004
Embed Views
313

Actions

Likes
1
Downloads
17
Comments
0

2 Embeds 313

http://tech-haneman.hatenablog.com 292
https://twitter.com 21

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Windows Azure Storage:Best Practices and Internals Windows Azure Storage:Best Practices and Internals Presentation Transcript

  • Windows Azure Storage: Best Practices and Internals 2013/11/4 R.1.0 kyrt Takekazu Omi takekazu.omi@kyrt.in @takekazuomi
  • 自己紹介 近江 武一 • Windows Azure (特にTable)の構築支援 • アーキテクチャ設計、検証 twitter: @takekazuomi github: https://github.com/takekazuomi http://kyrt.in 2013/11/4 kyrt @takekazuomi 2
  • Agenda • Introduction to Storage • Internals • Coding with Azure Table Storage • Azure Table and SQL Database • Appendix 2013/11/4 kyrt @takekazuomi 3
  • Introduction to Storage Windows Azure Storageのご紹介 2013/11/4 kyrt @takekazuomi 4
  • 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
  • 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
  • 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
  • Internals 2013/11/4 kyrt @takekazuomi 8
  • 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
  • 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
  • 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
  • partition ? • • • • • Azure Storageは分散ストレージ データはPartitionに分割して処理される Partitionへの分割はコードでコントロールできる 実際にpartitionがどのように分散されるかは負荷で変わる Partition=物理マシン1台ではない。パーテションの数を増やしても 性能务化しない(Consistent hashingのvirtual nodeの考えと似て る) • Partitionを跨いだ処理は一貫性が保証されない(分散トランザク ションはサポートしてない、読み取り一貫性も無い) • 内部的にIDC内で3重化、GEO-REPLICATIONで複製を選択すると6 重に保存される 2013/11/4 kyrt @takekazuomi 12
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Best Practices 2013/11/4 kyrt @takekazuomi 22
  • 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
  • Best Practices- 共通(2) • Accountのスケーラビリティターゲットを理解する • 必要なら複数のstorage accountを使う • partition分割を意識する • Cacheを上手く使う • Cacheミスのときだけstorageにfall backする • account/ partitionの限界を越えられる • 複数partitionに負荷を分散することでスパイクを排除する • HTTPSを使う 2013/11/4 kyrt @takekazuomi 24
  • 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
  • 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
  • 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
  • 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
  • Designing Azure Table Storage 2013/11/4 kyrt @takekazuomi 29
  • 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
  • 仕様: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
  • 仕様: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
  • 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
  • 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
  • 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
  • Table : Class = 1:1 • Single Class, Single Table mapping • 別Classのデータは同一 Partitionに入らない 2013/11/4 Person Inbox Outbox Friend kyrt @takekazuomi 36
  • Table:Class = 1:N • データの粒度 を考えて Partition を分割 • 読込アクセス(Read)とトラ ンザクション(Write)に注目 Table Data インデックス Log kyrt @takekazuomi オブジェクトのデータ Index 2013/11/4 内容 ストレージの変更履歴ログ 37
  • keyの設計 • Azure TableではKeyの設計が非常に重要 • PartitionKeyの選択 • 同一Partition内のものはEGTでAtomicに処理出来る • 複数PartitionのデータをAtomicに処理するような分散トランザクショ ンの仕組みは無い • Partitionには同時アクセス数の上限がある • 複数のEntiryの場合 • 基本的な考えは、Single RootのTreeになるようにする • 単一Entity依存関係無しの場合 2013/11/4 kyrt @takekazuomi 38
  • Keyの採番 • 採番(=連番と考えない) • Uniq性 • Uniqであれば良いなら、GUIDなどを利用。クライアントの演算だけで採番できるの で非常に高速に採番可能です • Uniq性 + 時系列での増加(減少) • 時間を元にした値+乱数(あるいはGUID)を利用します。時間はTickを元にすると Longで表現することができます。またTickのリバースキー(例:Int64.MaxValue-Tick 等)を使うと逆順にもできます。乱数が必要なのは時間だけだと衝突する可能性が低 くないからです。採番速度は衝突の頻度次第です。乱数の代わりにGUIDを使えば上 記と同等の速度で採番可能です • Uniq性 + 連続の番号 • 連番を生成するのはAzure Tableだけだと楽観的ロックを使わざるえません。読んで 書かないといけないので、成功した場合でも100ms以上の時間が必要です。非常に遅 いので、使える場面が限定されます。 どの方法も重複した場合のリトライロジックを入れた方が無難 2013/11/4 kyrt @takekazuomi 39
  • その他 • Embedded • one to one, one to manyのパターンはシリアライズしてプロパティに 埋め込む策がある • 正規化を崩すが読み込みPerformanceは良い。更新時を検討する 2013/11/4 kyrt @takekazuomi 40
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Query Options 3つしか無い • $top • 取得件数、1000件以下に制限 • $filter • 演算子で使えるのは、eq, gt, ge, lt, le, ne と and, not, or • $select • 取得するプロパティを指定 2013/11/4 kyrt @takekazuomi 47
  • 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
  • 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
  • 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
  • Appendix 2013/11/4 kyrt @takekazuomi 51
  • 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
  • 最後に • 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