« 2016 | もくじ |

レポート

AWS Summit Tokyo 2017

～イノベーションを加速する AWS の Super Powers～

株式会社オージス総研

大西洋平、矢田恵子

2017年6月15日

AWSに関する日本最大級のイベント「AWS Summit 2017」が 2017/5/31～6/2 に開催されました。今年は、基調講演・セッション・展示ブースで AI や IoT を取り上げる内容が増え、AWS の適用領域がクラウドから AI・IoT の領域へ大きく拡大していることを感じさせるイベントになりました。本記事では著者が聴講したセッションを中心にイベントの模様をお伝えします。

aws

参加の動機

大西

普段、IoT に関する技術開発に携わっており、顧客案件から自社製品・サービス開発やデモ開発において毎日のように AWS を活用しています。また、昨今、AI 技術に対するニーズの高まりを受け、個人的に機械学習を勉強しています。今年の AWS Summit Tokyo は、特に IoT や AI に関するセッションが増えているため、その最新動向や、近年盛り上がっている分野の技術・事例動向の調査のために参加しました。

矢田

現在、サーバレスアーキテクチャに触れる機会が多いことと、業務にかまけてAWS関連の知識に対するブラッシュアップがここ暫く滞っていたこともあり、今回は、業務に直結する所（主にサーバレスアーキテクチャやセキュリティ）に関連したセッションを中心に聴講してきました。

セッション紹介（Day 3）

Day 3 基調講演（キーノート）

セッション紹介ページ

Keynote

（基調講演開始前の様子。なんと DJ ありで、このライティング！技術系カンファレンスとは思えない雰囲気でした・・・）

スピーカ

ホストスピーカー：
- Werner Vogels 氏, CTO Amazon.com
ゲストスピーカー：
- 中村浩氏, 東日本電信電話株式会社取締役ビジネス開発本部副本部長兼第一部門長
- 川西泉氏, ソニーモバイルコミュニケーションズ株式会社取締役 EVP
- 藤本真樹氏, グリー株式会社開発・人事統括取締役執行役員常務 CTO
- 安川健太氏, 株式会社ソラコム最高技術責任者

セッション概要

Amazon.com CTO Werner Vogels 氏がホストスピーカーを務め、「AWS を利用することで、企業の規模や種類に関係なく、Super Powers（超能力）を手に入れることができる」と切り出し、AWS クラウドサービスおよび活用事例が紹介された。
AWS で得られる “Super Powers（超能力）” とそれを実現するサービス
- SUPERSONIC SPEED（超音速）：ハードウェアによる計算の高速化
  - EC2 GPU インスタンス（P2）、EC2 FPGAインスタンス（F1）
- INVISIBILITY （目に見えない）：サーバを維持管理することなく、クラウドアプリケーション開発に専念できる
  - AWS Lambda：サーバレスなコード実行
  - AWS Step Functions：視覚的なワークフローを使って分散アプリケーションの構築
  - AWS X-Ray：運用環境で分散アプリケーションの分析とデバッグ
  - AWS DynamoDB Accelerator: 完全マネージド型のインメモリキャッシュを提供し、クエリのパフォーマンスを通常の DynamoDB の10倍にまで改善
  - AWS IoT： IoT 向けメッセージブローカ、ルールエンジン、認証認可基盤
  - AWS Greengrass：エッジコンピューティング向けの AWS Lambda 環境
- FLIGHT（飛び立つ）：AWS へのデータ移行
  - Amazon Aurora：MySQL、PostgreSQL 互換のマネージドDB
- X-RAYビジョン（透視）：ビッグデータ分析
  - Amazon Athena：標準 SQL を使って S3 のデータを簡単に分析できるインタラクティブなクエリサービス
  - Amazon EMR：ビッグデータを処理するための一般的なフレームワークを使って大規模なデータセットを分析
  - Amazon Redshift：複雑なクエリの実行と超高速なクエリパフォーマンスを可能にするペタバイト規模のデータウェアハウス
  - Amazon Redshift Spectrum： Amazon S3内のエクサバイト級のデータを直接クエリ
