Help us understand the problem. What is going on with this article?

AWS Summit Tokyo 2019 Day-3 参加メモ

AWS Summit Day3

概要

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 ビズリーチ)

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

    • 矢継ぎ早にシステム増改築
    • アーキテクチャもリリース時点での実績あるもの選定
      • 現在のトレンドとは7年分くらいの乖離がある状態
    • →すべてリプレイスを決断
      • 3つのWEB、管理画面、2つのアプリなどなど
    • 負債のたまらないシステムはむりでも、負債を返済しやすい仕組みに
    • 1.認証基盤のリプレイス
      • 認証チェックが面倒
      • 様々な認証との連携が面倒
      • セキュリティオートメーションが面倒
      • Amazon Cognitoの採用
        • 基本的な認証機能の完備
        • 様々な外部認証にも対応
        • 充実のセキュリティ対応(Advanced Security Feature)
      • →既存のシステムをCognito移行は大変
        • 既存のシステムでの会員ID払い出し済みをどうするか
        • 既存システムにも新会員のメアドを持たせたい、など
          • →Cognitoの処理をトリガにLambdaで既存システム機能をキック、メアド登録などで対応
    • 2.認可基盤のリプレイス
      • CoginitoとAPI Gatewayを組み合わせ、
      • CognitoのIdentity Poolで権限(Scope)判断
      • 認可、認証、アプリが疎結合
      • →グループメンバーなどの変動が多く、APIの増減も多い、複雑
    • 3.Webサーバのリプレース
      • スティッキーセッション利用
      • ステートフルなサーバ設定
        • =スケールしないWEBサーバだった
      • ECS、Fargate、Auroraで構成、APIGatewayを介する
    • 4.ビルド、デプロイのマネージド化
      • Github Jenkins直列
        • ビルドの高負荷化、デプロイ直列化で時間がかかる状況
      • Github-webhook-jenkins->Code Pipeline
      • ->CodeBuildでDockerImegeをBuild->ECR/ECS/API GateWayへ
    • 5.DBのAurora化、SolrのElasticSearch化
      • MySqlからAuroraへ
      • DynamoDBとRedisを廃止し、RDBに統合
    • 6.バッチのマネージド化
      • 自作のジョブスケジューラ
      • スケールアウトば難しく、スケールアップで対応していた
      • CloudWatch + StepFunction 起動時間を含むすべての設定をTeraformで管理
      • バッチ起動環境がスケーラブルに
    • 7.運用方法のリプレイス
      • 特権管理でAWS Systems Manager(SSM)の導入
        • 今までは自宅からの緊急対応時等にはVPN経由で:証明書管理・運用が面倒
        • リプレイス後はSTS+SSMを利用した時限つき特権権限を導入
      • ログ監視
        • DataDog Logsの導入 AWSと親和性が高い
          • 各種メトリクスやAPMもDataDogへ
    • 8.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:正規化しすぎると非効率になりえる>非正規化して扱いやすくすることも
      • 1:1の場合、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にもデータは保管されているので課金かかるが、微々たるもの)
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away