細か過ぎて伝わらないかもしれないAzureインフラ話で領域展開

1. インフラ廻戦 品川事変 前夜編
細か過ぎて伝わらないかもしれない話で領域展開
真壁 徹
日本マイクロソフト株式会社
2021/06/28
Azure Infra Day 前夜祭 - MSTechNight #13

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

3. お伝えしたいこと
ごぶさたの理由
最近の面白ネタ
最近の関心事

4. ごぶさたの理由
Azureインフラトーク夜会は 2019/11のMS Tech Night以来です

5. 働きながら大学院で研究しておりました
おかげさまで 修士号をいただきました
国立 北陸先端科学技術大学院大学(JAIST)
情報科学系 セキュリティ・ネットワーク領域
領 域 展 開
さあ帳を下すぞ という感じであります
セキュリティ・ネットワーク領域
JAIST 北陸先端科学技術大学院大学

6. 最近の面白ネタ

7. 大学院の研究で感じたこと
わたしが思いつくような研究ネタは、
だいたい誰かが先にやっている
特に Microsoft Research
Search - Microsoft Research
Research Areas: Systems and networking

8. 論文はいいぞ
審美眼を磨く
そこにサービス仕様やTipsは書いてありません
今日明日の仕事に直接役立たないかもしれません
ですが、先端の技術的課題(例: クラウドの中で起こっていること)を
客観的なデータ、過去からの知の積み上げとともに知ることは
仕事での技術選定、設計や実装における判断の支えになります
※中身を想像しながらニヤニヤするだけでも 楽しい

9. Microsoft Research/Azure関連
論文から 3つほどご紹介

10. オーバークロック？ ガッと冷やせばいいじゃない
Cost-Efficient Overclocking in Immersion-Cooled Datacenters
液浸冷却 その先にある取り組み
オーバークロックで性能上限と集
約率を上げたい
オーバークロックのトレードオフ
(消費電力、安定性、寿命)を液浸冷
却で解決できるのでは
オーバークロックの効果がある
ワークロードを見極めたい
液浸

11. ワークロード別の効果(性能)
ワークロードによって得られる効果と伸び率、負の影響(消費電力)に差がある
CPU
GPU(機械学習)

12. データセンタ間ってどう繋いでるの？課題は？
Beyond the mega-data center: networking multi-data center regions
Azureリージョンは複数の可用性ゾーン、データセンタで構成
データセンタ間をいかに接続するか？
ハブでつなぐ？メッシュにする？マルチハブ？
様々な課題、視点と解決のための設計と技術(光スイッチングなど)
この論文を読んだ後、パケットの気持ちになってAzureを触るとと
ても楽しい

13. どんなスイッチが使われ、どんな壊れ方をしたか
Surviving switch failures in cloud datacenters
マイクロソフトが保有する180,000
台超のスイッチで調査
3か月の調査期間で4,681台のス
イッチが故障 (約2%)
原因はベンダーによって様々
同じハードで比較すると、ベンダ
製ネットワークOSよりSONiCの故
障が少ない
Microsoft Does The Math On Azure Datacenter
Switch Failures (nextplatform.com)

14. 他にもグッとくる論文は多いのですが
時間の都合により 今日はここまで
またやりましょう
いい論文を見つけたら教えてください

15. 最近の関心事

16. インフラのリファクタリング
言うは易し 行うは難し
構築中/後に、どんどん新しいインフラ機能やサービスが提供される
コスト削減、運用簡素化、リスク軽減、セキュリティレベル向上、etc
しかし能動的に採用、リファクタリングの必要があるものも多い
リリース後も継続開発、投資するプロジェクトでは、取り組みやすい
そうでないプロジェクトは… どうするか？
うまいやり方を、もっと議論、共有したい
(やり方がイメージできれば、計画、予算が立てやすくなる)

17. クラウド導入フレームワークでの言及
ランディングゾーンのリファクター
Infrastructure as Codeによって、
環境構築作業は楽に、再現性高く
なった
そのコードをいかにリファクタリ
ングするか
組織視点、実施タイミングと学習
曲線に触れており、しみじみと参
考になる