- PRECOGNITION （予見）：機械学習
  - Amazon Machine Learning：基本的な機械学習モデルの作成・実行
  - Deep Learning AMI：深層学習の実行環境があらかじめ整備された AMI
  - Amazon Rekognition：画像認識
  - Amazon Polly：音声合成
  - Amazon Lex：音声認識および自然言語理解
- IMMORTALITY（不朽）：絶え間ないイノベーション
  - 日々、新しい機能を追加

参考資料

Day3 基調講演動画（英語）
- 講演資料
if-up 2017 | SORACOM Inside - IoTスケールなプラットフォームの構築と運用
- 本資料はソラコム主催の技術カンファレンス if-up 2017 の際に、ソラコム CTO 安川氏がシステムの内部アーキテクチャを紹介した資料。基調講演中にもほぼ同じ内容の資料が使われた。

所感

大西

講演者 Werner Vogels 氏の「AWS を利用することで、企業の規模や種類に関係なく、Super Powers（超能力）を手に入れることができる」という言葉を端的に表しているのが、ソラコム社だと感じました。ソラコム社は、2015 年に設立されたスタートアップにも関わらず、いっきに IoT 向け通信の新サービスを立て続けにリリースし、すでに欧米やアジアの主要先進国でサービスを展開しています。

ソラコム CTO 安川氏の講演いわく、このスピードが実現できたのは、AWS の基盤上に AWS の設計思想に忠実に最初からグローバル展開できるようにシステムを設計したからだそうです（安川氏は、ソラコム以前は、米国 AWS で DynamoDB の開発チームに参加しており、講演者の Werner Vogels の元で分散システムの開発に携わっていた経験があるそうです）。

基調講演から、今後 AWS は IoT、AI の領域へイノベーションを拡大しようとしていることが分かりました。

IoT 分野
- AWS からクラウドとデバイスをつなぐメッセージブローカ（AWS IoT）
- エッジコンピューティング環境（AWS Greengrass）
AI 分野
- 学習済みの深層学習モデルがクラウド経由で即座に利用できる（Rekognition、Polly、Lex）
- カスタムの深層学習モデルの学習や実行がすぐに始められる環境（Deep Learning AMI）

大きな資本を持たないスタートアップであっても、これらのサービスを利用し、短期間に自社製品・サービスを展開する事例が今後も増えていくと予想されます。競争のスピードが加速する中で、技術者にとっても、AWS のようなサービスを徹底的に使い、より速いサイクルで開発を進めることが強く求められると感じました。

DevSecOps on AWS - Policy in Code

セッション紹介ページ

SecDevOps

スピーカー

酒德知明氏、アマゾンウェブサービスジャパン株式会社技術統括本部パートナーソリューションアーキテクト

セッション概要

DevSecOpsについて
- DevOpsの概念のなかでセキュリティ・コンプライアンスも一緒に考えて行く
  - セキュリティ・コンプライアンスは、今まではPDCAを回すのがとても大変だったが、AWSの様々なサービスを組み合わせることで、DevOpsの中で一緒にループを回していけるようになる
アカウントの管理
- グランドルールや、必要な時にアカウントのアップデートを実施するにあたっていかに自動化を行うか
- AWS IAMを利用する。
  - ユーザーにはロールで権限を付与する。ロールを付け直すことで、別の権限が利用可能になる。
- git-secretsの活用
  - アクセスキーのソースコード内埋め込み防止や、すでにうっかり埋め込んでしまったアクセスキーを発見するためのツール。
ProActiveMonitoringLifeCycleの考え方
- AWS上では、権限付与を最小限として厳しく制限するよりも、やってはいけないことをどう防止するか、を管理するほうが良い
- AWSの多数のサービスを開発者に横断的に見てもらうことで
- CloudTrail(API実行の記録)、CloudWatchEvent(APIイベントの検知)、Config(設定値の記録)、Lambda(イベントトリガーにアクションを実行)を組み合わせて、「特定の操作を行ったユーザーに対して、権限を剥奪しつつ、特定の操作前の状態に戻す」ということが実現可能
Multi Region＋Multi Account
- 複数リージョン・複数アカウントで、同様の管理を行いたい場合にどのように実施するのか
セキュリティベースラインの考え方
- ベースラインは、Dev,Ops,Secの3者が、一緒に話しながら作って行くもの

参考 URL

所感

矢田

