GM, Artificial Intelligence である Dr. Matt Wood が登壇し、お客様がどのようにそれらのコンピューティング環境を AWS で活用しているかの詳細について、3 つの事例を紹介しました。

北京とサンフランシスコのスタートアップでは、自律走行レベル 4 を実現し、200 マイルを完全に自律走行できるトラックを開発しています。CT スキャンの医療画像から Deep Learning により腫瘍を見つける事例では、腫瘍を早期に発見できるだけでなく、全てのスキャン画像を日常的に解析することができるようになりました。北バージニアの大学では 50 万にもおよぶ論文を自動的にカテゴリ分けするために自然言語処理アルゴリズムを使っており、大量の CPU 処理のために 2 時間だけ EC2 スポットインスタンスを使用して 110 万コアで計算処理を行っています。AI や機械学習で実行できる処理能力やデータ量は、10 年前には想像もできなかったほどのスケールとなっています。

そして Matt は、ここ数年の AI、Deep Learning の飛躍的な進化の要因として 3 つの要因をあげて説明しました。1 つ目はハードウエアによる高速化です。NVIDIA の最新 GPU の V100 はディープラーニングを高速化する機構をハードウェアに組み込んでおり、V100 を 8 個搭載した p3.16xlarge はペタフロップス（PFLOPS）級の非常に高い処理性能を実現します。2 つ目は、機械学習フレームワークの拡充です。AWS では Tensorflow、MXNet、Caffe2 などのあらゆるフレームワークが事前設定された AMI を AWS Marketplace からダウンロードして効率的に動かせます。Amazon は TensorFlow ではパッチも提供しており、パフォーマンスを３-５倍改善することに貢献しました。MXNet でも、学習において 7-8 倍のパフォーマンス改善を達成しているなど、コードの提供に貢献をしています。3 つ目は、急速に成長しているコミュニティです。AWS と Microsoft は、2 カ月前に  Gluon という機械学習ライブラリを発表しました。

ここで Perter が再び登壇し、元 EC2 の GM であった自身の経験を振り返りながら、EC2 のここまでの道のりについて語りました。AWS は EC2 やインフラストラクチャの全てに対して長期に渡り多くの投資をしてパフォーマンスの最適化を継続してきました。Perter はここで、ハイレベルな EC2 のアーキテクチャについて語り、高速で低価格な非常に信頼性の高いネットワークと、インスタンスやマシンイメージ、セキュリティグループ等全てを管理しお客様に API を提供するマイクロサービスについて説明しました。そして EC2 ホストでは、お客様のインスタンスを実行するために、カスタマの環境が定義されたとおりに提供する EC2 ホストソフトウェアが稼働しています。EC2 が最初にサービスを開始してから、EC2 のソフトウェア群は常に拡張・改善され、今日提供されている様々な機能を追加してきました。

Peter は、EC2 インスタンスが目指している重要なゴールを 3 つあげました。1 つ目は高いセキュリティです。AWS のサービスは常にセキュリティから始まります。セキュリティの観点では、ハードウェアやソフトウェア、EC2 イメージの完全性、状況の可視性が重要になります。2 つ目にパフォーマンスも重要です。パフォーマンスの絶対値が高いことだけでなく、様々な異なる負荷の傾向をもつワークロードに対応できる可変性や可用性が重要です。そして 3 つ目に、お客様が使い慣れたハードウェア上で実行されているサーバーと同様に利用でき、ハードウェアを意識せずにすむような抽象化レイヤーを提供することが重要です。例えば EC2 が利用するディスクを iSCSI で提供することも検討されていました。これはサービス提供側からするとシンプルですが、お客様に OS 側で iSCSI クライアントの設定や管理をする無用な作業を強いることになるため、Amazon EBS ではネイティブなディスクとして見えるように提供しました。

C4 インスタンスは C3 インスタンスの 1 年後にリリースされましたが、ストレージ処理を Nitro システムに移行しました。ネットワークと同様にリソース負荷が高くパフォーマンスへの影響が大きい処理です。C4 インスタンスでは EBS 最適化オプションがデフォルトで有効になりました。全てのインスタンスは、Nitro システム上でストレージ処理のため専用のリソースが確保されるので、もはや EBS 最適化は必要なくなったのです。これにより、20% のシステムリソースをお客様のインスタンスに割り当てられるようになりました。

C5 インスタンスでの性能のさらなる最適化に関しては、非常に大きな決定が必要でした。Nitro システムは専用ハードウェアでしたが、1 世代目は汎用の ASCI を利用していました。2 代目はスタートアップの Annapurna Labs の ASIC を利用しました。このアプローチはうまく行っていましたが、Nitro の真の長期のビジョンを考えると、違うアプローチを検討しなければいけないことが分かっていました。この時点で、このまま専用ハードウェアを使用する、FPGA を利用する、カスタムシリコンでハードウェアをカスタムするという、3 つの選択肢がありました。高性能で、かつ安価であるという困難な要件でしたが、AWS は Ananapruna 社と協力し、カスタムシリコンでハードウェアをカスタムするという最も適切でハードな選択肢を選びました。C5 インスタンスは、EC2 ソフトウェアと Ananapruna のシリコンの長年に渡る積み重ねによって実現したものです。先日発表している VMware on AWS でもこの Nitro は使用されています。

