Windows Azure Storage:Best Practices and Internals

Windows Azure Storage:Best Practices and Internals

kyrt Takekazu Omi

[email protected]

@takekazuomi

2013/11/4 R.1.0

自己紹介

近江武一

• Windows Azure （特に Table) の構築支援• アーキテクチャ設計、検証twitter: @takekazuomigithub: https://github.com/takekazuomihttp://kyrt.in

2013/11/4 kyrt @takekazuomi 2

http://kyrt.in/

Agenda

• Introduction to Storage• Internals• Coding with Azure Table Storage• Azure Table and SQL Database• Appendix


Introduction to StorageWindows Azure Storage のご紹介


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, Ruby2013/11/4 kyrt @takekazuomi 5

Abstractions - Blob, Table, Queue

Storage は３種類ある

BlobREST file system• Block/Page• Data 共有 - image, video

…• Big Data - raw data/logs

…• Backup – SQLDatabase,

file backup• Disks – mount VHDs

Tablestructure data

• key/value• schema less• scale• partationed sorted

set

QueueReliable messaging system

• component/role 間結合• 非同期タスクスケジュ

ラーの実装• process/work flows の

構築2013/11/4 kyrt @takekazuomi 6

Azure Storage 基盤

• 3 つは、共通の Azure Storage 基盤の上に構築• Azure 内でも諸々の用途に利用

2013/11/4 kyrt @takekazuomi

Azure Storage Clusters

Table Blob Queue

OS/Data Disk

Media ServicesCloudDriveDiagnostics CDN

7

Internals


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


Windows Azure Storage Concepts

Account

Containerhttps://<account>.blob.core.windows.net/<container>

https://<account>.table.core.windows.net/<table>

https://<account>.queue.core.windows.net/<queue>

Table

Queue Messages

Entities

Blobs


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/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx2013/11/4 kyrt @takekazuomi 11

http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx



partition ？

• Azure Storage は分散ストレージ• データは Partition に分割して処理される• Partition への分割はコードでコントロールできる• 実際に partition がどのように分散されるかは負荷で変わる• Partition ＝物理マシン 1 台ではない。パーテションの数を増やしても

性能劣化しない（ Consistent hashing の virtual node の考えと似てる）

• Partition を跨いだ処理は一貫性が保証されない（分散トランザクションはサポートしてない、読み取り一貫性も無い）

• 内部的に IDC 内で 3 重化、 GEO-REPLICATION で複製を選択すると 6重に保存される


Windows Azure Storage のアーキテクチャーコンポーネン

ト

s

front end

partition layer

stream layer

storage stamp

VIP

s

front end

partition layer

stream layer

storage stamp

VIPDNS

ロケーションサービス

アカウント管理

DNS 参照

blob, table, queue へのアクセス

stamp 間リプリケーション


stamp 内リプリケーション stamp 内リプリケーション

13

３つのレイヤ - 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 を保持


stream layer

• stream への Write は、 Append のみ• Open/Close/Delete/Rename/Read/Apped/Concat

pointer of extent E1

B11

B12

・・・

B1x

extent E1 - sealed


B21

B22

・・・

B2x

extent E2 - sealed


B31

B32

・・・

B3x

extent E1 - sealed


B41

B42

B43

extent E1 - unsealed

stream //bar


sealed extent の最適化

• シールされた extent を replication -> erasure coding で最適化• リード・ソロモン符号を使って最適化• 単純に 3 重にリプリケーションした場合 3 倍のコストだが 1.3 － 1.5 倍

のコストに低減できる

この辺りは日々改善• Local Reconstruction Codes (LRCs)

• LRC は３つの障害があっても１００％の復元でき、３つのレプリカや６＋３リードソロモンより耐久性に優れている。

• LCR はリードソロモンより 14 ％データオーバーヘッドが小さく、少ないデータフラグメントの読み込みで復旧することができる


partition layer architecture

partition map table

partition manager

partition server 1

partition server 1

partition server 1

paxos lock

service

front end

stream layer

partition layer

updateread

update lease

read/write

watch lease

assign partition


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 ロックサービスが使われます


range partition の処理

commit log stream

meta data stream

row data stream

blob data stream

stream layer

partition layer

memory table

row page cache

bloom filter

readwrite


• 複数レプリカからの Read ロードバランシング

• レイテンシー / ロードをモニタリングしてダイナミックにレプリカを選択します。95% レイテンシーで追加のレプリカからのパラレル読み込みが開始されます。

• write load balancing• レイテンシー / ロードをモニタリングし

てレプリカセットを seal し、別の nodeの新しい extent を割り当てます

• capacity load balancing• node が十分な Disk を持つように、レプ

リカのデータの遅延移動が行われます。• 重要： hot nodes/disks は除外されます

Dynamic Load Balancing – stream layer

front end

partition layerM

P P P P P P

stream layer

Architecture Summary

• Durability: 全てのデータは 3 つのレプリカに保存される• Consistency: 全てのコミットは 3 つのレプリカにわたって成功したときに完了する

