セミナーメモ AWS Summit Tokyo 2019 Day-3

AWS Summit Day3

2019/6/14＠幕張メッセ

基調講演

メルカリ

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