18. 最重要課題は おそらくテスト
アプリ開発におけるTDDのようなことを、インフラでも可能か
動いているインフラをリファクタ
リングするなら、既存環境への影
響を検証しなければならない
多くの現場で、インフラ構築後の
テストは未だ手作業で高コスト
テストを容易に実行できなければ、
リファクタリングの敷居は高い

19. ソフトウェアのテストピラミッド
ユニットテストの重要性
Small
(Unit)
Medium
(Integration/Service)
Large
(UI/E2E)
コードを変更したら、他の要素とは独立
して、素早くテストをする
内部の質に関するフィードバックを素早
く得る
変更部だけでなく既存コードへの影響を
確認する
手法やツールは多く存在(それを標準機能
として持つプログラミング言語もある)
か
か
る
手
間
や
時
間
ピラミッドを支える
ユニットテストをしっかりやろう！

20. インフラのテストピラミッド？
ユニットテストが悩ましい
Small
(Unit)
Medium
(Integration/Service)
Large
(System/E2E)
Network Storage
VM
Managed
Services
例えば VM設定の
変更テストに
必要なリソースは…
• テスト対象の他に依存するリソースが必要
• 多くのリソースはモックやスタブで代替できない
• それぞれのリソース作成に時間がかかる
• 常時テスト環境を動かしておく手はあるが、コスト
とのトレードオフ
• つまり、素早く頻繁なユニットテストが難しい
• 結果や影響が明白なケースでも都度ユニットテスト
すべき？(同サブネットでのIPアドレス変更やディス
クサイズ増減など)

21. インフラのテストダイヤモンド
Small
(Offline)
Medium
(Stack)
Large
(System/E2E)
Infrastructure as Code, 2nd Edition – O’Reilly
コードの文法検証など、リソース作成
を伴わず、素早く頻繁に実施
(例: terraform validate/plan)
本番環境監視のサブセットを用意し、
テストを効率化する
外形監視、ヘルスチェックエンドポイ
ントの有無が実現性に大きく影響
(参照)コンセプト
テスト可能な依存リソースをまとめた「ス
タック」単位でテストを実施
テスト、再現しやすいスタックを作ること
で、迅速な復旧や容易な横展開など、本番
環境にも好影響がある

22. スイスチーズ テスティングモデル
それぞれのテストには漏れがあるかもしれないが 多層でリスクを検知する
Infrastructure as Code, 2nd Edition – O’Reilly
(参照)コンセプト
Offline
Tests
Stack
Tests
System
Tests
Alerts
リ
ス
ク

23. ツールは徐々に充実
Azure のランディング ゾーン用のテスト駆動開発
テストの苦労はツールだけでは解
決しないが、大きく影響
特にPolicyとResource Graphは「リ
ソースが望む状態に作られた/設定
された」かを検証(verification)する
ために強力なツール
でも、Policy自体のテストが面倒
だったり、Resource Graphクエリ
を手打ちしていたり、が現状

24. verificationを支えるツール、やり口
ここを整備しないと テストは楽にならない
Terratest
Terraform使いでGoが書ける場合 有力な選択肢
未対応リソースがあった場合の対応方針は要検討
(自ら開発するか、プルリクがタイムリーにマージされやすいか、など)
InSpec
Rubyで書かれている
Terratestと同様、未対応リソースがあった場合の対応方針は要検討
Resource Graph APIを叩くツールを自作
AzureのAPIを叩くアプリを作れるなら、それほど難しくない
試しに作ってみた: ToruMakabe/azverify (github.com)
(JSONで、あるべきリソースの状態を定義し、実際のリソースと照合する)

25. ぼちぼち世の中も落ち着きそうなので
ぜひ議論、共有していきましょう

26. まとめ

27. お伝えしたかったこと
ごぶさたしておりました 修行しておりました
論文はいいぞ
テストは重要 今後も議論、共有したいですね

28. © Copyright Microsoft Corporation. All rights reserved.