AWS Summit Tokyo 2019 振り返りレポート

AWS Summit Tokyo 2019 振り返りです。

ことしは幕張メッセでの3日日間開催。横浜民からすると遠いけど3days 皆勤賞を目指しました。

1日目

基調講演

ステージの上でのダンスに合わせて、リアルタイム?でのエフェクト合成がされていました。

その後、長崎社長による基調講演が開始されました。

特に記憶に残っているキーワードは以下です。

  • クラウド利用者の2人に1人はAWSを選択する。(つまり、シェア50%)
  • この1年間で行ったAWSサービスのアップデートは1957回
  • この約2000回にも及ぶサービスアップデートは、すべて、お客様からの声を反映している
  • 機械学習の利用を支援するサービスを多数用意
  • 「将来のITを支える人材育成を」をキーワードにする「aws educate」
  • 日本国内のAPN(AWS Partner Network)に加盟するパートナー数は2017年では521社だったが、2018年には750社となった

さて、次は、聴講したセッションです。

セッション:AWSでの Operational Excellence ~クラウドで回す監視と運用PDCA

スピーカー:石川 公基氏 (アマゾン ウェブ サービス ジャパン株式会社) 資料

前の現場でめちゃくちゃお世話になった石川さんのセッション。

リソース監視で疲弊していませんか? アプリケーションのクラウド化にあわせて、移行後の運用についてもクラウドに適した形に変えていきましょう。Amazon CloudWatchやAWS Developer Tools のほか、AWS サポートから提供されるツールやサービスを監視・運用の見直しに活用できるポイントをご紹介します。

はい!疲弊しています!!

かいつまんでまとめると・・・・

旧来のリソース死活監視からビジネス監視へシフト

今までは、1台のサーバが停止するとアラートがあがり、オペレータやSEがかけつけて対処するといったことが一般的だった。

しかし、今は、ワークロードに応じてインスタンスが自動的にスケールイン・アウトしたり、自動復旧(自動再作成)したりする。

そのため、1台1台を個別にかわいがるのではなく、そのインスタンスで提供しているサービスつまりビジネスが正常に稼働しているかを監視するようにシフトする。

システムのデプロイや作業を自動化・省力化する

運用手順書などによってオペレータの手作業によって運用されているが、これを自動化・ツール化することで対応の迅速化やヒューマンエラーによる事故を防ぐ。

しかし、全部を一気に切り替えるのは難しいので、一部を自動化・半自動化するなどで少しずつ変えていく。

とくに月次や週次などで繰り返して行うようなものから変えていくと効果的である。

セッション:DNP における CCoE の役割と AWS DeepRacer を活用した人材育成

スピーカー:和田 剛氏 (大日本印刷株式会社) 資料

DNPではパブリッククラウド活用の推進組織としてCCoE(Cloud Center of Excellence)を設立し、コミュニケーションハブとして活動することで、プロジェクト支援や共通サービスの開発、ガイドラインの作成に加えて、人材育成の役割を担っています。本セッションでは、DNPが考えるCCoEの役割と、人材育成の活動の一環として実施しているAWS DeepRacerの社内レースについてご紹介いたします。

従来はオンプレで情報システムを運用していたが、AWSシフトに合わせて、CCoE(Cloud Center of Excellence)を立ち上げて大日本印刷社内のエンジニア育成をはじめた。

現在では140アカウントある。

将来に向けて価値を生み出せるビルダーの育成が急務となった。

そこで、re:Invent2018で発表された、Deep Racer をつかったクラウドエンジニア育成を始めた。

社内レースと共有会

社内レースを月1回開催している。あわせて、Pitと呼んでいる勉強会を週2回行って底上げもはかっている。

この取り組み自体は「業務」として行っている。

海外のサミットレースでの武者修行

Deep Racer で得られたもの

敷居が高い感じていた強化学習がとても身近なものになった。

世界のレベル/温度感がわかり、本気で取り組むとともに、社員のオーナーシップを再確認できた。

また、楽しむ風土を醸成できた。

セッション:Transit Gateway Deep Dive アーキテクチャガイド

スピーカー:菊池 之裕氏 (アマゾン ウェブ サービス ジャパン株式会社) 資料

AWS Transit Gateway はお客様が複数のAmazon Virtual Private Cloud (VPC) とオンプレミスネットワークを単一のゲートウェイに接続できるようにするサービスです。AWS で実行するワークロードの数が増えるにつれ、その増加に対応できるよう複数のアカウントと Amazon VPC 間のネットワークをスケールする能力が必要になります。このセッションでは、AWS Transit Gatewayのアーキテクチャおよびユースケースをより深く説明し、Transit Gatewayを理解し使いこなせるようにご説明いたします。

