M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]

Microsoft Japan Digital Days
*本資料の内容 (添付文書、リンク先などを含む) は Microsoft Japan Digital Days における公開日時点のものであり、予告なく変更される場合があります。
#MSDD2021
あなたの知らない
Azureインフラの世界
日本マイクロソフト株式会社
シニアクラウドソリューションアーキテクト
真壁徹
# M08

お伝えしたいこと
 Azureのインフラストラクチャーに関する
「よく知られていそうだが、実際はそうでもない」話
 設計に役立つ概念、実装技術、検証データ
 心豊かに日々の作業を行うための小ネタ
 知るほどに愛が湧く

Agenda  Availability Zonesのすすめ
 ネットワークレイテンシ依存要素と測定
 仮想マシン起動時間依存要素と測定
 疑似障害テストと観測手法の現在

Availability Zonesの
すすめ

Availability Zones(AZ) のすすめ
 各Zoneは独立した電源、冷却、
ネットワーク設備を備える
 障害、災害の影響を局所化
 サービスのAZ化が進行中
 [Link] Availability Zones をサ
ポートする Azure サービス
 可用性を重視するシステムでは
利用を強く推奨
[Link] Azure のリージョンと Availability Zones

障害、災害だけでなくメンテナンス影響の観点でも推奨
 設備だけではなく、仮想マシン
のメンテナンススケジュール単位
(更新ドメイン)も分離
 仮想マシンはもちろん、その上
で動いているマネージドサービス
にも好影響
 マネージドサービスは更新ドメインが
不可視だが、ゾーン冗長構成を選
択することで明確に
「お客様の観点からは、ゾーン冗長性を備え
たゲートウェイをデプロイできるようになります。
つまり、すべてのゲートウェイインスタンスが複
数の Azure Availability Zones にわたって
デプロイされ、それぞれの Availability Zone
が別々の障害ドメインおよび更新ドメインと
なります。これにより、ゲートウェイの信頼性、
可用性、およびゾーン障害に対する回復性
が向上します。」
[Link] Azure Availability Zones でのゾーン冗長仮想
ネットワークゲートウェイ - Azure VPN Gateway

AZ識別子はサブスクリプションによって異なる
 意外に知られていない
 概念的にはサブスクリプション
IDのハッシュ化
 リソースの偏りを避けるなどの目
的
 AZ識別子とリソースを厳密に
紐づけたい場合は、同じサブス
クリプション下で行う
「可用性ゾーン識別子 (上の図の番号 1、2、
3) は、各サブスクリプションの実際の物理
ゾーンに個別に論理マップされます。つまり、
特定のサブスクリプションの可用性ゾーン 1
が、別のサブスクリプションの可用性ゾーン 1
とは異なる物理ゾーンを参照している可能性
があります。そのため、仮想マシンの配置で
は、異なるサブスクリプション間で可用性ゾー
ン ID を使用しないようにお勧めします。」
[Link] Azure のリージョンと Availability Zones

AZ化に際しての関心事
 私が、これまで最も多くご相談
をいただいた話題は
AZ間のレイテンシ
レイテンシの
目安は？

ネットワークレイテンシ
依存要素と測定

Azureネットワーク主な構成要素
アプリケーション
ゲストOS ネットワークスタック
ホストOS 仮想スイッチ
アクセラレータ付きネットワークデバイス
(SmartNIC)
ネットワーク装置(スイッチ、ルーターなど)
(SmartNIC)
Accelerated
Networking
伝送媒体
(主に光ケーブル)

レイテンシへの影響が想定される要素
(SmartNIC)
(SmartNIC)
Accelerated
Networking
伝送媒体
(主に光ケーブル)
有効/無効
この区間の「長さ」
(同/別AZ、Proximity Placement Group)
経路上のネットワーク
装置の数、性能

AZ間レイテンシに限らず網羅的に検証してみましょう
パターン Acclerated Networking Proximity Placement
Group
Zone
送信側VM 受信側VM
1 1
2 〇 1
3 〇 1
4 〇〇 1
5 〇〇〇 1
6 〇〇 1と2
7 〇〇 1と3
8 〇〇 2と3
• 仮想マシンはすべて Standard_D2d_v4 とする
(2 vCPUだが1NICをAccelerate Networking有効化できる)
• 東日本リージョン

AZ3
AZ2
AZ1
Proximity
Placement Group
検証パターン図
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
無効
Accelerated
Networking
無効
1
8
7
6
5
4
3
2
VM

