Microsoft Open Tech Night #1

1. インフラ野郎 Azureチーム
Pro X
真壁 徹
日本マイクロソフト株式会社
2019/11/26
インフラ技術好きな あなたのハートをジャッカル
Microsoft Open Tech Night #1

2. 自己紹介
apiVersion: selfIntroduction/v1
name: “真壁 徹(まかべ とおる)”
company:
name: “日本マイクロソフト株式会社”
role: “クラウド ソリューションアーキテクト”
career:
- name: “大和総研”
- name: ”HP Enterprise”
cert : “CNCF Certified Kubernetes Admin.”

3. 「できること」だけじゃなく
「生まれた背景や目的」を知ることで
テクノロジーは輝きを増す

4. • これから紹介する技術はリージョンによっ
て導入時期が異なります
• 将来、予告なしに他技術に置き換わる可能
性があります
• 海底データセンターは実験段階です
• Ignite 2019で使われたスライドはそのまま
転載しています (スライド下部にリンク)

5. 本日のメニュー
海底データセンター計画 “Natick” 近況
マルチテナントコンテナー基盤 “Atlas”
ニーズや使い方の変化にあわせた、足回りの改善

6. Igniteの発表 多すぎ 今夜は わたしの好みだけ
リンク

7. 海底データセンター計画 “Natick” 近況

8. Project Natick

9. Project Natick Phase 2 & beyond
• 世界人口の50%以上は沿岸に住
んでいる
• ならばその近くにデータを置い
たら？海底は冷却にもよさげ
• 2015年にPhase 1は完了し、環境
への影響や運用の検証へ移行
• 潜水艦技術を活かしたNatick 2
筒には864台のサーバーを搭載
(27.6Petabytes Disks)
https://natick.research.microsoft.com/

10. Subsea cable connection
Natick 2
sized PV
Ballast tanks for
transport (floating) and
deployment (sinking)
[BRK3097] Inside Azure datacenter architecture

11. [BRK3097] Inside Azure datacenter architecture

12. (海底DCとは別に実用化が進む) Liquid Cooling
Micro-
channel
Cold Plates
One
phase
immersion
Air
Cooled
Olympus
Two
phase
immersion
[BRK3097] Inside Azure datacenter architecture

13. マルチテナントコンテナー基盤 “Atlas”

14. コンテナー需要の高まり
Azure Container Instancesなどコンテナーそのものを提供するサービスだけでなく
Azure Functionsなどサーバーレスサービスの基盤としてもコンテナーは利用されている
仮想マシンと同等の分離度で提供したい
セキュリティのニーズにより、コンテナーがOSカーネルを共有しないようにしたい
これまで仮想マシンレベル分離度を明言したサービスでは、仮想マシン群を事前に作って割当
仮想マシンの分離度とコンテナーのリソース効率、短時間配備の両立
コンテナーに最適化した軽量仮想マシン基盤
Hyper-V コンテナーやLCOW、Service Fabricなど 要素技術を開発し、機は熟した
マルチテナントコンテナー基盤の必要性

15. つまりこういう基盤を作りたかった
Kubernetesをはじめとする
OSSエコシステム
Microsoft
エコシステム
将来のニーズ
コンテナー サーバーレス コンテナー サーバーレス
コンテナー共通基盤
• 仮想マシンレベルで分離しセキュリティーレベルを向上
• サービス間で設備を共有しコストを抑制
• 低レイヤーでの技術イニシアチブを確保

16. Atlas
Multitenant, serverless containers platform for container-based Azure services
AKS
Virtual Nodes
ACI RP
Azure
Functions RP
Future
Serverless
Multitenant
Services
ACI API
Functions
definition
Atlas RP / Control Plane
Container groups
(CaaS)
Service Fabric Cluster 1
(5000 Nodes, 80000 Cores)
Service Fabric Cluster 2
(5000 Nodes, 80000 GPU Cores)
[BRK3097] Inside Azure datacenter architecture

17. Project Teleport
2K 200MB 2GB 5GB
Dedicated VM 1.8s 12.7s 83.9s 412.8s
Azure Container
Instance (ACI)
25.3s 66.4s 188.1s 522.4s
Project Teleport 2.8s 3.3s 4.1s 7.6s
[BRK3097] Inside Azure datacenter architecture

18. ニーズや使い方の変化にあわせた
足回りの改善

19. ユーザーと使い方の変化
Microsoftエコシステム < OSSエコシステム な大規模ユーザーが増加
大規模、短時間で急激にVMを増減させたい というニーズ
コンテナー/マイクロサービス化、認証、リトライなどでアウトバウンド通信量が増加
サービスを提供し続けながら、足回りであるストレージやネットワークを進化させる必要がある
ハードウェア的進化
より性能の高いハードウェア (SCUTI-O SSD for Azureなど)
サービス的進化
ストレージやディスクの新サービスや新たな提供方式
Azure インフラストラクチャー ニーズの変化
“足に来る”