• Availability: 3 つのレプリカのどからでも読むことができる。もし、書込み時になにか問題があった場合も新しい extent に追記することができる

• Performance/Scale: Retry の原因となるレイテンシーの95% は、 Auto scale out と load balance によるもの。（ based on load/capacity ）


Best Practices


Best Practices- 共通（１）

• 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 は同一データセンター内


Best Practices- 共通（２）

• Account のスケーラビリティターゲットを理解する• 必要なら複数の storage account を使う• partition 分割を意識する

• Cache を上手く使う• Cacheミスのときだけ storage に fall back する• account/ partition の限界を越えられる

• 複数 partition に負荷を分散することでスパイクを排除する• HTTPS を使う


Best Practices- 共通（３）

• 送受信を最適化する• 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 で自動的に削除されます


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 へのアクセスはスケールする


kyrt @takekazuomi

Table Best Practice

• hotspot を避けるように PartitionKey, RowKey を選択する• Table Scan はコストが高い – レイテンシーが重要なシナリオでは避ける

• Batch を使う：同一 PartitionKey では複数の Entity を同時に更新できる

• Schema-less: 複数の Type を同一の Table に入れる• Index は１つだけ（ PartitionKey, RowKey ）：複数の

Index が必要な場合は複合キーを検討する• Entity Locality ：ソート順の近い場所に必要なものを置く

• 関連する Entity を近い場所に置くことで IO が軽減されてPerformance が向上する

2013/11/4 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 に制限される


DesigningAzure Table Storage


Characteristics of Azure Table Storage大きな特徴

1. Schema less2. Partition3. Range Query4. Strong 　 Consistency5. Hi Scalability6. Low cost

RDB(SQL) に比べて 5,6 は優位、他の K/VS に比べると、 3,4は特徴的。


仕様： 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 の合計が最大で１ MBまで• PartitionKey と RowKey の Property で使えない文字、’ /’, ’\’, ’#’, ’? ’,

U+0000 to U+001F, U+007F to U+009F• PartitionKey と RowKey は、最大１ KBまで

http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx2013/11/4 kyrt @takekazuomi 31

http://msdn.microsoft.com/en-us/library/aa664670(VS.71).aspx



http://www.w3.org/TR/REC-xml/

http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx



仕様： Azure Table (2) - Property TypesWCF 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.


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


Entity の設計• データ・モデルを考える際に

• Partition にどのようにデータを配置するかでトランザクションが使えるかが決まる

• Entity の Key を何にするかで Query の可否（パフォーマンス）が決まる• Entity を分割する価値

• 正規化のメリットは限られている、同一 Entity に入れられる物は入れてしまう• 集計等で Partition を跨いた処理が必要

• システムの主たる目的が、 OLTP か OLAP かの性格付けは初期段階でする。 OLTP なら、Azure Table は向いているが OLAP 的に使うのは Azure 　 Table だけでは無理でHadoop等の併用を検討する

• アドホックな集計でなくある程度安定したものなら専用の INDEX データをトランザクション時に生成する

まずは、 Partition を考えてみよう


kyrt @takekazuomi

pattern of Table and Partition usage

• Table 分割の２つの 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 35

Table : Class = 1:1

• Single Class, Single Table mapping

• 別 Class のデータは同一Partition に入らない


Person

Inbox

Outbox

Friend

36

Table:Class = 1:N

Table 内容

Data オブジェクトのデータ

Index インデックス

Log ストレージの変更履歴ログ

• データの粒度を考えて Partition を分割

• 読込アクセス（ Read ）とトランザクション（ Write ）に注目


key の設計

• Azure Table では Key の設計が非常に重要• PartitionKey の選択

• 同一 Partition 内のものは EGT で Atomic に処理出来る• 複数 Partition のデータを Atomic に処理するような分散トランザク

ションの仕組みは無い• Partition には同時アクセス数の上限がある

• 複数の Entiry の場合• 基本的な考えは、 Single Root の Tree になるようにする

• 単一 Entity 依存関係無しの場合


Key の採番

• 採番（＝連番と考えない）

• Uniq 性• Uniq であれば良いなら、 GUID などを利用。クライアントの演算だけで採番できるので非常に高速に採番可能です

• Uniq 性 + 時系列での増加（減少）• 時間を元にした値＋乱数（あるいは GUID ）を利用します。時間は Tick を元にすると Long で表現

