Microsoft Webinar

1. EC やキャンペーン サイトのパフォーマンスを向上！
～ 最新高速ハイスケール サービスの採用と機能の最適配置で
お客様向け Web サイトを高速化

2. Founder and CEO
ZEN ARCHITECTS Co.,Ltd.
Hiromasa Oka

4. Microsoft
Azure
Search
Cosmos DB
Blob
Storage
Cosmos DB
SQL Database
Search
ローカルでの
インデクシング
Cosmos DB
Search
ローカルでの
インデクシング
リアルタイムGeoレプリケーション
App Service App Service App Service
Traffic Manager
西日本(Primary) 米国東部 西ヨーロッパ
日本ユーザ 米国ユーザ ヨーロッパユーザ
オンプレミス
システム
ローカルでの
インデクシング
Azure CDN Azure CDN Azure CDN
SQL Database
リアルタイムGeoレプリケーション
SQL Database
Blob
Storage
Blob
Storage
https://www.microsoft.com/ja-jp/casestudies/ffs.fujifilm.aspx

5. App Service App Service App Service App Service App Service App Service App Service App Service App Service App Service
Cosmos DB Cosmos DB
リアルタイムGeoレプリケーション
Web Apps Web Apps Web Apps Web Apps
Web Apps Web AppsWeb Apps Web AppsWeb Apps Web Apps
Application
Gateway
Application
Gateway
App Service
Web Apps
Web Apps
Application
Gateway
Application
Gateway
Application
Gateway
Application
Gateway
西日本東日本(Primary)
西日本リージョン東日本リージョン
Traffic Manager
App Service

9. ピーク時への対処は？
ユーザーに我慢してもらう？

11. 未使用リソースの
コストは許容できる？

12. 想定ピークを
超える可能性は？

13. ＝弾力性 (Elasticity)

14. 1. 弾力的なアプリケーション
2. アプリケーションに追従できるデータストア
3. 地理分散と災害対策(DR)

17. Auto Scaling の動作 (Linux + PHP + Wordpress + MySQL)
①VMのCPUの使用率をトリガーに Auto Scaling が開始する。
②Auto Scaling 設定で定義されている イメージが起動し、起動スクリプトの内容に沿って構築が始まる。
③起動スクリプトで chef がキックされる。また、 Git サーバーから Web アプリケーションもデプロイされる。
Linux + MySQL, phpのinstall + yum update + wordpressをGitからpull
④chef での構築後に LB のヘルスチェックが成功した段階でサービスイン。

18. Auto Scaling の動作 (Linux + PHP + Wordpress + MySQL)
事前に、Gitからコンテナ(Docker Image)を構築
（CIによるプロダクションコードのCommit時の実行が望ましい）
①CPUの使用率をトリガーに Auto Scaling が開始する。
②Auto Scaling 設定で定義されているContainerが起動。
③必要アプリケーションがインストールされているDocker ImageをRegistryからデプロイ。
⑤LB のヘルスチェックが成功した段階でサービスイン。
Git Server

19. Auto Scaling の動作 (Linux + PHP + Wordpress + MySQL)
事前に、Gitからコンテナ(Docker Image)を構築
（CIによるプロダクションコードのCommit時の実行が望ましい）
①LBへのRequest/secやCPUの使用率をトリガーに、Docker ImageをAppServiceリソースグループにデプロイ。
②内部LBによるヘルスチェックが成功した段階でサービスインされる。
Git Server
AppService
パフォーマンス情報
①
AppServiceリソースグループAzure Container Registory

20. VMSS + Chef ACS (Docker) AppService on Linux
2台→4台 約 7 分 約 40 秒 約 17 秒
2台→10台 約 7 分 約 41 秒 約 20 秒
検証環境
• VM
• LoadBalancer
• AutoScaleSet（オートスケール）
• Chef-Solo
• Github
• Azure Container Service
• DC/OS
• Marathon
• Docker Container
• Github
• AppService on Linux
with Docker Container
• Github
プロセス
• 手動でスケールアウト
• ベースイメージ起動
• yum install
• php, mysqlをchefでインストール
• wordpressをgitでインストール
• apache起動
• loadbalancerのヘルスチェック
• 手動でスケールアウト
• ベースイメージ起動
• wordpressをgitでインストール
• apache起動
• loadbalancerのヘルスチェック
• 手動でスケールアウト
• wordpressをgitでインストール
• loadbalancerのヘルスチェック

