JAWS DAYS 2017でサーバーレスの話とマフィアセッションをやりました

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

3/11に開催されたJAWS DAYS 2017でサーバーレスの話とマフィアセッションをやりました。

サーバーレスの今とこれから

サーバーレスが今なぜ熱いのかという話と、(スライド内ではあまり触れてませんが)これからどういう実装がサーバーレスに置き換わっていくかという話をしました。また、今監訳しているServerless SPAの中から、WebアプリをSPAにしてユーザー認証やフェデレーション、データベースや集計処理をサーバーレスにする場合の開発の流れについて話しました。

監訳についてはその後10名くらいの方が追加チェックにご協力いただき、一気に日本語の言いまわしなどのレベルが上がりました。

www.slideshare.net

マフィアトーク

すっかり毎年恒例になりそうなマフィアトークのモデレータを今年もやらせていただきました。昔からこのJAWS DAYSをきっかけに転職につながる方が多いので、ぜひとも毎年続けたいと思っています。どういう仕事がしたいか、どんな仲間と働きたいか考えるときに、AWSJやパートナー企業でのキャリアを考慮してみる機会になってくれるとありがたいです。

しかしパネルディスカッションのモデレータというのは非常に準備が大変ですな。今回も「質問表を書いて記入してもらう」「衣装を揃える」「みんなで呑んで質問の答えを参考に深掘りしたり取捨選択する」というので準備に2〜3週間前からトータル20時間くらいかかったかなと。上のサーバーレスが4〜5時間だったと思います。

www.slideshare.net

ということで短い報告にはなりますが今年も非常に楽しめました。

jawsdays2017.jaws-ug.jp

最近開催した勉強会と話した資料

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

最近開催した勉強会と話した資料をまとめておきます。昨年12月から直近までです。

2016.12

2016.12.5 AWS re:Invent 2016 Recap

JAWS-UG横浜 #8 でAWS re:Inventのラップアップイベントを宇宙最速開催。

jawsug-yokohama.connpass.com

www.slideshare.net

  • ユーザーが直接Lambda(FaaS)を使う以外に、あらゆるサービスの基底コンポーネントとしてLambdaが組み込まれていくことで、それらを活用するアーキテクチャもまたサーバーレスになるという流れが強まってますね、という話。
  • Lambda@EdgeやAthenaなど新しい活用方法が広まってきていいですね。

2016.12.7 & 12.13 re:Port 2016

毎年恒例、今年は東京と大阪で開催されたスカイアーチさんのAWS参加報告会にお呼ばれ。

connpass.com

  • Lightsail、VPSということで注目度が低いけど、組込みAMI(WordPressやRedmine)の便利さ、価格競争力から考えるとピーキーじゃないものはこれで十分であってバランスのいいサービスですね、という話

2016.12.8 Codenize Meetup

これは主催のみ。インフラのコード化ということでCodenize.toolsのユーザーを主体としたイベントを開催したけど、今後はCodenize.toolsが主体とするVMの世界からさらに拡張し、コンテナの世界のライフサイクルのコード化、サーバーレスの世界のライフサイクルのコード化もまじえて開催したいと思っています。

codenize.connpass.com

2016.12.11 Serverless Meetup Sapporo

照井君がオーガナイズしてくれた札幌のServerless Meetup。

serverless.connpass.com

  • サーバーレスを牽引するFaaSもいまや各クラウドベンダーやOSSからさまざまなものがリリースされており、それぞれの特徴の紹介

2016.12.20 パソナテックさんイベント

パソナテックさん主催のイベント「12/20(火) 実務で活かせるセキュアなAWSアーキテクチャ設計 〜AWS re:Invent 2016アップデート最新版〜」

https://www.pasonatech.co.jp/skill_up/event/seminar_1220.jspwww.pasonatech.co.jp

  • AWSをはじめるにあたって役立つ知識をとにかくいろんなre:Inventのトピックにからめて2時間(でも足りなかったけど)お話しました。

2017.1

2017.1.17 Serverless Meetup Tokyo #2

毎回大人気のイベント。

serverless.connpass.com

2017.1.25 MySQL→Aurora移行セミナー

マジセミさん/パソナテックさん共催のイベント。マジセミさんの開催頻度と内容の幅広さには驚かされますね。

osslabo.doorkeeper.jp

  • MySQL→Auroraの移行方法の説明や異種間DB移行の方法について解説しました。

2017.1.27 Serverless Meetup Osaka #2

こちらも毎回大人気のサーバーレスイベント。今回は「ボイス」関連のサーバーレスに特化してやってみました。

serverless.connpass.com

  • サーバーレスアーキテクチャの簡単な説明とコミュニティでのアンケート結果

2017.2

2017.2.10 JAWS-UG横浜 #9 - Operational Excellence

横浜支部も再始動してついにトータル9回目の開催。今回は新規でコアメンバーになってくれたNECメンバーが中心になって開催しました。

jawsug-yokohama.connpass.com

  • AWSの相談で特に多い導入後の反省点についてどういう導入パスを歩めばスムーズだったか、今から見直す場合にどういう視点をもてばよいかという点で非常に役に立つ「AWS Cloud Adoption Framework」、またセクションナインでもアセスメントのサービスに活用をしている「AWS Well-Architected Framework」の紹介をしました。

2017.2.17 デブサミ2017

縁あってデブサミで「サーバーレスにおける開発プロセス戦略」についてパネルディスカッションのモデレーターとして参加させていただきました。

event.shoeisha.jp

  • パネラーにミクシィの生井さん、Wi2の相馬さん、日経の猪飼さんにご参加いただき、それぞれのプロジェクトで導入したサーバーレスの構成やそのときの導入経緯や苦労話などを話しました。

しんやさんにレポートも上げていただきました。

dev.classmethod.jp

今後

今後直近で予定しているものとしては、JAWS DAYS 2017でのサーバーレスのセッションやマフィアトークくらいですが、その後にもいろいろ控えており楽しみです。

2017.3.11 JAWS DAYS

jawsdays2017.jaws-ug.jp

jawsdays2017.jaws-ug.jp

主催コミュニティ

Serverless MeetupやCodenize Meetup、JAWS-UG横浜では引き続きここでしか聞けない、そして毎回ヒーローが産まれるような楽しい会にしていきたいと思っています。最新情報はそれぞれconnpassグループで配信されますのでぜひジョインしてください。

Serverless Meetup

  • コオーガナイザ募集中です。

serverless.connpass.com

Serverless Community(JP) もよろしくお願いします。

Codenize Meetup

  • 次回開催に向けた企画・運営メンバー募集中です。

codenize.connpass.com

JAWS-UG横浜

  • 横浜に暮らす、横浜で働くAWSユーザーの皆さんの企画・運営参加を常時募集しています。

jawsug-yokohama.connpass.com

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

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