「DevOps」はよく聞きますが、それにSec（セキュリティ）が加わっている、ということがどういうことなのか興味があり、セッションに参加しました。 ProActiveMonitoringLifeCycleの考え方は、「何かが発生したときに、防御と対処を同時に行うことができる」からこそ生まれたもので、そのおかげで「エンジニアに権限を与えて色々とサービスを試してもらうこと」が可能となり、プロダクトやプロジェクト環境をより良いモノにしていくことができるのかな、と感じています。実際のプロジェクトに、ProActiveMonitoringLifeCycleの考え方を適用していくには、なかなか難しい部分もありますが、小さな範囲からでも少しずつ導入していくようにしたいと考えています。

AWS Greengrass Deep Dive

セッション紹介ページ

スピーカ

Craig Williams, Partner Solutions Architect, IoT Specialist Amazon Web Services, Inc.

セッション概要

AWS Greengrass
- 「エッジコンピューティング」を実現するためのサービス
  - データの生成源であるデバイスの近傍にあるコンピュータで一種のデータ処理・分析を行う技術
- エッジコンピューティングの背景
  - クラウドに接続できない機器がまだ多くある（医療機器、産業機器、僻地にある機器）
    - 物理的に通信環境を用意できない
    - 経済的に割に合わない
    - セキュリティやプライバシーに関する法律によりクラウドへデータを上げられない
機能
- AWS Lambda： Lambda 関数をエッジデバイスで実行できる
- デバイスシャドウ：デバイスの状態をデバイスとクラウドで自動的に同期できる
- メッセージ：ローカルまたはリモートの MQTT ブローカとメッセージの送受信ができる
- セキュリティ： AWS IoT 認証・認可基盤と同一のものをローカルのデバイスに適用できる
メリット
- ローカルイベントへの即時応答
  - クラウドへの問合せを行わずに処理する。
- オフラインでのオペレーション継続
  - デバイスの近傍である程度処理が完結する。
  - ネットワークが接続したタイミングでクラウドと状態の同期を行う。
- 通信コストの削減
  - クラウドへの問合せを減らすことで通信コストを削減する。
AWS Greengrass の構成
- AWS Greengrass Core ・・・ Greengrassの実行環境
  - 要件
    - CPU：最低 1GHz、x86 または ARM
    - RAM： 128 MB
    - OS: Linux（Ubuntu または Amazon Linux）
- AWS IoT Device SDK
  - AWS IoT と接続するデバイス向けアプリケーションの開発環境（C/C++、Node.js他）

参考資料

AWS Greengrass 製品ページ
AWS Greengrass Documentation
Getting Started with AWS Greengrass
- 製品の概要紹介動画（英語）
Announcing AWS Greengrass - January 2017 AWS Online Tech Talks
- エンジニア向けのオンラインセミナー動画（英語）
- 資料
Developer.IO - 【レポート】AWS Summit Tokyo 2017：AWS Greengrass Deep Dive #AWSSummit

所感

大西

一部の IoT システムでは、ローカルイベントへの即時応答、オフラインでのオペレーション継続、通信コストの削減などの理由により、エッジコンピューティングのような技術を利用する機会は今後増えてくると予想されます。その際、自前で全てを構築すると開発コストが膨大になるため、既存の製品を利用することが一般的です。

AWS Greengrass の場合、以下の理由から、クラウド側で AWS IoT や AWS Lambda を活用している場合に良いオプションであると感じました。

認証認可のモデルが AWS IoT と共通
AWS Lambda 関数を動かせる
AWS IoT との連携がサポートされている

AWS で実現するセキュリティ・オートメーション

スピーカー

桐山隼人氏、アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト

概要

何のためのオートメーションなのか
- 自動化によって得られる効率化は勿論だが、それだけが目的ではなく、効率化の先にある革新へ向かうためのもの
- データの「集約 → 可視化・効果測定 → 意思決定」が自動化されることで、「やる」「やらない」を決定することができる。この一連の流れを繰り返すことで、革新を目指して行く
  - このオートメーションの仕組みをセキュリティに対して適用していく
何をオートメーション化するのか
- オートメーション化を意識したプロセス・継続的な分類として適応型セキュリティアーキテクチャを考えると良い
  - 防御、検知、対応、予測の 4 象限＋象限の中心に継続的な監視・分析
  - AWSサービスとして、これらの象限に対応したものがあるので、組み合わせて利用していく
