1. 1

2. 更新履歴
• 以下の日付でドキュメントを更新、確認しています。
2
バージョン
1.00 2014/6/30 ・初版リリース
1.10 2014/9/30 ・2014年9月現在の情報に更新
1.20 2015/1/31 ・2015年1月現在の情報に更新

3. 目次
3
• スケールアップとスケールアウト
• オートスケール
• ストレージを活用したハイパフォーマンス実現方法
• キャッシュを活用したハイパフォーマンス実現方法
• その他のハイパフォーマンス実現方法
• メディアサービスの活用
• SQL Database Premium
• ハイスペックインスタンスの活用
• トラフィックマネージャーの活用

4. 4

5. スケールアップとスケールアウト
5
スケールアップ
• ハードウェアのスペックを増強することで、
性能・容量を向上させること
• 垂直スケールとも呼ばれる
⇔縮小させることは「スケールダウン」
スケールアウト
• サーバーの台数を増強することで、性能・容
量を向上させること
• 水平スケールとも呼ばれる
⇔縮小させることは「スケールイン」
スケールアップ
スケールアウト

6. 仮想マシン、クラウドサービスにおけるスケールアップ
6
サイズ コア数
メモリ
一時
ディスク
(GB)
データ
ディスク
最大接続数
最大IOPS
A0 (XS) 共用 0.768 20 1 1 × 500 標準
A1 (S) 1 1.75 70 2 2 × 500 〃
A2 (M) 2 3.5 135 4 4 × 500 〃
A3 (L) 4 7 285 8 8 × 500 〃
A4 (XL) 8 14 605 16 16 × 500 〃
A5 2 14 135 4 4 × 500 メモリ集中型
A6 4 28 285 8 8 × 500 〃
A7 8 56 605 16 16 × 500 〃
A8 8 56 382 16 16 × 500 コンピューティング集中型
A9 16 112 382 16 16 × 500 〃
• 管理ポータルより「インスタンス サイズ」を変更しスケールアップする
• 稼働後でもサイズの変更は容易に可能、ただしインスタンスの再起動を伴う
• 本スライドではAシリーズを紹介（SSDドライブを持つDシリーズ、Gシリーズも選択可能）

7. Azure における負荷分散、スケールアウト
7
負荷分散
• リクエストをロードバランサーが受け付け、各インスタンスに負荷を分散する
• Azureではロードバランサーが無償で提供される
スケールアウト
• 水平にコンピューティングインスタンスを増やす
• 仮想マシン、クラウドサービス、Webサイト それぞれ仕様、設定方法が異なる
• 一時的な高負荷には、スケールアウトによりパフォーマンスを維持
• 低負荷時には、スケールインにより、必要性能を維持しながらランニングコスト
を削減
• 自動でのスケールアウト、スケールインも可能(※後述)
• サブスクリプションで既定のコア数等に制限がかかっているので、拡張したい場
合は、課金サポートに問い合わせる
http://azure.microsoft.com/ja-jp/documentation/articles/azure-subscription-service-limits/

8. 仮想マシンのスケールアウト(1)
8
• エンドポイントの「負荷分散セット」に、複数の仮想マシンを配置することで負荷分散を実現
Microsoft Azure データセンター
仮想マシン
仮想マシン
仮想マシン
ユーザー
ロードバランサー
クラウドサービス
負荷分散セット

9. 仮想マシンのスケールアウト (2)
9
• 管理ポータルより1つ目の仮想マシンに負荷分散エンドポイントを作成可能
• 2つ目以降の仮想マシンに作成した負荷分散エンドポイントを追加

10. クラウドサービスのスケールアウト (1)
10
• クラウドサービスのロール内に複数のインスタンスを用意すると、
Azure のロードバランサーで自動的に負荷分散される
Microsoft Azure データセンター
クラウドサービス
ユーザー
ロードバランサー SQL Database

11. クラウドサービスのスケールアウト (2)
11
• インスタンス数は管理ポータルのスケールタブから手動で変更可能
※ただし.cscfgファイル（クラウド・サービス構成ファイル）には反映されず、
再デプロイ時に設定が継続されないので注意すること

12. Webサイトのスケールアウト(1)
• Webサイトを複数インスタンス用意すると、Azure のロードバランサーで自動的に負荷分散される
• スケールアウトするには、「共有」以上のレベルを選択する
• それぞれのWebサイトのローカルストレージは同一ディスクを参照しているので、インスタンスを
増やしても、それぞれのローカルストレージを意識する必要はない
12
Microsoft Azure データセンター
Web サイト
ユーザー
ロードバランサー SQL Database

