Azureのインフラを支える技術(概要編)

  • 18
    Like
  • 0
    Comment

やや遅くなってしまったが、年末に参加した Azure のインフラの勉強会のまとめ。

事の発端

2016/12/26にNHNテコラスさんにて開催された、「インフラ野郎Azureチーム Night」での Microsoft 真壁さんの講演が、あまりにも面白い上に広いトピックを扱っていて、一部消化不良になった人がおり、2回戦よろしく…というような声があがっていた。(はいそこ、m9 はナシでw)

そういうわけで、興味のあるところを中心にざっくり要点をまとめておこうと思ったのが発端。なお、タイトルに「概要編」とあるように、この記事は当日のメモをもとにしたざっくりとしたまとめ+リンク集である。特に興味のあるトピックについては、論文も参照して深堀りして別途記事にする予定。

余談だが、この記事のタイトルは、最初「Azureのインフラのナニカ」にしよう思っていた。ただ、これだと Qiita のガイドラインに沿っていないことに気がついたので考え直すことにしたのはヒミツ(笑)

お題

まずは、ことの発端になった死海文書プレゼンは以下。

このp5に術式式次第があって、引用すると以下のような呪文がに書かれている...

  • グローバルに広がるデータセンター
  • チップ四銃士を連れてきたよ
  • クラウドのサーバはコモディティかフフッ
  • 逃げるは恥だが知れば役立つストレージ
  • 神ってる?ネットワーク

当日のメモをもとに再構成されたナニカ

上記の「式次第」を、一般的なクラウド用語で言い換えると以下のようになる。特に 2. は他ではあまり聞かない話で、非常に面白かった。また、6. 以下は、真壁さんも話のなかで触れていたのだが、独立性が高いので、私の責任で独立トピックとして分離した。

  1. データセンタ
  2. ハードウェア・アクセラレータ
  3. コンピュート
  4. ストレージ
  5. ネットワーク
  6. 分散処理基盤

データセンタ

Microsoft のデータセンタ技術に関する取り組みの変遷と、スケール感の話。

海中データセンタとか、規模感とか、これはこれで面白いのだが、個人的には講演で教えてもらったくらいで十分かなぁと思うので、データセンタについては別立てで深堀りはしない予定。でも、興味のある方がいらっしゃれば、プロの視点から、ぜひおねがいしたいです!(他力本願)

以下、当日のメモより。

  • 100 DC以上、140ヶ国以上、100-200万台くらい、32 Region
    • 日本では東日本(埼玉/東京)と西日本(大阪)
  • Region レベルでPairを構成する
    • 災害時は、被災したRegionと同じURIで Pair 側にアクセスできる!?
    • 国内だと、東京・大阪で Pair を構成
    • Region、DC/Zone の下に Fault Domain という単位があり、これは利用者に見える
  • パートナーのデータセンタを使うこともあるというのは、少し意外だった。GoogleもパートナーのDCを使うこともあるようだし、自前で建設がコストにあうかどうかはその土地しだいかとも思う。

ハードウェア・アクセラレータ

個人的にはこの話が一番面白かった。

ここでは FPGA の話を中心にまとめるが、ハードウェア・アクセラレータという意味では、もちろん GPU や ASIC もある。真壁さんによれば、FPGA(low-laytency向け)とGPU(Deep Lerning向け)を用途によって使い分けているとのことだった。(枯れてきたらASIC化するのだろうか...)

論文を読んだまとめは別記事にまとめるが、ここで言うFPGAによるハードウェア・アクセラレータには以下のような特徴がある。

  • 後述のbladeに装着するメザニンカードの形状
  • FPGAはNIC の外側に配置されており、40GbEのトラフィックをToR SW-NIC間でスルーすることもある
    • bump-in-the-wire architecture
    • 既に50GbEを使ったSmartNIC Gen2が存在する
  • FPGAはコンピュート(CPU)とは独立に管理されている
  • 用途は大きく以下の3種類に分類される
    1. 個々のホストの処理のオフロード処理
    2. 個々のホストの通信処理のオフロード
    3. CPUのクラスタとは独立した、FPGAクラスタとしての処理

コンピュート

物理サーバについてはあまり特筆することはなくて、OpenCompute Cloud Server v2.1 (blade) とのこと。独自デザインで効率追求という解もあるわけだが、なによりも調達を重視しているからとのことだった。

なお、仮想サーバ関連では、Azureでは起動ディスクはすべてリモートになるのこと。

ストレージ

ストレージとしては、一般論としては以下の3種類がかと思う。

  1. ブロック・ストレージ
  2. オブジェクト・ストレージ
  3. ネットワーク・ストレージ
    • NFSやCIFSのようなPOSIX semantics をもったストレージのことを意図している

当日の話は、上記 2. のオブジェクト・ストレージのサービスである Windows Azure Storage(WAS) の紹介だった。

サービスの構造等については、真壁さんのプレゼンを見てもらうとして、特に気になったのは以下。

  • CAP定理を破った!?
    • この件は論文をチェック中。
  • 3-replica + Erasure Coding
  • WASを使うときに必要になる、ストレージ・アカウントなるものがある。
    • これを使ってURIとRegionを切り離しており、DRの時に効いているとのこと。
    • Global Load Balancer のしくみがどうなっているのかも気になるので論文調査予定

ネットワーク

以下、気になったことの箇条書きのみ。

  • この規模ではL2はつらいので、大規模では定番になりつつあるLeaf-Spine構造
  • 40GbE はいろいろ効率が悪いので、今後は 25/50GbE へ移行
  • LBやFWはソフト実装。
  • SONiCというソフトSWをOSS公開している。
  • HyperScale SDN Controller
    • DCをまたがって論理的に1つのコントローラで管理している
    • Service Fabric というMicrosoftの分散処理基盤上で動いている
  • RoCE v2 (RDMA over Ethernet)を使っている
  • シリコン・フォトニクスを既に使いはじめている(まずはSW-SW間から)

分散処理基盤

えー、これも調べなきゃと思ったので Placeholder ということで(苦笑)

まとめ

  • Microsoft の本気っぷりに慄然...
  • 自分でサービスを作っている人たちは楽しそうだなぁ...と思った次第。(おい、そこか...
  • Azureインフラの深堀り勉強会(セミナーではなく、本当に論文の輪講会のような)をやりたいんですけどねぇ...(とおいめ

リンク集

  1. データセンタ関連
  2. ハードウェア・アクセラレータ関連
  3. コンピュート関連
  4. ストレージ関連
  5. ネットワーク関連
  6. 分散処理基盤関連 - Service Fabric