1

更新履歴

• 以下の日付でドキュメントを更新、確認しています。

2

バージョン

1.00 2014/6/30 ・初版リリース

1.10 2014/9/30 ・2014年9月現在の情報に更新

1.20 2015/1/31 ・2015年1月現在の情報に更新

目次

3

• スケールアップとスケールアウト

• オートスケール

• ストレージを活用したハイパフォーマンス実現方法

• キャッシュを活用したハイパフォーマンス実現方法

• その他のハイパフォーマンス実現方法• メディアサービスの活用

• SQL Database Premium

• ハイスペックインスタンスの活用

• トラフィックマネージャーの活用

4

スケールアップとスケールアウト

5

スケールアップ

• ハードウェアのスペックを増強することで、性能・容量を向上させること

• 垂直スケールとも呼ばれる⇔縮小させることは「スケールダウン」

スケールアウト

• サーバーの台数を増強することで、性能・容量を向上させること

• 水平スケールとも呼ばれる⇔縮小させることは「スケールイン」

スケールアップ

スケールアウト

仮想マシン、クラウドサービスにおけるスケールアップ

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シリーズも選択可能）

Azure における負荷分散、スケールアウト

7

負荷分散• リクエストをロードバランサーが受け付け、各インスタンスに負荷を分散する

• Azureではロードバランサーが無償で提供される

スケールアウト• 水平にコンピューティングインスタンスを増やす

• 仮想マシン、クラウドサービス、Webサイト それぞれ仕様、設定方法が異なる

• 一時的な高負荷には、スケールアウトによりパフォーマンスを維持

• 低負荷時には、スケールインにより、必要性能を維持しながらランニングコストを削減

• 自動でのスケールアウト、スケールインも可能(※後述)

• サブスクリプションで既定のコア数等に制限がかかっているので、拡張したい場合は、課金サポートに問い合わせるhttp://azure.microsoft.com/ja-jp/documentation/articles/azure-subscription-service-limits/

仮想マシンのスケールアウト(1)

8

• エンドポイントの「負荷分散セット」に、複数の仮想マシンを配置することで負荷分散を実現

Microsoft Azure データセンター

仮想マシン

仮想マシン

仮想マシン

ユーザーロードバランサー

クラウドサービス

負荷分散セット

仮想マシンのスケールアウト (2)

9

• 管理ポータルより1つ目の仮想マシンに負荷分散エンドポイントを作成可能

• 2つ目以降の仮想マシンに作成した負荷分散エンドポイントを追加

クラウドサービスのスケールアウト (1)

10

• クラウドサービスのロール内に複数のインスタンスを用意すると、Azure のロードバランサーで自動的に負荷分散される

Microsoft Azure データセンター

クラウドサービス

ユーザーロードバランサー SQL Database

クラウドサービスのスケールアウト (2)

11

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

Webサイトのスケールアウト(1)• Webサイトを複数インスタンス用意すると、Azure のロードバランサーで自動的に負荷分散される

• スケールアウトするには、「共有」以上のレベルを選択する

• それぞれのWebサイトのローカルストレージは同一ディスクを参照しているので、インスタンスを増やしても、それぞれのローカルストレージを意識する必要はない

12

Microsoft Azure データセンター

Web サイト

ユーザーロードバランサー SQL Database

Webサイトのスケールアウト (2)

13

• インスタンス数は管理ポータルのスケールタブから手動で変更可能

• 管理ポータルでのスケール設定は、永続的に有効

• レベルにより設定可能なインスタンス数の上限が異なる

モード

1（増やすことはできない）

共有 6※共有インスタンス

基本 3※専用インスタンス

標準 10※専用インスタンス

14

オートスケールとは

15

• 設定条件によりスケールの伸縮を自動的に行う機能のこと（設定条件＝サーバーの負荷増減時、事前に設定したスケジュールなど）

• 自動化による監視・運用コストの軽減を実現

負荷増大時はスケールアウト

負荷減少時はスケールイン

ロードバランサー

Azureにおけるオートスケール

16

• スケジュール(平日、休日、日中、夜間、期間指定)によるスケール設定

• メトリック（CPU使用率、キュー数など）によるスケール設定

• スケジュールとメトリックを組み合わせたスケール設定も可能

スケジュールによる設定例

• ピークが平日日中に見込まれる場合、インスタンス数を夜間、休日よりも増やす

• 期間限定キャンペーンを実施する場合、期間中はインスタンス数を通常時よりも増やす

CPU使用率による設定例

• CPU使用率の閾値を下限60%～上限80%と設定、インスタンス数を2～5と設定→下限を下回るとインスタンス数が最小2まで減り、上限を上回ると最大5まで増える

スケジュールによるオートスケールの設定

17

①定期的なスケジュールの設定