どのようにオートメーション化するのか
- IPアドレスのブラックリスト反映
  - 定期的にLambdaを用いて、ブラックリストをダウンロード、WAFにブラックリストを登録し、WAFではその情報を元にブロックする。
- 端末自動隔離
  - 定期的にLambdaでInspectorを呼び出しEC2の脆弱性を診断、NGだったものはLambdaでNACL/SGポートブロックを実行（論理的に隔離）する。
  - 結果はSNSで通知したり、ポートブロックのログをFlow Logsに表示する。
  - 合わせて、何が起きたかを調査するためにEBSのスナップショットを取得する。
- 情報の可視化
  - VPC Flow Logs 、Elasticsearch、Kibanaを用いてダッシュボードとして利用する。
  - DGA（Domain Generation Algorithm）を用いて生成されたドメインからのアクセス排除
    - DGAにて生成されたドメインをMachine Learningで学習させた情報を用いて、不審なドメインの場合に、WAFに登録してブロック
    - 精度もかなり高い（90%超）
  - リスクベースでのセキュリティ戦略が可能
    - AWSのサービスを組み合わせることで、リスクベースでのセキュリティ対策の意思決定が可能となる。

参考URL

所感

矢田

セキュリティに対する自動化を実現するための例は、とても勉強になりました。先に参加したDevSecOpsの考え方も合わせて適用をしていきたいと考えています。それよりも、機械学習を用いて、不審なドメインを予測して防ぐというやり方もあったのか！と目から鱗でした。今後、セキュリティの予防の観点から機械学習を使って不審なものは排除する、というパターンはどんどん出てくるのではないか、と感じています。

[アプトポッド] リアルタイムな双方向ファストデータ伝送を実現する高速 IoT 基盤 - 開発・運用のこれまでとこれから

セッション紹介ページ

スピーカ

坂元淳一氏, 株式会社アプトポッド代表取締役
梶田裕高氏, 株式会社アプトポッド CTO
柏崎輝氏, 株式会社アプトポッドサーバー・インフラリードアーキテクト

セッション概要

アプトポッド社
- 自動車、産業機器などのモバイルインターネット経由でのリアルタイムな遠隔診断や遠隔制御及びデータ解析などを実現するエンドツーエンドの超高速 IoT フレームワーク intdash を開発・提供している。
製品
- intdash
- アプトポッド社の IoT フレームワーク
- Websocket 上に独自プロトコルを実装
  - デバイス・クラウド・ブラウザを接続
  - リアルタイム（ミリ秒単位のレイテンシ）かつ双方向でメッセージが送れる
  - エンド・ツー・エンドでのデータの完全性を保証している
- Visual M2M
- intdash で収集したデータを可視化する BI ツール
- マウス操作で簡単にダッシュボードが作成できる
開発動機
- 当初は、デバイス・クラウドの連携に MQTT、クラウド・BI ツール間は HTTP を使っていた。
- 以下の理由により、Websocket上に、完全性を担保する独自プロトコルを開発するにいたった。
  - MQTT 最新プロトコルバージョン 3.1.1 で、プロトコルレベルでのエンド･ツー･エンドでの到達保証をサポートしていない。3.1.1 でサポートしているのは、クライアント・ブローカ間のみ。その先のクライアントへの到達保証はしていない。（筆者注）次期バージョンである 5.0 では、エンド・ツー・エンドでの到達保証が検討されている。
  - 全てのパケットにトピック名が入り、小さいデータを頻繁に送付する用途によってはオーバヘッドが大きい。
  - BI ツールとクラウド間の通信を HTTP で行うと、クラウド上のイベント発生をポーリングで問い合わせるスタイルになるため、即時性が低い。
活用実績
- 自動車研究開発工程における遠隔データ収集基盤
- ヨーロッパ広域における量産車両の長期リモートデータログ
- 遠隔での機械装置診断システム
- 安全運転の自動判定システム
- ウェアラブルバイタルセンサーによる遠隔ストレス診断システム
- 遠隔での機械制御PoC

参考資料

所感

大西