20. ニーズや使い方の変化
たとえば: Adobeさん

21. Adobe Prefers Open-Source-Based Solutions
Windows Server
Powershell
.net
Visual Studio
Team Services
CentOS Linux
Azure CLI
Java
EclipseDev Tools, CI/CD
Dev Languages
Scripting Languages
Server OS
Adobe Stack“Microsoft Shop” Stack
Cloud Provider Microsoft Azure
Microsoft Azure Amazon Web
ServicesAdobe Datacenter
GitJenkins Jira
Python
Bash
[BRK2266] How Adobe Delivers High Availability to Customers Through Multi-AZ Architecture

22. What is the scale of Adobe Azure usage?
Azure Subscriptions: Thousands
VMs: >350K CPU/vCPU
compute hours per day
Azure Resource Manager (ARM) API
Request: >1B requests per month
Database: >100K vCPU/DTU compute
hours per day
Storage: Growing to multiple PBs of data
Microsoft CSAs on Adobe Account:
5 full-time
[BRK2266] How Adobe Delivers High Availability to Customers Through Multi-AZ Architecture

23. では今、インフラのどこを強化すべきか？

24. 3x
BeastAzure servers: General purpose
Gen 2
Processor 2 x 6 Core 2.1 GHz
Memory 32 GiB
Hard Drive 6 x 500 GB
SSD None
NIC 1 Gb/s
Godzilla
Processor 2 x 16 Core 2.0 GHz
Memory 512 GiB
Hard Drive None
SSD 9 x 800 GB
NIC 40 Gb/s
Beast
Processor 4 x 18 Core 2.5 GHz
Memory 4096 GiB
Hard Drive None
SSD
4 x 2 TB NVMe, 1 x
960 GB SATA
NIC 40 Gb/s
Intel Gen 6
Processor
2 x Skylake 24 Core
2.7GHz
Memory 768GiB DDR4
Hard Drive None
SSD
4 x 960 GB M.2 SSDs
and 1 x 960 GB SATA
NIC 40 Gb/s + FPGA
Beast v2
Processor 8 x 28 Core 2.5 GHz
Memory 12 TiB
Hard Drive None
SSD
4 x 2 TB NVMe, 1 x
960 GB SATA
NIC 50 Gb/s
Intel Gen 7
Processor
2 x 26 core
Cascade Lake
Memory 576 GB DDR4
Hard Drive None
SSD 7 x 960 GB M.2 NVMe
NIC 50 Gb/s + FPGA
Optimized Gen 6
Processor
2 x 24 core
Skylake Lake
Memory 192 GB DDR4
Hard Drive None
SSD 5 x 960 GB M.2 NVMe
NIC 40 Gb/s + FPGA
AMD Gen 6
Processor
2 x 32 core
Naples
Memory 512 GB DDR4
Hard Drive None
SSD 7 x 960 GB M.2 NVMe
NIC 50 Gb/s + FPGA
AMD Gen 7
Processor
2 x 32 core
Rome
Memory 768 GB DDR4
Hard Drive None
SSD 7 x 960 GB M.2 NVMe
NIC 50 Gb/s + FPGA
[BRK3097] Inside Azure datacenter architecture

25. 頭と身体(サーバー)は強い
焦点は足回り(ストレージ、ネットワーク)

26. ストレージに関する
代表的な課題と取り組み
(ブロックディスク性能)

27. Azure Compute Host
Front End
Partition Servers
Stream Servers
Storage Devices
Standard/Premium Storage Stamp
従来のAzure Managed Disk
Standard/Premium
• Queueなど他ストレージサービス
と同じ基盤上にPage Blobとして
実装
• 汎用性や拡張性に優れるが、ブ
ロックデバイスに特化した性能改
善がしにくい(ドライバー含め)
• 速いストレージハードウェアに加
え、方式を見直す必要あり
• そこで開発されたのがUltra Disk

28. https://www.opencompute.org/wiki/Server/ProjectOlympus
Ultra Disk
Hardware Platform
– Open Compute
Project
NVMe SSDs
Hot swappable SSD
Reduced Replica Rebuilds
Supports future tech roadmaps
[BRK3167] Ultra Disk: Race into the future with fastest disk storage in the cloud

29. Inside Ultra
Disk Storage
Azure Compute Host
Front End
Partition Servers
Stream Servers
Storage Devices
Premium Storage Stamp
Storage Servers
Storage Devices
Ultra Dish Storage Stamp
[BRK3167] Ultra Disk: Race into the future with fastest disk storage in the cloud