microsoft/Ethr
 Goで書かれたネットワーク性能
測定ツール
 オープンソース
 (私見)ソースコードが読みやすい
 この検証ではTCP Latencyテス
トを使用
[Link] microsoft/ethr

runTCPLatencyTest
conn, err := ethrDial(TCP, test.dialAddr)
[snip]
ExitForLoop:
for {
ExitSelect:
select {
case <-test.done:
break ExitForLoop
default:
t0 := time.Now()
for i := uint32(0); i < rttCount; i++ {
s1 := time.Now()
n, err := conn.Write(buff)
[snip]
_, err = io.ReadFull(conn, buff)
[snip]
e2 := time.Since(s1)
latencyNumbers[i] = e2
}
[snip]
TCPコネクション作成
rttCount = 1000
(1000回送受信する)
事前に作成しておいたコネクションへ
のWrite(直前)から、ReadFull完了
(直後)までの時間
buff は 1byte

adminuser@vm-nw-latency-eval-1:~$ ethr -c 10.0.0.10 -t l -p tcp
[snip]
Using destination: 10.0.0.10, ip: 10.0.0.10, port: 8888
Running latency test: 1000, 1
-----------------------------------------------------------------------------------------
Avg Min 50% 90% 95% 99% 99.9% 99.99% Max
402.582us 168.303us 291.005us 725.212us 980.417us 1.955ms 3.397ms 3.397ms 5.510ms
463.081us 161.703us 324.505us 901.015us 1.153ms 1.939ms 3.079ms 3.079ms 3.184ms
463.531us 171.303us 305.205us 953.014us 1.247ms 2.008ms 2.478ms 2.478ms 2.494ms
Ethr done, duration: 10s.
(参考) Pattern 1
全パターンの結果はGitHubに公開(リンクは資料末を参照)
1行が1000回の
送受信サマリ
10秒間測定
1000回の送受信ごとにサマリする
送受信サイズは1Byte
次ページに
平均を記載
次ページに
平均を記載

AZ3
AZ2
AZ1
Proximity
Placement Group
検証結果
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
有効
Accelerated
Networking
無効
Accelerated
Networking
無効
1
8
7
6
5
4
3
2
Avg: 402us
99%: 1801us
Avg: 1103us
99%: 2467us
Avg: 784us
99%: 847us
Avg: 180us
99%: 609us
Avg: 81us
99%: 170us
Avg: 636us
99%: 1666us
Avg: 810us
99%: 890us
Avg: 1064us
99%: 1847us

検証まとめ
 AZ間レイテンシは平均で1msを、99パーセンタイルでも2msを下回る
ケースが多かった
 Accelerated Networkingの貢献度は大きい
 無効でのAZ内通信は、有効なAZ間よりレイテンシが大きくなることもある
 AZに関わらずAccelerated Networkingの有効化を強く推奨
 従来、コア数が少ない(1～2)VMサイズでは未サポートだった
 現在、それらのサイズであっても1NIC限定で有効化できるものが増えている
(Standard_D2d_v4など)

仮想マシン起動時間
依存要素と測定

仮想マシンのスケジューリング
 VM間のレイテンシを意識するようになると、気になること
 Azureの中には、膨大な数の物理サーバーがある
 VMはどのようなルールやポリシで、物理サーバーへ割り当てられるのだろう
 ユーザーの指定した条件、制約を元に、リソースを割り当てることを一
般的に「スケジューリング」と呼ぶ
 たとえば、Proximity Placement Groupは「同じグループを指定された仮想
マシンを、同じデータセンターに配置する」という制約
 VMファミリ/サイズ、AZ識別子など、ユーザーの指定した条件、制約をフィルタ
とし、割り当て物理サーバーを決定している
 大規模クラウドにおいて、効率良いスケジューリングは重要テーマ

条件を3軸(CPU、メモリ、ディスク容量)に絞ったとしても…
 どこかの軸がいっぱいになった時点で新規VMの割り当て不可となる
 大規模環境においては、膨大な遊休リソースが生まれる
 将来を予測しながら、利用率を最適化したい
 数分後に大量の作成要求があるかもしれない
 クラウドのVMのライフサイクルは短く、多くは短時間で削除される
 NP困難な組み合わせ最適化問題
 Azureでは機械学習を活用
 Microsoft Researchには、このテーマ専門の
研究チームがある(Resource Central) VM2
V
M
1
Memory
CPU
Disk
スカスカやないか
メモリたっぷり
ほしいのねん

機械学習は、仮想マシン提供待ち時間の短縮にも貢献
 機械学習を活かしたPre-
Provisioning
 ユーザーが仮想マシン作成を指
示する前に、予測して準備して
おく
[Link] Intelligent Virtual Machine
Provisioning in Cloud Computing -
Microsoft Research
ユーザーか
らの要求
スケジュー
リング
VM
作成
ユーザーへ
の通知
ユーザーか
らの要求
準備済み
VMを割り当て
ユーザーへ
の通知
従来
Pre-
Provisioning

Azure仮想マシン主な構成要素
ローカルディスク
物理サーバー
NIC
仮想マシン
OS/システム
ディスク
データディスク
イメージ
ギャラリー
CPU メモリ
コピー
(Ephemeral Disk利用時)
コピー

起動時間への影響が想定される要素
(スケジューリング後)
ローカルディスク
物理サーバー
NIC
仮想マシン
OS/システム
ディスク
データディスク
イメージ
ギャラリー
CPU メモリ
コピー
(Ephemeral Disk利用時)
コピー
数と性能量と性能
量と性能
(起動時に激しいI/Oを伴うセット
アップを行う場合など)
量と性能
(起動時に激しいI/Oを伴うセット
アップを行う場合など)
Azure提供イメージ
/カスタムイメージ
Accelerated
Networking
有効/無効

検証してみましょう
概要 VMサイズ OS Disk OS Disk
Size(GB)
Accel. Net. カスタム
イメージ
0 ベース Standard_D2ds_v4 Premium_LRS 30 〇
1 旧世代 Standard_DS2_v2 Premium_LRS 30 〇
2 Accel. Net. 無効 Standard_D2ds_v4 Premium_LRS 30
3 Ephemeral OS Disk Standard_D2ds_v4 Ephemeral 30 〇
4 低速OS Disk(HDD) Standard_D2ds_v4 Standard_LRS 30 〇
5 カスタムイメージ Standard_D2ds_v4 Premium_LRS 30 〇〇
6 CPU/Memory 増 Standard_D8ds_v4 Premium_LRS 30 〇
7 CPU/Memory/Diskサイズ増 Standard_D8ds_v4 Premium_LRS 100 〇
• OSイメージはCanonical:UbuntuServer:18.04-LTS
• カスタムイメージはCanonical:UbuntuServer:18.04-LTSを再イメージ化し、共有イメージギャラリーに配置

検証結果
概要シリーズ1 シリーズ2 シリーズ3
Min Max Avg Min Max Avg Min Max Avg
0 ベース 48 53 50 48 78 52 48 51 49
1 旧世代 47 51 49 48 49 49 48 78 52
2 Accel. Net. 無効 47 50 49 48 49 49 48 51 49
3 Ephemeral OS Disk 29 81 38 28 109 58 29 37 33
4 低速OS Disk(HDD) 48 206 73 48 93 59 47 349 80
5 カスタムイメージ 48 52 50 47 49 49 48 53 49
6 CPU/Memory 増 47 79 52 48 51 49 48 51 49
7 CPU/Memory/Diskサイズ増 47 63 51 48 83 55 48 78 53
• TerraformでVMを作成し、Provisionerでssh(echoコマンド実行)できるまでの経過時間(秒)
• 時系列で傾向を把握するため、1シリーズあたり連続10回試行した
• 各試行後は10分待機
• 作成間隔が長い場合の傾向も把握するため、各シリーズの実行日は分けた

検証結果 (シリーズ1)
0
50
100
150
200
250
1 2 3 4 5 6 7 8 9 10
azurerm_linux_virtual_machine.vm_startup_time_eval["0"] azurerm_linux_virtual_machine.vm_startup_time_eval["1"] azurerm_linux_virtual_machine.vm_startup_time_eval["2"]
azurerm_linux_virtual_machine.vm_startup_time_eval["6"] azurerm_linux_virtual_machine.vm_startup_time_eval["7"]
OS Disk: Standard(HDD)
OS Disk:
Ephemeral

0
20
40
60
80
100
120
1 2 3 4 5 6 7 8 9 10
学習モデルの更新など
イベントが発生した可能性あり

0
50
100
150
200
250
300
350
400
1 2 3 4 5 6 7 8 9 10
OS Disk: Standard(HDD)
OS Disk:
Ephemeral

検証まとめ
 構成に関わらず、概ね50秒前後で利用可能となった
 Pre-Provisioningが効いている
 OS Diskの配置、タイプは影響の大きな要素
 Ephemeral: たまに外れるが、さらなる時間短縮へ寄与する
 Standard(HDD): 外れた時の影響が大きい
 揮発性を受け入れられるのであれば、Ephemeralは有力な選択肢
 起動の速さは回復力の高さでもある
 当然ながら起動後の性能も高い

Mark Russinovich, “Inside Azure Datacenter Architecture”, Microsoft Ignite 2020
(参考) 物理サーバーごとのリソース上限を超えるために
構成要素ごとにプールを作り、動的に組み合わせられるよう、開発を進めている

疑似障害テストと
観測手法の現在

可能な限り把握、コントロールするために
 「細かいことは気にしなくていい。クラウドがやってくれる」
 とは言え、使い始めると
 「知りたい」「測定したい」「制御したい」「試験したい」
 当然のニーズ
 しかも今回、レイテンシや仮想マシンスケジューリングなどを知り、
Azureの中身に関心を持ってしまいましたね
 それに応える機能やサービス、手法が増えてきている
 疑似障害注入
 可観測性向上

Azure Chaos Studio
(当プレゼンテーション収録時点では)
プライベートプレビュー中、しばしお待ちを

シンプルで楽な疑似障害注入手法
 アプリが動く環境の疑似障害注入は難しくない
 VM、アプリやプロセス、サービスインスタンスはユーザーが
コントロールできる
 止める、消す、暴走させる、etc
 難しいのは、ネットワークの先にある依存リソースや
サービスの、一時的な無応答や遅延の再現
 アプリに仕込んだタイムアウト検出、リトライロジックのテ
ストをどうするか？
 VNet環境下でよく使われる手法は、NSGルール
による遮断
VNet Injected/Routed
Resources
Dependencies
(Resources/Services)
NSG
Rules

NSGによる遮断の注意点
Resources
Dependencies
Resources
Dependencies
NSG
Rules
Resources
Dependencies
NSG
Rules
Resources
Dependencies
NSG
Rules
TCPコネクションを作成する前にNSGルールを設定
NSGルールを設定した時点ですでにTCPコネクションが存在
新規コネクション作成を拒否
既存コネクションは遮断できない

解決策: Linux Traffic Control(TC)
 アプリが動く環境上で送出パケットをコン
トロールする
 Linux TCが代表例
 多くのLinux/Docker/Kubernetes向けカオ
スエンジニアリングツールで採用されている
 Linux VMやAKSなど管理者権限を持てる
サービスでの有力な選択肢
 qdiscを利用し、カーネル内で遅延やパケット
ロスを注入
Socket
Network Device
Driver
Queueing
Discipline(qdisc)
Protocol
(TCP, UDP, etc)
Network Device
userspace
kernel
device
App

runTCPLatencyTest
func runTCPLatencyTest(test *ethrTest, g time.Duration, toStop chan int) {
ui.printMsg("Running latency test: %v, %v", test.clientParam.RttCount,
test.clientParam.BufferSize)
conn, err := ethrDial(TCP, test.dialAddr)
if err != nil {
ui.printErr("Error dialing the latency connection: %v", err)
return
}
[snip]
新規コネクション作成に失敗すると、
このメッセージが出力される
では、EthrのTCPレイテンシテストを活用し、NSGとTCによる遮断時の挙動
を確認してみましょう

NSG:コネクション確立前
```
Terraformで下記パラメータのNSG Ruleを注入しておく
nsg_rule_injection = {
name = "ethr"
priority = 200
direction = "Outbound"
access = "Deny"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "8888"
source_address_prefix = "*"
destination_address_prefix = "*"
}
```
$ ethr -c 10.0.0.4 -t l -p tcp -d 0
[snip]
Error dialing the latency connection: dial tcp4 :0->10.0.0.4:8888: i/o timeout
^CEthr done, received interrupt signal.
Ethrサーバー(ポート番号:8888)向け
通信を拒否する
コネクション作成が失敗する

NSG:コネクション確立後
$ ethr -c 10.0.0.4 -t l -p tcp -d 0
[snip]
-----------------------------------------------------------------------------------------
Avg Min 50% 90% 95% 99% 99.9% 99.99% Max
419.529us 398.305us 406.105us 463.006us 467.707us 474.106us 512.707us 512.707us 558.008us
[snip]
テスト開始、コネクション確
立後に別セッションから
NSG Ruleを注入
止まらない

TC:コネクション確立前
$ sudo tc qdisc add dev eth0 root handle 1: prio
$ sudo tc filter add dev eth0 protocol ip parent 1: prio 2 u32 match ip dst 0.0.0.0/0 flowid 1:2
$ sudo tc qdisc add dev eth0 parent 1:1 handle 10: netem loss 100%
$ sudo tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 8888 0xffff flowid 1:1
$ ethr -c 10.0.0.4 -t l -p tcp -d 0
[snip]
Error dialing the latency connection: dial tcp4 :0->10.0.0.4:8888: i/o timeout
^CEthr done, received interrupt signal.
Ethrサーバー(ポート番号:8888)向けの
パケットを100%破棄する
コネクション作成が失敗する

TC:コネクション確立後
$ ethr -c 10.0.0.4 -t l -p tcp -d 0
[snip]
-----------------------------------------------------------------------------------------
Avg Min 50% 90% 95% 99% 99.9% 99.99% Max
412.555us 396.803us 405.603us 420.303us 465.003us 471.403us 693.505us 693.505us 1.550ms
408.641us 397.203us 401.702us 409.302us 418.603us 463.804us 1.544ms 1.544ms 2.311ms
416.548us 399.302us 406.103us 462.503us 470.203us 476.503us 539.104us 539.104us 1.138ms
[stopping…]
Ethr done, connection terminated.
テスト開始、コネクション確
立後に別セッションからtc
qdisc、filterでパケットを
100%破棄
止まったまま、数分後にコネ
クションが終了する
TCを使えば、コネクション確立後にも疑似的な応答不可状態を注入できた
ただし、何が起こっているかが明確には分からない TCPなので再送しているはずだが…
(パケットキャプチャの海から拾い上げる？つらい)

eBPF (extended Berkeley Packet Filter)
[Link] What is eBPF? An Introduction and Deep Dive into the eBPF Technology
• パケットフィルタとして歴史あるBPF(Berkeley Packet Filter)を拡張した仕組み
• ネットワークに限らず、様々なシステムイベントをカーネル空間で効率よく取得可能
• ユースケース: 可観測性向上、パケット転送、DDoSフィルタ、etc
• eBPF Foundation: 2021/8月に設立(Microsoft, Facebook, Google, Isovalent, Netflix)

tcpretrans
$ sudo /usr/share/bcc/tools/tcpretrans
Tracing retransmits ... Hit Ctrl-C to end
TIME PID IP LADDR:LPORT T> RADDR:RPORT STATE
08:41:19 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:41:19 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:41:19 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:41:20 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:41:22 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:41:26 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:41:32 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:41:46 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:42:14 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
08:43:10 0 4 10.0.0.5:60035 R> 10.0.0.4:8888 ESTABLISHED
コネクション確立後にパケットが破
棄されており、それによるTCP再送
が確認できる
eBPFのツールキットであるBPF Compiler Collection (BCC)に含まれるTCP再送チェックツール
(tcpretrans)で容易に確認できる
アプリのタイムアウト、リトライロジック検証、裏付けに極めて有用
これはeBPFのひとつの活用例に過ぎず、他にも多様なユースケースがある

検証まとめ
 NSGやTCなど、ネットワーク要素での障害注入は有用
 手間や権限、できることのトレードオフで検討
 OSカーネルレベルでの技術動向は意識しておくと楽しい
 eBPF
 クラウドサービスの機能として組み込まれる動向
 管理者権限の取れないサービスでは…
 Azure Chaos Studio ご期待ください
 公開後もフィードバック、ご要望お待ちしております
(ユーザーから可視、コントロールできる範囲は、ニーズによって決まります)

全検証環境構築、検証コードとデータ
ToruMakabe/ms-japan-digital-days-2021 (github.com)

より深掘りしたい皆様へ - 関連論文
 Accelerated Networking
 Azure Accelerated Networking: SmartNICs in the Public Cloud
 Inter-AZ/Datacenter, Regional Networking
 Beyond the mega-data center: networking multi-data center regions
 Scheduling, Resource Central
 Resource Central: Understanding and Predicting Workloads for Improved
Resource Management in Large Cloud Platforms
 Pre-Provisioning
 Intelligent Virtual Machine Provisioning in Cloud Computing
 Correlation-Aware Heuristic Search for Intelligent Virtual Machine Provisioning
in Cloud Systems

M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]

More Related Content

What's hot

Similar to M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]

More from 日本マイクロソフト株式会社

M08_あなたの知らない Azure インフラの世界 [Microsoft Japan Digital Days]