AWS の通信経路をまとめてわかりやすくするTransit Gatewayのセッションです。少ないVPCしかないとメリットがわかりづらいですが、メッシュ状にPeering接続していたりするような環境では効果が発揮できます。

これまでのAWSのネットワーク管理とTransit Gatwayとの違い

前述のとおり、これまではVPCが複数あり互いに通信したい場合はVPC Peering接続を行っている。このVPCが多数ある場合はメッシュ接続しないとならないし、VPNやDirect Connect(DX)が出てくるとさらに複雑化してくる。

これを簡素化するのがTransit Gateway となる。

Transit Gateway がネットワークの中央にあるハブとなり、個々のVPCやVPN、DXなどをアタッチすることで、今までのようなメッシュ構成にすることなく通信が行える。

TransitGatewayの用語と動作

アタッチメント

Transit Gatewayに接続する、個々のVPCやVPN、DX(Direct Connect Gateway)のこと

ルートテーブル

通信経路の設定。これは複数作ることができる。

アソシエーション

アタッチメント済みのリソースをルートテーブルに結びつけること。

アタッチメントはアソシエートしたルートテーブルにパケットが送信されるようになる。

アタッチメントは1つのルートテーブルにのみアソシエートできる。

プロパゲーション

アタッチメントされたリソースからルートテーブルに経路を伝播すること(プロパゲートしたいアタッチメントを登録する)。

ルートテーブルに伝播した経路が登録され、ルーティングの際に参照される。

プロパゲートはアソシエートに関係なく複数のルーティングテーブルに設定が可能である。

スタティックルート

プロパゲーションとは別にルーティング情報を手動で登録すること。

こちらもルーティングの際に参照される。

ブラックホールルートも設定可能。

指定CIDRに対して、どのアタッチメントに流すかを指定する。

ユースケース

いくつか例示されたユースケースの中で興味をもったのは以下のとおりです。

インターネットに自由に通信できるOutbound Route Domain

NAT Gatewayでインターネットに出る通信について、VPC Peeringの場合は個々のVPCにNAT Gatewayを用意する必要があった。

Transit GatewayではNAT Gatway用のVPCを用意して、そこ1か所へ集約することができる。そのため、NAT Gatewayの料金を抑止することができる。

VPC間のトラフィックをインライン監査するRouteDomein

セキュリティアプライアンスなミドルウェアを稼働させるVPCを用意し、必ずそこを通るようにTransit Gatewayを設定できる。

ただし、このミドルウェアが稼働するインスタンスについては、マルチAZで構成し冗長化を図っておかないと単一障害点(SPOF:Single Point Of Failure)になるのでご注意を。

2日目

セッション:[初級]AWS で始める IoT入門

スピーカー:市川 純氏(アマゾン ウェブ サービス ジャパン株式会社)

資料

re:Invent 2018では新たに4つのサービスが発表され、AWS IoTに関わるサービスは毎年増え続けています。それぞれのサービスがどのような目的で使えるのかなど、これからIoTを始めたいお客様にはサービスの理解、すでにご利用されているお客様には、新たにたされたサービスがどのようなものなのかを理解頂けるような内容となっております。

AWS IoTについての入門的セッションでした。AWS IoTの各種サービスがどういった使われ方をしているのかをユースケースベースでお話されていました。

ユースケース毎のAWS IoT各種サービスの使われ方

お話があったユースケースは以下の通り。

  • コネクティッドホーム(いわゆる、おうちIoT)
  • 工場などの生産現場

わたし自身もAlexaなどのスマートスピーカーや、スマートプラグといったIoT製品を使っています。1個人の自宅でも複数台のIoT機器が存在することになるので、これらのデバイスを管理するのにも、AWS IoTのサービスが利用できます。

コネクティッドホームでのAWS IoTの使われ方

色々とサービスが列挙されていました。

  • AWS IoT Core
    認証サービス
  • AWS IoT Greengrass
    小型コンピュータ(Raspberry piなど)に搭載して使うイメージのサービスLambdaやsagemakerで作ったモデルをもとに推論ができる
  • Amazon FreeRTOS
    電球に埋め込めるくらい小さいデバイス用途のサービス。WiFiやBLE、AWS IoT Coreなどに接続するためのライブラリが入っている
  • AWS IoT Device SDK
    Android、iOS、各種言語のSDKを提供しており、アプリ開発に役立てることができる
  • AWS IoT Things Graph
    プログラミングせず(ノンコーディング)にIoTアプリケーションをサクッと開発できるサービス
  • AWS IoT Device Management
    デバイスの管理や監視を行うサービス。例えば、ファームウェアアップデートのジョブ実行や状況確認も行える
  • AWS IoT Defender
    AWS IoTで管理しているデバイス向けのマネージドなセキュリティサービス。
  • AWS IoT Analytics
    デバイスのデータを収集し、データクレンジングといった前処理、保存、分析、可視化をするサービス

