http://kyrt.in/

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は３種類ある
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. ３つのレイヤ - 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は３つの障害があっても１００％の復元でき、３つのレプリカや
６＋３リードソロモンより耐久性に優れている。
• 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- 共通（１）
• 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- 共通（２）
• Accountのスケーラビリティターゲットを理解する
• 必要なら複数のstorage accountを使う
• partition分割を意識する
• Cacheを上手く使う
• Cacheミスのときだけstorageにfall backする
• account/ partitionの限界を越えられる
• 複数partitionに負荷を分散することでスパイクを排除する
• HTTPSを使う
2013/11/4
kyrt @takekazuomi
24

25. 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で自動的に削除されます
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は１つだけ（ 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 の合計が最大で１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.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分割の２つの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 == "...")
この場合、１のようにならずに全てのpartition がScanされる。
つまり４と同じ
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 のエンティティ、最大４MBの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