そして Peter は、EC2 の Bare Metal（ベアメタル）インスタンスのリリースについて発表しました。非仮想化、仮想化の両方のメリットがあり、拡張性があり、セキュアで、ライセンスの制限などにも適用できるものです。

ここで Peter は、Auto Desk 社の Brian Mathews 氏 (VP of Platform Engineering) を壇上に迎えます。現実世界の課題をシミュレーションするソフトウェアを提供する Autodesk は、解像度の向上による計算量の増加をクラウドで解決しており、人間がゴールと制約を入力し、クラウドのコンピューティングパワーを活かして AI が膨大なデザインを生成するジェネレーティブデザインという手法により、オートバイの部品や航空機のパーティションの軽量化を実現しています。Mathews 氏は、「クラウドはコンピュータをオンプレミスからプロバイダに移すだけではなく、コンピューティングの規模を拡大する度に新しい現象を想像させてくれます。より良い世界をつくるためにあなたはクラウドをどう使いますか？」と問いかけてプレゼンテーションを終えました。

次に Peter は、ロードバランサーの進化について語りました。Amazon における初期のロードバランサーは 166MHz CPU、32MB メモリ、16個 の10/100MB ポートを搭載し、独自の HA 機構とフロッピーディスクドライブを持つハードウェアロードバランサーでした。その後多くのベンダーがハードウェアロードバランサーを提供し、信頼性、拡張性、パフォーマンス、コストを競いましたが、それらはコモディティと言うほどには安くなく、コストの大部分を占めるようになりました。もう一つの大きな問題はそれがブラックボックスで問題を特定して修正することが極めて困難だったことです。また、設定が煩雑だったことも問題でした。Amazon はマイクロサービスを指向しており、ロードバランサが管理する VIP は 10 年前の 6000 から現在では 60万 に増えています。これをすべて設定するのは現実的ではありませんでした。そこで、分散型の S3 ロードバランサーを開発し、従来のハードウェアロードバランサーが抱える問題を解決しました。そして、現在はそれを AWS Hyperplane という内部サービスとして 4 つの AWS サービスで活用しています。Amazon Elastic File System は、PB 級のストレージに対する長時間のステートフルなコネクションと、GB 級のスループットを実現しています。また、AWS Managed NAT は数万の長時間コネクションでの数十 GB のスループットを処理し、セキュアなインターネット接続を実現しています。AWS Network Loadbalancer は、AWS のお客様にとっての Hyperplane です。今年 9 月にローンチ後、お客様は数百万リクエスト/秒まで高速にスケールするアプリケーションを構築できるようになりました。

また、今日発表された AWS PrivateLink の新機能では、自分の VPC 上に構築したサービスを異なるアカウントの VPC に共有できるようになりました。これも AWS Hyperplane によって、IPS やファイアウォールの設定をすることなく実装されています。このようにして AWS のロードバランサーは、非常に高いスケーラビリティを実現しました。

スケーラビリティと同時に AWS が最も重視しているのがセキュリティです。AWS の VP and Chief Information Secuirty Officer である Stephen Schmidt が登壇し、AWS におけるセキュリティやイノベーションにおけるセキュリティをどの様に実現しているかを紹介しました。最もセキュリティエラーを引き起こすのはミスコンフィギュレーションであり、よい解決策は tool 化することです、と Stephen は語りました。AWS での取り組み例として、CEO である Andy Jassy と VP との間でセキュリティイシューに関する週次のミーティングがあることや、ローンチする全てのサービスについてセキュリティレビューを実施していること、アプリケーションセキュリティチームは今年、約 1900 件のセキュリティレビューを実施していることなどを紹介しました。

次に AWS におけるセキュリティエンジニアに関する話題に移ります。ここでは AWS にはセキュリティオペレーションセンター（SOC）が無いことや任意の特定のシフトでは 1 人のセキュリティエンジニアがオペレーションを実施している事が明かされます。なぜこの様な事が実現できるのでしょうか。それは自動化されているからです。例えば、AWS ではインフラ全体に共通な問題については、通常 5 分から 15 分の間隔で検知する事ができる様になっています。また復旧に必要なアクションや、フォレンジック調査なども自動化されています。 Stephen は「私たちは皆さんも使っている AWS Lambda を広範囲に利用することで、それらを実現しています」と述べました。

最後に、Stephen は、Amazon Macie チームの設立メンバーである Jenny Brinkley と、Netfilix 社の Chief Product Officer である Greg Peters 氏を壇上へ迎えました。まず Peters 氏はセキュリティに関連する OSS プロジェクトが 15 プロジェクトに達している事や、その多くは AWS と関係するものであり、セキュリティチームが高速で大規模なクラウドへのデプロイメントツールをターゲットにしていることを紹介しました。さらにその他にも、新しいアプリケーションリリース時における最小権限の設定方法に関して、リリース当初は大きめの権限セットを適用し、アプリケーションの振る舞いを観察しながら徐々に最小権限に近づけていくといったアプローチを行っている等、セキュリティに関するディスカッションが行われ、ナイトキーノートを締めくくりました。