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に標準対応
- Amazon Kinesis
- Image Search
Panasonic
- くらしのCyber Physical化
- 眼によるセンシングに着目:85%を目からセンシング
- Vieureka PlatformをAWS上に構築
- エッジデバイス上で映像をAI処理
- エッジデバイスからMetadataをクラウドに送信
- クラウド上で機械学習、推論モデル生成
- クラウドから戻ってきた後でエッジデータ上で再推論、再強化
- エッジデバイス上で映像をAI処理
- 来客分析
- カメラ毎に人数カウントや性別・年齢推定、滞留時間を収集・分析
- 入退室管理
- カラービットを読み取って入退室管理
- Vieureka PlatformをAWS上に構築
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へ
- Github Jenkins直列
- 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へ
- DataDog Logsの導入 AWSと親和性が高い
- 特権管理でAWS Systems Manager(SSM)の導入
- 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はオプション:クエリによる幅広い探索で利用
- RDBと同様、Tableでデータを分割
- 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とは別で非同期で書き込まれる
- Table構造
-
Capacity Control
- MySQLでの分散方式の例
- 水平分散 and/or 垂直分散
- 必要なスループットをどう安定して実現するか?
- インスタンスはどれ?サイズは?
- Cassandraなどの分散DBによる解決
- ノードを追加することでキャパシティ向上
- アプリからの接続管理など、多くの運用が必要
- ノードを追加することでキャパシティ向上
- メンテナンスフリー
- 拡張性
- Burst Capacity
- 利用されなかったキャパシティ分を過去300秒までリザーブ
- プロビジョン分を超えた場合に利用する
- Auto Scaling
- ターゲット使用率と上限、下限を設定するだけ
- 利用は無料
- パーティション内でのスループット
- テーブルスループットはパーティションに均等に付与される
- 全体で合計値の性能が出るように設計
- 負荷が単一のパーティションに偏った場合は?
- ユーザが使えるパーティション毎のスループットは、あくまでそのパーティションの上限
- →Adaptive capacity
- 集中したパーティションのキャパシティを動的に増やす
- DynamoDB On-demand
- 今まではCapacity Unit をプロビジョンする必要があった
- →リクエストごとの従量課金に
- Burst Capacity
- MySQLでの分散方式の例
-
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にもデータは保管されているので課金かかるが、微々たるもの)