(アップビートな音楽)
ナレーターの声: 皆様、
AWS グローバルインフラストラクチャ
およびカスタマーサポート担当バイスプレジデント、
Peter DeSantis の登場です
(アップビートな音楽が続く)
PETER DESANTIS: こんにちは、皆さん!re:Invent 2018 にようこそ
お越しいただきありがとうございます
re:Invent 2018 の初日を
楽しんでいただけていることと思います
例年と同様、ここにいらっしゃる皆さんの熱気に
圧倒されています
たくさんのお客様や技術者の皆さんと
意見を
交わす機会が持てたことをとても嬉しく思っています
本当に充実した 1 週間になるだろうとワクワクしています
昨年もこの基調講演に参加された皆さんは、
本当に重要なアイテムの 1 つ、
ビールがなかったことを覚えて
いらっしゃいますね(拍手)
今夜はビールだけでなく軽食などもご用意
しています
皆さんはビールやそれぞれお好きなものを楽しまれましたか?
(拍手)
良かったですさらにビールホルダーや記念グラスも
ご用意しました!
グラスは今週予定しているたくさんのアクティビティーで
プレゼントします
エアドラミング、Tatonka、トリビアナイトなどのアクティビティがありますが、Monday
Night Live
だけが専用の記念グラスを用意して
います
お帰りの際には、必ずお受け取りください
さあ、始めましょう。昨年は、たくさんのことがありました
今夜は当社がリリースした製品と機能のいくつかについてご紹介したいと
思います
また、これらリリースを支えている
イノベーション
についても簡単にご説明します
当社のグローバルインフラストラクチャからシリコンまで、
そのすべてに
見られるイノベーションについてです
また、今夜はすばらしいゲストスピーカーの皆さんもお招きしています
それぞれの顧客のために
取り組んでいることついて
ワクワクするようなお話しが
聞けます
AWS クラウドの新たな可能性を見つけるこれまでの道のりについて
お話をしていただけます
それでは、さっそく始めましょう
AWS グローバルインフラストラクチャは、
全世界に何百万もの顧客を抱えており、
想像できる限りのあらゆる方法で使われています
また、これには、このように大規模なインフラストラクチャの構築と運用で
何年もかけて
培われてきた
たくさんの知識が組み込まれています
私たちは、他のどのクラウドプロバイダーよりも経験が
豊富で、
運用パフォーマンスにも優れています
今夜はまず、グローバルインフラストラクチャの
アップデートについてお話ししましょう
AWS クラウドは 19 の地理的リージョンで運用されています
さらに 5 つのリージョンを追加することを発表済みです
スウェーデン、バーレーン、インタリア、香港、南アフリカ
です
AWS のリージョンは地図上の地理的ポイントと一致しています
このため、アプリケーションを実行する場所や
データを
保存する場所を決めるときに
便利です
ただし、このように地図を見てしまうと、
リージョン
について軽く考えてしまいがちになりますこれらの各ロケーションは
単なるデータセンターではありません
まったく違います各リージョンは
複数の
データセンターで構成されています
これらは地理的に離れた領域であり、
アベイラビリティーゾーンといいます
各アベイラビリティーゾーンが 1 つのデータセンターですが、
多数のデータセンターがあることも多くあります
また、同じリージョンの他のアベイラビリティーゾーン
からは
完全に独立しているように作成されています
すべてのリージョンに、2 つ以上のアベイラビリティーゾーンがあります
3 つ以上が必要とされるすべてのリージョンには 3 つ以上のアベイラビリティーゾーンがあります
一部のリージョンには 6 つものアベイラビリティー
ゾーンがあります
すべて合計すると、57 のアベイラビリティーゾーンがあります
すべてのリージョンに完全に独立した複数の
アベイラビリティー
ゾーンがあることで、顧客は距離が遠いと使えない
一般的な
レプリケーションテクニックを使って
それぞれの
アプリケーションを簡単に記述できます
また、すべてのリージョンの
複数のアベイラビリティゾーンに
一貫した方法でアクセスできるため、
顧客はどのリージョンにもそれぞれのアプリケーションとデータをデプロイでき、そのリージョンで
管理できます
この点は、1 つのデータセンターを
リージョンと呼ぶことが多い、
またはデータセンターの一部をアベイラビリティーゾーンと呼ぶことが多い
他のクラウドプロバイダーとは
まったく異なります
私たちがリージョンやアベイラビリティーゾーンについて
話すときは、
かなり詳しく話す必要があります
これにより、Gartner は高可用性
を求める
エンタープライズアプリケーションを実行する方法として
AWS のアプローチが
推奨されるアプローチであると認めて
います
少し時間を取って、アベイラビリティーゾーンについて詳しく
見てみましょう
インフラストラクチャを大きく分割したものの 1 つ 1 つが
アベイラビリティゾーンです
すべてのアベイラビリティーゾーンは最初は 1 つの
データ
センターでしたが、ほとんどが複数のデータセンターに拡張
されています
現在当社で最も大きなアベイラビリティーゾーンには 14 のデータセンター
があります
また、各データセンターもかなり大きく、中には 30 万台もの
サーバーが
あるものもありますこのように、アベイラビリティーゾーンは巨大です
各アベイラビリティーゾーンは、インフラストラクチャ内で完全に
分離されています
アベイラビリティゾーンは、他のアベイラビリティーゾーンと
意味のある距離で分離されています
通りを隔てて分けるといったことではなく
意味のある分け方です
正確な距離はリージョンの特定の地理的属性
によって
決まりますが、少なくとも 1 マイル、ほとんどの場合で
数マイル離れています
この距離は各アベイラビリティゾーンに
フォールトトレランス機能を提供するため、
リージョン内の他のアベイラビリティーゾーンに障害が生じても
同じ状態に
なることはありません
また、各アベイラビリティゾーンには
それぞれ独立した電力基盤があります
電力系統の UPS や発電機が分かれているだけでなく、
電力が完全に分離されています
各アベイラビリティーゾーンは他の
アベイラビリティーゾーンのほか、
世界のその他の部分との接続を提供する
トランジットセンターにも接続されており、
冗長性が高く、拡張性に優れたネットワークを
実現します
アベイラビリティーゾーンを機能させるには、
スループットが非常に高く、低レイテンシーのネットワークを
提供する必要があります
ただし、障害までもが同じように起こる
ネットワーキングアプローチは
避ける必要があります
では、AWS リージョンの内部の物理的なネットワークを
見てみましょう
アベイラビリティーゾーン間のネットワーキングの
可用性を本当に高いものにするために
しなければならない重要なことの 1 つは、
たくさんの物理ネットワークキャパシティを
デプロイすることです
余分なキャパシティーは、ネットワークエンジニアの最良の
友と言えるでしょう
私たちのリージョンモデルでは、
膨大な数の接続を
低コストでデプロイできます
当社最大のリージョンの 1 つだけで、
アベイラビリティーゾーンと
世界のその他の部分とアベイラビリティーゾーンをつなぐ
トランジットセンター
の間を 388 本のファイバストランドで接続しています
全体として、このファイバはその 1 つの
リージョン内だけで
4,947 テラビットを伝送できます
これはかなりのキャパシティです
これにより顧客は、本当に可用性に優れたネットワークを
利用できます
このような大量のキャパシティーを追加するには、
コストにかなりの重点を置く必要があります
コストを抑える方法の 1 つは、ケーブルあたりに収容するファイバーの数を
増やすことです
新しい敷設用の溝はいつでも掘ることができますが、
想像がつくように、
コストはあまり安くありません
また、高密度波長分割多重、つまり DWDM を使うことも
できます
ただし、繰り返しになりますがこれも費用が高く付きます
同じケーブルにより多くのファイバーをコストを抑えて
収容できれば、
たくさんのキャパシティーをより低いコストで得ることができます
この光ファイバーケーブルが最初に設置されたのは
数年前です
これについては、James Hamilton が 2 年前の
2016 年に
ここで話しました
当時は、これが一番密度の高い
ファイバケーブルでした
3,456 本のファイバーを 2 インチのケーブルに収容したものです
右側のケーブルは、6,912 本のファイバーを同じ
ケーブルに収容しています
以前のケーブルの約 2 倍です
物理的な世界でこんなに増やせることは
そうそうありません
私たちはこのケーブルをパートナーの 1 社と設計し、今年の初め
このケーブルを
敷設した世界初の企業に
なりました
インフラストラクチャのすべてのレイヤーで見られる
これらのイノベーションのおかげで、
私たちはより低いコストで規模を大きくし続けているの
です
次に進む前に、皆さんにお伝えしておきたいことが
あります
アベイラビリティゾーンについて、
またこれらによって
可用性と耐久性の高いコスト効率に優れたアプリケーションがどのように可能になるかについては、
今夜だけでなく、
この 10 年間でもたくさんの時間を割いて話してきました
このメッセージ
に顧客から共感が得られていることを
とても嬉しく思っています
現在、当社の大規模な顧客のすべてが
それぞれのアプリケーションで
アベイラビリティーゾーンを利用しています
アベイラビリティゾーンが新たな標準になるにつれて、
益々多くのプロバイダーが自社のゾーンを
売り込んでいます
しかし、利用しようとしているゾーンが真のアベイラビリティーゾーン
だということはどうやってわかるでしょうか?
これは、ある有名なクラウドプロバイダーが
自分たちのゾーンについて
詳細ページで説明している内容です
他のプロバイダーが説明していることはもっと少なく、「通常」「ほとんど」「したほうがよい」などの言葉が使われています
大抵の顧客は、「通常、パワーがある」や「通常、冷却機能がある」
といったことでは
満足しないことが
わかっています
また、「通常、動作する」サービスにも
満足しません
では、アベイラビリティーゾーンを利用して高可用性
アプリケーションを
構築する場合、それらが本当に独立していることはどのように
わかるでしょうか?
最近は益々わかりにくくなってきています
しかし、プロバイダーがそれぞれのアベイラビリティゾーンを
分離する方法について説明するときに「通常」という言葉を使う場合は、
疑ってください
また、プロバイダーがそれぞれのリージョン全体のほんの一部
でしかアベイラビリティゾーンを提供していない場合は、
疑ってください
アベイラビリティゾーン内のインスタンスへのレイテンシーが
他のアベイラビリティゾーンの
インスタンスへのレイテンシーとあまり変わらない
場合は、
疑ってください
1 つの電力障害が複数のアベイラビリティーゾーン、
または複数のリージョン全体の
サービスに影響を与える場合は、
かなり疑ってください
それでは本題に戻って、ネットワークの説明に移りましょう
地図を描いてみましょう
先ほど説明した、公開されている 19 の AWS リージョン
から始めます
ここに接続ポイントを追加します
世界中に150 の接続ポイントがあります
私たちはこれらの接続ポイントを使って、世界中の数千もの
Eyeball Networks
と直接接続しています
これらの接続ポイントに加えて、Direct Connect ロケーションの
ネットワークも
ありますこれらも追加します
89 の Direct Connect ロケーションがあり、他のプロバイダーの
2 倍のパートナーが
これらロケーションへの接続を
可能にしています
これらのロケーションとパートナーは、
世界中の AWS の顧客が
私たちと直接接続し、それぞれのデータを AWS グローバルネットワークを使って
どの AWS リージョンにでも
送信できるようにします
さて、顧客がグローバルネットワークにアクセスできる方法について
話しましたが、
ここでネットワーク自体について見てみましょう
これは巨大なネットワークです
このすべてのネットワークが先ほど説明した
各リージョンのネットワークを
接続していることを覚えておいてください
これは全体として、これまで組み立てられた中で
最も高度に拡張された
専用のグローバルクラウドネットワークです
また、実に急速に成長しています
すべての過程は大変なので説明しませんが、
重要なことだけ少しお話ししましょう
私たちがオーストラリアと米国を結ぶハワイキ海底ケーブルに
参加していることは
以前にお話ししましたこのケーブルは
現在、運用されています
また、日本と米国を結ぶジュピター
ケーブル
に参加することも発表しました
この新しいケーブルは 2020 年に運用が開始されると、
この重要なバックボーンルートに
かなりのキャパシティーを新たに提供することになり
ます
最後に、香港とシンガポール、
そして米国を直接結ぶ
Bay-to-Bay Express ケーブル
についても最近発表しました
この新しいケーブルの運用が 2021 年に開始されると、
これらロケーションの
トラフィックの可用性がこれまでになく高められます
これらは、私たちが現在進めているプロジェクトのほんの一部
です
大西洋全域、インド、中東、アフリカの一部
のプロジェクトに
積極的に取り組んでいます
これは AWS グローバルインフラストラクチャへの継続投資の大部分を
占めています
では、この巨大なネットワークが重要なのはなぜでしょうか?
AWS グローバルネットワークに特有な点を理解するために、
まずは
インターネットの仕組みについて
説明しましょう
インターネットはすばらしい空間です
数百ものプロバイダーが
独立して運用する高度接続
ネットワークで構成されています
これは Center for Applied Internet Data Analysis
が提供している、
インターネットの状況を示す興味深い
地図です
この図の周囲にあるネットワークが
Eyeball Networks です
通常ユーザーは、このネットワークに到達
しようとします
中心にあるネットワークは、高度に接続された
ネットワークで
それらネットワーク間でパケットがルーティングされます
これらのネットワークはすべて、この巨大な Eyeball Networks
と
疎結合ルーティングプロトコルを使って
互いに接続し、
パケットを効果的に移動させています
このしくみは驚くほどうまく機能しています
中央機関のない大規模な分散システム、
つまり
連携しているが、競合もしている多数の参加者で
構成されている状況において、
インターネットはすばらしい成功です
ただし、この従来のアプローチには欠点も
あります
最初に、パケットはあるプロバイダーから次のプロバイダーに
渡されます
これらのプロバイダーは、パケットを
渡す先の
ネットワークの稼働状況の把握に限界があります
さらに、何か問題が起こったとき、
事態はいつも悪化するものですが、
例えばファイバの切断、ルータの故障などが生じると、各
プロバイダーはネイバーから膨大な量の情報、
ルーティング情報を集めて
処理しなければなりません
また、パケットの送信先に
関する大量の情報
を計算し直す必要もあります
インターネットのような巨大なネットワークでは、これには
数分かかります
どんなに大きなルーターでもです
さらに、ネットワークを再調整する際には
ネットワークの輻輳を引き起こすこともあります
結局のところ、すべての参加者は自由に判断
できるため、
複数の参加者がトラフィックを
同じ場所に
送信して問題を修復しようとすることは珍しくありません
この場合、同じルートにトラフィックを
送信しようとする
参加者が多すぎる状態になり、結果として
輻輳と再計算が
さらに増えることになります
通常の状態に戻るまでにはたいてい数分
かかります
しかし、これらの事態が生じているときに
パケット伝送遅延が
顕著になることが多くあります
これはしばしば「Internet Weather」と
呼ばれています
グローバルネットワーキングのこのようなアプローチは、ほとんどのアプリケーションで
問題ありません
コストを抑えつつ、信頼性の高い方法です
ほとんどのアプリケーションは、今説明したような
パフォーマンスで
十分に動作します
しかし、一部のアプリケーションは、このような事態が生じるとかなり壊滅的な状態に
なることがあります
例えば、音声やビデオ、高度にインタラクティブなゲームについて
考えてみてください
あるいは、世界の離れた 2 か所にある
ソフトウェアサービス間で
通信する必要がある場合を考えてください
このようなタイプのアプリケーションの場合は、もっと良い
アプローチがあります
各参加者が最小限の情報で
ルーティングの判断をしなければならない
インターネットと異なり、AWS グローバル
ネットワークでは、
ネットワークのすべての特性を把握
できます
すべてのリンクのレイテンシーもキャパシティも
わかります
また、リアルタイムモニタリングにより、
すべてのリンクの利用状況もわかります
この可視性により、ネットワーク内の
すべての場所で
必要なキャパシティーを常に利用できます
さらに、あらゆる障害の影響を継続的に
モデル化し、
キャパシティが適切で
レイテンシーが
同等の冗長パスにパケットを送信することで、
直ちに
対応できるようにネットワークをプログラムできます
分散化されているインターネットのアプローチと異なり、
この方法では
アプリケーションにほぼ気付かれることなく障害を処理
できます
私たちは、先ほどお見せしたマップの周囲にある
すべてのネットワークに
接続しているため、AWS
グローバルネットワークを使って
エンドユーザーのネットワークに直接トラフィックを
ルーティングし、
インターネットアプローチの欠点を回避しています
私が今夜本当に話したいことは、
AWS グローバルネットワーク
の活用方法についてです
先ほど説明したように、顧客のトラフィックの多くが
すでにこの巨大なネットワーク上を
転送されており、AWS Direct Connect などの機能を使えば、
専用ネットワークとして
すぐにでも利用できます
また、AWS リージョン間でアプリケーションが通信する場合にも
利用します
これにより、アプリケーションの一貫したパフォーマンスと
ネットワーク変動の減少が
保証されます
しかし、AWS グローバルネットワークを使って
アプリケーションを最適化したい場合はどうでしょうか?
今夜、AWS Global Accelerator について
発表できることを嬉しく思います
AWS Global Accelerator では、AWS Global Network を利用して、
アプリケーションの
パフォーマンスと可用性を
簡単に改善
できます(拍手喝采)
それでは、AWS Global Accelerator のメリットについて簡単に
見てみましょう
ネットワークパフォーマンスについて話してきましたので、
その点から始めましょう
AWS Global Accelerator は、顧客のトラフィックを
AWS グローバルネットワークで
処理できるようにすることで、アプリケーションのパフォーマンスを
改善します
顧客のトラフィックは、エンドユーザーから
最寄りの
AWS エッジロケーションにルーティングされ、
そこから輻輳のない、
冗長性を備えた可用性の高い AWS Global Network を横断します
パフォーマンスの改善に加えて、AWS Global
Accelerator には
障害分離機能が組み込まれているため、
ネットワークの
稼働状況やアプリケーションの設定の変更に
すぐに対応できます
さらに、AWS Global Accelerator では、
リージョンの各エンドポイントに
トラフィックをルーティングする方法をコントロールできます
稼働状況、レイテンシー、地理的位置などの
設定しているポリシーを使って、
複数のリージョンでアプリケーションを簡単に
実行できるようにし、
グローバルに最適化されたパフォーマンスと
きわめて高い可用性を実現できます
さて、今夜はすでにグローバルネットワークを
管理する方法について
たくさんのことをお話ししました
ところが、AWS の顧客は自前のグローバルネットワークを
持っています
自分の VPC、自分の
アカウントを使ったネットワークで、
オンプレミスのインフラストラクチャと
AWS
の間では VPN と DX 接続を利用している場合もあります
そこで私たちは考えました
顧客がそれぞれのグローバルネットワークを
もっと簡単に管理できるようにするにはどうすればよいか?
今夜、ぜひ皆さんに AWS Transit
Gateway について発表したいと思います
これは数千の AWS アカウント、
数千の VPC
を相互に、またオンプレミスのグローバルネットワークに接続できるようにする新しい
サービスです (拍手喝采)
ありがとうございます (さらに拍手喝采)
ありがとうAWS Transit Gateway で得られるメリットは、
オンプレミスのグローバルネットワーク
の管理が簡単になるだけでなく、他にもたくさん
あります
まず、一か所でコントロールできるため、
中央で管理している
ゲートウェイに簡単に素早く接続できるほか、ネットワークを
簡単かつ
素早く拡大できます
また、Cloud Watch や VPC フローログなど、
セキュリティや
モニタリングでネイティブの AWS サービスも利用できます
この統合により、チームはネットワークを
中央から監視し、
ネットワークに問題が生じた場合も対応
できます
Transit Gateway により、コンプライアンスおよび
セキュリティポリシーの
実施と管理が簡単になります
さらに、Transit Gateway では拡張性も
高められます
例えば、複数の VPN 接続を
作成し、
トラフィックをすべての VPC に
分配できます
オンプレミス環境と AWS ネットワークの
帯域幅を
オンデマンドで拡張できます
Transit Gateway は、お客様にオンプレミスと
それぞれの
AWS クラウド環境を結ぶ
安全で管理が簡単なネットワークを
利用できるようにするために私たちが新たに考えているもう 1 つの方法なのです
いいでしょうここで、皆さんに
Chris Dyl 氏をご紹介したいと思います
Epic Games のプラットフォーム担当ディレクターであり、
世界で
最も人気のゲームで社会現象も巻き起こしている Fortnite の
作成者です
(アップビートな音楽)
CHRIS DYL: 紹介ありがとう、Peter
本日、この場で Epic Games についてお話しできることを心から
嬉しく思っています
皆さんの多くが、Epic をゲームを通じてご存じではないかと思います
Gears of War や Fortnite など、とても人気のゲームがいくつか
あります
さて、Epic は 1991 年に設立され
ました
それ以来ずっと、新しいゲームを作り続けて
います
現在、世界各地にある 25 か所のスタジオで
800 人を超える社員が働いています
また、この年末までに
さらにスタジオが
増える予定です
ところで、社名からゲームばかり作っている会社だと思われるかもしれませんが、
そうではありません
例えば、Unreal Engine と呼ばれるものも作って
います
これは制作ツールのスイートで、
これを使って
開発者は驚くようなインタラクティブ体験を作成できます
Unreal はもう何年もの間、Epic の業績の
中核を担っています
現在、Unreal Engine を利用している開発者は
世界中で
700 万人を超えており、
PC、コンソール、仮想現実、複合現実、その他のプラットフォームで実行できる
高度にインタラクティブなシューティングプログラムが
制作されています
では、Unreal Engine のパワーについて少し
お見せしましょう
ここに例がありますこれは
映画ロードオブザリングのゴラム役を演じた俳優 Andy Serkis です
これでは、Andy の表情をこれらの
デジタル
キャラクタにリアルタイムに転送しています
このタイプのテクノロジーができるまでは
一旦録画して
後から再生する必要がありましたが、現在は
リアルタイムで
ほぼ完成した合成を見ることができます本当にすばらしいことです
このエンジンについては丸一日でも話していられますが、
次に Fortnite についてお話ししましょう
さて、Fortnite についてはたくさんの方がご存じでしょう
ポップカルチャーの社会現象になっています
無料のゲームで、100 人のプレーヤーが最後の 1 人になるまで
戦います
Fortnite は本当にたくさんのプレーヤーを引き付けています
実際、登録プレーヤー数は世界中で
 2 億人を超えており、ピーク時の同時接続
