Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

インフラ野郎AzureチームProX

1,726 views

Published on

Microsoft Open Tech Night #1

Published in: Technology
  • Be the first to comment

インフラ野郎AzureチームProX

  1. 1. インフラ野郎 Azureチーム Pro X 真壁 徹 日本マイクロソフト株式会社 2019/11/26 インフラ技術好きな あなたのハートをジャッカル Microsoft Open Tech Night #1
  2. 2. 自己紹介 apiVersion: selfIntroduction/v1 name: “真壁 徹(まかべ とおる)” company: name: “日本マイクロソフト株式会社” role: “クラウド ソリューションアーキテクト” career: - name: “大和総研” - name: ”HP Enterprise” cert : “CNCF Certified Kubernetes Admin.”
  3. 3. 「できること」だけじゃなく 「生まれた背景や目的」を知ることで テクノロジーは輝きを増す
  4. 4. • これから紹介する技術はリージョンによっ て導入時期が異なります • 将来、予告なしに他技術に置き換わる可能 性があります • 海底データセンターは実験段階です • Ignite 2019で使われたスライドはそのまま 転載しています (スライド下部にリンク)
  5. 5. 本日のメニュー 海底データセンター計画 “Natick” 近況 マルチテナントコンテナー基盤 “Atlas” ニーズや使い方の変化にあわせた、足回りの改善
  6. 6. Igniteの発表 多すぎ 今夜は わたしの好みだけ リンク
  7. 7. 海底データセンター計画 “Natick” 近況
  8. 8. Project Natick
  9. 9. Project Natick Phase 2 & beyond • 世界人口の50%以上は沿岸に住 んでいる • ならばその近くにデータを置い たら?海底は冷却にもよさげ • 2015年にPhase 1は完了し、環境 への影響や運用の検証へ移行 • 潜水艦技術を活かしたNatick 2 筒には864台のサーバーを搭載 (27.6Petabytes Disks) https://natick.research.microsoft.com/
  10. 10. Subsea cable connection Natick 2 sized PV Ballast tanks for transport (floating) and deployment (sinking) [BRK3097] Inside Azure datacenter architecture
  11. 11. [BRK3097] Inside Azure datacenter architecture
  12. 12. (海底DCとは別に実用化が進む) Liquid Cooling Micro- channel Cold Plates One phase immersion Air Cooled Olympus Two phase immersion [BRK3097] Inside Azure datacenter architecture
  13. 13. マルチテナントコンテナー基盤 “Atlas”
  14. 14. コンテナー需要の高まり Azure Container Instancesなどコンテナーそのものを提供するサービスだけでなく Azure Functionsなどサーバーレスサービスの基盤としてもコンテナーは利用されている 仮想マシンと同等の分離度で提供したい セキュリティのニーズにより、コンテナーがOSカーネルを共有しないようにしたい これまで仮想マシンレベル分離度を明言したサービスでは、仮想マシン群を事前に作って割当 仮想マシンの分離度とコンテナーのリソース効率、短時間配備の両立 コンテナーに最適化した軽量仮想マシン基盤 Hyper-V コンテナーやLCOW、Service Fabricなど 要素技術を開発し、機は熟した マルチテナントコンテナー基盤の必要性
  15. 15. つまりこういう基盤を作りたかった Kubernetesをはじめとする OSSエコシステム Microsoft エコシステム 将来のニーズ コンテナー サーバーレス コンテナー サーバーレス コンテナー共通基盤 • 仮想マシンレベルで分離しセキュリティーレベルを向上 • サービス間で設備を共有しコストを抑制 • 低レイヤーでの技術イニシアチブを確保
  16. 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. 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. 18. ニーズや使い方の変化にあわせた 足回りの改善
  19. 19. ユーザーと使い方の変化 Microsoftエコシステム < OSSエコシステム な大規模ユーザーが増加 大規模、短時間で急激にVMを増減させたい というニーズ コンテナー/マイクロサービス化、認証、リトライなどでアウトバウンド通信量が増加 サービスを提供し続けながら、足回りであるストレージやネットワークを進化させる必要がある ハードウェア的進化 より性能の高いハードウェア (SCUTI-O SSD for Azureなど) サービス的進化 ストレージやディスクの新サービスや新たな提供方式 Azure インフラストラクチャー ニーズの変化 “足に来る”
  20. 20. ニーズや使い方の変化 たとえば: Adobeさん
  21. 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. 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. 23. では今、インフラのどこを強化すべきか?
  24. 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. 25. 頭と身体(サーバー)は強い 焦点は足回り(ストレージ、ネットワーク)
  26. 26. ストレージに関する 代表的な課題と取り組み (ブロックディスク性能)
  27. 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. 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. 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. 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. 31. しかし 新しいハードウェアは展開に時間がかかる サービス提供方式でも改善できないか?
  32. 32. その原因、OSディスクのサイズかも… Premium/Standard Diskの性能はサイズで決まる (Ultra Diskは別途IOPS指定可) VMを多数、一気に作成/追加/削除する場合に時間がかかる (Kubernetesクラスターなど) コンテナーを詰め込んだVM上のサービスで遅延が大きい、不安定 たとえばAKSではOSディスク性能の 飽和がクラスターの安定稼働に影響 するケースが多い (緩和策としてOSディスクの既定サ イズを30GBから100GBに変更) https://github.com/Azure/AKS/issues/1322
  33. 33. IOPS上限の高いディスクを使えば解決する、が 性能のためだけに過剰なサイズのディスクを使いたくない →ピークだけ一時的にIOPS上限が緩和されればいいのでは?
  34. 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. 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. 36. ネットワークに関する 代表的な課題と取り組み (アウトバウンド通信爆発)
  37. 37. アウトバウンド通信の増加 コンテナー/マイクロサービス化、外部/Key Vault認証、マネージドデータストア、リトライ、etc コネクションプーリングや静的クライアントの利用など、アプリで打てる手はあるが… Azure Basic Load Balancer “Ananta”ベース SNAT制御の転換期 Azure Basic LB はPre-warmingが不要、インバウンド処理能力の高さなどでAzureを支えてきた また、明示的にユーザーが指定/構築しなくても、アウトバウンド向けSNATが提供されて幸せだった しかしアウトバウンド接続数の多いシステムで、SNATポート枯渇による通信断が見られるように これはBasic LBを使わずSNATのみの場合でも起こる課題 (内部機能は共通なため) SNATポートの枯渇
  38. 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. 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. 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. 41. 使い方の変化にともない Azureの足回りもステップアップの時期です 新サービスやガイダンスは要チェック
  42. 42. 知りたいと 思う気持ちを 大切に
  43. 43. マイ Microsoft Learn コレクション インフラ野郎への道 – 心得編 https://docs.microsoft.com/ja-jp/users/tomakabe/collections/rqqps18k0eden
  44. 44. © Copyright Microsoft Corporation. All rights reserved.

×