MQTT がエンド・ツー・エンドでの到達保証をサポートしていないため、完全性が重要なユースケースにおいては、アプリケーションレベルでエンド・ツー・エンドでの到達保証をサポートする独自プロトコルを実装するという例を筆者自身も見たことがあります。これを、プロジェクト内で開発しようとすると、膨大な開発コストがかかるため、アプリケーション開発者としてはミドルウェアのレイヤーで対処してほしい問題だと思います。その点で、アプトボット社の製品は非常に有益だと思います。

全ての IoT システムにおいてリアルタイムでの転送が必須になるわけではありません。そのために、アプトポット社は、一見、特定のユースケースに特化したソリューションを提供しようとしているように見えます。しかし、AWS のようなクラウドベンダーが汎用的な IoT プラットフォームを提供しているため、同様の IoT プラットフォームを提供するベンダーが今後生き残る上では、市場での立ち居地をはっきりし、大手ベンダーのサービスがカバーしない、または、できないニッチ領域へ積極的にソリューションを提供することが重要だと感じました。

アプトポッド社がターゲットにしているリアルタイム性の強いユースケースは、技術が成熟するにしたがって、今後、市場が拡大していきそうな可能性を感じました。

セッション紹介（Day 4）

[JINS] バイタルデータの意味付けという荒波を乗り越える！適切な処理分担のためのサーバーレスアーキテクチャー

セッション紹介ページ

スピーカー：

菰田泰生氏、株式会社ジンズ JINS MEMEグループ技術責任者

概要

バイタル(生体)データ
- IoTのバイタルデータ自体の事例は少ない
  - あっても心拍センサーの事例が大半
  - これは心拍センターは、枯れたデバイス・アルゴリズムで利用できることが大きい。またノイズや空白などで情報が欠けたとしても、周波数が一定なので予測しやすいため、ノイズ除去がやりやすいため。
- MEMEで利用する眼電位のデータはとても大変
  - ノイズが多い上に、予測が付けづらい。
  - 生データそのままだとデータ量が多い（ちょっとした音楽ストリームと同じレベル）
MEMEでのアルゴリズムの制約
- MEMEに搭載しているCPUは、割り算ができないタイプのモノ（Cortex-M0/MSP）
- ハード的な制約でアルゴリズムにも制約がかかる。（CPUだけでなくバッテリーなども）
- レイヤー毎の多段処理がまだまだ必要。
将来的な処理フロー
- MEMEの中で特徴点抽出、サマライズして次にわたせるようにしたい。
- スマホ側では、MEMEの情報とクラウドの情報を融合して、意味づけられたデータを生成してサービスを提供できるようにしたい。
サーバーのアーキテクチャ
- 当初は、EC2→ DynamoDB
- その後、Kinesis→ ElasticBeanstalk → DynamoDB → ElasticBeanstalk → S3
- さらに進化して、Kinesis→ Lambda → DynamoDB → Lambda → S3
- ある日突然良いサービスが提供されたときも、サービスを差し替えやすいように作成している。
開発プロセスでは、開発スピードを重視
- プロトタイピングでは、Web上でほぼリアルタイムに結果を確認することでロジックを即検証できるように、本番では1レイヤーずつ、問題無いことを確認しながらリリースする。

参考URL

所感

矢田

ハード的な制約によってアルゴリズムに制約が出たり、いかに少ないリソースで、必要な情報を抽出するか、という点の苦労が伝わってきて、自分が持っていない新たな目線で物事を見れるようになって良かったです。また、「サービスの差し替えはある」ということを念頭に入れた形で、差し替えやすいようにアーキテクチャを考慮している点は、自分はちょくちょく忘れる部分でもあるので、アーキテクチャを考える際に念頭に入れつつ検討できるようにしておきたいと思います。

サーバレスで王道 Web フレームワークを使う方法

セッション紹介ページ

スピーカー

塚田朗弘氏、アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト

概要

いつものフレームワークを使うにはどうするの？
- サーバレスアーキテクチャ（Lambda＋APIGateway）で、いつものフレームワークを使う方法について。今回は、node.js(Express.js)とJava(Spring)のフレームワークについて。
Express.jsの場合
- サンプルは、github/awslabsにあるサンプルコードを取得して実行すればOK
- 実際に既存のプロジェクトをマイグレーションしたい場合は
  - 必要なファイルをサンプルコードからコピー
  - package.jsonの中の「scripts」と「config」をコピーするなど、必要な設定を行うと動作させることが可能