プレーヤー数は 800 万人を超えています
このゲームでは、空飛ぶバスからスカイダイビングで飛び降り、
他のプレーヤーとの撃ち合いを制しながら、
途中
変わった構造の建築物を作って進み勝利を
目指します
私たちはこれをビクトリーロイヤルと呼んでいます
今、この瞬間にも数百万人のプレーヤーがゲーム
を楽しんでいます
それでは、これらすべてを実際に動かしているものについてご紹介
しましょう
2014 年ごろより、Epic Games は Gears of War などの
ゲームの開発者から
自社ゲームをサービスモデルとして
提供する
オンラインゲームのパブリッシャーへの移行を始めました
私たちは信頼できるクラウドパートナーが必要でした
そうすれば、
私たちのプラットフォームで私たちの製品によるイノベーションに集中できるからです
ご覧のように、当社は現在かなりの部分を
AWS に頼っています
すべてのさまざまなサービスで使っており、
Fortnite にとっても、
それを動かしているプラットフォーム
にとっても不可欠なものになっています
本当に AWS は私たちの成長を可能にしています
Fortnite はここ 12 か月だけで 100 倍に
成長しており、
ここにきて私たちにとって拡張性が非常に重要なものになっています
私たちは、20 を超えるアベイラビリティーゾーンでゲームサービスを
実行しています
現在、世界中で 26 のアベイラビリティーゾーンを
利用しています
また、特定の地域ではピーク時の
ワークロードの
高低差が約 10 倍もあります
このため、クラウドで提供される伸縮性が
私たちには本当に重要です
Fortnite では実際に、能力の限界をテストして
います
Fortnite の物語の一部として、
それぞれ数分間だけ続く
1 回限りのイベントを何度か実施しました
プレーヤー全員に、同じ時刻にログインして
これらのイベントに
参加するように招待しました
最初のイベントでは、
巨大なロケット船を発射しました1 億 2,500 万人の全プレーヤーに
同じ時刻に
ログインして同時に全員でプレイするように招待しました
Fortnite でこれまで見たことのないレベルのスケールに到達しました
おそらく、
ゲーム史上最高のレベルでしょう
その後も再度、ごく最近にも実施しました
ファンの間で
ケビンという愛称が付けられたキューブのイベントです
説明が少し難しく、その場にいないとわからない
ものです
YouTube や Twitch で探してみてください
よくわかると思います
本当にすごいです
これらのイベントでは AWS
のキャパシティ
を限界まで拡大していました
では、これらすべてを実際に
どのように成し遂げたのか詳しく見てみましょう
先に説明したように、Fortnite は主に AWS で実行
されています
私たちは、世界規模のゲームサーバーフリートを手に入れていますが、
これは
複数のアベイラビリティーゾーン、バックエンドサービス
データベースのセット、
ウェブサイトで実行され、すべてのゲームオペレーションをサポートします
また、非常に大きな分析パイプラインもあり、これは
Unreal Engine、
Fortnite、今後予定されているものを含むすべての当社の製品を
サポートしています
さらに、Java、Ochre、Go などのさまざまなテクノロジーを使った
数十もの
マイクロサービスも利用しています
すべてを説明する時間はありませんので、
分析パイプライン
について説明しましょう
この統計を見るとよくわかるでしょう
ゲームクライアントは常に私たちにデータを
送り続けるため、
分析パイプラインはユーザーと大規模なインフラストラクチャ
から受け取る
膨大な量のテレメトリデータを処理しています
すべてのデータを管理しているため、
1 分あたり 1 億 2,500 万のイベントでは、
月あたり 5 ペタバイトもの驚異的なデータ量に
なります
私たちは今まさにこの状況ですでは、これらすべてを管理するには
どうすればよいでしょうか?
私たちの分析パイプライン全体は、AWS
インフラストラクチャ上で実行します
複数のソースからユーザーストリームに
データを送信しますが、
ここでは一時的な保存用の
Spark Dynamo DB
で主に使われるリアルタイムパイプライン、Grafana、
Scoreboard API などのフィーディングツール
これについては後で少し説明します
アナリストが分析に利用できるリアルタイム SQL タイプのツール
などが使われています
また、バッチパイプラインもあり、これではすべてのデータを
S3 に受け取ります
S3 は当社のデータレイクであり、ここにすべてを
保存します
それに加えて、大量の EMR
処理を実行してデータを一括して
テーブルにまとめ、上位の S3 を使って
それら
テーブルを Tableau などのツールや何か他のものにすぐに
渡し、
最終的には、アナリストがアドホックな SQL
分析ツールによって
ゲームプレイのテレメトリデータを深く掘り下げる
ことができます
では、これらすべてのデータで何をするでしょうか?
1 つは、サービスの稼働状況を
監視します
クライアントは
異なるタイプの多くの問題に対する
実にすばらしい警告メカニズムです
クライアントはユーザーエクスペリエンスを実によく理解しています
クライアント側から監視できることは実際にたくさんありますが
これらは
バックエンドからはまったく
監視できません
例えば、ISP の停止や同様のタイプの問題
です
また、トーナメントでも使っています
昨年、Fortnite では複数のトーナメントを実施しました
Fortnite では
主従のカスタムルールを複雑に絡ませて
ゲームの
勝者を基本的に判断します
賞品として、モノからお金までさまざまなものを渡して
います
来年だけで総額 1 億ドルを超える
賞金を
用意することを発表しており、これらトーナメントで
提供することになります
さらに、基本的な KPI にも使っています公表する
KPI はすべて業務の
運営に利用していますが、それらには
ユーザーあたりの平均収入
月あたりのアクティブユーザー数、1 日あたりのアクティブユーザー数
などがあります
また、最後になりましたが、詳しいゲーム分析にも
使っています
基本的には、ゲームのデザインに注目してさらに良くしようと
しています
さて、私たちが先を見越して考えていることの
1 つに
グローバルな弾力性があります
多くのゲームサーバーはそれぞれ
分散していますが、当社のサーバーの多くは
1 つの
アベイラビリティーゾーンで実行している状態です
これは問題が生じた場合に
影響を受けるユーザー数という点で良いことではありません
私たちは、この点のすべてについて改善に取り組んで
います
私たちは成長に伴い、これらマイクロサービス
を管理するもっとよい方法がないか常に探していました
このため、便利な管理ツールとして、
EKS や
Kubernetes などのテクノロジーを検討しています
さらに、世界最大のゲームの 1 つとして、
当社のサービスに継続して
攻撃を仕掛けて
得をしようと目論む
たくさんの悪役に対して常に警戒する必要があります
このため、Amazon GuardDuty など
正しい検出に役立つものを
検討しています
また、ソーシャルグラフを作成できる Neptune などの
ツールも検討しているほか、
詐欺防止ツールの実装も考えています
本当に忙しい状態です
また最近では、
Fortnite の新しい期間限定モード、フードファイトを開始しました
ダーバーガー対ピザピットの戦い
です
世界が二手に分かれたフードファイトが始まっています
予告動画をご覧ください
(ゲーム音楽の再生)
ご覧のように、キャラの動きには何の制限もありません
私たちは
Fortnite でこういったことをやってのけている
のです
それでは皆さん、この後もどうぞ楽しんでください
フードファイトで
お会いしましょうありがとうございました (拍手)
(アップビートな音楽)
PETER DESANTIS: ありがとう、Chris
こんなバトルと知ってたら、皆さんに投げる用のビールとトマトを
持ってきたのですが、
知りませんでした
一日前のスコアがそうであるように、一日前のイノベーションも
すぐに的外れなものに
なってしまうことがあります。お客様が AWS について最も
高く評価することの 1 つに
イノベーションのペースが速いことがあります
この上ないすばらしい体験を
提供し、
お客様の信頼を日々獲得するには、
このペースのイノベーションを維持することが不可欠です。
今夜は皆さんと一緒に、私たちが昨年
提供を開始した
すばらしい機能のいくつかについて見ていきたいと思います
皆さんにご興味があれば、さらに少し発表もしたいと思います
(喝采)
わかりました昨年も私の話をお聞きいただいた皆さんなら、
私たちが
EC2 コンピュータアーキテクチャを
ここ数年かけて
Nitro と呼ばれるシステムに刷新した話をしたことを覚えている
でしょう
まず簡単に、Nitro システムとは何かについて、
またこれが
重要である理由について説明しましょう
今ご覧になっているのは、標準的な
クラウドホスティング
プラットフォームを簡単に示したものです
サーバーと仮想化レイヤーが
まずあります
この仮想化レイヤーにはハイパーバイザーが含まれますが、
あらゆる種類の
重要なことを実行するたくさんのカスタム機能も
含まれています
例えば、ユーザーの VPC 構成に従って、
ネットワークを
保護、管理、遮断するソフトウェアが
あります
また、ストレージで同様のことを実行するソフトウェアも
あります
さらに、インスタンスを監視、
管理、
さらに保護する機能もあります
このいくつかはリモートサービスで実行できますが、
ほとんどは
サーバーで実行する必要があります
プロバイダーはそのコードの最適化にたくさんの時間を割けますが、
ここでの物理的法則は
シンプルです
このソフトウェアは常に、顧客のインスタンスと
同じ
サーバー上で実行されます
数年前、私たちは EC2 インフラストラクチャを
完全に
作り変える作業を開始しました
基本的な考えはシンプルでした
すべての機能を
メインサーバーから専用ホストのローカル
ハードウェアに移すというものでした
このようにすれば、実行する際にサーバーのリソースを消費
することがありません
数年かけて、このアーキテクチャに進化
させました
昨年ここで C5 インスタンスを紹介しましたが、
これは
すべての EC2 ソフトウェアを Nitro システムに
完全にオフロードした
最初の EC2 インスタンスでした
この図にある要素は先ほどとすべて
同じですが、
メインホストではなく Nitro サーバーで
実行されています
昨年、Nitro の大きな 3 つのメリットについて
説明しました
1 つ目はセキュリティの強化です
元の EC2 アーキテクチャはハイパーバイザーと
複数の
EC2 固有のソフトウェアの新機能で保護されていました
ソフトウェアを別のシステムにオフロードすることで、
私たちはさらに強力な
セキュリティ境界を作成できます
信頼性の根幹を別にし、サーバーと
Nitro コントローラ間
の API を絞り込むことで、
インスタンスと当社の EC2 環境のセキュリティを
さらに強力に検証できます
2 つ目はパフォーマンスの改善です
この点についてはすでに触れましたが、
このすべてを
メインサーバーから移動することで、サーバーの
リソースを
顧客のワークロードにしっかり集中できます
また、専用のハードウェアを使うことで、
EC2 ソフトウェア
スタックでパフォーマンスがきわめて重要な部分を最適化
できます
最後、3 つ目のメリットは親しみやすさです
仮想化コードがメインサーバーから
移されたため
ネイティブネットワーキングを提供し
違反内容を EC2 サーバーに
直接保存できますこれは、ハイパーバイザーを実行する必要がまったくなくなることを
意味します
これと先ほど説明したセキュリティ
のメリットにより
ベアメタルインスタンスの実行が可能になります
さて、実際は 4 つ目のメリットがあります
昨年は説明していませんでした
それは、イノベーションのペースです
EC2 ソフトウェアをメインサーバーから
Nitro システムに移すことで
私たちは新しいインフラストラクチャを
顧客に提供することが
以前より簡単になりました
新しいハードウェアの変形ごとに最適化ソフトウェアを
移植する必要はもうありません
代わりに、どのハードウェアにでも Nitro システムをすぐに
追加できるため、
急でも完全に機能する EC2 インスタンスを
利用できます
AWS は、どのプロバイダーよりもインスタンスのポートフォリオが
充実しています
Nitro システムにより、新しいインスタンスの数を簡単に
増やせます
また、昨年にはその前年の
2 倍の
インスタンスを導入しました
この傾向は、今後も続くと予測しています
これら新しいインスタンスについて説明する前に、
かなり重要でワクワクするような今の傾向について
簡単にお話ししたいと思います
新しいハードウェアプラットフォームの設計や新しいプロセッサの
作成には
費用がかなり掛かります
この費用をたくさんの数のサーバーで分ける場合は
サーバーごとに増えるコストが
かなり抑えられます
一方、サーバーの数が少なくて済む
場合は、
特殊化を費用の点で正当化するのは
難しくなります
このため、従来のデータセンターでは
限られたタイプのプロセッサを使って
わずかな種類の
サーバーが設計されていました
各社が所有しているサーバーのタイプは片手ほどの種類
だけでした
つまり、特殊化は意味のないものでした
結果として、ほとんどのサーバーの
ワークロードは
汎用プロセッサと同タイプのサーバーで頑なに
処理されていました
これをまったく変えたのがクラウドです
成功して広く使われているクラウドコンピューティング
システムでは
ロングテールとされるワークロードでさえ 1000 や 10,000
もあります
以前は、企業が特殊化を費用の点で正当化することは
不可能でしたが
クラウドでは
これらの投資を
かなり多くの用途に分散させることができます
多くの場合、ハードウェアの特殊化もコストの点でかなりの
メリットが
得られ、お客様にはより良い経験を
もたらすことができます
間違いなく、ハードウェアの最適化は可能
であるだけでなく
ほぼ必要なことなことだと言えます
最近提供を始めたコンピューティングオプションをいくつか
見てみましょう
プロセッサの速度はほぼ横ばいの状態です
その代わりに、コア密度が増大しています
しかし、シングルスレッドのパフォーマンス
が重要な場合もあります
これはオンラインゲームなど
絶対にレイテンシーを避けられない
アプリケーションで、最高のシングルスレッドパフォーマンスが
必要なため、
または支払う必要がある
コアあたり
のライセンス料が高額なアプリケーションであるためかのいずれかです
私たちは最近、z1d インスタンスの提供を始めました
これは優れたシングルスレッドパフォーマンスを
カスタムの Intel Xeon スケーラブルプロセッサにより
提供します
このプロセッサは 12 コアを搭載しており、
すべてが同時に
最高 4 GHz のパフォーマンスを維持できます
これはクラウドインスタンスの中で最速です
このインスタンスは多数のユニークな
イノベーションで支えられています
まず、カスタムプロセッサを作成するための
Intel と AWS のコラボレーションです
また、このプロセッサには特別な
パワーと冷却機能が必要です
というのも、通常のプロセッサよりも多くのパワーを
必要とするため
冷却機能もかなり強力なものが必要になります
これらの投資は規模の小さな
従来のデータセンターでは
簡単に正当化できません
また最高のパフォーマンスを確実に
提供しようとする場合は、当然ながら
ソフトウェアのパフォーマンスに重い負担がかからないようにしたいと
考えます
Nitro システムでは、このカスタムプロセッサの
すべてのパフォーマンスを
顧客に直接届けることができます
高いコア速度が役に立つアプリケーションも
あれば
できるだけたくさんのメモリが必要なアプリケーションもあります
企業がビジネス上の決定を迅速に下すために
ますます多くの
リアルタイムデータを処理し続けるようになるにつれ
SAP Honor などのインメモリデータベースのデプロイメントが
今後も拡大し続けます
私たちはすでに、大きなメモリインスタンスを必要とする顧客向けに
いくつかのオプションを用意しています
X1 と X1e インスタンスは、それぞれ 2 テラバイトと
4 テラバイトのメモリを搭載しています
しかし、顧客は、最も要求の厳しい
インメモリの
ワークロードを実行するためにさらに大きなものを求めました
このため、私たちは最近、最大 12 テラバイトの
メモリを
搭載した EC2 メモリインスタンスをリリースしました
8 ソケットのプラットフォームで、最新
世代の
Intel Platinum Skylake プロセッサを採用し、448
のコンピューティングスレッドを提供します
これは EC2 インスタンスで利用可能な演算機能とメモリ
として最大です
さて、他のプロバイダーはこの問題を解決しようとして、
これらのようなハイエンドのサーバーを
ホスティングオプションとして提供することを
選びました
ネイティブインスタンスを提供するのではなく、プロバイダーが
代わりにホストを管理し
外部のデータセンターに
接続するのと同じ方法で
それぞれのクラウド環境を接続します
つまり、複数の環境を処理する必要があるだけでなく
より高いレイテンシー
を許容し、さらには
大きなメモリインスタンスをインスタンスとしてまったく使えないということを
受け入れる必要があります
しかし、Nitro システムでは、このような妥協をする必要が
ありませんでした
これら EC2 のハイメモリインスタンスは、私たちにとってまったく
新しい
ハードウェアプラットフォームです
しかし、Nitro システムと統合することによって
他の
インスタンスと同じネットワーキング、同じアクセスを AWS
サービスに
提供できました
また、メモリが 12 テラバイトの場合
ハイパーバイザーは必要ありません
このように大きなメモリサーバーで実行するように
設計されているハイパーバイザーはありません
Nitro システムを使うことで、私たちは EC2
ハイメモリサーバーを
ベアメタルインスタンスとして提供できます
これにより顧客はハードウェアで
直接実行できます
これで終わりではありません
最大規模のワークロードのために
さらに大きなインスタンス
最大 24 テラバイトのメモリを来年提供する予定です
ご存知かもしれませんが、今月の初めに
最も人気のあるインスタンスに
AMD プロセッサを搭載したタイプを
いくつか発表しました
これらのインスタンスは新しい AMD EPYC プロセッサを使っており
AMD 以外の同等品と同様のパフォーマンスを
提供しますが
コストは 10 パーセント抑えられています
Nitro システムにより、私たちはこれら新しい
インスタンスを
簡単かつ素早く評価できますが
通常であれば新しいプロセッサの評価で行う
開発作業は必要ありません
ハードウェアイノベーションを
これまで
よりも速く提供できるようになり本当にワクワクしています
しかし、私たちは考えました
加速するためにもっとできることはないのか？
昨年、皆さんに Annapurna についてお話ししました
数年前、私たちは Nitro システムの初期バージョン
を提供するために
Annapurna システムと協力するようになりました
私たちは同社のチームと
テクノロジーをすばらしいと感じ、
2015 年初めに Annapurna システムを買収しました
このチームの Nitro システムに関する展望と
進捗状況には
心から満足していましたが、AWS が設計して
製造するとしたら
どのようなサーバープロセッサになるのか
ぜひ考えてくれないかと頼みました
今夜、EC2 A1 インスタンス
を発表できることを嬉しく思います
これには AWS Graviton プロセッサが搭載されています (拍手喝采)
スケールアウト型ワークロードと
AWS 環境で必要とされる機能だけに特に
集中することで
A1 はワークロードにかかるコストを最大 45 パーセント
削減します
A1 インスタンスのパワーとして使われている
AWS サーバープロセッサ
は Annapurna labs 製 AWS Graviton プロセッサ
です
Graviton プロセッサは 64 ビット ARM
アーキテクチャをベースとした
16 コアのプロセッサです
Graviton プロセッサでは、皆さんや顧客からの直接の
フィードバックによる
構築、反復、イノベーションが可能です
A1 インスタンスは、コンテナ化された
マイクロサービス、
ウェブサーバー、キャッシュ層などのスケールアウト型ワークロードに
最適です
また、これらワークロードでコストを最大 45 パーセント
削減できます
A1 インスタンスにより、開発者は
ARM ベース
の開発環境に簡単にアクセスできます
私たちは A1 インスタンスが
ARM 開発者コミュニティの
教育者や愛好家の間で人気になると期待しています
もちろん、新しい ARM ベースのプロセッサを使うには
優れたソフトウェアとツールが必要です
A1 インスタンスには利用できる Linux ディストリビューションが
複数あります
Amazon Linux、Red Hat、Ubuntu などです
また、ドクターサポートのある最適化しやすい ARM 
もあります
さらに、A1 インスタンスは AWS の開発者ツールでサポートされています
CodePipeline、CodeCommit、Cloud 9 などです
新しいコンピューティングばかりです
しかし、まだまだ終わりではありません
Intel とのパートナーシップは 12 年になりますが、
このパートナーシップによる
共同イノベーションとその継続を
私たちは心から嬉しく思っています
最近提供を始めた Intel のいくつかのインスタンスについて
お話ししましたが、
私たちは現在も次世代の
Intel Xeon プロセッサ、Cascade Lake
のサポートで Intel と緊密に連携
しています
これにより、より低価格の複数のタイプの
EC2 サーバーインスタンス
が可能なると思います
また、顧客と
Intel
と緊密に連携し、Deep Learning
Boost などの新しいテクノロジーにも取り組んでいます
これでは、Intel プロセッサ
を使っている顧客に
推論アクセラレーションを可能にします
私たちは、AWS クラウドにも新しいコンピューティング
オプションを実現しようと頑張っています
これら新しいオプションは、皆さんのアプリケーションの
さらなる最適化を可能にすると考えています
AWS は他のどのプロバイダーよりも断然多くの
コンピューティング
オプションを提供しており、
今後も手を抜くつもりはありません
Nitro のすべてのメリットは、
ベアメタルインスタンス
を見るだけでわかります
昨年の基調講演で、ベアメタルインスタンスについてお知らせ
しました
それ以降、着実にベアメタルインスタンスの拡大を
続けています
ベアメタルでは、アプリケーションが
ハードウェアのプロセッサ
メモリ、ストレージリソースに直接アクセスできます
ベアメタルも、スタンダードインスタンスと
同様のパフォーマンスを提供し
AWS サービスに同じようにアクセスできますが
ユーザー自身のオペレーティング
システムやハイパーバイザーをネイティブに実行できます
このため、ベアメタルインスタンスは
仮想化されていないハードウェアを
実行する必要があるワークロード
特定のハイパーバイザーが必要なワークロード
ライセンスの関係で
仮想化されたハードウェアでは実行できない
ソフトウェアの実行に理想的です
私たちは最近、複数の新しいベアメタル
インスタンスを追加しました
Nitro システムにより、今後も新しいファミリーを
継続して
追加していくことができますベアメタルインスタンスはさらにたくさんに増えると
予想されます
ここに示しているのは、ベアメタルインスタンスを
使っている
顧客やパートナーの一部です
ベアメタルの顧客の多くが、従来のかなり
大規模な EC2 フリートに加えて
特定の要件を満たすための
少数の
ベアメタルインスタンスを実行する必要があることに気付いています
昨年、VMware Cloud on AWS を発表しました
これは、AWS と VMware が共同で開発した統合クラウド
サービスです
VMware Cloud on AWS は拡張性、安全性、革新性に
優れたサービスを提供し
顧客はそれぞれのオンプレミスの VMware vSphere
インフラストラクチャを
AWS クラウドにシームレスに移行して
拡張できます
VMware はベアメタルの顧客でもあり、
ベアメタルインスタンスを通して
VMware Cloud on AWS を提供することで
まったく新しい事業を生み出し
大きな変貌を遂げています
さて、今夜はたくさんのすばらしいコンピューティングオプションについて
見てきました
私はかなりコンピュータネットワーキングよりの人間ですが
実際には
ストレージも重要です
AWS の顧客向けにたくさんのストレージオプションを
提供しています
完全管理の耐久性に優れたオブジェクトストレージ
を提供する Amazon S3
完全管理のブロックストレージを提供する
Amazon EBS
完全管理の伸縮自在のファイルシステムを提供する
Amazon EFS があります
これらのオプションはすべて
さまざまなタイプのアプリケーションで役立ちます
しかし、時にはローカルディスクさえあればよい場合もあります
ローカルストレージを提供するインスタンスもいくつか
あります
例えば、I ファミリーは大容量の
高性能
SSD ストレージを提供し、D ファミリーはさらに大容量の
ローカルハードドライブを
提供します
ところが、顧客からは時折、もっと小さな SSD があればよいという
声が聞かれていました
こう聞いていた私たちは、今年の初め
よく使われている
さまざまなインスタンスタイプにローカルストレージを追加する機能を
リリースしました
当社のコンピュータ最適化汎用インスタンスと
メモリ最適化インスタンスのすべてで
ローカルディスクオプションが利用できるようになりました
これらのインスタンスはすべて、ローカルディスクの表示に Nitro システム
を使います
では、Nitro システムがこれら新しいローカルディスクの
パフォーマンスを
どのように改善しているのか見てみましょう
パフォーマンスのベンチマークテストを行う方法はたくさんあります
このデータは標準的な FIO テストによるものです
I インスタンスの最新 2 世代のテールレイテンシーと
当社の新しい
ローカルディスクのテールレイテンシーのそれぞれ平均を比較しています
新しいローカルディスクの平均レイテンシーは
オペレーション
あたり 20 マイクロ秒、I3 インスタンスは
30 マイクロ秒です
つまり、SSD のユースケースに最適化され、
パフォーマンスが重要な
アプリケーションで広く使われている
インスタンスよりも 33 パーセント改善されています
しかし、ローカルディスクが実際に優れており
Nitro システムが本当に効果的だとわかるのは
テールレイテンシーです
右のグラフをご覧ください
99 パーセントのテールレイテンシーで
Nitro ベースのローカルディスクと
I2 および I3 を比較しています
新しいローカルディスクのテールレイテンシーは 57 パーセント
低くなっています
これらローカルディスクの性能は、クラウドで
これまで提供された中で最高です
つまり、この大部分が
Nitro システムのイノベーションに
よるものです
先ほども言いましたが、ローカルディスクを要望した顧客は
少数で
使っている顧客も少数です
さて、今夜はこれまで、パフォーマンスについて
たくさんのことを説明してきました
パフォーマンスは大いに重要です
このため、私たちは皆さんの
アプリケーションに優れたパフォーマンスを提供できるように多くの時間を割いて研究し
新しいことを考えています
ほとんどすべてのアプリケーションで、パフォーマンスが重要になる領域が
1 つあります
それは、データセンターネットワークのパフォーマンス
です
私たちがデータセンターネットワークをどのように構築し
それが驚くような
パフォーマンスを低コストで提供するのにどのように役立っているのか
お話ししたいと思います
Nitro システムは、このストーリーで重要な
役割を担います
ただし、一部に関してのみです
最初に、私たちを含む世界全体が
データセンターネットワークをどのように構築してきたのか
簡単にその歴史を見てみましょう
その昔、ネットワーキングの大半はブラックボックス化された装置
として提供されていました
つまり、少数のプロバイダーがネットワークを
実行するために
必要なハードウェアとソフトウェアの両方を製造し
大きな鉄の
ネットワーキングデバイスとして提供して
いました
これらのデバイスは、高いマージンを付けて売られる傾向にあったため
ネットワーキングの全体的なコストはかなり高い
ものでした
この結果、コンピューティング環境のほとんどが
必要なネットワーク環境
には程遠いもので、これは本当に
残念なことでした
というのも、それら価格の高いネットワーキングボックスを
使っていても
データセンターのわずかな部分しかネットワークを
使っていなかったからです
ネットワークによる制約は
絶対に受けたくないものです
しかし、残念ながら受けることが多い状態でした
同様に、これらのデバイスのすべての機能を
確認することも
私たちの問題になりました
プロバイダーは、ネットワーキング装置の
高い価値を
維持するために、顧客が求めるあらゆる機能を詰め込もうと
躍起になっていました
これらの機能のほとんどは、顧客のほんの
一部しか
使っていませんでしたが
膨大な数になった機能は動作を
複雑にし、障害を生じやすくしました
さらに、大規模なネットワークプロバイダーである私たちならではの
問題にも
直面しました
つまり
私たちの実稼働環境をそのままミラーリングできるテスト環境を持つネットワークプロバイダーが
ありませんでした
これは、ネットワーキングの変更があっても
私たちの実稼働環境
については実際にデプロイするまで
十分にテストできないことを意味します
これは顧客にとっていいことではありません
問題があったときに
ネットワークプロバイダーが
それぞれの環境の限られた規模で問題を再現することは簡単では
ありませんでした
つまり、問題の特定、診断
修正、テストに
長い時間がかかっていました
いうまでもなく、これはクラウドプロバイダーにとって
いいことではありませんでした
それから、状況が大きく変わり始めました
ネットワーキング分野に新しい企業が登場し始めた
のです
これらの企業の中には、ASIC、つまり
最新のスイッチやルーターには必ず搭載されている特定用途向けプロセッサ
の製造を始めるところがあり
ました
また、それら ASIC とファイバーやネットワーク
を接続するのに
必要な光学部品、コネクタの製造を始める企業もありました
さらに、スイッチの製造を始める企業もありました
これは私たちがネットワーキングで
革命を起こすために
必要な原材料でした
私たちはこれらのさまざまなプロバイダーと協力し
ネットワークを実行するソフトウェアにかなりの投資を行いました
私たちのソフトウェアは、少し前に説明した
ソフトウェアとは異なり
比較的シンプルなものです
ネットワークを運用し、スケーリングするのに
必要な
機能だけを提供します
また、EC2 ネットワークの仮想化と
最近の Nitro システムへの投資により、従来であれば
ネットワーク機能
と呼んでいたことの多くを
ネットワークから Nitro システムに
移行することが可能になり
シンプルで安全、信頼性の高い
低コストの高速ネットワークの構築に集中できるようになりました
これは私たちのネットワークファブリックの
各ピースを論理的に示した図です
各サークルは Amazon スイッチを表し
これらは
先ほど説明したコンポーネントで作成されています
これらのスイッチは、ネットワークの特定のエリアの
要件に基づいて
接続されていますが、だいたいは
高密度クラスターと呼ばれる
ネットワークに接続されます
このスイッチの配置により
スケーリングが可能になり
ネットワーク内の
ポイント間に
複数の独立パスが提供されるため
十分な冗長性やスケーリング性能が
得られ、非常に簡単に高可用性を
提供できます
合わせて、これらの特性により、ネットワークのスケーリングが可能になり
高可用性を提供できるだけでなく
これらすべてを低コストで実行
できます
このネットワークの一番下に、EC2
ホストがあります
説明した Nitro システムが
動作するところでもあります
先に説明したように、Nitro システムには
専用の
ハードウェアリソースがあり
すべての EC2 インスタンスに到着する
すべてのパケットを処理します
パケットはセキュリティポリシーに基づいてフィルタリングされ
VPC の構成に基づいて
完全に仮想化されます
また、これはすべてインスタンス専用の特別なハードウェアで
実行されるため、非常に素早く
一貫した方法で
さらにかなりの低コストで実行できます
さて、一歩離れてみると
隙のないセキュリティ
大きな規模、高可用性、低コストを提供するために
設計された
データセンターネットワークファブリックであることがわかります
大規模な運用を考えて、また業界を超えて見られる
急速なイノベーションを
活用できるように設計されて
います
同時に、AWS を提供するために必要な
独自のセキュリティのしくみや機能
を実行する、ネットワークの
エッジにある
ソフトウェアやハードウェアにもかなりの
投資が行われています
この投資の結果は、パフォーマンスの
継続的な
改善を通して見ることができます
パフォーマンスを測る最も重要で
わかりやすい方法の 1 つは
スループット、つまり帯域幅です
この図は 
2006 年の EC2 開始以降の
インスタンススループットにおける重要なマイルストーンを示しています
最初の 6 年間は 1 ギガビットのネットワークが
限界でした
2012 年に弊社は 10
ギガビットネットワークの最初のインスタンスを導入しました
そして 4 年後の 2016 年、25 ギガネットワークの
最初のインスタンスを
導入しました
そしてもちろん、これで
終わってしまうなら
たいして面白い話になりません
そこで今夜、
C5n インスタンス (拍手喝采) の
一般的な利用可能時期をお知らせします
簡単にご理解いただけるインスタンスです
C5 では最大 100 ギガビットのネットワーク
帯域幅が提供されます
AWS はクラウドプロバイダとして初めて
この能力を広範囲で利用できるようにしました
C5 インスタンスでは昨年開始した
C5 インスタンスと比較して
4 倍のネットワークスループットが
提供されます
これによりネットワーク接続アプリケーションが
 AWS でより効果的に拡張されます