・日中／夜間、平日／週末、平日の日中／平日の夜間／週末

・開始時刻、終了時刻を指定することで「日中」を定義可能 ※日中でない時間が夜間

②特定の日付の設定

・開始日時、終了日時を指定

②

①「日中」をここで定義

平日＝月曜日の「1日の開始」～金曜日の「1日の終了」週末＝金曜日の「1日の終了」～月曜日の「1日の開始」

日中＝1日の開始～1日の終了夜間＝1日の終了～1日の開始

Webサイトのオートスケール設定

18

①スケジュールの設定

②メトリックの設定（CPU使用率を条件とするかしないか）

③インスタンス数の指定

①

②

③

②

スケジュールごとに異なるスケールを設定可

インスタンスサイズはスケジュールごとに異なるサイズの設定不可

メトリックによるスケールに「なし」を指定した場合、以下を指定・インスタンス数

メトリックによるスケールに「CPU」を指定した場合、以下を指定・インスタンス数の最小値～最大値・CPU使用率の最小値～最大値

クラウドサービスのオートスケール設定

19

①スケジュールの設定

②メトリックの設定（CPU使用率 または キュー数 または指定しない）

③インスタンス数の指定

④スケール切り替え時の増減インスタンス数、切り替えの待機時間の指定

①

②

③

②

スケジュールごとに異なるスケールを設定可

メトリックによるスケールに「なし」を指定した場合、以下を指定・インスタンス数

メトリックによるスケールに「CPU」を指定した場合、以下を指定・インスタンス数の最小値～最大値・CPU使用率の最小値～最大値・切り替えの際に増減させるインスタンス数・切り替え後、次の切り替えまでの待機時間

④

④

メトリックによるスケールに「キュー」を指定した場合、以下を指定・インスタンス数の最小値～最大値（※「CPU」指定時と同様）・キュー名・1台の仮想マシンで処理するメッセージ数・切り替えの際に増減させるインスタンス数（※「CPU」指定時と同様）・切り替え後、次の切り替えまでの待機時間（※「CPU」指定時と同様）

仮想マシンのオートスケールの設定

20

準備

・ピーク時に見込まれる台数分、同一イメージの仮想マシンを用意する

・それらの仮想マシンを同一の負荷分散セットに配置する

設定

・ 「仮想マシン」 メニューではなく、「クラウドサービス」メニューより設定する

・仮想マシンのオートスケールの設定はクラウドサービスの設定と同様

（設定可能なインスタンス数の上限は負荷分散セットに配置した仮想マシン台数となる）

VM3

停止中

VM4

停止中VM1

実行中

VM2

実行中VM3

停止→起動

VM1

実行中

VM2

実行中

VM4

停止→起動

条件設定により待機系の仮想マシンが自動起動

21

ストレージを活用したハイパフォーマンス実現

• Azureのストレージは、複数サーバーを束ねた仮想ストレージとして作られているため、高負荷に耐えることができる

• テーブル非正規化された大量のデータ登録、管理を高速化

• BLOB静的コンテンツの配信によるコンピューティングへの負荷軽減

• キューメッセージのキューイングにより、バックエンドのインスタンスによる非同期処理を実現

22

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 略 ・・・・

Azure BLOBの活用

24

概要

・BLOB=Binary Large OBject（巨大なバイナリデータ）

・画像、音声、動画、テキスト等様々な種類のファイルを保存するのに適している

・ブロックBLOB、ページBLOBの2種類がある

ブロックBLOB

・画像、音声、動画など巨大なバイナリデータを保存する用途

・シーケンシャルアクセスに強い

・大量のデータを分割して並列処理でアップロード可能

ページBLOB

・ランダムアクセスと頻繁に更新されるデータを保存する用途

・Azure仮想マシンのファイルシステムなど

静的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.windows.net/image/myimage.jpgのようにストレージのURLになる。コンピューティング側へのリクエストを減らし負荷軽減も行う。

●コンピューティング側には動的なリクエストのみ届き、アクセス負荷が軽減される。

Azure ストレージ・キューの活用

26

概要

・キューとメッセージで構成

・Azure サーバー間のメッセージ通信に利用

・バックグラウンドでの非同期通信に利用

・メッセージは処理に成功しない限りキューに残り、リトライの対象となる

・2,000メッセージ/秒 のパフォーマンス

・厳密なFIFO(先入先出)ではなく、キューに優先度を持たせる場合は、設計上の検討が必要

・REST APIによる管理が可能

バックエンドでの非同期処理とキュー

• パフォーマンスを必要とする処理を非同期にしてバックエンドで処理

• 処理要求はキューに保存して、フロントはレスポンスを返す

• バックエンドには、Workerロールや、キュー監視を行うサービスを仮想マシンに構築

• バックエンドで、BLOBやテーブルへの書き込み処理を行う