コネクテッドホームでAWS IoTを使うメリット

メリットをまとめると次の通りになります。

  • 大量のデバイスを管理し、セキュアな接続を提供できる
  • 継続的なファームウェアップデートを行う仕組みを利用してデバイスの最新化が行える
  • マイクロコントローラやートウェイ向けのサービスも用意されているのでデバイスに応じた柔軟な対応ができる
  • 収集したデータを分析し、可視化することでビジネスに活かせる

生産現場でのAWS IoTの使われ方

機器故障の予兆検知や実際に故障した際の自動アラート、そして、生産した物品の不良品判別に活用されている。

  • ML Inference
    エッジ側(機器側)つまりクラウド側ではないところでで推論が行える。例えば、画像アップロードにかかるレイテンシを気にすることなく不良品判別などが行える
  • AWS IoT Events
    機器及び一連のデバイスからのデータを継続的に監視し、発生した事象(予兆検知や故障検出)に応じた対応を即座に行える

生産現場でAWS IoTを使うメリット

使われ方に書いてある通り、エッジ側で推論ができるため迅速な判定が行える。同様に、コネクティッドホームに記載あるメリットも享受できる。

セッション:[初級]AWSにおけるデータベースの選択指針

スピーカー:高橋 敏行氏 (アマゾン ウェブ サービス ジャパン株式会社) 資料

データベースは、企業のシステムにおいて重要なコンポーネントの1つです。AWS ではデータベースを実行する方法に多くの選択肢があります。お客様がオンプレミスで使用しているデータベースを AWS に移行する際に、その選択肢の中から最適なものを選ぶガイドラインを、ユースケースと交えてご紹介します。

みんな大好きゆっきーさんによる、AWSに数多あるデータベースサービスからユースケースに沿った選択指針についてご説明いtだきました。

アンマネージドとマネージド

アンマネージドは名前の通り、AWSでマネージメントしないつまり、利用者側でEC2にソフトウェアをインストールしてよしなに使うもの。ゴリゴリにチューニングしたい場合などにはよいがバックアップやパッチあて、ディザスタリカバリーといった諸々の運用作業は利用者側で行う必要がある。

反対にマネージドでは、ユーザーはデーターベースを「利用する」ことだけを考え、バックアップやパッチあて、ディザスタリカバリーといったものはAWSへオフロードできる。

そのマネージドなデータベースサービスは現在では7種類用意されている。

  • リレーショナル:Amazon Relational Database Service
  • キーバリュー:Amazon DynamoDB
  • ドキュメント:Amazon DocumentDB
  • インメモリー:Amazon ElastiCache
  • グラフ:Amazon Neptune
  • 時系列:Amazon Timestream
  • 台帳:Amazon Quantum Ledger Database(QLDB)

用途に応じた使い分け、選択を行う。

リレーショナル (RDS)

AWS でデータベースと言ったら真っ先に思い浮かべる方が多いと思われる[*要出典]、Amazon Relational Database Service(Amazon RDS)です。現在は以下の5つのエンジンとAmazonが開発したAmazon Auroraを合わせて6種類(7種類)存在する。

  • Amazon Aurora(MySQL互換/PostgreSQL互換)
  • MySQL
  • PostgreSQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server

ユースケース

データの正確性や一貫性が最重要視されるようなシステム、アプリケーションで使用される。

例えば、商品情報や顧客情報といったものを管理するもの

キーバリュー

キーとバリューで構成されるデータベースのこと。リレーショナルデータベースにあるスキーマといった概念がないため、読み書きする際のクエリがシンプルになり、低遅延で高スループットな対応が可能になる。ただし、基本的には「結果整合性」という考え方になっているため、「最終的に正しければよい」ものなので、読み取りのタイミングによっては更新前のデータが返ることがあるのでそのあたりを加味したアプリケーション実装が求められる。

  • Amazon DynamoDB

ユースケース

モバイルアプリやウェブアプリ、ゲーム、広告、お買い物サイトのショッピングカートといったもの

ドキュメント

キーバリューに考え方が近く、JSONやXMLといったものでデータが構造化されている。複雑なデータモデルにも対応できる。

  • Amazon DocumentDB(MongoDB互換)

ユースケース

ニュースやブログといったコンテンツの管理。リレーショナルデータベースではスキーマ設計が必要になるが、属性情報が頻繁に増えたり減ったりとする場合に追随するのが難しいため、ドキュメントデータベースを選択すると良い

インメモリー

