AWS峰会第三天

2019年6月14日，地点在幕张国际展览中心。

基调演讲

方便用中文表达”メルカリ”

• AI/ML

Image Search

EKS Cluster 利用して、S3に保管しているイメージを使ってトレーニング
S3

充実したイベントフック、ツール群とエコシステム

AI出品

出品しようとしたもののブランドなどを推測、入力支援

AML Tech Stack
Splunk

Amazon Kinesis

ログ収集パイプライン
splunkに標準対応

松下

• くらしのCyber Physical化

 

• 眼によるセンシングに着目：85％を目からセンシング

Vieureka PlatformをAWS上に構築

エッジデバイス上で映像をAI処理

エッジデバイスからMetadataをクラウドに送信
クラウド上で機械学習、推論モデル生成
クラウドから戻ってきた後でエッジデータ上で再推論、再強化

来客分析

カメラ毎に人数カウントや性別・年齢推定、滞留時間を収集・分析

入退室管理

カラービットを読み取って入退室管理

合成的整体

• 人工知能を利用することで、天才に依存せずに科学的な発明を

 

• 創薬分野

医薬品の開発にかかるコスト・期間

人工知能によって分子を推測、実験、モデルの改良
人間だと数か月→数秒に

病気のもととなるたんぱく質を阻害する分子を設計
AWSで科学者が機械学習エンジニアに
仮説検証を今までにない精度と速度で
AIによりライフサイエンス領域は新時代へ

【初级】AWS容器服务入门

• Amazon ECS

Dockerオペレーション自動化
クラウドでコンテナを本番環境利用するためのオーケストレーター　2014　初のフルマネージドオーケストレータ
AWSサービスとの高度な連携
多様なワークロードをサポートする「タスク」と「サービス」というシンプルなリソース表現
Linux/Windowsサポート

Amazon EKS

2018　51%のkubernetesユーザーがAWS上で動かしていた→AWSでサービス化
運用難易度の高いKubernetesマスターをマネージドで提供
OSSそのままのKubernetes：他と移行可能なCNCF Certified
各種AWSと連携
EKSサービスチームOSSチームによるKubenetesコミュニティへの貢献
オープンソース
Pod,Deployment,Service,Jobなどのリソースに代表される高い表現力

Amazon ECR

フルマネージドなプライベートコンテナレジストリ
セキュア：保管イメージの自動的な暗号化、IAM連携
スケーラブルかつ高い可用性
Docker CLIから利用可能

ECS/EKS/Kubernetesだけでなく、その他コンテナオーケストレータからも利用可能

※コンテナ実行環境
EC2を使うとEC2インスタンスの管理業務発生

AWS Fargate

コンテナ専用実行環境
AWSマネージドでEC2インスタンスのプロビジョン、スケール、管理不要
コンテナネイティブ
AWS連携
インフラを管理せずにスケールでき、ネットワークの細かな制御が可能

AWS Cloud Map

クラウドリソースのためのサービスディスカバリ：クラウドリソースのためのDNSみたいなもの

AWS App Mesh

アプリケーションレベルのネットワーク：サービスメッシュ

Amazon CloudWatch　Conteiner Insights

CloudWatchのコンテナ用：現在パブリックプレビュー

Functions,Container,VM　多様な選択肢の中から管理負荷・開発容易性等の検討しジャッジする

DevOps的巨大改进！利用传统的托管服务完全替换旧的架构！（由突破点提供）

転職プラットフォームシステムのリプレイス遂行中

矢継ぎ早にシステム増改築
アーキテクチャもリリース時点での実績あるもの選定

現在のトレンドとは７年分くらいの乖離がある状態

→すべてリプレイスを決断

３つのWEB、管理画面、２つのアプリなどなど

負債のたまらないシステムはむりでも、負債を返済しやすい仕組みに
１．認証基盤のリプレイス

認証チェックが面倒
様々な認証との連携が面倒
セキュリティオートメーションが面倒
↓
Amazon Cognitoの採用

基本的な認証機能の完備
様々な外部認証にも対応
充実のセキュリティ対応（Advanced Security Feature）

→既存のシステムをCognito移行は大変

既存のシステムでの会員ID払い出し済みをどうするか
既存システムにも新会員のメアドを持たせたい、など

→Cognitoの処理をトリガにLambdaで既存システム機能をキック、メアド登録などで対応

２．認可基盤のリプレイス

CoginitoとAPI Gatewayを組み合わせ、
CognitoのIdentity Poolで権限（Scope）判断
認可、認証、アプリが疎結合
→グループメンバーなどの変動が多く、APIの増減も多い、複雑

３．Webサーバのリプレース

スティッキーセッション利用
ステートフルなサーバ設定

＝スケールしないWEBサーバだった

↓
ECS、Fargate、Auroraで構成、APIGatewayを介する

４．ビルド、デプロイのマネージド化

Github Jenkins直列

ビルドの高負荷化、デプロイ直列化で時間がかかる状況

↓
Github-webhook-jenkins->Code Pipeline
->CodeBuildでDockerImegeをBuild->ECR/ECS/API GateWayへ

５．DBのAurora化、SolrのElasticSearch化

MySqlからAuroraへ
DynamoDBとRedisを廃止し、RDBに統合

６．バッチのマネージド化

自作のジョブスケジューラ
スケールアウトば難しく、スケールアップで対応していた
↓
CloudWatch + StepFunction 起動時間を含むすべての設定をTeraformで管理
バッチ起動環境がスケーラブルに

７．運用方法のリプレイス

特権管理でAWS Systems Manager(SSM)の導入

今までは自宅からの緊急対応時等にはVPN経由で：証明書管理・運用が面倒
リプレイス後はSTS＋SSMを利用した時限つき特権権限を導入

ログ監視