27

Microsoft Azure データセンター

Webロール

Webロール

ユーザー

ロードバランサー

フロントエンド

キュー

バックエンド

Workerロール

仮想マシン

BLOB

テーブル

28

キャッシュの活用 In-Role-Cache

• クラウドサービス上で動作するキャッシュ• Memcached互換• Webロール、Workerロールの中で実行可能• 分割するインスタンス数、割当メモリ容量をカスタマイズ可能

Co-located Role caching• ロール内にデプロイされたアプリケーションと同居して動作• ロール内にキャッシュ用のメモリ領域を確保• ロール内の各インスタンスに分散される

Dedicated Role caching• キャッシュ専用の 独立したロールとして起動(実態はWorker Role) • スケールアウトすることが可能

29

Azure Managed Cacheの活用(1)• 占有型の分散In-Memoryキャッシュ

• スケーラブル、インスタンスを増やすのが容易

• 仮想マシン、Webサイトでキャッシュを利用する際に最適、立ち上げが容易

• 大きめのキャッシュサイズもサポート（最大150GB）

• キャッシュの期限切れに対応(時間指定、スライディング指定)

• プレミアムプランでは高可用性をサポート、障害時もデータを保持

30

Azure Managed Cacheの活用(2)

• ASP.NETのセッション状態やOutputページキャッシュなどの

プロバイダーを提供

• .NETのシリアライズできるマネージドオブジェクトをキャッシュ

• アイテム単位などでキャッシュに変更があった際にコールバックする

機能を有する

• キャパシティプランニングの参考http://msdn.microsoft.com/library/azure/dn386139.aspx

31

CDN の活用• 画像やファイル等のコンテンツをグローバルで大規模にキャッシュ

• BLOB、コンピューティング上のファイルをキャッシュ可能

• 廉価に大規模キャッシュを利用可能

• 世界に29のエッジサーバーがあり、最寄りの場所からキャッシュしたコンテンツを取得できる※2015年1月現在

32

コンピューティング

仮想マシン WEBロール

Microsoft Azure データセンター

BLOB

画像,CSS,JS等の静的ファイル

Azure CDN

Azure CDN

33

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

• RDBMS、SharePoint Server等＝メモリ使用量が多いアプリケーション

• 画像処理エンジン、データ分析ツール等＝CPU時間を多く使うアプリケーション

• ハイスペックインスタンス（A5～A9）、(D1～D14) 、(G1～G5)を活用することで処理能力を向上

メディアサービスの活用

36

• 動画メディア配信に関連する各フローをAzureのコンピューティングでスケールアウト

• さまざまな動画ファイルの規格を吸収

• PC、タブレット、各種スマートフォン等、異なるデバイスに対応

• デジタルコンテンツの著作権管理（DRM）

• ストリーミング方式に対応

エンコード

フォーマット変換

デジタル保護

オンデマンドストリーミング

ライブストリーミング

メディアサービス

ストレージ

さまざまなデバイス

配信メディア元ファイル

トラフィックマネージャー

37

• 複数の仮想サーバーで実行されている同一サービス向けの通信を振り分ける機能

• 同じデータセンター内、または世界各地のデータセンター間での制御が可能

• 3種類のポリシー（パフォーマンス、ラウンドロビン、フェールオーバー）を使ってレイテンシの低減、負荷分散、可用性向上が期待できる

ユーザー

Microsoft Azure データセンター

西ヨーロッパ

Microsoft Azure データセンター

日本（東）

Microsoft Azure データセンター

米国西部

トラフィックマネージャー[azurestudy01].trafficmanager.net

38

39

トラフィックマネージャーの負荷分散方法

40

パフォーマンス

• トラフィックをネットワーク的に最も近いサービスにリダイレクトさせる方法

• 同一サービスが世界各地のデータセンターに展開されている場合に利用

• アプリケーションのレスポンスタイム向上に効果的

ラウンドロビン

• トラフィックをラウンドロビン方式でサービスにリダイレクトさせる方法

• 稼働中の複数サービスの負荷を均等に分散したい場合に利用

• 停止しているサービスにはリダイレクトしないため、サービスを停止させずに保守が可能

フェールオーバー

• 主要サービス停止時にはバックアップにリダイレクトさせる方法

• 通常時には主要サービスに全トラフィックが使用される場合に利用

SendGridによる大規模メール配信

• 仮想マシン上に構築するメールサーバーの負荷、および送信遅延を解決

• Azure ストアから「SendGrid」を購入することによって大規模なメール配信、メールサーバー機能が利用可能

• Azure 契約者は月25,000通までは無料

• Goldプランでは月30万通の送信が可能で、それ以上の契約も可能

• Parse APIを利用するとメール受信を元に他の処理と連動可能

41