【過去記事】AWS Summit Tokyo 2019 Day-3 参加メモ

## はじめに
- この記事は、Qiitaアカウントの整理のため、別のアカウントで投稿した過去の記事を移行してきたものです。全く同様の記事があるかもしれませんが、盗作等ではありませんのであしからずご容赦ください。
- 過去記事　投稿日： 2019年06月15日

## 概要
AWS Summit Tokyo、3日目の最終日も参加できました。幕張はやっぱ遠いな。。。

最終日で特に印象的だったのは、基調講演でのSyntheticGestaltの話し。これは本当にテクノロジーが世界・社会を変えるという現在進行形の話で、その内容を目の当たりにしたというすごい感覚でした。

あとはDeepRacerワークショップ。機械学習とか全く縁がなかったし、今の業務とも全く関係ないんだけど、すごく面白い分野です。もっと知りたい。

以下、参加したセッションのメモ書き。

## 基調講演

### メルカリ
 * AI/ML
    * Image Search
        * EKS Cluster 利用して、S3に保管しているイメージを使ってトレーニング
        * S3
            * 充実したイベントフック、ツール群とエコシステム
    * AI出品
        * 出品しようとしたもののブランドなどを推測、入力支援
* AML Tech Stack
    * Splunk
        * Amazon Kinesis 
            * ログ収集パイプライン
            * splunkに標準対応

### Panasonic
* くらしのCyber Physical化
* 眼によるセンシングに着目：85％を目からセンシング
    * Vieureka PlatformをAWS上に構築
        * エッジデバイス上で映像をAI処理
            * エッジデバイスからMetadataをクラウドに送信
            * クラウド上で機械学習、推論モデル生成
            * クラウドから戻ってきた後でエッジデータ上で再推論、再強化
    * 来客分析
        * カメラ毎に人数カウントや性別・年齢推定、滞留時間を収集・分析
    * 入退室管理
        * カラービットを読み取って入退室管理

### SyntheticGestalt
* 人工知能を利用することで、天才に依存せずに科学的な発明を
* 創薬分野
    * 医薬品の開発にかかるコスト・期間
        * 人工知能によって分子を推測、実験、モデルの改良
        * 人間だと数か月→数秒に
    * 病気のもととなるたんぱく質を阻害する分子を設計
    * 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の劇的改善！古いアーキテクチャから王道のマネージドサービスを活用しフルリプレイス！（by ビズリーチ）

* 転職プラットフォームシステムのリプレイス遂行中
    * 矢継ぎ早にシステム増改築
    * アーキテクチャもリリース時点での実績あるもの選定
        * 現在のトレンドとは７年分くらいの乖離がある状態
    * →すべてリプレイスを決断
        * ３つの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年がかり）

## Amazon DynamoDB Deep Dive

* 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にもデータは保管されているので課金かかるが、微々たるもの）