13. Webサイトのスケールアウト (2)
13
• インスタンス数は管理ポータルのスケールタブから手動で変更可能
• 管理ポータルでのスケール設定は、永続的に有効
• レベルにより設定可能なインスタンス数の上限が異なる
モード
1（増やすことはできない）
共有 6※共有インスタンス
基本 3※専用インスタンス
標準 10※専用インスタンス

14. 14

15. オートスケールとは
15
• 設定条件によりスケールの伸縮を自動的に行う機能のこと
（設定条件＝サーバーの負荷増減時、事前に設定したスケ
ジュールなど）
• 自動化による監視・運用コストの軽減を実現
負荷増大時はスケールアウト
負荷減少時はスケールイン
ロードバランサー

16. Azureにおけるオートスケール
16
• スケジュール(平日、休日、日中、夜間、期間指定)によるスケール設定
• メトリック（CPU使用率、キュー数など）によるスケール設定
• スケジュールとメトリックを組み合わせたスケール設定も可能
スケジュールによる設定例
• ピークが平日日中に見込まれる場合、インスタンス数を夜間、休日よりも増やす
• 期間限定キャンペーンを実施する場合、期間中はインスタンス数を通常時よりも増やす
CPU使用率による設定例
• CPU使用率の閾値を下限60%～上限80%と設定、インスタンス数を2～5と設定
→下限を下回るとインスタンス数が最小2まで減り、上限を上回ると最大5まで増える

17. スケジュールによるオートスケールの設定
17
①定期的なスケジュールの設定
・日中／夜間、平日／週末、平日の日中／平日の夜間／週末
・開始時刻、終了時刻を指定することで「日中」を定義可能 ※日中でない時間が夜間
②特定の日付の設定
・開始日時、終了日時を指定
②
①
「日中」をここで定義
平日＝月曜日の「1日の開始」～金曜日の「1日の終了」
週末＝金曜日の「1日の終了」～月曜日の「1日の開始」
日中＝1日の開始～1日の終了
夜間＝1日の終了～1日の開始

18. Webサイトのオートスケール設定
18
①スケジュールの設定
②メトリックの設定（CPU使用率を条件とするかしないか）
③インスタンス数の指定
①
②
③
②
スケジュールごとに異なるスケールを設定可
インスタンスサイズは
スケジュールごとに異なるサイズの設定不可
メトリックによるスケールに「なし」を
指定した場合、以下を指定
・インスタンス数
メトリックによるスケールに「CPU」を
指定した場合、以下を指定
・インスタンス数の最小値～最大値
・CPU使用率の最小値～最大値

19. クラウドサービスのオートスケール設定
19
①スケジュールの設定
②メトリックの設定（CPU使用率 または キュー数 または指定しない）
③インスタンス数の指定
④スケール切り替え時の増減インスタンス数、切り替えの待機時間の指定
①
②
③
②
スケジュールごとに異なるスケールを設定可
メトリックによるスケールに「なし」を指定した場合、以下を指定
・インスタンス数
メトリックによるスケールに「CPU」を指定した場合、以下を指定
・インスタンス数の最小値～最大値
・CPU使用率の最小値～最大値
・切り替えの際に増減させるインスタンス数
・切り替え後、次の切り替えまでの待機時間
④
④
メトリックによるスケールに「キュー」を指定した場合、以下を指定
・インスタンス数の最小値～最大値 （※「CPU」指定時と同様）
・キュー名
・1台の仮想マシンで処理するメッセージ数
・切り替えの際に増減させるインスタンス数（※「CPU」指定時と同様）
・切り替え後、次の切り替えまでの待機時間（※「CPU」指定時と同様）

20. 仮想マシンのオートスケールの設定
20
準備
・ピーク時に見込まれる台数分、同一イメージの仮想マシンを用意する
・それらの仮想マシンを同一の負荷分散セットに配置する
設定
・ 「仮想マシン」 メニューではなく、「クラウドサービス」メニューより設定する
・仮想マシンのオートスケールの設定はクラウドサービスの設定と同様
（設定可能なインスタンス数の上限は負荷分散セットに配置した仮想マシン台数となる）
VM3
停止中
VM4
停止中
VM1
実行中
VM2
実行中
VM3
停止→起動
VM1
実行中
VM2
実行中
VM4
停止→起動
条件設定により待機系の仮想マシンが自動起動

21. 21