することができます。また Tick のリバースキー (例： Int64.MaxValue-Tick等）を使うと逆順にもできます。乱数が必要なのは時間だけだと衝突する可能性が低くないからです。採番速度は衝突の頻度次第です。乱数の代わりに GUID を使えば上記と同等の速度で採番可能です

• Uniq 性 + 連続の番号• 連番を生成するのは Azure Table だけだと楽観的ロックを使わざるえません。読んで書かないと

いけないので、成功した場合でも 100ms以上の時間が必要です。非常に遅いので、使える場面が限定されます。

どの方法も重複した場合のリトライロジックを入れた方が無難


その他

• Embedded • one to one, one to many のパターンはシリアライズしてプロパ

ティに埋め込む策がある• 正規化を崩すが読み込み Performance は良い。更新時を検討する


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-windows-phone-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


http://blogs.msdn.com/b/windowsazurestorage/archive/2013/07/12/introducing-storage-client-library-2-1-rc-for-net-and-windows-phone-8.aspx



http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07/announcing-storage-client-library-2-1-rtm.aspx



TableEntity

• Entity は、 TableEntity から派生して作成

• TableEntity Class は、 3 つのシステムプロパティ、 ETag 、シリアライザ、デシリアライザが実装

• https://github.com/WindowsAzure/azure-sdk-for-net/blob/master/microsoft-azure-api/Services/Storage/Lib/Common/Table/TableEntity.cs#L31

• ReadEntity/WriteEntity のoverride でプロパティへの保存形式を変更可能

• ITableEntity を実装することで自前実装可


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; } }

LastLogonDate

42

https://github.com/WindowsAzure/azure-sdk-for-net/blob/master/microsoft-azure-api/Services/Storage/Lib/Common/Table/TableEntity.cs#L31




Write Operation

• Entity を用意してTableIOperation Class の static method を呼んで操作のオブジェクトを作成して、 Table Client の Execute を呼ぶのが基本

• Batchの場合は、 TableBatchOperation にTableIOperation を入れてExecute で実行

• TableIOperation では、 Entity として、 ITableEntity を受け入れる

var person = new Person()

{

FirstName = "Harp",

LastName = "Walter",

LastLoginDate = DateTime.UtcNow.Date.AddDays(-10)

};

var insertOperation = TableOperation.Insert(person);

table.Execute(insertOperation);


Write OptionEntityの更新系の操作は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• PUT If-Match無し• http://msdn.microsoft.com/en-us/library/windowsazure/hh452242.aspx







http://msdn.microsoft.com/en-us/library/windowsazure/hh452241.aspx

http://msdn.microsoft.com/en-us/library/windowsazure/hh452242.aspx

Read Operation

• LINQ式で書ける• 実は、 1.x では出来たけど、 2.0 で無くなって、 2.1 で LINQ 復活

var query = from ent in currentTable.CreateQuery<CustomerEntity>()

where ent.PartitionKey == “users” && ent.RowKey = “joe”

select ent;


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 == "...")

この場合、１のようにならずに全ての partition が Scan される。つまり４と同じ


Query Options

3 つしか無い• $top

• 取得件数、 1000件以下に制限

• $filter• 演算子で使えるのは、 eq, gt, ge, lt, le, ne と and, not, or

• $select• 取得するプロパティを指定


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


http://msdn.microsoft.com/ja-jp/windowsazure/jj647756

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/overview-of-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/microsoft-azure-api/Services/Storage/Lib/Common/RetryPolicies/ExponentialRetry.cs#L71

• Blob側とコードを共有しているので上記説明と少し違う2013/11/4 kyrt @takekazuomi 49

http://msdn.microsoft.com/ja-jp/library/dd179357.aspx



https://github.com/WindowsAzure/azure-sdk-for-net/blob/master/microsoft-azure-api/Services/Storage/Lib/Common/RetryPolicies/ExponentialRetry.cs#L71



Entity Group Transaction

entity group transaction (EGT) の要件• トランザクション内の全てのエンティティは同一 PartitionKey で無ければなら

ない（ Table も同じ）• entity は、 transaction 内に一回だけ出現できます。そして、 1 つだけの操作

がそれに対して許されます。• transaction には、最大 100 のエンティティ、最大４MB の Payload が許されます。

• 全てのエンティティは、 Table Service Data Model に沿っていなければいけません。

• 上記の条件をクリアすれば、 BatchOperation でまとめて処理できます。• EGT は、 MultiPart Mime の Request で一括で送られ、良いパフォーマ

ンスが出ます（条件が良いと 10 倍以上早くなります）• http://msdn.microsoft.com/en-us/library/dd894038.aspx


http://msdn.microsoft.com/en-us/library/dd894038.aspx

Appendix


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 PEAR


https://github.com/WindowsAzure/azure-sdk-for-net

https://github.com/WindowsAzure/azure-sdk-for-net

https://github.com/WindowsAzure/azure-sdk-for-node



https://github.com/WindowsAzure/azure-sdk-for-java



https://github.com/WindowsAzure/azure-sdk-for-python



https://github.com/WindowsAzure/azure-sdk-for-ruby



https://github.com/WindowsAzure/azure-sdk-for-php

https://github.com/WindowsAzure/azure-sdk-for-php

最後に• 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時点のものです。


http://msdn.microsoft.com/ja-jp/windowsazure/dd439432#leaning

http://channel9.msdn.com/Events/Build/2013/3-541



Windows Azure Storage:Best Practices and Internals

Technology