30. Azure Exclusive Cloud Enterprise-class
storage device:
The world’s fastest SSD; 8us latency and 9GB/s
bandwidth at the application level.
Writes as fast as Reads; Reads IOPs at 2.35M
and Writes IOPs at 1.95M
A single NVMe drive equipped with 128 I/O
queue pair, it provides 1 queue pair per
logical processor to 1 processor in 128VP VM.
Constant performance: ultra-performance 3D
XPoint media provides superior endurance
over NAND.
Hardware Built-in Quality of Services for
multiple VM scaling.
SCUTI-O
[BRK3097] Inside Azure datacenter architecture

31. しかし
新しいハードウェアは展開に時間がかかる
サービス提供方式でも改善できないか？

32. その原因、OSディスクのサイズかも…
Premium/Standard Diskの性能はサイズで決まる (Ultra Diskは別途IOPS指定可)
VMを多数、一気に作成/追加/削除する場合に時間がかかる
(Kubernetesクラスターなど)
コンテナーを詰め込んだVM上のサービスで遅延が大きい、不安定
たとえばAKSではOSディスク性能の
飽和がクラスターの安定稼働に影響
するケースが多い
(緩和策としてOSディスクの既定サ
イズを30GBから100GBに変更)
https://github.com/Azure/AKS/issues/1322

33. IOPS上限の高いディスクを使えば解決する、が
性能のためだけに過剰なサイズのディスクを使いたくない
→ピークだけ一時的にIOPS上限が緩和されればいいのでは？

34. Disk performance
Average: 500
Peak
Baseline
Max: 1300
Should I provision
for the peak or
baseline?
[BRK3283] Optimize price-performance and lower TCO for your workloads with the next-gen Azure Disks

35. Disk Bursting support
30x
Performance Boost
✓ Optimize for performance and cost
✓ Better tolerance for spiky disk traffic
[BRK3283] Optimize price-performance and lower TCO for your workloads with the next-gen Azure Disks

36. ネットワークに関する
代表的な課題と取り組み
(アウトバウンド通信爆発)

37. アウトバウンド通信の増加
コンテナー/マイクロサービス化、外部/Key Vault認証、マネージドデータストア、リトライ、etc
コネクションプーリングや静的クライアントの利用など、アプリで打てる手はあるが…
Azure Basic Load Balancer “Ananta”ベース SNAT制御の転換期
Azure Basic LB はPre-warmingが不要、インバウンド処理能力の高さなどでAzureを支えてきた
また、明示的にユーザーが指定/構築しなくても、アウトバウンド向けSNATが提供されて幸せだった
しかしアウトバウンド接続数の多いシステムで、SNATポート枯渇による通信断が見られるように
これはBasic LBを使わずSNATのみの場合でも起こる課題 (内部機能は共通なため)
SNATポートの枯渇

38. (Basic LBベース) Inbound Connections
Ananta: Cloud Scale Load Balancing” Microsoft, SIGCOMM 2013
RouterRouter MUX
Host
MUXRouter MUX
…
Host
Agent
1
2
3
VM
DIP
4
5
6
7
8
Dest:
VIP
Src:
Client
Packet
Headers
Dest:
VIP
Dest:
DIP
Src:
Mux
Src:
Client
Dest:
Client
Src:
VIPPacket
Headers
Client

39. (Basic LBベース) Outbound SNAT Connections
Ananta: Cloud Scale Load Balancing” Microsoft, SIGCOMM 2013
Packet
Headers
Dest:
Server:80
Src:
VIP:1025
VIP:1025 → DIP2
Server
Dest:
Server:80
Src:
DIP2:5555
最近
カツカツ

40. Standard Load Balancerのすすめ
コンテナーが多く動くAKSなどでは、すでにStandard Load Balancerが既定に
接続数に応じてStandard LBの選択
やパブリックIPアドレス付与など、
明示的にSNATを制御しましょう
Standard LBはIPアドレスを追加し
てSNATポート数を増やせる &
Zone Redundantにも対応
なおSNATの改善は今後も予定され
ています Stay tuned!
Azure Kubernetes Service リリースノート
(Standard LBの既定化)
Standard LBを既定や条件とするサービスが
今後も増える見込み

41. 使い方の変化にともない
Azureの足回りもステップアップの時期です
新サービスやガイダンスは要チェック

42. 知りたいと
思う気持ちを
大切に

43. マイ Microsoft Learn コレクション
インフラ野郎への道 – 心得編
https://docs.microsoft.com/ja-jp/users/tomakabe/collections/rqqps18k0eden

44. © Copyright Microsoft Corporation. All rights reserved.