「ITエンジニアリングの本質」を考える
•
25 likes•15,317 views
JTF2017 基調講演での発表予定資料です。 https://2017.techfesta.jp/
Report
Share
「ITエンジニアリングの本質」を考える
- 1. JTF2017 基調講演 「ITエンジニアリングの本質」を考える 2017/08/27 Google Cloud, Cloud Solutions Architect 中井 悦司 / Etsuji Nakai
- 2. Etsuji Nakai Cloud Solutions Architect at Google Twitter @enakai00 $ who am i https://www.dlmarket.jp/products/detail/501016 （同人誌）
- 5. 「ITエンジニアリングの本質」とは？ When I was younger and first started thinking about my future, I decided to either become a professor or start a company. I felt that either option would give me a lot of autonomy --- the freedom to think from first principle and real-world physics rather than having to accept the prevailing "wisdom." 「世に蔓延する常識を受け入れるのではな く、現実世界を動かす第一原理にもとづい て思考する自由」
- 6. Datacenter as a computer!
- 7. 1Pbps のデータセンタースイッチ！ 素朴な疑問 ● どういう意味において1Pbpsなの？ ● 何が目的で開発したの？ ● 開発中に苦労した事は？ ● などなど・・・ 本日のお題：Jupiter Network
- 8. 元ネタはこちら https://research.google.com/pubs/pub43837.html https://www.youtube.com/watch?v=DfaPcbofT2c
- 9. ● データセンターネットワーク ○ 複数のサーバークラスターを均一な帯域で接続する高速ネットワーク ○ ソフトウェア制御の Clos トポロジーによるロードバランシング ● B2 ネットワーク ○ インターネットと相互接続するためのグローバルネットワーク ● B4 ネットワーク ○ データセンター間を相互接続するグローバルな内部ネットワーク ○ OpenFlow を用いたトラフィックエンジニアリングにより、パケットの優先順位に 応じてパケットの経路と帯域を自動制御 Google ネットワークの全体像 今日はここの話！
- 10. ● Clos トポロジー：メッシュ型の多重経路で接続された L2 ネットワーク ● 複数経路をロードバランスすることで、特定のリンクがボトルネックになることを回避 ● ロードバランスのための経路情報をソフトウェアで自動制御 データセンターネットワークの特徴
- 11. データセンター ネットワーキング Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network (Sigcomm 2015 での論文)
- 12. ● 複数クラスターを構成する数万台のサーバー ● 12 年前は帯域が分離されてボトルネックが発生 ○ アプリ側で通信の局所性の考慮が必要 ○ CPU / メモリーの有効活用が困難 ○ スケーラビリティーに影響 データセンター ネットワーキングの大きな課題 Datacenter 1 Gbps / machine within rack 100 Mbps / machine within small cluster 1 Mbps / machine within datacenter
- 13. ● 技術的挑戦 : すべてのサーバ一で帯域を均一化 ○ ジョブ スケジューリングの簡素化 ○ アプリ配置の最適化で CPU／メモリーを有効活用 ○ スケーラビリティの向上 データセンター ネットワーキングの大きな課題 X Gbps / machine flat bandwidth Datacenter
- 14. ● マーチャント シリコン : 汎用部品、 コモディティ価格、容易に入手可能 ● Clos トポロジー :リンク数の少ない チップを用いながら、レイヤーを追 加することで、自由にスケーリング ● 集中制御 / 管理 設計上の基本方針
- 15. Google データセンターを支えてきた 5 つの世代の ネットワーク スイッチ Edge Aggregation Block 1 Edge Aggregation Block 2 Edge Aggregation Block N Spine Block 1 Spine Block 2 Spine Block 3 Spine Block 4 Spine Block M Server racks with ToR switches
- 16. 課題 ● 大規模でのオペレーション ● 拡張性の高いルーティング / 大規 模マルチパスによるルーティング ● 外部ベンダーとの相互運用性 Google のアプローチ ● 集中的な構成と管理 ● 分散環境を論理的に集中管理 ● 境界ルータでの BGP スタックの統合 データセンタースイッチの特徴 : 制御と管理
- 17. ソフトウェアによる経路制御 : Firepath Firepath Master Firepath Client 1 Firepath Client 2 Firepath Client N Interface state update Link State database FMRP protocol コントロール プレーン FMRP
- 18. ソフトウェアによる経路制御 : Firepath Firepath Master Firepath Client 1 Firepath Client 2 Firepath Client N (Border router) Firepath Client, BGP 1 (Border router) Firepath Client, BGP M External BGP peers Interface state update Link State database FMRP protocol eBGP protocol (inband) FMRP コントロール プレーン
- 20. 課題 ● チップ上のバッファ容量不足 ● 安価 / 信頼性の低い部品の可用性 Google のアプローチ ● スイッチ（ECN など）とホスト （DCTCP など）のチューニング ● ソフトウェアによる冗長性担保 ● 必要なものだけを実装 パフォーマンスと信頼性の実現
- 21. Saturn Firehose 1.0 1T 10T 100T 1000T ‘04 ‘05 ‘06 ‘08 ‘09 ‘12 Bisection B/w Year Watchtower Firehose 1.1 4 Post Jupiter
- 22. Saturn Firehose 1.0 1T 10T 100T 1000T ‘04 ‘05 ‘06 ‘08 ‘09 ‘12 Bisection B/w Year Watchtower 4 Post Jupiter + 2012年 データセンター内で 1.3Pbps Firehose 1.1
- 23. Google データセンターにおけるネットワーク スイッチの変遷 Firehose 1.1 (2006) Watchtower (2008) Saturn (2009) Jupiter (2012)
- 24. データセンター内トラフィックの増加 Traffic generated by servers in our datacenters Aggregatetraffic 50x 1x Jul ‘08 Jun ‘09 May ‘10 Apr ‘11 Mar ‘12 Feb ‘13 Dec ‘13 Nov ‘14 Time
- 26. 第１世代：Firehose 1.0 ● サーバー筐体に PCI 経由で制御するスイッチングチップボードを搭載 ○ Linux の起動時間と HW の信頼性に課題 ○ 本番採用は見送り
- 27. 第２世代：Firehose 1.1 ● ネットワークチップを収める専用筐体（ラインカード）を設計 ● ６枚のラインカードを１台のシャーシに搭載 ○ シャーシは、スイッチ間を内部接続するバックプレーンを持たない ○ ポート間接続には CX4（10G対応のメタルケーブル）を使用
- 28. 第２世代：Firehose 1.1 ● その結果 ○ ケーブル地獄・・・ ○ CX4 ポートをファイバーに 変換する専用コネクタを 発注・・・
- 29. 第２世代：Firehose 1.1 ● はじめての本番投入！ ○ 安全のため既存のルーターシステムと並列に接続 ○ 問題発生時は、既存のルーターにフォールバック
- 31. 第４世代：Saturn ● Watchtower の性能向上版 ● チップあたりのポート数増加 ● ToR にも 10Gbps ポートを採用
- 32. 第５世代：Jupiter ● バックプレーンを持たない構造を再び採用 ● Centauri モジュールを組み合わせるブロック方式を採用 ● 40Gbps / 4 x 10Gbps 切り 替え型チップを採用
- 33. 第５世代：Jupiter ● Centauri x 1：ToR スイッチ ● Centauri x 4：Middle Block ● Middle Block x 8 : Aggregation Block ○ ラック 2 本に 1 つの Aggregation Block がちょうど収まる構成 ● Middle Block x 6 : Spine Block ● Spine Block x 256 + Aggregation Block x 64 の最大構成で総帯域 1.3Pbps を達成 Middle Block
- 34. まとめ
- 36. （補足）分散ストレージを支える仕組み ● すべての計算ノードがすべてのストレージノードに同じ帯域で接続可能 計算ノード ストレージ ノード ストレージ ノード ストレージ ノード 分散ストレージ ノンブロッキング・ネットワーク 計算ノード 計算ノード 計算ノード ストレージ ノード ストレージ ノード ストレージ ノード 分散ストレージ ノンブロッキング・ネットワーク 計算ノード追加
- 37. Google のインフラを一般開放した Google Cloud Platform VIRTUAL NETWORK LOAD BALANCING CDN DNS INTERCONNECT Management Compute Storage Networking Data Machine Learning STACKDRIVER IDENTITY AND ACCESS MANAGEMENT CLOUD MLE SPEECH API VISION API TRANSLATE API NATURAL LANGUAGE API
- 38. 公開論文から読み解くインフラ技術の「思想」 ● 「謎技術」の実体は、徹底的な合理主義 ● 「技術的制約」に対する恐ろしいほどの洞察力 ○ この制約を受けいれることが何が可能になるのか？ ○ この制約を打破することで何が可能になるのか？ http://www.school.ctc-g.co.jp/columns/nakai2/
- 39. 参考文献 ● Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network (Sigcomm 2015) ● B4: Experience with a Globally-Deployed Software Defined WAN (Sigcomm 2013) ● BwE: Flexible, Hierarchical Bandwidth Allocation for WAN Distributed Computing (Sigcomm 2015) ● Evolve or Die: High-Availability Design Principles Drawn from Google's Network Infrastructure (Sigcomm 2016)
- 40. Thank You.