21. スパイク前に
Scale-out
落ち着いたら
Scale-in

22. スパイク前に
VMSSのScale-out
落ち着いたら
VMSSをScale-in
ACSは弾力性が
高いのだが..

23. 細かなメッシュで
負荷に追従

24. Server HW
Hypervisor
VM
App Container
App
Deploy
Ready-to-go-Infrastructure
Provision/Boot
Install/Configure
VNet/Virtual Private Cloud
いつでもセルフプロビジョニング
できるリソースプール

25. pre-provisioned ready to host
pool of ready-to-go https://msdn.microsoft.com/en-us/magazine/mt793270
Server HW
Hypervisor
VM
App Container
App
Deploy
Pre-provisioned/readytohost
どのノードもいつでもデプロイできるように
”暖めてある”リソースプール

26. pre-provisioned ready to host
pool of ready-to-go https://msdn.microsoft.com/en-us/magazine/mt793270
Server HW
Hypervisor
VM
App Container
App
Deploy
Pre-provisioned/readytohost
どのノードもいつでもデプロイできるように
”暖めてある”リソースプール
サーバーレス基盤
いわゆる
を支える仕組み

27. そのサーバーレスネイティブな内部実装
ILB
Instances
Kudu
LoadBalancer
Deployer Telemetry
Prod/Stage
Blob
Allocate
Deploy
Allocate

28. そのサーバーレスネイティブな内部実装
Call
Functions
Kudu
Deployer
Telemetry
Compile
DeAllocateAzure Functions
Pre-Processor
(WebJobs Script Runtime)
App Service Dynamic Runtime
Allocate
Deploy
Run
https://msdn.microsoft.com/en-us/magazine/mt793269.aspx
参考：Serverless Architecture with Azure Functions

31. 高負荷時の苦労の大部分は “Too Many Connections” との闘い

32. Connection
Pool

33. Request
Application
Server
RDB
Load
Balancer
Connection
Pool
Request
AppService
Cosmos DB
ILB
VIP
約10分
Downtime
30秒
15秒

34. VIP
Primary
Node
10GB
Secondary Secondary
Realtime GEO Replication
Japan East
US East
Allocate
Allocate
Master
Region
US East
“Hot Pool”
Japan East
“Hot Pool”
The architecture of BW-Tree atomic record store.
https://www.microsoft.com/en-us/research/publication/the-bw-tree-a-b-tree-for-new-hardware/

36. SQL Database
参照系ワークロード 更新系ワークロード
注文
Service Bus
Queue
Blob Storage
画像/動画
Functions
(Fixed)
カート
ショップ利用者
商品メンテナンス（新商品追加・販売終了）
在庫管理システム
入荷
商品ID/単価/在庫
出荷
順番性の保証
目的別/商品別/優先度別の
キュー配置
各キュー専用の処理インスタンス
ユーザ/商品ID/数量
商品ID/商品名/
商品説明
商品画像 フルテキスト
インデックス AAD B2C
認証
ユーザーアカウント
権限情報
Web Apps
Functions
(Dynamic)
Mobile Apps
App Service
API Apps
Microsoft Azure
Web Apps
Azure
Search
Cosmos DB
(DocumentDB)
一覧/検索詳細
インデクシング
“Adaptive Scale”
Store-Front Architecture Pattern
ECサイト等の
「一覧」「詳細」「絞り込み」
「全文検索」
などのバックエンド機能を
ほぼNoOpsで実現可能
Web-Document-Search (WDS)
アーキテクチャパターン

37. ECサイト：一覧画面
一覧表示
全文検索
絞り込み
サムネイル

38. ECサイト：詳細画面
商品画像
商品説明
・仕様