キーバーリューデータベースと同じく、キーとバリューで構成されるデータベースであるが、インメモリーの名の通り、メモリ上で読み書きが行われるため非常に高いパフォーマンスが発揮される。特にミリ秒単位での応答が求められるといったリアルタイム性の高いアプリケーションの課題を解消できる。

  • Amazon ElastiCache

ユースケース

データや推論、クエリといったものをキャッシュし超高速レスポンスが必要なアプリケーションの場合に選択する

ただし、インメモリのため障害発生時などにデータが吹っ飛ぶ可能性があるため、データ損失リスクも考えて、消えても良いデータなのか消えると困るものなのか、困るなら定期保存するといったことも合わせて考える。

グラフ

データの複雑な「関係性」を表すのに適したデータベース種別。関連が1対1ではなく他対他になっている。

  • Amazon Neptune

ユースケース

SNSのともだちといった関連性、これを買った人はこれも買っていますといったおすすめ(リコメンデーション)機能といったものを実現する際に選択する。

時系列

「時間」が唯一の軸となり、特定の間隔ででデータが記録され、その経過に伴う変化を測定する。つまり、パフォーマンスログといった絶え間なく出力されるデータの分析をすることを得意とする。

  • Amazon Timestream(プレビュー)

ユースケース

多数のソース(例:管理対象マシン)から大量で粒度が小さいデータを即座に分析したい場合に選択する

台帳

データの変更を検証・追跡し、改ざんされていないことがつねに求められるものを管理するためのもの

  • Amazon Quantum Ledger Database(プレビュー)

ユースケース

病院で使用するカルテや住民票や戸籍といった、改ざいが起きたら本当にまずいものの管理をする際に選択する。

DeepRacer ワークショップ

講師:中田 光昭氏(アマゾン ウェブ サービス ジャパン株式会社) 資料

AWS DeepRacer は、 1/18 スケールのレーシングカーを利用して、強化学習を楽しみながら理解できるサービスです。強化学習に必要な環境はすべて AWS DeepRacer によって提供され、ユーザはレーシングカーを上手く走らせるための強化学習に集中することができます。AWS DeepRacer ワークショップでは、強化学習を体験しながら、実際のレーシングカーを走らせる方法をお伝えします。具体的には、強化学習の基礎的な内容を紹介し、コンソールの利用方法や、レーシングカーが走る様子をシミュレーションで確認する方法をご説明します。

資料にあるハンズオンテキストをもとにAWS DeepRacerのコンソールから強化学習を行って、バーチャルサーキットで走らせるといったものでした。

説明や資料がとても親切丁寧なため、機械学習初心者でもすんなりと始められる内容でした。

3日目

俺たちの AWS loft Tokyo. 実際に作ってみたらこうなった。

スピーカー:松田 和樹氏(アマゾン ウェブ サービス ジャパン株式会社)
ゲストスピピーカー:
伊藤 哲志氏(株式会社tyotto)
宮崎 翔平氏(スマートマキアート)

資料

AWS Loft Tokyoとは

スタートアップとデベロッパーが学び、コーディングし、交流し「挑戦をカタチにする場所へ」をキーワードに提供されているスペース

  • コワーキングスペース
  • Ask An Expertカウンター
  • イベント・セミナー

といったものが提供されている

Loft を活用されているお客様の事例

伊藤 哲志氏(株式会社tyotto)の事例

教育で世界をちょっと(tyotto)良くするをキーワードに活動。

学習塾の運営やキャリア教育コンテンツの開発、学習支援アプリの開発を手掛けている。

AWS Loftは日々のコワーキング利用と、技術課題に直面した際に、Ask An Expertを利用している。また、AWS主催のセミナーにも参加している。

Ask An Expert 質問事例としては資料に挙げられていただけで40件!スライドに小さい文字でびっしりとなっていた。

宮崎 翔平氏(スマートマキアート)の事例

AWS Loft で作ったもので特許を取られた方。わたしが尊敬する友人。

事例紹介では以下のAWS Loft で作ったものを挙げられていました。

  • 音声サービスのログ収集・分析結果提供システム(特許出願)
  • Alexaスキル「ヒロインの告白
  • 声によるユーザレビュー機能

やはり、開発で行き詰まった際に Ask An Expert を活用して課題を解決していたそうです。

これから利用される方へ

新しいことに挑戦する人は 特別 な人ではないし、まずは一歩目を踏み出すことが重要である。

まとめ

当初の目標通り、皆勤賞になりましたが、やはりAWSのカンファレンスは学びが多いです。泣く泣く参加できなかったセッションについても、参加された話を聞くと本当にそう感じます。

来年は横浜だそうで、幕張メッセよりも行きやすいので今からとても楽しみで仕方ありません。