AWS re:Invent 2016: Tuesday Night Live with James Hamilton

セクションナイン吉田真吾@yoshidashingo)です。

昨年のAWS re:Inventではたくさんの発表がありとても楽しめました。

f:id:yoshidashingo:20170124193102j:plain

そんな中でも特に2年ぶりにAWSを構成するインフラの話が聞けたのが個人的には盛り上がりました。

2年前の話は以下のエントリーに書いてあります。

yoshidashingo.hatenablog.com

今回はAWSのインフラの情報についてワクワクしながら聞くことができた(たとえるなら、自分が普段食べてるコアラのマーチが工場でどうやって出来上がるかを見るようなワクワク感)のですが、それにも増して「James Hamilton氏がそのハイプレッシャーな立場においてそれ以上にこの仕事が楽しくてしかたないという情熱を毛穴という毛穴から発散しているような姿」が印象的でした。


AWS re:Invent 2016: Tuesday Night Live with James Hamilton

Tuesday Night Live with James Hamilton

AWSのサーバーの規模

10年前のAmazonのサーバー規模を毎日追加

f:id:yoshidashingo:20170104203920j:plain

  • 2015年のAWSはおおよそ”2005年のAmazon(年商84.9億ドル)で必要だったサーバー規模”を毎日追加した
  • それはFORTUNE500社のサーバー規模の合計分と同等でもある

柔軟性がニューノーマル

f:id:yoshidashingo:20170104203929j:plain

  • AWS自体のサーバー規模は Amazon Prime Day をターゲットに調達している。(クラウドを無限に見せるために、一時期のC3インスタンスのように、人気がありすぎて不足して起動できないということがないようにしないといけないですからね。)

※ちなみに2013年は年商70億ドル規模と同等↓ということだったので、サーバーの台数規模は21%増えた模様。

f:id:yoshidashingo:20170104204832j:plain

  • ただし同期間中、AWSの年商の伸びは、2013年=$31億、2015年=$78.8億154% 増えている ため相当の乖離があるように見えるため、後ほど出てくるサーバーの集約率が実はものすごく上がっているのかもしれない。)

海底ケーブルのネットワーク

なぜ独自の Amazon Global Network が必要か?

f:id:yoshidashingo:20170104203935j:plain

  • レイテンシー、パケットロス、サービスの全体品質の改善のために独自ネットワークが必要
  • 相互接続の競合による品質低下を割けるため
  • 大規模な運用制御のため

f:id:yoshidashingo:20170104203942j:plain

  • CloudFrontのエッジロケーションは68箇所にある

f:id:yoshidashingo:20170104203956j:plain

  • 冗長化された100GbE回線が世界中をぐるっと囲んでいるので
    • 一部のリンクが切断されても大丈夫
    • すべてのリージョン間の通信が専用のキャパシティが確保された状態で冗長化されている(ただし中国は除く)

最新プロジェクトについて

f:id:yoshidashingo:20170104204002j:plain

  • ハワイの「太平洋横断ケーブル」について
  • 14,000kmに渡り、オーストラリア/ニュージーランド/ハワイ/オレゴンと接続する
  • ケーブルを3本束ねて一対のケーブルにしている
  • 100Gケーブルに100多重の波長で多重通信がされる(※MAX=10Tbps?)
  • ニュージーランドの陸揚局に引き揚げられたのがちょうど先週のこと

リージョンとアベイラビリティゾーン(AZ)の構成について

リージョンの内部構成について

f:id:yoshidashingo:20170104204008j:plain

  • リージョンは全部で14箇所あり、リージョンの中には、
  • 2つ以上のアベイラビリティゾーン(電源やネットワークが独立して確保されている単位)で構成されている
  • 最近のリージョンは最低3AZ以上で構成されている
  • 多いリージョンでは5AZで構成されている

リージョンとインターネット間のトランジットセンターについて

f:id:yoshidashingo:20170104204014j:plain

  • 2箇所で冗長化されている
  • 高速のピアでデータセンターのファシリティと接続されている

AZ内やAZ同士をつなぐメトロコネクト用の光ケーブルについて

f:id:yoshidashingo:20170104204020j:plain

  • 126の独自経路を持っている
  • 242,472本のケーブル束を張り巡らせている
  • AWSは3,456本fiber count table を1つのデータセンターに配備した初めての会社となった(※fiber count tableが何を指すかまで分かりませんでしたのでどなたか分かる人がいらっしゃったら教えて欲しいです。1つのビルディング内というところまでは聞き取れました。)

アベイラビリティゾーン(AZ)内のデータセンターの構成について

f:id:yoshidashingo:20170104204025j:plain

  • それぞれのAZは1つ以上のデータセンターで構成されている
  • 中には8データセンターで構成されているAZもある
  • データセンター間のネットワーク接続は冗長化されている
  • いくつかのAZは 30万台のサーバー で構成されている

データセンターについて

f:id:yoshidashingo:20170104204031j:plain

  • 60〜120メガワットまたはそれ以上のデータセンターの建設は容易だが、AWSのデータセンターは5〜8万台のサーバーを収容し、消費電力の総量は25〜32メガワットに抑えている
  • スケールが大きい(収容台数が多い)ことでコストをゆるやかに抑えている
  • しかしスケールが大きいことは障害の影響が素早く大規模に広がってしまうことでもある
  • 冗長化や並列性(ここでは並列しているうえに独立して実行できるという意味合いで解釈)によりメンテナンスしやすく設計されている