39. Web Apps
SearchCosmos DB
(Document)
一覧/全文検索
インデクシング
一般的なRDBベースのフロント処理
Azure の WDSパターンでのフロント処理
処理方式 性能（レスポンスタイム）
一覧 RDBへのクエリー
（範囲やKey）
INDEXやデータ量に依存
非常に遅くなる場合もある
詳細 RDBへのクエリー
（ユニークKey）
基本的に速いが、他処理での高負
荷時は引きずられる
全文検索 RDBへのLike検索 重い。機能が限定的。他の検索エ
ンジンを併用する場合が多い
詳細
RDB
処理方式 性能
一覧 Searchへのクエリー
（属性やファセット）
作成済みINDEXのみ対象のため、
元データに依存せず常に高速
詳細 Cosmos DBへのクエ
リー（ユニークKey）
検索処理と分離されているため、
常に高速
全文検索 Searchへのクエリー
（複数の属性横断）
ワードINDEXが生成されているた
め、ゆらぎ対応も含めて常に高速
アプリ
サーバ
一覧/詳細/全文検索

40. Web Apps
SearchCosmos DB
(Document)
一覧/全文検索
インデクシング
一般的なRDBベースのフロント処理
Azure の WDSパターンでのフロント処理
処理方式 性能（レスポンスタイム）
一覧 RDBへのクエリー
（範囲やKey）
INDEXやデータ量に依存
非常に遅くなる場合もある
詳細 RDBへのクエリー
（ユニークKey）
基本的に速いが、他処理での高負
荷時は引きずられる
全文検索 RDBへのLike検索 重い。機能が限定的。他の検索エ
ンジンを併用する場合が多い
詳細
RDB
処理方式 性能
一覧 Searchへのクエリー
（属性やファセット）
作成済みINDEXのみ対象のため、
元データに依存せず常に高速
詳細 Cosmos DBへのクエ
リー（ユニークKey）
検索処理と分離されているため、
常に高速
全文検索 Searchへのクエリー
（複数の属性横断）
ワードINDEXが生成されているた
め、ゆらぎ対応も含めて常に高速
アプリ
サーバ
一覧/詳細/全文検索
コネクションも含めた処理間の依存関係が強く
性能を安定させづらい
目的毎に処理ノードを分離し、ステートレスに
呼び出すことで、リニアに性能を制御できる

41. ECサイト：詳細画面
商品画像
商品説明
・仕様
データ一貫性が
求められる
ACIDトランザクションが
必要な要素のみRDBを使う

42. Current solution for front-end processing for NoOps（Apr.2017)
Document DB
VIP
telemetry
Functions
(Serverless)
Call API
“Scale-out RU”
Webhook
Alert Rule
monitor
2017/4 時点での
NoOps実装
サービス毎に個別にスケールさせていた
テレメトリで最大RU/secを監視。
しきい値を超えたら Webhook からFunctions
を呼び、API経由でRUをスケールアウト
HTTP Request
AppService
ILB
Request/sec がしきい値を超えたら
スケールアウト
WebAppsのエンドポイントの
Request/sec を監視
WebApps
telemetry
Burst

43. HTTP Request
AppService
ILB
Request/sec がしきい値を超えたら
スケールアウト
WebAppsのエンドポイントの
Request/sec を監視
WebApps
Current solution for front-end processing for NoOps（May. 2017)
telemetry
Burst
Build 2017 後の
NoOps実装
Cosmos DB
VIP
Cosmos DB で、スケールアウトの概念すら ほぼ 不要に
設定している RU/sec の値を超えたら
予約しているRU/min の予備ノードを利用
RU/min = 設定しているRU/secの10倍のリソースを
スパイク時のバッファとして確保するオプション
(1,000RU/s設定 → 10,000RU までのスパイクを許容)
RU/min

