はじめに

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