お客様はネットワークパフォーマンスの
向上の利点として
 S3 との間で高速にデータを転送することができ
アプリケーションの
データ取り込みの待機時間を減らして
結果をすばやく得ることができます
Analytics、Machine Learning、
ビッグデータ、データ類アプリケーションなどの
広範なアプリケーションで
このようなネットワークパフォーマンスの
向上が効果をもたらします
このようなネットワークパフォーマンスの向上は
大規模なインスタンス
だけに限定されるわけではありません
小規模な C5n インスタンスでは最大
25 ギガビット
または 25 ギガビットのネットワークスループットが得られます
これにより、ネットワーク接続のワークロードを
より低いコストで実行できます
そして、改善されているのはネットワークのスループットだけでは
ありません
C5n は最新世代の AWS
Nitro システムで構築されています
そして重要な世代のいくつかで
ネットワークパフォーマンスの向上を実現させています
ネットワークパフォーマンスについてお話しするにあたり
ネットワーク要件が厳しいことで悪評の高い
コンピューティングの分野について
お話ししたいと思います
ハイパフォーマンスコンピューティングつまり HPC は
非常にネットワーク要件の厳しい
顧客として有名です
その要件は
ネットワークプロバイダーの同種の業界とテクノロジーにまたがり、
さらに高いパフォーマンスの実現を目指しています
弊社の目標は長きにわたり、
敏捷性、コスト削減、伸縮性などの AWS
 クラウドの強力な価値を