44. API Apps
Blob
Storage
認証
Storage
Queue
Blob
Storage
SQL Database
Cosm
DB
Cognitive
Services
Machine
Learning
Functions
API G
Application
Insights
Azure Monitor
国内データセンター
Token
.NET
• マスターファイル保管
• アカウント管理
• 権限管理
Identity Framework
Functions
負荷モニター/オートスケール
Search
App Service
Web Apps
オンプレミスシステム
Functions
Storage
Queue
Cosmos DB
(Document)
画像アップロードや、
他システムとの同期などは
QLL※ + Scale-out で実装
※Queue-based Load Leveling

45. Microsoft Cloud Design Patterns
https://docs.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling

46. Message
WebJobs / Functions
ILB
Queue
Storage Queue
/Service Bus
しきい値として設定したCPU利用率を
超えたらスケールアウト
monitor
AppService Plan のCPU利用率を監視
AppService
Current solution for backend processing for NoOps（Apr.2017)
Now
telemetry
Document DB
VIP
テレメトリで最大RU/secを監視。
しきい値を超えたら Webhook からFunctions
を呼び、API経由でRUをスケールアウト
telemetry
Functions
(Serverless)
Call API
“Scale-out RU”
Webhook
Alert Rule
monitor
2017/4時点での
NoOps実装
ジョブ・スパイク
無理矢理感が
あったが

47. Message
ILB
Queue
Storage Queue
/Service Bus
キューの待ち行列が指定した長さ
を超えたらスケールアウトmonitor
AppInsights による Queue Length の監視
AppService
Current solution for backend processing for NoOps（May.2017)
Now
Cosmos DB
VIP
ジョブ・スパイク Build 2017 後の
NoOps実装
Application
Insights
telemetry
設定している RU/sec の値を超えたら
予約しているRU/min の予備ノードを利用
ほぼ理想型に
WebJobs / Functions

49. • ペアリージョン（Pair Region）

50. • 障害ドメイン（Fault Domain）

51. App Service App Service App Service
Traffic Manager
日本リージョン 北米リージョン ヨーロッパリージョン
日本ユーザー 北米ユーザー ヨーロッパユーザー

52. Cosmos DB Cosmos DBCosmos DB
リアルタイムGeoレプリケーション
SQL Database SQL Database
リアルタイムGeoレプリケーション
SQL Database
グローバル単一エンドポイントが提供されているため、
リージョン全体の障害発生時にも
日本リージョン 北米リージョン ヨーロッパリージョン

53. Microsoft
Azure
Search
Cosmos DB
Blob
Storage
Cosmos DB
SQL Database
Search
ローカルでの
インデクシング
Cosmos DB
Search
ローカルでの
インデクシング
リアルタイムGeoレプリケーション
App Service App Service App Service
Traffic Manager
西日本(Primary) 米国東部 西ヨーロッパ
日本ユーザ 米国ユーザ ヨーロッパユーザ
オンプレミス
システム
ローカルでの
インデクシング
Azure CDN Azure CDN Azure CDN
SQL Database
リアルタイムGeoレプリケーション
SQL Database
Blob
Storage
Blob
Storage

54. App Service App Service App Service App Service App Service App Service App Service App Service App Service App Service
Cosmos DB Cosmos DB
リアルタイムGeoレプリケーション
Web Apps Web Apps Web Apps Web Apps
Web Apps Web AppsWeb Apps Web AppsWeb Apps Web Apps
Application
Gateway
Application
Gateway
App Service
Web Apps
Web Apps
Application
Gateway
Application
Gateway
Application
Gateway
Application
Gateway
西日本東日本(Primary)
西日本リージョン東日本リージョン
Traffic Manager
App Service

55. https://docs.microsoft.com/en-us/azure/architecture/guide/design-principles/
✓ Design for self healing 自己回復を設計せよ
✓ Make all things redundant 全てを冗長化せよ
✓ Minimize coordination ブロッキングを最小化せよ
✓ Design to scale out スケールアウトで設計せよ
✓ Partition around limits パーティショニングで限界を超えよ
✓ Design for operations 運用に向けて設計せよ
✓ Use managed services マネージドサービスを活用せよ
✓ Use the best data store for the job 最適なデータストアを選択せよ
✓ Design for evolution 進化を前提に設計せよ
✓ Build for the needs of business ビジネスニーズを実現せよ