Springの場合
- サンプルは、github/awslabsにあるサンプルコードを取得後、
  - MavenでPackage作成
  - CloudFormationパッケージの作成
  - デプロイを実行することで、サンプルが利用できる
- 実際に既存のファイルをマイグレーションしたい場合は
  - pom.xmlで依存関係を設定
  - LambdaHandlerを作成
  - Lambda関数をパッケージングしてデプロイする
  - API GatewayやCloudFormationの作成・設定は、サンプルコードが参考になる。

参考 URL

所感

矢田

思っていた以上に簡単に王道のフレームワークがサーバレスアーキテクチャ上でも使えることに驚きました（特にExpress.jsを利用した場合）。（個人的には、Pythonでもこの仕組みがあるといいなあ…と思いつつ）また、今回awslabsの紹介もあったのですが、このリポジトリの存在自体は知っていたものの、普段はサンプルのお世話になる程度で、あまりじっくりと他の内容は見ていませんでした。想像以上に色々な(面白い)ものが置かれていることも分かったので、これからはここのリポジトリも色々と参考にさせていただきたいと思います。

Testable Lambda: Working Effectively with Legacy Lambda

セッション紹介ページ

スピーカ

和田卓人氏、タワーズ・クエスト株式会社取締役社長

概要

AWS Lambda に対する自動テストのベストプラクティスはまだない。
ここで言うレガシーコードとは、テストがないコードのこと。
- テストコードが書かれていない
できる限り、最小の時間で回せるように工夫をしていく必要がある
- ローカルでも実行できるところはローカルでテストを行う。
- localstack（AWSのローカル実装）を使うとローカル上でもAWSとの疎通テストを擬似的に実行可能。
レガシーコードと闘う為には、カバレッジを可視化することがとても重要
テストの大きさの概念
- プロジェクト単位で決める。small,medium,largeの3種類
- テストの実施時間が異なるフィードバックループを作ること。
運用監視もテストと考える
- 監視は継続的なテストである

参考 URL

所感

矢田

今回のAWS Summitの中でも一番楽しみにしていたセッションで、現在、Lambdaでのテストをどう回していくか悩んでいることもあり、何か一つでも持ち帰れられるものがあれば…と参加しました。ベストプラクティスはまだない、との事ですが、色々な工夫によって早くテストを回すための方法(localstackを用いてローカルで素早く回す、など)や、テストの大きさやフィードバックループの考え方など早速取り入れて行きたいと感じました。

サーバーレスアプリケーションのための CI/CD パイプライン構築

セッション紹介ページ

スピーカー

小梁川貴史氏、アマゾンウェブサービスジャパン株式会社技術統括本部パートナーソリューションアーキテクト

概要

CI/CDについて
- CI(Continuous Integration)
- CD(Continuous Delivery or Deployment)
- Delivery：テスト通過後、本番環境へのリリース判断後に本番リリース
- Deploy：テスト通過後、そのまま本番環境へリリース
SAMについて
- Severless Application Modelの略
- 実体はCloudFormationだが、サーバレスに向けて最適化されたもので、Lambda、APIGateway、DynamoDBをリソースとして指定可能。
SAMとCODEシリーズサービスの連携
- CodePipeline、CodeCommit、CodeBuildと連携してデプロイフローを作る
- CodeCommitにコードをPush、CodePipelineが変更を検知してCodeBuildにbuild指示を送る
CI/CDのためのプログラミング
- Lambdaは、テストしやすい＆管理しやすい単位で作成する
- ひとつのLambdaで表現可能だとしても出来るだけ切り分ける
- 環境情報は環境変数を利用して取得するようにする
サーバレスといっても特別なことは何もない。
ただし、テスト品質は人に依存する部分。CI/CDで浮いた工数を使ってより価値のあるところに注力して欲しい

参考 URL

所感

矢田

Lambdaのデプロイ手法についても色々な方法がありますが、SAMを使った場合にどのようになるかを知りたくて参加しましたが、SAMとCODEシリーズと連携させてフローを作ったり、そのフローとしても判断フェーズを入れてリリースできるのは、なかなか良さそうだな…と感じました。また、サーバレスといっても特別な事はないことや、テスト品質の重要性についても改めて認識出来て良かったと思います。