22. ストレージを活用したハイパフォーマンス実現
• Azureのストレージは、複数サーバーを束ねた仮想ストレージとして
作られているため、高負荷に耐えることができる
• テーブル
非正規化された大量のデータ登録、管理を高速化
• BLOB
静的コンテンツの配信によるコンピューティングへの負荷軽減
• キュー
メッセージのキューイングにより、バックエンドのインスタンスによ
る非同期処理を実現
22

23. Azure テーブルの活用
23
概要
• 分散Key-Value型のデータストアにより高パフォーマンスを実現
• 非正規化された大量のデータ登録と管理を高速に処理する
• Partition KeyとRow keyによってキー管理する
• 単一パーティション単位で2,000エンティティ/秒間 トランザクション
• ストレージアカウント単位で20,000エンティティ/秒間トランザクション
リレーショナルデータベースとの差異
• テーブルとテーブルを結合（JOIN）できない
• パーティションの異なる一連のデータ処理を同一トランザクションにできない
• 1つのテーブルに異なる構造のエンティティを格納することができる
PartitionKey RowKey Timestamp その他項目
MyTable1 99999001 2013-10-25 00:00:00 ・・・・
MyTable1 99999002 略 ・・・・
MyTable2 99999001 略 ・・・・

24. Azure BLOBの活用
24
概要
・BLOB=Binary Large OBject（巨大なバイナリデータ）
・画像、音声、動画、テキスト等様々な種類のファイルを保存するのに適している
・ブロックBLOB、ページBLOBの2種類がある
ブロックBLOB
・画像、音声、動画など巨大なバイナリデータを保存する用途
・シーケンシャルアクセスに強い
・大量のデータを分割して並列処理でアップロード可能
ページBLOB
・ランダムアクセスと頻繁に更新されるデータを保存する用途
・Azure仮想マシンのファイルシステムなど

25. 静的Webサーバーとしての Azure BLOB活用
• Azure BLOBに、HTML,CSS,JS,画像等の静的ファイルを格納
• 一般的なWEBシステムでは、画像やCSSをBLOBに配置することによって
コンピューティング側へ負荷が集中するのを防ぐことが可能
• BLOBストレージは、秒間60MB/秒など高パフォーマンスを発揮
25
コンピューティング
仮想マシン WEBロール
Microsoft Azure データセンター
BLOBストレージ
画像,CSS,JS等の静的ファイル
●静的なファイルはBLOBへ格納。URLは
http://<YOUR_ACCOUNT>.blob.core.w
indows.net/image/myimage.jpg
のようにストレージのURLになる。
コンピューティング側へのリクエストを減
らし負荷軽減も行う。
●コンピューティング側には
動的なリクエストのみ届き、
アクセス負荷が軽減される。

26. Azure ストレージ・キューの活用
26
概要
・キューとメッセージで構成
・Azure サーバー間のメッセージ通信に利用
・バックグラウンドでの非同期通信に利用
・メッセージは処理に成功しない限りキューに残り、リトライの対象となる
・2,000メッセージ/秒 のパフォーマンス
・厳密なFIFO(先入先出)ではなく、キューに優先度を持たせる場合は、設計上の検討が必要
・REST APIによる管理が可能

27. バックエンドでの非同期処理とキュー
• パフォーマンスを必要とする処理を非同期にしてバックエンドで処理
• 処理要求はキューに保存して、フロントはレスポンスを返す
• バックエンドには、Workerロールや、
キュー監視を行うサービスを仮想マシンに構築
• バックエンドで、BLOBやテーブルへの書き込み処理を行う
27
Microsoft Azure データセンター
Webロール
Webロール
ユーザー
ロードバランサー
フロント
エンド
キュー
バック
エンド
Workerロール
仮想マシン
BLOB
テーブル

28. 28

29. キャッシュの活用 In-Role-Cache
• クラウドサービス上で動作するキャッシュ
• Memcached互換
• Webロール、Workerロールの中で実行可能
• 分割するインスタンス数、割当メモリ容量をカスタマイズ可能
Co-located Role caching
• ロール内にデプロイされたアプリケーションと同居して動作
• ロール内にキャッシュ用のメモリ領域を確保
• ロール内の各インスタンスに分散される
Dedicated Role caching
• キャッシュ専用の 独立したロールとして起動(実態はWorker Role)
• スケールアウトすることが可能
29