自作、自作、自作

AWSでは独自カスタムのルーターを利用している

f:id:yoshidashingo:20170104204037j:plain

  • 旧来のルーターは複雑で不安定なうえに高価で問題の解決に6ヶ月かかるものもあった
  • ハードウェアを独自設計し、プロトコルも専用チームで作成した
  • 25GbEを早期にコミットした
    • この当時で10GbEと40GbEを実稼働していた
    • 光学系の可用性は厳しいがコミットできた
  • 40GbEの中身は10GbEを4ソケットで構成
  • 50GbE(25GbEソケット2つで構成)は40GbEより安価に実現できた

SDN(Software-Defined Network)について

f:id:yoshidashingo:20170104204043j:plain

  • EC2はローンチ当時からSDNベースで構成されていた
  • 2012年に以下のようにソフトウェアからハードウェアにオフロードした
    • カスタム 10GbE NIC(ネットワークインタフェースコントローラー)
    • AWSのソフトウェアでカスタマイズされたNICのプロセッサ
  • サーバーのネットワーク仮想化によるオーバーヘッドのオフロードに成功した
  • 低レイテンシとサーバーのジッタ低下かできた
    • SR-IOV拡張ネットワーキングの採用
    • プレイスメントグループ内における平均70マイクロ秒未満のRTT

2016年からルーターのカスタムチップを自作

f:id:yoshidashingo:20170104204049j:plain

  • カスタムチップで25GbEを実現
    • 25GbE 2つによる構成は40GbEより安価に広帯域を実現できた
  • これは Amazon Annapurna ASIC と呼ばれている
    • 拡張ネットワーキングの第2世代を提供している
    • AWS独自のチップ/ハードウェア/ソフトウェア設計になっている
    • AWSのペースオブイノベーションモデルの則っている(年々成長する)
  • 個々のインスタンスでピーク時には20GbEの帯域が提供できる
    • 小さめのインスタンスの場合は10GbEまで
    • ほとんどのインスタンスタイプで対応済み

※Amazon は2015年初に Annapurna Labs を3.5億ドルで買収していますが、名称から推察するにこのチームがAcqui-Hireされてチップ設計チームになったものと思われます。

www.extremetech.com

まれに起こりうる電源喪失について

f:id:yoshidashingo:20170104204056j:plain

  • 米国の主要航空会社に起きた世界規模の障害の事例
    • いくつかのサーバーがフェイルオーバーしたり電源喪失をした
    • それにより1億ドルの利益を失った(その月の2%くらいに相当)
    • 電源制御盤の故障や予備電源の稼働失敗も起きていた
  • 顧客影響
    • 月曜日:1000フライトが欠航
    • 火曜日:775フライトが欠航
    • 水曜日:90フライトが欠航
  • このときのオペレータにとってはこの欠陥は初めてのものだったのだろう
    • 経験知を得るための圧縮アルゴリズムは存在しない

電源制御盤を自作

f:id:yoshidashingo:20170104204104j:plain

  • さきほどの航空会社に起きたエラーは2013年のスーパーボウルのときに起きたものと同じだった
  • 電源制御盤がバックアップ電源に切り替わらなかった
  • データセンターは5〜10分間完全に電源喪失した
  • Amazonのカスタムファームウェアはこういった挙動から防御できるようになっている
    • 外部エラーの場合すべてのファシリティが稼働する
    • 内部エラーの場合、当該ブランチのブレーカーのみ開くようになっており、他に影響は波及しない

ストレージサーバーを自作

f:id:yoshidashingo:20170104204111j:plain

  • 2014年の時点では 1ラックに収容していたディスクは 880本だった
  • 次の世代の設計では
    • 1ラックに1110本のディスクを収容
    • 設計当時で8.8PB、現在では11PB格納できる
    • 2778ポンド=1250kgのストレージ重量を搭載可能
  • さらに高度な設計が現在は採用されている

コンピュートサーバーも自作

f:id:yoshidashingo:20170104204118j:plain

  • シンプルで装飾のない1Uサーバー
  • 密度よりも排熱効率と電源効率に優れている
  • PSU(電源装置)やVRD(電圧レギュレータダウン)の電源効率は90%以上
  • すでに新しい設計で置換えられている
    • にも関わらず最近ブログで書かれたいくつかのクラウドサーバーと比較されている

100%再生エネルギー化に向けて

f:id:yoshidashingo:20170104204125j:plain

現在の到達度および見通し

f:id:yoshidashingo:20170104204131j:plain

  • 現時点で45%、2017年に入るまでに50%

再生エネルギーファームの建設見通し

f:id:yoshidashingo:20170104204138j:plain

  • すでに4箇所の風力発電ファームと1箇所の太陽発電ファームが稼働している
  • 今後複数の太陽発電ファームを建設していく

現在907メガワットを生産している

f:id:yoshidashingo:20170104204147j:plain

将来的には260万メガワット時の生産を目指している

f:id:yoshidashingo:20170104204154j:plain

まとめ

AWSのユーザーとして、AWSが内部で利用している技術を知っておく必要があるかというと、知らなくても使えるけど、知っておくとよりうまく使いこなせるでしょう、ということになります。しかも普段は開示されない情報が多い中、このジェームズ・ハミルトン氏が表で話してしまえば情報解禁が既成事実になるという流れもあるので、今後もチェックしておくと、きっとワクワクする情報に触れることができると思いますよ。

(年越してからの公開になってしまいすいませんでした。)