AWS Summit day2 report
AWS Summit の2日目参加レポートです 今年のAWS Summitには2日目から参加してきました
Amazon Sumerian によるVR/AR/MRアプリケーションの開発
Amazon Sumerian(スメリアン)の紹介
XR
- AR
- VR
- MR (Mixed Reality) 物理とかそうが相互作用
開発プロセスの簡素化
- XRコンテンツを簡単に開発・配信するためい必要なツールや配信基盤を提供
- Webベースの開発環境
- マルチプラットフォーム
- Sumerian Host
- セリフに合わせて口を動かしたりするキャラクター
- AWSほかサービス連携
活用シーン
作成の仕方とか
用語
- シーン
- エンティティ
- アセット
基本操作
シーンの作成 > エンティティーの配置 > 配信
特徴
- JSでも記述できる
- WebIDEは日本語になってる
チュートリアルは60以上ある
デジタルツイン * 物理的なものを仮想の世界に持ち込む
みずほ銀行、三菱UFJ銀行のデジタル・トランスフォーメーションにおけるデータ利活用
Section 1(みずほ銀行)
- 課題1 キャパシティ不足
課題2 リスクを抑えたい
情報活用の中心 -> S3
データレイク
- S3
分析
- Redshift
- Glue(PySpark/Scala)
可視化
- QuickSitght
ETL
- Athena
収集
- Lambda
Section2(みずほ銀行)
データ利活用の悩み
- 現状把握、洞察に労力がかかる
- データ資産化の手法に改善の余地あり
思考した結果と考察
- Excel SaS -> Athena , S3 , Redshift , QuickSightへ
SasからAthenaSQLに言語変換
コーディング
- SQLが煩雑
- 運用
- AthenaのUI使いにくい
- 最大40倍速
今後の展望
- 社内の類似業務を移行したい
- セルフサービスBI
Section3(三菱UFJ)
チャット施策での活用
- 年間数百万 -> コールセンター負荷
- WebChat新設
- AI一次請け -> コールセンター
- AI チャットBotでは個人情報の扱いは取り扱ってない
システム全体像
- クラウドサービスを組み合わせ
- チャットボット より高性能が出た場合、簡単に取り替えられる仕組み
- データの分析を簡単に行える基盤
方針
パネルディスカッション
Q1: クラウド利用時のセキュリティ
既存の社内セキュリティルールに沿って利用する課題に同対応?
-
銀行内のプライベートガイドラインに沿って CCOEと連携 CCOEは一緒に考えてもらえる相談窓口的な
-
ガイドライン作成にかかった時間
-
数ヶ月程度 バージョン3くらい
-
1-2ヶ月 改定を繰り返している
Q2: クラウドを乗りこなすには
今回のご経験を通じて、クラウドを乗りこなすには組織側にどういった対応や変化が必要でしょうか?
-
IT部門に丸投げ -> ユーザ側で選定、自由度がます , 勉強する範囲が増えてる
-
完璧を求めすぎない 徐々に良くしていく 自分たちで使っていく意識改革
Q3: クラウド上のシステムの運用する
- 今回発表のAWS環境でのアプリケーションではどのように運用されていますか
クラウドならではの部分はありますか?
-
自分たちで開発できる環境がもともとある 親和性が高い
-
IT部門ではなく、自分たちの部署で運用 成功するかわからない 将来的にIT部門に移管していく
Q4: 難しかった、想定外だった部分
- AWSクラウド利用を通じて、難しかった部分、もしくは想定外、うまく行かなかった部分は何でしょうか?
それらの改題をどのように乗り越えられましたか?
-
Dockerを活用 -> Fargate 当時private link対応なかった 必要なコストがどれくらいかを見極めた上で新機能
-
ナレッジについて
仲間づくりをしていきたい
制作・管理・アーカイブ・配信までエンドツーエンドのAWSメディア最新事例
Section1 AWS Japan
メディア業界を取り巻く環境について
メディア業界は非常に大きな変化に直地面
- 消費者行動の変化
- M&Aによる業界再編
- 視聴体験の向上
- メディアワークフローの変化
制作関連事例
クラウド化を県とする主な理由
- 働き方改革
- 場所を問わずに働ける
- 物理的なりそーすのせいやくからの開放
- コスト
- 初期肥料不要、従来下記人のリーズナブルな費用で利用可能
- 定期的な設備投資から運用コストへ
- セキュリティ
- 物理的なアクセスは一切不可
- すべての論理アクセスを記録・監査可能
高画質化ニーズへの対応
- 設備改正を待たずに最新の制作環境を構築可能
クラウド編集事例(ジェイスポーツ)
2018-12 AWS上でのクラウド編集の利用 Avid Media Composer をAWS上で試す
導入の背景と課題と目的
- エンディング 6min
- ディレクターは一人、年末年始 重労働
- 重労働の負荷を下げることをゴールとした
- 働き方改革、ワークフローの改善
構成
- NEXION TNOCを中継してAWSクラウド連携
- ファイルサイズ 40G程度
- クライアント Mac book Pro
- Avid
- Final Cut pro(クラウド編集した素材を最終的に仕上げ作業を行う)
メリット
- 編集作業場所から開放された(ビジネスホテルも作業できた)
- 外付けHDDも不要になった
- 緊急時でも迅速に対応可能(オンライン編集を中断することなく作業できた)
- 他社との素材共有が可能になるのでは
イマイチ
- クラウド編集した素材のコピーに時間がかかる
結果と課題
- クラウドへのIngest経路の手配
- 高速なインターネット回線が必要なため
- クライドIngest後のファイル化
- 編集フローがシームレスではない
- S3からEBSに手動でコピーが必要だった
- オンプレでの缶パケ可
- 複数の編集作業で使うに向けたワークロード
- ディレクターの数だけあるので整理が必要
Section2 CGにおけるAWS活用(NHKテクノロジーズ)
レンダリング
- 多数のコンピュータで分散処理
- フレーム単位で分散処理
CG制作(インフラ麺)の悩み
- いくら投資してもキリがない(常にリソースが足りない)
- 床台、電気代がかかる
- 毎年やっってくるマシン入れ替え・増設
AWSでの解決法
- EC2スポットインスタンスの利用
- 事実上無限のマシンリソース
- 使用しない場合、停止、削除でコストカット
- セットアップは1大文でAMIを再利用する
- 床台、電気代は利用料に含まれる(使った分だけ)
AWS Thinkbox Deadline 10
機能
- ジョブ・タスク機能
- サーバ管理
- ログ参照
AWS Portal
管理・アーカイブ
よくある課題 -> よくある状況 -> AWS
- 耐久性・可用性 -> 二重、三条の保存 -> S3等
- 消失が許されない
- 利用したいときにすぐ利用
- 中長期
- セキュリティ -> 物理的アクセスのリスク -> VPC等
- コンテンツの流出改ざんの防止
- 機密情報も含めた情報の取扱
- 検索性 -> Excel等での管理 -> Amazon Elastic Search等
- 有効なmetadata
クラウド活用したフジテレビ新マスターのコンテンツ管理プラットフォーム(フジテレビ)
放送局のマスターとは
- 放送局における心臓部
- 番組素材・CM・提供等
- 放送事業だけでなく、配信や番組販売も行っている
- マスター更新をきっかけに、番組素材を集めてマルチにアウトプットを行う
コンセプト
- 番組おンテンツのサービス感共有
- コスト削減
- 積極的にクラウド利用
- 関連するmetadataの利用
ワークフロー内でのAWS利用
- プレビュー
- 番組素材取り込み
- コンテンツ管理保存
- 再放送、再利用
デジタルアーカイブ機能で使ってるAWS
- Amazon Glacier
- S3
- Ec2
- Direct Connect
マスター＆FOD機能
- Amazon Glacier
- Elemental Media Convert
- S3
- EC2
- Direct Connect
完成予定
- WorkSpaces
- Amazon Glacier
- Elemental Media Convert
- S3
- EC2
- Direct Connect
苦労している
- ファイルサイズ大きい
- 保存料金は安いほどいい
- Direct Connect経由でのダウンロード料金
- フレーム(Timecode)の世界とAWSを両方熟知しているSIが少ない 107,892? -> 1hのドットフレーム数
導入効果
- 初期設備投資・保守費が抑えられる
- 使いたい番組素材にすぐにアクセス可能
- コストの見える化
- 10GでDirect ConnectでEC2がオンプレサーバのようにつかえる
- サーバスペックが容易に変更可能
スケジュール管理・動画変換・ポスプロ作業(IMAGICA Lab)
AWS上でポスプロの何ができるか
ポストプロダクションワークフロー例
編集依頼 > スケジュール > 編集 > 納品
スケジュール管理
- PANDAというスケジュール管理システム作った
アクセス負荷対策
- Auto Scaling
クラウド編集・管理・納品
- EDIUS + WoarkSpace
- S3
- TASKEE(独自で開発)
TASKEE
- アセット管理
- 作品/エピソード/ファイル
- カスタムメタデータの付与
- ブラウザ上で映像の中身を確認(Media Convert使用)
- 任意のユーザに期限付きダウンロード権限を付与
2K4K同時配信(フジテレビ)
2K同時配信
4K同時配信
- 4K収録 -> 2K/4Kを配信側で提供
- 共通配信基盤をAWS上に開発
- アドレッサブルTV
- MPEG-DASH配信
- Media Convertで配信用エンコード・パッケージ化を簡単に実現
- 大規模WebSocket対応
CMAF配信
配信遅延
- MPEG-DASH : 遅延が大きい
- フラグメント
- CMAFチャンク
- 超遅延配信 : ULL-CMAF
構成
- CMAF対応配信エンコーダー : Videon Edge Castrer 4K HEVC
- セグメントファイル確定前に順次チャンク転送可能な配信環境: Elemental Media Store, Cloudfront
- チャンク単位で取得・再生プレイヤー: NEX Player, hls.js
超低遅延(3,4秒)
- セグメント帳6
- フラグメント1
- mdat box 30
- チャンク 200msec
リアルタイム視聴分析
- Athena
- QuickSight
まとめ
前関わっていた案件で、MediaService周辺を調べ、構築したのですが、流石にCMAFまでは出来なかったのと、遅延を少なくする設定で非常に苦労したのを思い出したので、参考までに貼っておきます。
視聴体験を向上するメディアデータ分析・機械学習 事例
TBSラジオ + 電通
ラジオ業界でなぜ聴取率が課題とされていたか
スマートフォンが普遍的になり、音声コントロールデバイスが増える中＠EYES FREEメディアのビジネス可能性を見つめ直す
耳からの学習効果
- 図るすべがなかった
リスナーファインダーによる課題に対する取り組みと電通ならではの付加価値、どのようにじつげんしているか
地上波ラジオの現状
- テレビと異なりピープルメータによる取得データではない
- 首都圏でも2ヶ月に1度しか調査しない
- 豪華企画をやる意味は?
地上波ラジオはデジタルメディアへ
- radikoの登場
radikoのアクセスログデータの可視化
ダッシュボードの開発
リスナーファインダーによる課題に対する取り組みと電通ならではの付加価値、どのように実現しているか
状況
リアルタイムダッシュボード構築にチャレンジ
初期構成
- S3
- EC2
- Aurora
何をどうやった
- TV視聴可視化/番組分析ダッシュボードの自動化
リアルタイム構成
- S3
- EC2
- Aurora
- Lambda
- Cloud Front
全体最適化に向けて
- DashboardとAnalytics基盤でずれなしに
- サーバレス化
AWSサービスの選定
外部ツール
実際に利用して感じる課題と利点
進める上電ぽいんと - 編集制作活用を主眼とした - 新しいリスナーを＠開拓するためという目的に特価 - アジャイル開発の体制 - 電通の治験と、放送局の治験を積極的に共有
感想
- 社内スタッフの意識の変化
- 将来営業活動に発展
システム麺
- ユーザがみて認識できる画面/状況をすばやく
- 日々のデータ整理とDataLake構築
KPIは3つまで
思った以上に反響が大きい
- リアルタイムのKPIを増やしすぎてシステムダウン
- プロトタイプ構築 -> 最適構成への変更 （インフラ部分の統廃合が大変)
今後の展開
- 運用監視フロー
- より効果的なマーケティング
機能
- リアルタイム聴取
- SNSシェア状況の可視化
テレ朝
テレビ視聴データ
- データ放送を活用して収集する視聴データ
- dボタンを幼くても収集できる
- テレビメーカーの視聴データとは異なる
- 個人を特定する情報ではない(非特定視聴履歴)
- オプトアウト方式
課題
- 視聴者プロフィールを把握できない
テレビ視聴データの活用
- 広告とか
分析データ構成
- 属性・趣向データ
データレイク
- 1hで1億レコード超える
データワークフロー
機械学習アーキテクチャ
- クラスタリング、プロフィール予測
AWSを活用したユーザー認証実装パターン解説
ユーザと認証
エンドユーザが利用するアプリケーション
ユーザ認証に関連する関心事
AWSの認証関連サービス
- セキュリティを再優先事項
認証/認可
- Single Sign-ON
- Directory Service
- Cognito
Cloud Directory
IAM
- Secrets Manager
SSO
- 複数のAWSアカウントやビジネスアプリへのシングル最イノンを実現
特徴
- 多要素認証
パスワードポリシー
Cloud Trail対応
プログラミング不要
- マネージドで負荷軽減
Directory Service
- マネージド型 Microsoft Active Direcotry
Amazon Cognito
- カスタムアプリやAPIの認証・認可を提供
特徴
- 他要素認証
- パスワードポリシー
AWS Credentials
ソーシャル連携
外部IDプロバイダ連携
Cloud Trail対応
プログラミング不要
- マネージドで負荷軽減
ユーザプールとIDプール
ユーザ認証実装パターン
A往来型
ALB
- Cognito
- OIDC準拠IDプロバイダ
ALB使ってる
ALB -> ユーザプールへリダイレクト > 認証画面(Cognito) -> ID/Pass -> Token(Cognito)
ALB使ってない
カスタム実装が必要
EC2 RDS
Bの場合
API Gatwayでの認証
- Cognito
- IAM
- Lambda
フロー API Gatway
- Token -> API Gatway -> Lambda
EC2 RDS
アプリケーションロジック内でカスタム認証を実装
- 要件に合わないものを無理やり使わない
APIベース
- Credancial IDプールとの連携
- TokenをIDプールに渡す Credencial発行
IDプールによるCredencial発行
Cクラウドベンダー
SSO
- SAML2.0対応
フロー
ユーザ -> SSO -> 認証画面 -> ID/PASS -> ポータル画面を応答
AD
- ADFSを利用することなくSAML2.0対応アプリへADを莉芳した認証の組み込みが可能
オンプレも可
SSOはまだ東京リージョンない
- AD Connector利用して実現できる
無理やり使用はせず、カスタム実装という方法もある
テクロスにおけるAWS活用の歩み ソーシャルゲーム運用とデータレイクについて
神姫Project
AWSのち県はなかった
- ログの分析基盤もなし
- インフラ構築は手動
別のベンダークラウド
インスタンスが不安定
データベースが不安定、性能が出ない
AWS選んだ理由
移行
- mysqldumpを並列
- 24時間のダウンタイム
移行してよかったこと
Unitia
- 構成管理をAPIで自動で行うようにした
Terraformの導入
- 宣言的にインフラコード管理ができる
Infrastructure as Codeの読書会
- チームにおける共通言語、共通概念の獲得
- Infrastructure as Code に対するチームの認識の統一
ログ
- KPI分析
- CS対応
- 不具合調査
- 不正アクセス検知 etc...
保存箇所、形式がバラバラ
- ログを組み合わせて分析するのが難しい
- ログの管理コストが高い
ログを閲覧するインタフェースが違い、学習コストが高い
保守が大変
データレイク構築
- いろんなログを一つの基盤に集約
- 全部のログを長期保存したい
- 保守もしたい
結論
- Athena
S3
DBのスナップショットからリストア
- embulk + digdag
re dashで可視化
- 非エンジニアでもSQL操作してもらいKPI分析をスムーズに
大事にしてる価値観
- 新しいツールやサービスを積極的に検証、導入する
- その上でベストプラクティスを大事にする
ちなみにちょっと古いかもですがAthenaについては昔こんな記事を書いてるので参考までに carefree-se.hatenablog.com
Architecting for the Cloud 2019 -クラウドにおけるアーキテクチャの設計原則
- アーキテクチャの設計減速をあらためて見直す
- Webアプリにおける実践を通じて、理解
基本中の基本
EC2
VPC
AWS Global Infra
- 21 geo region
- 61 Availability Zones
東京リージョンで本当にいい? これは考える必要がある
障害を見越した設計
- 冗長化
- 障害の検出
- 永続データストレージ
- 複数データセンタを用いた自動復旧(Availality Zoneをうまく使う)
- Flow / logs
全レイヤでのセキュリティ実装
- 徹底的な防御
- AWSのセキュリティサービスを積極的使用
- 特権アクセス制限
- リアルタイム監査
ストレージの選択肢活用
伸縮性の実現
- ブートストラッピング or Golden Image(伸縮できるような形にする必要がある)
- Cloud init
- 家畜として扱う(換えが効くサービス)
- サービス継続性の重視
並列で考える
- 1台で100時間 = 100台で1時間 (秒単位の課金になってる)
- なめらかなスケーリング
- 障害影響範囲を小さく
- ソフトウェアの書き換え
疎結合はあなたを楽にします
- よいインタフェース定義
- サービスディスカバリ
- 対応できないときいの非同期処理
失敗時の適切な処理
SQS使うだけでも疎結合を楽にする
制約を恐れない
- 制限には理由がある
- 提供できるものを計画する
- うまくいくものを出荷する
- 出来るに出荷する
- 繰り返し繰り返す
実践(Webアプリ)
- セキュリティは常に最優先
必須 + アカウント用不要と権限管理、証跡
!. IAMユーザ・グループの管理 2. CloudTrail, Config, GuardDuty, Security Hub, MFA 3. 使わないリージョンは使えなくする - 香港リージョン : デフォルトでDisable 使えない Enableにする必要がある
- IAMユーザ使い回し絶対ダメ
- セキュリティ関連サービス -> 値段が安い
セッション情報は外に出す
- スケールさせやすくするためセッション情報は外出し
- EC2にはセッション情報は残さない
非同期処理
- SQSを挟んでFrontendとBackendを疎結合に
計算資源を使い捨てるために
- ブートストラッピング
- Cloud-init
- ゴールデンイメージ
- コンテナ
- ECS
インフラのコード化 - CloudFormation - OpsWorks
オリジンへの外部からのアクセス禁止
- S3 Origin Access Identitiy
- Custom Origin Security Groups
今日のWebアプリの最大の脅威
まとめ
- 障害を見越した設計
- 全レイヤでのセキュリティ実装
- ストレージ選択肢活用
- 伸縮性の実現
- 並列で考える
- 疎結合
制約を恐れない
AWS Well-Architected Tool
- AWS Trusted Advisor(Basicなところは機械的にチェックしてくれる)
AWSにおける機械学習入門
機会学習ハードル
- 数学・統計学知識
選ばれる理由
機械学習サービス
AIサービス
サービスの範囲
- 静止画・動画
- 音声処理
- テキスト処理
- Translate
- Comprehend 文書の解析
- チャットボット
- Amazon Lex 音声対話
- 時系列データ予測
- Amazon Forecast
- レコメンデーション
- Personalize
ML
- Amazon SageMaker
- 開発
- 学習
- デプロイ
MLフレームワーク/インフラストラクチャ
- TensorFlow
- 高GPU、CPU
機械学習を進める次のステップ
re:Mix
3日目最終日も参加予定なので、よろしくお願いしますー
3日目のレポートです。