おわりに

大西

今回、AWS Summit Tokyo に参加して、3年目になります。3年で変わったと感じた点が2点あります。

AWS は誰でも利用する共通のインフラになった
- この 3 年で AWS のサービス、コミュニティ、利活用のノウハウが成熟してきた感があります。AWS は、もはや誰でも利用する、共通のインフラとなっているので、使うだけでは優位性は得られません。いかに効果的に活用するか？へ世間の関心が移っていると思います。
AWS サービスの領域が IoT や AI に広がってきた
- 今回の AWS Summit Tokyo 2017 の基調講演であるように、大手クラウドベンダーが IoT や AI 分野にサービスを提供し始めています。今後も、ボリュームゾーンとなる領域に、大手ベンダーが低コストなサービスを提供してくることが想定されます。それにより、ますます IoT や AI の技術を活用したアプリケーションがより早く、より低コストで実現できるようになります。

キーノート講演者 Werner Vogels 氏の「AWS を利用することで、企業の規模や種類に関係なく、Super Powers（超能力）を手に入れることができる」というメッセージの通り、活用の仕方次第では、AWS 登場以前では技術面・コスト面で不可能だったようなスケールのアプリケーションも低コストで実現できます。

今後は、AWS のような誰でも利用できるサービスを理解して、使いこなし、その上で機動的に開発する能力で勝負する時代になってきています。自社のリソースを投入すべき競争領域を見定め、可能な限り、既存の製品・サービスを活用することでリバレッジを効かせ、素早く低コストにアプリケーションをリリースしていくことが重要であると感じました。

矢田

今回で 3 回目の参加となります。過去2回と比較して、開催期間も増え、人数も増え、会場も増え（！）と、かなり大きなイベントになっているのを肌身をもって感じました。前回は人混みで移動もかなり大変だったのですが、今回は会場が2カ所に大きく分散されたこともあり、そこまで酷い混雑もなく、スムーズに移動もでき、セッションの参加も問題なく出来たと感じています。（…とはいいつつ、その2つ会場の物理的な距離がソコソコ離れており、移動が大変だった気も…）

今回、会場2カ所のうちの1カ所を利用して、初めてDev dayとして独立した開発者向けのカンファレンス(日本が初めて、とのこと)が実施されたり、18:00以降にもアンコールセッションとしてテクニカルセッションの一部が再演されるなど、技術要素に関する知識のアップデートにはもってこい、な内容となっていて、変化が激しいAWSサービスの情報をまとめてキャッチアップできたのは、とてもありがたかったです。

Serverless Day

また、AWSとしても、今まで以上にServerlessに力を入れている印象を受けました。Dev dayの中でも「Serverless Day」として、1日特集を組まれていたりと、サーバレスアーキテクチャに関わっている身としてはとてもありがたい構成になっていました。また、セキュリティに関するセッションも数多く、『日本の場合だと「クラウドはセキュリティが心配だから使いたくない」と話す顧客が多い』とのことで、AWSとして、クラウド利用に踏み切れていない顧客の不安を払拭して、よりクラウドを多くの顧客に利用してもらえるようにしたい…という意図も感じ取れる機会となりました。

更新記録

2017/7/13（木）矢田のレポートを追記しました。
- Day3
  - DevSecOps on AWS - Policy in Code
  - AWS で実現するセキュリティ・オートメーション
- Day4

« 2016

AWS Summit Tokyo 2017

目次

参加の動機

大西

矢田

スピーカ

セッション概要

参考資料

所感

大西

スピーカ

セッション概要

参考資料

所感

大西

矢田

スピーカー

セッション概要

参考 URL

所感

矢田

スピーカ

セッション概要

参考資料

所感

大西

スピーカー

概要

参考URL

所感

矢田

スピーカ

セッション概要

参考資料

所感

大西

スピーカー：

概要

参考URL

所感

矢田

スピーカー

概要

参考 URL

所感

矢田

スピーカ

概要

参考 URL

所感

矢田

スピーカー

概要

参考 URL

所感

矢田

大西

矢田

更新記録