DataDog Logsの導入　AWSと親和性が高い

各種メトリクスやAPMもDataDogへ

８．Infrastructure as Code

上記すべてをTerraformでコード管理
tfファイル数：1200over
エンジニアがインフラチームへの依頼時にもtfファイルを書いて投げられるようになった

重視したのは

手動運用の自動化
コード化、可視化による標準化

リリースは8月以降予定（1年がかり）

亚马逊 DynamoDB 深入剖析

• DynamoDBとは？

フルマネージド
ハイパフォーマンス
エンタープライズ対応

主な認証、SLAの提供

DynamoDBの基礎知識

Table構造

RDBと同様、Tableでデータを分割

Tableの中にItemsを格納、
Itemは複数のAttributesを持つことができる
Partition Keyは必須：データ分布を決定
Sort Keyはオプション：クエリによる幅広い探索で利用

Item操作

読み込み、書き込みそれぞれ複数の操作コマンド

DynamoDB　Transactions

複数Item,Tableに対する書き込み・読み込みでACIDトランザクションが可能に
分離レベルはserializable ,ロックは取らない

Partition Keys

アイテムを一位に識別
パーティションキーをもとにItemがどこに位置するかが決まる
内部ではスケールのためにパーティションという単位で分散して保持

Sort Key

パーティションキー、ソートキー2つの属性を使って複合キーとしてItemを識別

パーティションに格納されたものは必ず3つのレプリカを持つ
Local Secondary Index

sort key以外に絞り込み検索を行うキーを持つことができる

Global Secondary Index

Partition Keyの代わりに使用できる
GSIをPKの逆引き的に利用、など
GSIはTableへのUpdateとは別で非同期で書き込まれる

Capacity Control

MySQLでの分散方式の例

水平分散　and/or 垂直分散

必要なスループットをどう安定して実現するか？

インスタンスはどれ？サイズは？

Cassandraなどの分散DBによる解決

ノードを追加することでキャパシティ向上

アプリからの接続管理など、多くの運用が必要

メンテナンスフリー
拡張性

Burst Capacity

利用されなかったキャパシティ分を過去300秒までリザーブ
プロビジョン分を超えた場合に利用する

Auto Scaling

ターゲット使用率と上限、下限を設定するだけ
利用は無料

パーティション内でのスループット

テーブルスループットはパーティションに均等に付与される
全体で合計値の性能が出るように設計
負荷が単一のパーティションに偏った場合は？

ユーザが使えるパーティション毎のスループットは、あくまでそのパーティションの上限
→Adaptive capacity

集中したパーティションのキャパシティを動的に増やす

DynamoDB On-demand

今まではCapacity Unit をプロビジョンする必要があった
→リクエストごとの従量課金に

NoSQLデータモデリング

RDBとは全く特性が異なる
NoSQL,DynamoDBの特徴を理解したうえでテーブル設計をする

ユースケースの理解
アクセスパターンの理解

Read/Writeワークロードについて
クエリの大きさや集計

Data-modeling

NoSQLデザインパターン

Review > repeat > review

NoSQL：正規化しすぎると非効率になりえる＞非正規化して扱いやすくすることも

１：１の場合、Partition Keyを使ったテーブル、GSI
Nリレーション、親子関係の場合、パーティションキーとソートキー、GSI
N:Mリレーションの場合、TableとGSI

GSI Overloading

GSIの制限：テーブルあたりデフォルト最大20まで
RDBでいう一行を複数レコードで
項目をSort Keyにし、GSIにより弾けるように

ER図は重要＋アクセスパターン（ユースケース）を整理し、モデリングを行うことが重要
クエリコンディション：この湯ユースケースではどのパラメータ、INDEX、条件を使うのか、をまとめることで開発しやすく

DeepRacer 工作坊

DeepRacer概要

強化学習をすべての開発者に
車からのカメラ画像のあらゆる見え方にたいして、取るべき運転行動を登録できればコースを走らせることができる

実際には無数の見え方が存在するため、登録自体が難しい
画像だけで走らせることができるようになるよう、学習させる

強化学習の導入

カメラ画像から行動を決定するモデルを学習により作成
主要な要素

モデル
エージェント（主体：DeepRacer本体そのもの）
行動
状態
環境
ゴール
報酬
エピソード

機械学習

教師あり学習

対応するラベルを持つ教師データにより学習

教師なし学習

学習データにラベルは不要

強化学習

特定の環境下で、一連の行動から学習

良い行動には報酬を、悪い行動には報酬なし

強化学習において、特定の行動にインセンティブを与える報酬関数が重要

例）センターラインを走るようにインセンティブを与える

ゴールのみに報酬設定ではどのルートがより良いのか判断できない

強化学習アルゴリズム：Vanilla plicy gradient

ゴール：累積報酬の最大化

現在の方策を利用してエピソードを集める→報酬を推定する→

シミュレータ

アーキテクチャ

SagemakarとRobomaker
NAT Gateway経由で
モデルはAmazon S3に
シミュレーション動画はKinesis　Video Stream経由
メトリクスはAmazon CloudWatchに

DeepRacer

行動空間：スピードとステアリングの組み合わせ定義

ハイパーパラメータ

Learning Rate：学習率
Batch Size:バッチサイズが大きいと、学習は安定する
Epoches
Discount factor
# of epsodes

シミュレーションと実環境のドメイン転移

難しさ

シミュレーション画像を利用して学習　実機では実世界の画像
実環境の完全なシミュレーションも難しい

戦略

環境制御を実世界に近づける
環境にランダムな要素を追加
モデルのモジュール化

DeepRacer課金しっぱなしを防ぐ

Create Modelのところで「Reset Resource」を実行！
（S3にもデータは保管されているので課金かかるが、微々たるもの）