要件の厳しいアプリケーションに等しく提供することでした
そのようなアプリケーションは
従来のエンタープライズデータセンターにおいて
非常に制約の厳しいものとして位置づけられます
高コストで拡張性の低いコンピュータクラスター上で
待ち行列に停滞し、
待機時間を費やすアプリケーションです
同時にそれらは幸運なアプリケーションでもあります
及ぼす影響が非常に大きいと考えられるアプリケーションの
多くは
科学的研究に関するもので、
コンピューティングを利用できないものです
AWS はハイパフォーマンスコンピューティングに
最適です
実際に弊社では AWS 開始前から
お客様の関心を
得ています
2005 年に EC2 を構築していたとき
弊社は少数の非公開の
Beta 版の顧客から新しいサーバーに関する
フィードバックを受けました
非常に多くの有益なフィードバックを提供していただいたお客様の 1 社が
南アフリカバイオインフォマティクス研究所、つまり
SANBI
でした
SANBI では MPI Blast アプリケーションを稼働して
遺伝子配列の
検索と照合を行っていました
そしてその処理を開始前の EC2
サーバーで実行していたのです
いまや MPI Blast アプリケーションは HPC コミュニティにとって
途方もなく並列なアプリケーションと呼ぶべき
ものとなっています
ネットワーク要件が厳しい HPC
アプリケーションとはほど遠いと言えます
しかしながら AWS の
コンピューティングの重要分野を変革するという約束は
当時から明白でした
そして、AWS を非常に要件の厳しい HPC の事例にさえも
対応可能なプラットフォームに変えようという
意欲が多くの開発者の間に
沸き起こりました
特に HPC をターゲットとした最初の大きな投資は
2010 年の
CC1 Instance、つまり Cluster
Computer Instance のリリースでした
このインスタンスタイプには
先程私がお話しした技術をごく初期に適用した
特別に開発された
ネットワークが
付随していました
このインスタンスにより、より要件の厳しい
ワークロードをクラウドに
送りたいと考えるお客様と直接やり取りする
最初の機会が与えられました
このリリースに続き CC2 Instance を公開しました
実のところ、開始前に CC2 クラスターで
スーパーコンピューティングベンチマークを実行し、
弊社は トップ 500 リストの 42 位に
ランクインしました
また、この時期に最初の汎用 GPU を
リリースしました
そのインスタンスを CG1 と呼んでいます
これらのクラスターコンピュータインスタンスでの
経験に加え
ご利用いただくお客様とのやり取りを通して
非常に要件の厳しい HPC アプリケーションの
ニーズに対応できるという確信を持つに至りました
弊社はクラスターコンピュータのインスタンスを
通常のインスタンスファミリーに集約することを決定しました
そして最近数年間にわたり
ネットワークパフォーマンスを改善し続ける一方で
お客様のアプリケーションの要件は
さらに厳しくなっています
C5n のリリースにより
さらにネットワーク消費量の多い
アプリケーションにも対応できるようになりました
しかし、HPC アプリケーションの
ニーズに本当に対応するには
もうひとつ必要なことがあります
コンピュータインスタンス間の遅延を最小限に抑えるには
HPC アプリケーションが
ゲストインスタンス内部のカーネルと
ネットワーキングスタック
をバイパスして
TCP などのハイレベルなプロトコルの使用を避ける必要があります
HPC アプリケーションにはネットワーク上で
ネイティブにサポートされる信頼性の高い
データグラムプロトコルが必要です
弊社では非常に要件の厳しいアプリケーションに使用するための
内部プロトコルを開発しました
このプロトコルは Scalable Reliable Datagram、
つまり SRD と呼ばれます
SRD ではデータセンターのネットワークファブリック、
トポロジー、および
運用上の特性に関する豊富な知識を使用して
可能な限り遅延の少ない
信頼性の高いパケット送信を
提供します
このようにネットワークを知ることで
SRD は弊社ネットワークの
すべての部分を最適な状態で利用することが可能です
ネットワークの特定部分に障害が発生すると
遅延を増大させることなく
その周囲のパケットをルーティングすることができます
これにより SRD は TCP などのプロトコルに比べてはるかに変動が少ない状態で
クラスターにパケットを
送信することができます
SRD は最新世代の Nitro システムにネイティブ実装することで
EC2 ハードウェア上の
リソースを一切消費することなく
最適なパフォーマンス
が得られるようになっています
もちろん、弊社はお客様のニーズに応えるため
お客様が
簡単に SRD を使用できるように
しました
そして今夜、お客様が高パフォーマンスの
コンピューティングアプリケーションを
容易に AWS クラウドに移行できるようにする
EC2 インスタンス用のネットワークアダプター
Elastic Fabric Adapter
つまり EFA を
発表いたします(拍手喝采)
EFA はオンプレミスの HPC クラスターの
ネットワーク性能と
EC2 クラウドのオンデマンドの
伸縮性をお客様に提供します
HPC アプリケーションでは
TCP などのインスタンス信頼性プロトコル
を回避し、ローカルカーネルをバイパスできるようになり
EC2 ネットワークファブリックを経由して
遅延や変動を最小限に抑えた状態で
信頼性の高い
ネットワーク送信が可能になりました
EFA は先程お話しした
C5n などの
100 ギガの新しいインスタンスタイプで利用可能です
EFA を使用すれば HPC アプリケーションで
ネットワークセンシティブなワークロードを
数千あるいは数万個にも及ぶコンピューティングコアにまで拡張することができます
また、EFA は主要なオープン
MPI フレームワークとネイティブで統合可能です
既にオープンソースライブラリの
LibFabric
との統合を完了しており
AWS 固有の変更を加えることなく
好みの MPI フレームワークを使用してアプリケーションが
実行できるようになっています
私たちはお客様がこれらの新しい性能を有効に活用できるよう
連携していきたいと
考えています
また、より多くの
HPC アプリケーションが AWS で動作できるようにしたいと考えています
それでは、AWS の Artificial Intelligence の GM である Dr. Matt Wood を
ご紹介したいと
思いますDr. Wood は
制約のあるコンピューティング環境の
実際の問題に精通しています
(アップビートな音楽)
MATT WOOD: 皆さん、こんばんは
Peter、ありがとうございました
今私たちはクラウドに出現してきている
機械学習の新しい波に直面しています
毎月、ほぼすべての業種の
数万人に及ぶアクティブユーザーが
機械学習を利用して意義のあるモデルを
構築しています
ただし、前からずっとそうではなかったことは
忘れがちです
実のところ、つい最近まで
機械学習モデルを構築することは
非常に大規模で
資金豊富なハイテク企業にのみ与えられた特権でした
それ以外に辛抱強く資金を調達しながらそれを実現できる
所といえば
大規模な研究機関だけでした
もしあなたが開発者で
機械学習を使い始めようと考えたら
5、6 年前でさえ
あなたの問題に積極的に取り組もうとしてくれる博士グループを探して
大学パートナーシップを
組む必要が
ありました
そして交付申請書に記入しなければなりませんでした
これが NSF 交付申請ハンドブックです
申請の提出方法を
把握するだけでも
この分厚い 181 ページに目を通さなければなりません
どうにかやり遂げて
必要な全資金が得られたら
やっと高額の小切手を書く機会が得られます
そしてそれをハードウェアベンダーに渡します
ハードウェアベンダーがその小切手を受け取り
あなたは待ちます
ハードウェアベンダーが
作業を開始し、
HPC クラスターと必要なすべてのリソースを構築するまでに
数週間、いや通常は数か月かかります
ようやく荷受所に届いたら
梱包を解き、
配置を決めて設置し、
すべての
入出力プラグを繋いで
必要な最新バージョンを
配線して構成します
そしてアルゴリズムを開始する機会を得ます
それから再び
通常は数日間、あるいは数週間か数か月間、
より高度なモデルの
トレーニングや学習が
入手できたデータから
可能になるまで待ちます
そしてついにモデルの評価に移ります
それがこの 47 パーセントという数値ですこれはコイントスより
少し低い確率です
ここでお気付きかと思いますが、
数年で
ある程度の成果が得られましたが
さらに多くのデータが必要になります
より良いアルゴリズムと
そしておそらく、より高速な計算が必要です
当然ながらこの時には博士課程の学生は
卒業していき
離れてしまうため
あなたは再び単調な作業を
繰り返さなければなりません
またパートナーとなるべき
学術機関を探して NSF
を提出して資金を申請します
いくらかの資金の提供を受け、
高額の小切手を書きます
その小切手がハードウェアベンダーにわたり
ベンダーは作業を開始し、必要なすべての
アプリケーションと
ハードウェアを構成して納品します
あなたは納品されるまで待ちます
それが荷受所に届いたら
受け取って
配置を決めて設置し、プラグを繋いで構成し、
アルゴリズムを実行して
さらに待ちます
そしてついに評価作業を実行して
結果を得て
結果がわずかに良くなっていたため
ある程度の成果が得られたことになります
しかしそれと同時に、おそらくさらに多くのデータや
より良いアルゴリズム、
より高速な計算が必要であることも意味します
ほとんどの場合、より高度な
モデルを構築するという点に関して
次の 3 つのことが言えます
より多くのデータ、より良いアルゴリズム、
より高速な計算が必要であるということです
これについてクラウドには良いニュースがあり
これまでになく安く簡単に
大量のデータを格納できるようになりました
ただし、データを S3 に格納することは
課題の一部にすぎません
そのデータを独自のアルゴリズムにかけるので
アルゴリズムでは
それらの例から学習し始めることになります
弊社では何年間かにわたって
これら 3 つの領域の
すべてに意義のある投資を行い、
より高度なモデルを構築し
より低いコストで運用できるように
改善を続けてきました
第一に、より多くのデータを
アルゴリズムに
移すことができるようになりました
機械学習モデルの構築、トレーニング、配備のための
完全に管理された
プラットフォームである
Amazon Sagemaker の導入を開始したとき
弊社ではパイプモードというものを採用しました
従来、機械学習では、ファイルが数千万個にもなる可能性があるデータをすべて使用して
トレーニングを開始
しようとすると、
それらのデータを
クラスターの周りにコピーする必要がありました
それにはスタートアップのはじめから
膨大な時間を要しました
そのためできるだけ迅速に GPU への
データの取得を試みなければなりませんでした
これがパイプモードに切り替わりましたパイプモードでは
データを S3 から直接クラスターに、そして直接 GPU に
ストリーミングして
トレーニングを
開始できるようにします
それによってトレーニング開始だけにかかる時間が
著しく減少し、
約 90 パーセント削減されました
なぜなら、クラスターにまでデータをコピーする必要が
なくなったからです
IO スループットは限界を超えて増大します
その理由は、より多くのデータを S3 から EC2 に
より速く移動させ GPU に送ることが
できるからです
その結果、ジョブ実行時間が
3 分の 1 にまで劇的に
削減されます
つまり、ファイルの代わりにパイプを使用するだけで
モデルのトレーニングが
3 分の 1 まで速くなります
最近になり、再度スループットを増大させて
さらに 9 倍ほど改善しました
継続的に向上させているのです
当然ながら、データをアルゴリズムにかけると
通常は
より良いアルゴリズムが必要になります
より多くのデータを抽出して
AWS クラウド上で使用できる
計算能力を有効活用したいと
考えるでしょう
弊社では AWS のさまざまな一連のフレームワークに
相当な資金を投資
しています
この点で弊社のアプローチは
他のベンダーとは少し異なるかもしれません
それは、これらのフレームワークをすべて
取り入れたいというアプローチです
TensorFlow、MXNet、PyTorch、Keras、Gluon は
AWS 上で可能な限り良好に動作します
実際、別々のチームを編成して
これらの各分野に集中
させるようにしています
トレーニングでの課題のひとつは
必要なだけの数の GPU を
クラウドから入手できるという
拡張性を活かせるかだけでなく
伸縮性も
挙げられます
多くの場合、運用にあたってそれらのバランスを取ることが
求められます
本日は、基本的なアルゴリズムの改善について
お知らせしたいと思います
MXNet の参照実装ですべてのアルゴリズムに
使用可能なものが
Dynamic Training です
Dynamic Training により
トレーニング中にリアルタイムで
トレーニングクラスターを動的に調整することができます(拍手)
つまり Dynamic Training では操作中に
収容能力を調整できるのです
したがって、Spot Instances のような
クラウドネイティブな技術を
利用できるようになりますさらに、必要な場合には
未使用の予約済みインスタンスに読み込むことが
可能になります
ミッションクリティカルなアプリケーションで必要な場合、
単にプールに戻せば
よいのです
このアプローチを使用してモデルの
トレーニングを行い
約 8 GPUから 96 GPU まで変化させると
Dynamic Training を使用すると
50 パーセント高速になり
コストが 30 パーセント低下していることがわかりました
つまり、パフォーマンスの改善が進むにつれて
コストも
低減されるのです
現在ではこれが MXNet で可能ですが
今後数か月間で
TensorFlow および Pytorch でも
可能になります
それでは、計算の高速化について見ていきましょう
これは重要な部分です
データをアルゴリズムにかけると
可能な限り大きい計算能力をもって
可能な限り速く動作させたいと考えるでしょう
NVIDIA Volta
はその点で最高のシステムと言えます
機械学習のトレーニングにはうってつけです
エンコードをシリコンディスク上で直接行いますが
それは深部の学習トレーニングの内部ループにとって
重要な要件です
新しいバージョンが入手可能であり、そして本日、
まったく新しいインスタンスで利用可能になります
それはクラウドのどの場所でも利用可能な
非常に強力なインスタンスです
それが P3dn です
(拍手)
P3dn インスタンスは最も強力な GPU
インスタンスです
それらは分散トレーニング用に設計されており、
先程お話しした
100 ギガビットのネットワークを使用します
V100 Volta の最新バージョンを入手することができます
GPU 単位で 32 ギガが確保されますが、現在の P3 より
2 倍改善されています
ネットワーク帯域幅で最大 100 ギガ
使用できます
弊社では 96 個の仮想 CPU を Intel Xeon
スケーラブルプロセッサー上で
AVX とともに動作させました1.5 倍改善しています
そしてその中に 2 テラバイトの NVME
ストレージを配備しました
そのためローカルにあるデータへの高速アクセスが可能です
これまでトレーニングについて、そしてトレーニングの重要性について
沢山お話ししてきました
それは重要ですが、これらのトレーニングモデルを使用し、
本稼働環境に移行して
新しいデータでの推論を導くことが
まさに機械学習に
求められていることです
そしてパフォーマンスも大いに問題になります
パフォーマンスはエッジにあって最も
痛切に感じられるものです
エッジで展開される機械学習モデルは
コンシューマー
アプリケーションと
工業用アプリケーションの両方で一般的になりつつあります
なぜエッジで展開されるかというと
常に遅延に対して
敏感であるからです
製造パイプライン
の管理方法について決定を下したり
コンシューマーデバイスに関して
コンシューマーにすばらしい経験を提供したりするために
クラウドまで往復で通信して
また戻るようなことを
したくはないからです
また、それらのモデルは小規模でリソースが制限されがちであり
多くの場合
1 つのハードウェアプラットフォーム上ではなく
さまざまなハードウェア上で
稼働させることが望まれます
つまり、必要なパフォーマンスが必要な精度で
得られるようにするには
個別の中立ネットワークモデルを特定の稼働させるハードウェアプラットフォームに合わせて
手動で調整しなければなりません
それは
きわめてまれなエキスパートによる
非常に時間のかかる
作業になります
本日は、Amazon Sagemaker の新しい機能である
Neo をご紹介いたします
これは詳細レベルの学習モデルコンパイラであり、
お客様はこれを使用してどこでもモデルをトレーニングし
展開することができ
パフォーマンスが
最大 2 倍向上します
(拍手)
それでは Neo がどのように動作するかを見ていきましょう
Sagemaker Neo は Sagemaker 内部にある
フルマネージドの環境であり、
これを使用して通常どおりに
モデルをトレーニングできます
次にそれを詳細レベルの学習コンパイラである新しい Neo で
解析します
そしてハードウェア固有のターゲットである
展開ターゲットを選択します
詳細レベルの学習コンパイラでは
通常の C++ コードをコンパイル
するときと同様に、認識しているすべてのことを利用します
それらの個々のプラットフォームがパフォーマンス面で優れていることを
有効に利用することが
できるのです
単一のトレーニングモデルから
複数の展開ターゲットを構築することができます
ターゲットが得られたら EC2 で実行するか、
Sagemaker で実行するか、または
Greengrass ML Inference を使用しても実行できます
あるいは、単にダウンロードして
使用中のデバイスで
実行することも可能です
何度かクリックするだけで
マテリアルを改善できます
弊社では既に
Intel、Qualcomm、Arm、Cadence、NVIDIA、Xlinkg、
FTGA など、いくつかのハードウェアベンダーと
提携しています
本日、Neo をオープンソースに移行します
(拍手)
つまり、他のベンダーが
詳細レベルの学習コンパイラと
関連するランタイムを入手して
独自に最適化機能を追加できるようになります
そのため新しい中立ネットワークが
使用可能になると、
リアルタイムでコンパイラと
ランタイムに追加されるようになり、
無料でどのデバイスにどのアプリでも
組み込むことができます
より多くのデータをアルゴリズムに
移して
クラウドとエッジの両方でより高速な計算を
行うことができます
したがって、研究者を
探す必要はもうありません
調査企画書を書く必要も
ありません
高額の小切手を渡す必要もなく
待っている必要もありません
すべてのハードウェアが荷受所に届いたら
場所を決めて設置し、構成し、
最終的に
モデルを構築します
それにより、少ない時間でより良いモデルを
構築できるのです
これまでの機械学習における道のりについてここで少し
拝聴したいと思います
それでは、GE Healthcare の
Analytics/AI 部門のシニアバイスプレジデントである
Keith Bigelow 氏を
ご紹介します
ありがとうございました(拍手)
(アップビートな音楽)
KEITH BIGELOW: Matt さん、ありがとうございましたこの場にお招きいただき、
皆さんにお話しできることを
とても嬉しく思います
GE Healthcare では、世界最高レベルの
医療機器を製作しています
弊社では10,000 台の医療機器を 120 か国に納品し、
約 190 億ドルの収入、約 30 億ドルの
利益を得ています
今夜ここで皆さんにお伝えしたいのはすべてが
Sagemaker に入っているということです
それでは、今夜遅くに私が交通事故に遭ったとします
救急車が来て私を一番近い
緊急治療室に運び込みます
緊急治療室では治療チームが
CT スキャンを実施します
怪我の状態を把握し、
手術の計画を立てて
準備し、手術を
行います
縫合を終えたら、最後にもう 1 つのことを
気にかける必要があります
それは X 線撮影を行うことです
X 線撮影の目的は、何か重大な状態が残っていないかどうかを
診断することです
もしそれがあれば、放射線科医がそれを見つけて
私は手術台に戻り、チームが
切開して処置し
その後私を
回復まで導きます
すばらしいですね、ここラスベガスには第 1 レベルの
外傷センターがあります
これは何を意味するでしょうかこれが意味しているのは、放射線科医が
画像をすばやく正確に読み取るために
毎日 24 時間体制で待機していることです
アメリカに住んでいる私たちは幸運です
なぜなら、国民およそ 1 万人ごとに
1 人の放射線科医がいるからです
したがって、主要都市では
対応人員が十分いることになります
しかし、世界では、そしてアメリカでも
農村部では
人々はそれほど幸運ではありません
例えばケニアでは、人口が 4,800 万人ほどですが
住民 24 万人に対して放射線科医 1 人です
このような不足は深刻な問題であり、
正確性や適時性の
問題につながります
もし事故に遭ったのがラスベガスで
なかったらどうなったでしょうか
ネバダ州の山奥ならどうだったでしょう
おそらくそこには放射線科医はいません
私の画像は読み取られないでしょう
そして 8 時間経って
朝になってから新しい放射線科のスタッフが現れたとき、
私は深刻な状態に陥っていたかもしれません
意識を失っていたかもしれません
そして私は手術室に急いで戻され、
彼らが問題を解決して最終的に私を回復に導けるように
多額の費用をかけ、自分の生命を大きな危険に
さらすことになったかも
しれません
先に進むために、これを改善するにはどうしたらよいか
考える必要があります
これは人工知能にとって
うってつけの機会です
このようなときに人工知能は
治療チームが命を救うための
手助けをします
それでは、それはどのような形になっているでしょうそれは詳細レベルの
学習アルゴリズムの形をとり、
このアルゴリズムが最初に調査と検出を行います
深刻な状態があるでしょうか次に、アルゴリズムでは
場所を突き止めます
治療チームの視線を
画像の重要部分に
引き付けますそして最後に
それを数値化します
それにより治療チームは、その箇所が本当に深刻であるのか、
あるいは大きな問題でないのか、
注視しておくべきものなのかがわかります
さて、私の場合は深刻な気胸であったとします
つまり肺が潰れかけているのです
アメリカでは年間 74,000 回これが発生
しています
人工知能にとっては大きな事例となります
データの量が膨大であり、
絶えず発生しています
このことについて考えるにあたり、あなたは疑問を抱く
かもしれません
Keith はこのアルゴリズムをどのように作成したのか
どうすれば自分の会社でこのアルゴリズムを作成できるか
といったように1283
01:19:26,733 --> 01:19:29,736
まず、前のプレゼンテーションで Matt が言っていたとおり、
弊社は
世界中の大病院と提携して
います
お話ししたとおり、弊社は120 か国で事業を展開しています
したがって、弊社のトレーニングデータセットには
対象となる人々の生命体をすべて反映させる
必要があるのです
それらのデータの関係をすべて取得したら
画像を報告書と結びつけて
匿名化し、
Edison AI サービスに投入します
このサービスで、データが取り込まれた後に
カタログを作成し、インデックスを作成して、
セキュリティを保護します
十分な大きさと十分な多様性を持つ、それらすべての生命体を表す
データセットが得られたら、
キュレーションに取り掛かることが
できます
キュレーション段階で私たちが一番行いたいことは
データの
グランドトゥルースを作成することです
つまり、治療チーム、医師、
放射線科医
が皆やって来て、それぞれの画像にラベルを
付けることになります
気胸陽性、気胸陰性
というようにです
しかしそれ以上のことを行います実際はピクセルレベルの
キューレーション
を行って肺の中で気胸の部分を丸で
囲みます
このように完璧なグランドトゥルースが得られたら
トレーニングに進むことができます
そして Sagemaker でトレーニングを行いますトレーニングを重ね、
最終的に
非常に正確なモデルを得ます
そのモデルが得られたら、次はこれを展開
します
同じモデルを利用して
あらゆる所で展開したいと考えます
そのため、約 4 年前に AWS とともに
構築したヘルスクラウドに
展開します
ご想像いただけるとおり、弊社ではサービスとして
遠隔医療
のアルゴリズムを実施しようとしています
ケニアに住む人たちすべてに
推論を伝えて
簡潔なフィードバックを与えます
エッジへの展開が可能です
例えば数十台の X 線がある病院があるとします
ネットワーク上にはおそらく数百台の X 線があるでしょう
病院ではそれらをアップグレードしたくありませんエッジデバイス
を単に展開して
設備全体を効率的にしたいと考えます
最終的には、私の今夜の自動車事故の後で
必要なことを実行できます
それは、このアルゴリズムを
X 線で展開したいということです
ポイントオブケアで、私が緊急治療室から運び出される前に
治療チームは
状態について警告を受け、それに
リアルタイムで対処
することができます
ポイントオブケアは事例として最適です
それでは Sagemaker と AWS を選ぶ理由はなんでしょうか
私たちの仕事は 1 つのアルゴリズムを構築することではありません
数千にも及ぶアルゴリズムを構築することです
それを行うためにはペタバイト単位のデータを
取り込む必要があります
そしてそのデータを従順に保存しなければなりません
たくさんのチームを使ってキューレーションの
作業をしてもらう必要があります
それらすべてのプロジェクトが能率よく効果的に作業を進められるように
キューレーションを
うまく調整しなければなりません
トレーニングにあたり、データ技術者たちは
何十回にもわたって P2 インスタンスの
実験をしたいと考えます
そして試みるのが、多くのデータから
1 つの非常に正確な
モデルをより分けることです
そのモデルが見つかったら、また P3 で繰り返します
P3 インスタンスでの作業時は、数日間のトレーニングが
数時間のトレーニングになっています
速く実行できるすばらしいパイプラインが
備わっているので
彼らは感激するでしょう
最後にデプロイしますが、Matt が言っていたように、デプロイは
あらゆる場所で行います
年間数万個のデバイスで行います
そのため Windows 上に展開しなければなりません
Windux で展開します
すみません、Windux ではなく Windows Linux です
CPU で展開し、存在する場合は GPU で
展開します
すべてのデバイスには、異なるメモリフットプリントが
あります
そのためこのモデルを最適化して、
最終的な展開先のそれぞれを
ターゲットとする必要があります
さて、ネタバレになってしまいますが、私は今夜の
自動車事故で命を取り留めます
治療チームは気胸をふさぎ
すばやく効果的に処置します
そして、私たちは人工知能によって命を
救おうとしています
健康管理の質は向上し、
ミスの数が減少します
したがって、コストの削減が見込まれます
それは X 線だけには留まりません
今週、超音波検査のためのまったく新しいアルゴリズムを
発表いたします
MR とCT のためのものですそれらがすべて Sagemaker に構築されます
これらのアルゴリズムを世界最大級の放射線イベントで
たったいまシカゴで
開始します
私たちのパートナーシップと
その意味を
たいへん光栄に思っています
弊社の目的は問題となる生活や時間を
向上させることです
Sagemaker と AWS を利用して
作業を始めたばかりです
ありがとうございました(拍手)
(アップビートな音楽)
PETER DESANTIS: Keith、ありがとうございました
さて、今夜の催しも終わりに近づいてきました
先を急ぎましょう
しかしその前に、お話ししたいことが
もう 1 つあります
今夜はビッグインスタンス、ビッグネットワークについて
沢山お話ししました
しかし、最近はお客様から
全般的にサーバー管理のご依頼をいただくことが
多くなってきました
そういったお客様にはサーバーレスコンピューティング
オプションを提供しています
そのオプション用に
インフラストラクチャをどのように最適化しているかをお話ししたいと思います
AWS では非常に多くのサーバーレスコンピューティング
オプションを提供しています
AWS Fargate は Amazon
Elastic Container サーバー向けの計算エンジンであり
お客様はサーバーやクラスターを
プロビジョニングせずにコンテナを
実行することができます
AWS Fargate を使用すると、コンテナを実行するために
EC2 インスタンスのクラスターを
プロビジョニング、設定、スケール
する必要がなくなります
AWS Lambda を使用するとお客様は
一切プロビジョニングを行うことなく
直接コードを実行できます
使用したコンピューティング時間に対してのみ課金されます
Lambda では、任意のアプリ上で仮想的にコードを実行することができ、
どのアプリケーションやバックエンドサービスにも
管理が不要です
サーバーレスコンピューティングの需要は
非常に多くなってきています
そして、より多くのお客様がコンテナや関数を
大規模に実行するようになっています
一般的に利用されるようになってからたった 3 年で、
AWS Lambda
は毎月 10 万人のお客様からの
1 兆件のリクエストを
既に処理しました
そして Fargate は AWS のお客様向けに毎週 1 千万のコンテナを
実行しています
AWS Fargate や
Lambda などのサービスを構築するときは、技術的なトレードオフを
考慮することが重要です
一部のプロバイダーはコード内で
複数のコンテナを実行しており、
1 つのサーバーや仮想マシン内で複数のお客様に
対応しています
この方法は効率が非常に良く、簡単に待ち時間を
短縮できるため
魅力的に感じられます
しかし、このようなマルチテナントの手法では
単一テナントのインスタンスやサーバーが提供する
高セキュリティの分離が
提供されません
AWS に関しては、このようなトレードオフを生じさせたく
ありません
もう 1 つの方法は、お客様のインスタンスやコードを
お客様固有のインスタンスや
サーバーで実行することです
これによって EC2 インスタンスと同様に
セキュリティが保護され隔離されますが
最高レベルのパフォーマンスと効率を得るのは
難しくなります
Lambda を公開したとき、お客様ごとに専用の
EC2 インスタンスを使用する
ことを決定しました
そして Fargate の公開時には、
Fargate の各タスクを
個別のインスタンスで構築することにしました
これにより必要なセキュリティが得られますが
効率は低くなり
コストが高くなってしまいます
これは良い開始方法でした
弊社のインフラストラクチャを新しくして
このようなコスト面でのトレードオフを
なくす必要があるとわかっていました
コンテナを対象に設計された場合、
仮想化の技術がどのようなものになるかを
考えました
その結果が Firecracker です
Firecracker はセキュアなマルチテナントコンテナや
機能ベースのサービスを作成し、
管理する目的で構築された
仮想化テクノロジーです
それでは Firecracker について少しお話しさせてください
Firecracker はセキュリティを重視して設計されています
Firecracker マイクロ VM は KVM ハードウェアの
仮想化レイヤーと連携して
従来の仮想マシンと同等の
セキュリティが確保されます
また Firecracker では最小限のデバイスモデルが
実装されていて
重要でない機能はすべて除外され
マイクロ VM の攻撃対象が減らされています
攻撃対象領域を減らすことが
セキュリティの強化には最も効果的です
セキュリティの次に Firecracker では速度を重視しています
Firecracker では、特にコンテナと Lambda  のために
最適化された
ゲスト Linux 環境により
仮想マシンの
作成時間が高速化されています
これにより起動時間が速くなりました
Firecracker マイクロ VM では 150 ミリ秒以下で
ユーザースペースコードが開始されます
Firecracker はスケールと効率性に配慮して設計
されています
Firecracker VM はそれぞれ 5 MB 未満の
オーバーヘッドを必要とします
そのためサーバーの密度を最大化することが
できます
多数のマイクロ VM を作成することもできます
Firecracker はサーバーごとに 1 秒間に 150 個のマイクロ VM を
作成できます
最後に、Firecracker は組み込みのメカニズムを備えていて
マイクロ VM が数千個ある場合でも
ネットワークとストレージが公平に共有されるように
しています
私たちは Firecracker を使用して、コストを削減し
Fargate や Lambda などのサービスのパフォーマンスを
向上させています
このように弊社では
EC2 インスタンスと同様にサーバーレスコンピューティングの
インフラストラクチャに対しても多大な投資をしていることを
おわかりいただけると思います
しかし、私たちはコミュニティが常に革新と共にあると
信じています
今夜ここで、Firecracker が
Apache 2 0 のライセンスで利用可能になることを
発表いたします(拍手喝采)
Firecracker マイクロ VM では、
従来の仮想マシンが備えていた
セキュリティと隔離の特性と、
以前はマルチテナント環境でのみ利用可能であった
スピードとリソース効率とが
組み合わされています
また、私たちはコミュニティと連携して
Container D、Docker、Carter のコンテナなど、
主要なコンテナワンタイムとの統合について
調査を
しています
さて、今夜は広範囲にわたってお伝えしました
沢山のことをお話しできたと思います
今週中は
多数の技術セッションが開催されます
テクノロジーについてさらに詳しくお知りになりたければ
ご参加ください
もう 1 枚スライドがあったのですが照明が明るくなってしまいました
このスライドは皆さんへの感謝の言葉です今週はお越しいただき
ありがとうございました
ご参加ありがとうございました  皆さんの情熱とパワーに感謝します
残りの re:Invent もお楽しみください (拍手)
素敵な夜をお過ごしください (拍手)
