インフラ廻戦 品川事変 前夜編
- 1. インフラ廻戦 品川事変 前夜編 細か過ぎて伝わらないかもしれない話で領域展開 真壁 徹 日本マイクロソフト株式会社 2021/06/28 Azure Infra Day 前夜祭 - MSTechNight #13
- 2. 自己紹介 apiVersion: selfIntroduction/v1 name: “真壁 徹(まかべ とおる)” company: name: “日本マイクロソフト株式会社” role: “クラウド ソリューションアーキテクト”
- 4. ごぶさたの理由 Azureインフラトーク夜会は 2019/11のMS Tech Night以来です
- 5. 働きながら大学院で研究しておりました おかげさまで 修士号をいただきました 国立 北陸先端科学技術大学院大学(JAIST) 情報科学系 セキュリティ・ネットワーク領域 領 域 展 開 さあ帳を下すぞ という感じであります セキュリティ・ネットワーク領域 JAIST 北陸先端科学技術大学院大学
- 6. 最近の面白ネタ
- 7. 大学院の研究で感じたこと わたしが思いつくような研究ネタは、 だいたい誰かが先にやっている 特に Microsoft Research Search - Microsoft Research Research Areas: Systems and networking
- 10. オーバークロック？ ガッと冷やせばいいじゃない Cost-Efficient Overclocking in Immersion-Cooled Datacenters 液浸冷却 その先にある取り組み オーバークロックで性能上限と集 約率を上げたい オーバークロックのトレードオフ (消費電力、安定性、寿命)を液浸冷 却で解決できるのでは オーバークロックの効果がある ワークロードを見極めたい 液浸
- 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)
- 15. 最近の関心事
- 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で、あるべきリソースの状態を定義し、実際のリソースと照合する)
- 26. まとめ
- 28. © Copyright Microsoft Corporation. All rights reserved.