30. Azure Managed Cache の活用(1)
• 占有型の分散In-Memoryキャッシュ
• スケーラブル、インスタンスを増やすのが容易
• 仮想マシン、Webサイトでキャッシュを利用する際に最適、立ち上げが容易
• 大きめのキャッシュサイズもサポート（最大150GB）
• キャッシュの期限切れに対応(時間指定、スライディング指定)
• プレミアムプランでは高可用性をサポート、障害時もデータを保持
30

31. Azure Managed Cache の活用(2)
• ASP.NETのセッション状態やOutputページキャッシュなどの
プロバイダーを提供
• .NETのシリアライズできるマネージドオブジェクトをキャッシュ
• アイテム単位などでキャッシュに変更があった際にコールバックする
機能を有する
• キャパシティプランニングの参考
http://msdn.microsoft.com/library/azure/dn386139.aspx
31

32. CDN の活用
• 画像やファイル等のコンテンツをグローバルで大規模にキャッシュ
• BLOB、コンピューティング上のファイルをキャッシュ可能
• 廉価に大規模キャッシュを利用可能
• 世界に29のエッジサーバーがあり、最寄りの場所からキャッシュしたコンテンツ
を取得できる※2015年1月現在
32
コンピューティング
仮想マシン WEBロール
Microsoft Azure データセンター
BLOB
画像,CSS,JS等の静的ファイル
Azure CDN
Azure CDN

33. 33

34. SQL Database Premiumの活用
34
• SQL Database のスケールアップが可能
• SQL Database Premiumを使用することでマルチテナント型の制限を緩和
• 高負荷、多数の同時リクエスト、短い応答時間が要求されるシナリオに適し
ている
• パフォーマンスレベルはP1, P2, P3の3種類
パフォーマンス
レベル
DTU 最大セッション
P1 100 200 2,000
P2 200 400 4,000
P3 800 1,600 16,000
http://msdn.microsoft.com/ja-jp/library/azure/dn741336.aspx

35. ハイスペックインスタンスの活用
35
• RDBMS、SharePoint Server等＝メモリ使用量が多い
アプリケーション
• 画像処理エンジン、データ分析ツール等＝CPU時間を多く使う
アプリケーション
• ハイスペックインスタンス（A5～A9）、(D1～D14) 、
(G1～G5)を活用することで処理能力を向上

36. メディアサービスの活用
36
• 動画メディア配信に関連する各フローをAzureのコンピューティングでスケールアウト
• さまざまな動画ファイルの規格を吸収
• PC、タブレット、各種スマートフォン等、異なるデバイスに対応
• デジタルコンテンツの著作権管理（DRM）
• ストリーミング方式に対応
エンコード
フォーマット
変換
デジタル
保護
オンデマンド
ストリーミング
ライブ
ストリーミング
メディアサービス
ストレージ
さまざまな
デバイス
配信メディア
元ファイル

37. トラフィックマネージャー
37
• 複数の仮想サーバーで実行されている同一サービス向けの通信を振り分ける機能
• 同じデータセンター内、または世界各地のデータセンター間での制御が可能
• 3種類のポリシー（パフォーマンス、ラウンドロビン、フェールオーバー）を使って
レイテンシの低減、負荷分散、可用性向上が期待できる
ユーザー
Microsoft Azure データセンター
西ヨーロッパ
Microsoft Azure データセンター
日本（東）
Microsoft Azure データセンター
米国西部
トラフィックマネージャー
[azurestudy01].trafficmanager.net

38. 38

39. 39

40. トラフィックマネージャーの負荷分散方法
40
パフォーマンス
• トラフィックをネットワーク的に最も近いサービスにリダイレクトさせる方法
• 同一サービスが世界各地のデータセンターに展開されている場合に利用
• アプリケーションのレスポンスタイム向上に効果的
ラウンドロビン
• トラフィックをラウンドロビン方式でサービスにリダイレクトさせる方法
• 稼働中の複数サービスの負荷を均等に分散したい場合に利用
• 停止しているサービスにはリダイレクトしないため、サービスを停止させずに保守が可能
フェールオーバー
• 主要サービス停止時にはバックアップにリダイレクトさせる方法
• 通常時には主要サービスに全トラフィックが使用される場合に利用

41. SendGrid による大規模メール配信
• 仮想マシン上に構築するメールサーバーの負荷、および送信遅延を解決
• Azure ストアから「SendGrid」を購入することによって大規模なメール配信、
メールサーバー機能が利用可能
• Azure 契約者は月25,000通までは無料
• Goldプランでは月30万通の送信が可能で、それ以上の契約も可能
• Parse APIを利用するとメール受信を元に他の処理と連動可能
41