2019-06-13 AWS Summit Tokyo 2019 Day2 #AWSSummit
2019/06/13 に開催された AWS Summit Tokyo 2019 Day2 のイベントレポートです。
●イベント概要
世界最大の AWS Summit を今年は幕張で開催！
クラウドの最新技術を "楽しんで学べる" 3 日間。
AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関する情報交換やコラボレーション、学習を行うことができる日本最大級のカンファレンスです。世界 25 ヵ国 35 都市で開催され、あらゆる業界や学習レベルの技術者が、AWS を利用することでいかに自社のビジネスを迅速に革新し、柔軟で信頼性の高いソリューションを大規模に提供できるかを発見できる機会です。
2019 年、日本では東京と大阪で開催します。年々来場者が増加している東京では、初めて幕張メッセで開催する運びとなりました。
当日は、140 社以上のお客様による先進事例セッションをはじめ、合計 250 以上にものぼる AWS の最新情報を含むテクニカルブレイクアウトセッションやデモンストレーション、ハンズオンワークショップを実施。また、過去最大規模となる EXPO 会場では、AWS Expo や 100 社を超えるスポンサー企業様が一同に出展する Sponsor Expo にて、AWS を基盤としたさまざまなソリューション、新技術を実際に体験いただけるほか、最新の AWS 関連ソリューションをご紹介します。さらには、深層学習と強化学習を組み合わせた実装を学ぶことのできる特別企画「DeepRacer リーグ」をはじめとした参加型企画もご用意しており、“楽しんで学べる" Summit を通じて、クラウドに関する最新情報と最新実用事例を学び、AWS 利用者との人脈を築くことができる機会をご提供します。なお、今年はネットワークイベント Interop Tokyo 2019 との同時期開催となっており、これにより、インターネット分野の 2019 年国内最大級の B to B イベントとなります。
■サムスンで実践される Galaxy スケールの AI サービスはどのようなデータベースアーキテクチャで支えられているのか?
Sangpill Kim さん [Amazon Web Services Korea]
●DBの構成
・ソウル、アイルランド、オハイオリージョン
・DynamoDB x ElastiCache Redis
●PoCシナリオ
・要件
グローバルな同期はしない
1つのリージョンにDBを配置、全リージョンでキャッシュ
-> ネットワークレイテンシー
全リージョンで同一アーキテクチャ
全リージョンでロードする同時ユーザ数: 2,000
デバイスごと: 300アイテム x 200KB
テストデータ: 10TB
・ゴール
100ミリ秒以内に 300アイテムを取得
キャッシュしたら 10ミリ秒以内
●テスト1: 集中型DBで要件を満たせるか？
・方法
3リージョンのAPIサーバから
ソウルリージョンのDynamoDBを呼び出す
同時 2,000ユーザ で 1時間
DynamoDBから 300アイテム x 192KB を返す
クエリ + ラウンドトリップタイム
平均値を計算
・結果
ソウル: 52ms
アイルランド: 1,512ms
オハイオ: 945ms
・わかったこと
予想通りネットワークの影響が出た
●テスト2: 集中型 x リージョンごとにRedis
・方法
3リージョンのAPIサーバから
ソウルリージョンのDynamoDBを呼び出す
同時 2,000ユーザ で 1時間
DynamoDBから 300アイテム x 192KB を返す
ElastiCache Redisに格納
ElastiCache Redisから 10倍のデータを取得
クエリ + ラウンドトリップタイム
平均値を計算
・結果
ソウル: 3,063ms
アイルランド: 1,442ms
オハイオ: 2,339ms
・わかったこと
高いメモリ使用率と高いトラフィックで
ElastiCache Redisのレイテンシーが増加
-> 空きメモリの確保が必要
■データレイク構築における成功の秘訣 ～マインドと進め方、設計ベストプラクティス～
畔勝 洋平 さん [アマゾン ウェブ サービス ジャパン]
●データレイクとは
・将来、必要になったときに分析できるように明細データを捨てずに蓄積する「湖」
・あらゆるデータフォマットを、そのまま保存
・スケーラブルに容量無制限で保存できるストレージ
オンプレならHadoopクラスタなどの管理が必要
●ゴミ溜めになってしまうのでは？
・メタデータもセットで登録しないと活用できない
DWHでデータ・ディクショナリがないと分析できないのと同じ
・データレイクはDWHを拡張する
DWH + ビッグデータ処理などにも
●Amazonでの事例
・状況
分析ユーザとユースケースは多種多様
38,000データセット
・DWHの課題
毎年サーバとストレージを倍に増強
パッチ適用などのメンテは月に数百時間
●Andesプロジェクト
・ゴール
成長に合わせて拡張可能なエコシステム
オープンなアーキテクチャで多様な分析の選択肢を提供
・アーキテクチャ
以前はOracleが中心
S3中心に変更
-> RedshiftにLOAD
<- Redshift Spectrumで参照
※re:Invent2018 で発表済み
●マインドと進め方
・情報系案件でよくある課題
ステークホルダーが多く総意を得るのが難しい
主業務があるから、メリットを感じない
提供先は優先して提供してほしい
スケジュール通りに完了したい
クラウドで大丈夫？
ROIは？
-> 調整するうちに本来のゴールから離れて使いづらい結果に
・WorkingBackwards
全てはお客様を起点に逆算して考える
ステークホルダーの目線を合わせる
迷子になったら立ち戻る
プレスリリース -> FAQ -> 体験の詳細をつめる
・スモールスタート
サービスや分析アプリの進化は早い
将来を見越した要件、技術選定、標準化にこだわりすぎない
データフローを用意して、必要に応じて拡張
・ハンズオン・トレーニング
座学だけでなく、体感しないとわからないことも
園児にだけでなく意思決定に関わるステークホルダーも
地味に意思決定に効いてくる
机上より実機検証のほうが早い
オンプレ仮想化基盤と違う
あの業務課題の解決にフィットするのでは！
-> AWS Data Lakeハンズオンセミナー
-> ProServeによるデータレイク・ワークショップ
・PoCドリブン設計
クラウドはアジャイル開発との相性が良い
ウォーターフォールでもPoCドリブンで早く高品質な設計ができる
・進め方のまとめ
WorkingBackwardsで決めて
スモールスタートで始める
ハンズオン・トレーニングでしる
PoCドリブンで高品質に
●8つの設計ベストプラクティス
・大まかなグルーピング
S3に蓄積して分析
クロスアカウントでデータ連携
セキュリティ
1. S3のデータをSQLで分析
・流れ
CSV: 収集用バケット
Glue: パーティション分割
Parquet: 蓄積用バケット
Athena: 参照
・パフォーマンスのポイント
フィルタ条件に合うパーティション分割
分割しぎない
分布を均等に
※Athenaは読み込んだサイズによって課金されるので、絞る
読み込み量を減らすために列志向フォーマットに変換
同じ列のデータがまとまっているので圧縮効率が良い
FileMetaDataで性能も良い
ファイルサイズを小さくしすぎない 128MB〜数GB
EMRでは64MB単位でS3アクセス
小さいとオーバヘッドが大きくなる
2. S3バケットの分け方
・人が見て見やすい単位
収集用、蓄積用
・バケット単位の設定を変えたい場合
バージョニング、ライフサイクル、オブジェクトロックなど
・分け方の例
収集用
1ヶ月で削除 or アーカイブ
データソースにアクセス許可
蓄積用
削除なし
提供先からアクセス許可
3. マルチアカウント構成
・データレイク用にアカウントを分ける
本番、開発、サンドボックスなど
・構成例
本番、開発、サンドボックス
x
システムA、データレイク、システムB
のマトリックス
4. S3バケット間コピー
・処理が早い
・同一リージョン内では無料
5. S3クロスアカウントアクセス制御
・バケットポリシーで aws:PrincipalOrgID でアクセス許可
・ポリシーサイズ上限の考慮不要
6. SSE-KMSによる暗号化
・サーバーサイド暗号化のため、S3側でデータの絞り込みが効く
・万一S3でパブリック公開しても、KMSの権限も必要なので見れない
7. S3パブリック公開防止
・S3 Block Public Accessをアカウントレベルで有効化
アカウントレベル、バケットレベルで設定できる
アカウントレベル設定 > バケットレベル設定
8. SCPによる特定作業禁止
・AWS Organizations
マスター
- メンバー
- OU
- メンバー
-> SCPを メンバー or OU にアタッチ
・Service Control Policy
S3 Block Public Access設定変更禁止 SCP
データレイク用アカウント作成
●8つの設計ベストプラクティスまとめ
・S3のデータをSQLで分析
・S3バケットの分け方
・データレイク用アカウント
・S3経由でデータ連携
・PrincipalOrgIDでアクセス制御
・KMS-SSEで暗号化
・S3 Block Public Access
・SCPで特性操作禁止
■Amazon Managed Blockchainの使いどころとソニー・ミュージック様における使用事例について ～ ソニーミュージックはなぜAWSを選んだのか？ 音楽の権利処理のブロックチェーン・システムを解説 ～
中武 優樹 さん [アマゾン ウェブ サービス ジャパン]
●ブロックチェーンとは
・主な特徴
分散台帳
コンセンサスアルゴリズム
スマートコントラクト
・他の当事者が取引に同意、記録
-> 中央集権を排除できる
・様々な業種で可能性を探している
●ユースケース
・ヘルスケア
カルテの電子化
改ざんできない、変更履歴を厳密に
・製造業
サプライチェーン
到着予測なども
・デジタルコンテンツ
コンテンツをトークン化
低コストで売買可能に
●よく聞く質問1:
スケーラブルなブロックチェーンネットワークを
構築、設定、管理するのが大変
-> Amazon Managed Blockchain
KMSでネットワークの証明書を保護
キーストレージを設定する必要はない
Hyperledger Fabricをサポート、Ethreumも追加予定
ノードのスケーラビリティをコントロールできる
・構築フロー
ネットワーク作成
メンバーの招待
ノードの追加
・Guardianの事例
保険会社
管理が簡単になった
●よく聞く質問2:
鍵管理のベストプラクティスが知りたい
・KMS
鍵の管理を一元化
気密性、可用性を確保
アクセスニーズに合わせてスケール
・CloudHSM
secp256k1に対応
ブロックチェーンでも使える形式
・事例
Ginco
Enterprise wallet
必須要件のクリア
VPCでネットワーク分離
●よく聞く質問3:
これからブロックチェーンを始める。AWSをどう活用する？
・変更可能な台帳管理が必要ならQLDB
透過的でイミュータブル、暗号的に検証できる分散台帳
・事例
healthdirect
●傾向
・信頼された中央機関による台帳の必要性
会社をまたがって共有する必要がない
・分散機関によるトランザクション実行の必要性
会社をまたがって共有する必要がある
第三者認証で取引を効率化したい
白川 朋幸 さん [ソニー・ミュージックエンタテインメント]
●なぜAWSを選んだ？
・やすかったから
・スクラッチ
イニシャル: 1,500
ランニング: 20+
・マネージド
イニシャル: 100
ランニング: 5+
●音楽業界のデータフロー
作家: 著作権 が楽曲制作と同時に発生
-> 音楽出版
作家から預かった権利
分配に関する権利情報
-> 中央管理団体
楽曲管理に関する情報
※権利情報が一部欠落: 各社が管理している
-> 販売・サービス事業者
-> 一般ユーザ
・関連する会社間で紙の契約書が飛び交う
-> やがてクリエイターの収益高が止まる
-> 創作活動の生産性低下
-> Blockchain化
●QLDBとManaged Blockchainのどちらを使う？
・各社 & 中央雨管理団体のシステムがある
-> Managed Blockchain
・権利や契約情報を管理
-> 権利処理のコストを圧縮
-> クリエイターに還元！
●デモ
※セッションマネージャー便利
・Aアカウントで楽曲情報を登録
・Bアカウントで参照
●所感
・まだHyperledger Fabricを直接いじる部分がある
クロスアカウントでチャネル作成する手順が複雑
鍵交換がAWSコンソール上で完結できない
-> 今後のバージョンアップに期待
・Chain Code Repositoryがほしい
ピアノード間でChainCodeの共有が必要
現行だと、CodeCommit->S3->Lambdaで同じものを登録
●Blockchain@Loft やります！
7/25 @AWS Loft Tokyo
■AWSを活用したユーザー認証実装パターン解説
堀場 隆文 さん [アマゾン ウェブ サービス ジャパン]
●ユーザー認証の概要
・インフラ
AWS管理者
↓
システム全体
management console / aws api
-> 認証
aws resource
EC2, Auroraにアクセスする権限があるか？
-> 認可
↑
セキュリティ担当者
・アプリ
開発者
↓
システム全体
カスタムアプリ
awsアプリ
QuickSight
Connect
・エンドユーザー
消費者
従業員
パートナー
-> ここの認証の話
●エンドユーザーが利用するwebアプリ
A: 従来型(HTMLベース)
B: モダンなAPIベース(SPA)
静的コンテンツリクエスト
web APIコール
AWS APIコール
C: クラウドベンダー提供のアプリ
●ユーザ認証に関する関心事
・強固な認証
多要素認証
・ユーザビリティ
SSO
・ガバナンス/コンプライアンス
・構築/運用性
-> 時間、コストがかかる
-> マネージドサービスでイノベーションへの集中を！
●関連サービス
・ID管理/認証/認可
ID管理/認証 だと
SSO, DirectoryService, Cognito
・インフラ保護
・データ保護
・発見的統制
・定性的統制
●課題
・クラウドジャーニーを歩んでいくに従って
アカウントは増えていくので覚えていられない
-> SSO
・マネージドでActiveDirectoryを利用したい
-> DirectoryService
・AWSのcredentialsも管理したい
-> Cognito
●AWS SSO
・強固な認証
多要素認証
固定のパスワードポリシー
・ユーザビリティ
SSO
・ガバナンス/コンプライアンス
ActiveDirectory対応
CloudTrail対応
・構築/運用性
プログラミング不要
マネージド
●Amazon Cognito
・強固な認証
多要素認証
パスワードポリシー
AWS Credentials
・ユーザビリティ
ソーシャル連携
・ガバナンス/コンプライアンス
外部IDプロバイダ連携 SAML2.0
CloudTrail対応
・構築/運用性
プログラミング不要
マネージド
・ユーザープールとIDプール
1: ID/Password -> Token
ユーザープール
ユーザー認証
ユーザーディレクトリ
SAML2.0
2: Token -> Credentials
IDプール
AWS Credentials発行
SAML2.0
3: AWS APIコール
●A: 従来型
・A-1: 認証サービスの活用
ALB
-> Cognito.ユーザープール
-> OIDC対応プロバイダ
・A-2: カスタム実装
EC2 + RDS
EC2 + 既存DB
●B: SPA
・B-1: APIGatewayで提供している場合
Cognito.ユーザープール
IAM
Lambda
・B-2: 独自実装で提供している場合
EC2 + RDS
EC2 + 既存DB
・B-3: Cognito.IDプールを利用する場合
ユーザープール + IDプール
OIDC/SAML2.0 IDプロバイダ + IDプール
※IDプールによるAWS Credentials発行
事前にIAMロールの割り当てルールを設定
認証済みユーザへのロール割当
認証されていないユーザへのデフォルトロール割当
割り当てられたIAMロールを利用して一時的なCredentialsを発行
-> AWS Amplifyで簡単に実装できます
●C: クラウドアプリ
・C-1: SSOを提供したい場合
AWS SSO
100以上のアプリと連携
SAML2.0
・C-2: ADを活用したい場合
ADFSなしでSAML2.0対応
オンプレADとも連携可能
AWS DirectoryServicesとも連携可能
※東京リージョンはまだ
AD Connector経由で別リージョンと連携
■ビジネスを加速するAI活用 - Amazon Forecast と Amazon Personalize
David Pearson さん [Amazon Web Services, Inc.]
●目指しているところ
全てのビルダーに機械学習を提供
●AMAZON ML Stack
・ML Frameworks + Infrastructure
tensorflow
pythorch
keras
glon
-> データサイエンティストなどプロが必要
・ML Services
SageMaker
機械学習を一般へ
ステップごとに指導していく
データの収集と準備
アルゴリズムの選択と最適化
学習環境の構築と管理
モデルのチューニング
モデルの実装
本番環境の拡張と管理
・AI Services
Vision / Speech / Language
Chatbots / Forecasting / Recommendations
関数として利用できる
オムニチャンネルで顧客志向と感情の分析
ドキュメント分析
ビデオのメタデータ抽出
コールセンターエージェント対応効率改善
-> データサイエンティストなしで同じ価値を提供したい
●Amazon Forecast
・概要
まだプレビュー
過去履歴などから将来の時系列を予測
あらゆるドメインに適用可能
受容予測、人員予測、経済指標予測、在庫計画
・予測とは
精度の高さが必要
過剰予測 -> リソースの無駄
過小予測 -> 機会損失
※15%の精度向上 -> 3%の利益向上と言われている
複雑なもの
季節性 / メタデータの管理 / 外部要因（プロモ、祝日など）
・特徴
ドメインに対応したモデルを5ステップで作成
データパイプラインのsetup
autoMLまたはビルトインアルゴリズムの選択
複数のモデルで制度を比較
モデルをデプロイ
予測結果を生成
データの取り込み
履歴データ / 関連データ / 商品属性
検索ヒット率、天候データを取り込みたいなど、関連データを追加できる！
予測は状況によって変わるから幅が必要なもの
リテール向けの独自予測アルゴリズム MQ-RNN
Amazon.comの経験を注ぎ込んだ
直感的なコンソールとAPIで利用できる
予測の可視化
OracleやSAPに連携
●Amazon Personalize
・正しいレコメンデーションとは
カスタムモデルが必要
音楽 / 映画 / 商品 / コンテンツ それぞれ属性が違う
・データの流れ
アクティビティストリーム
インベントリ
デモグラ情報
-> Amazon Personalize
-> カスタムなパーソナライズ / レコメンド
・拡張可能なスキーマ
関連するデータを持っているなら後で追加できる
・内部の処理の流れ
Inspect Data
-> Identify Features
Select Algorighms
-> Select HyperParams
Train Models
-> Optimize Models
Host Models
-> Build Feature Store
Create Realtime Caches
-> ミリ秒単位でレコメンド
・ビルトインモデル
Recipesから選ぶ or AutoMLに任せる
Recipesはベースラインをつくるためのもの
ベースラインと比較して最適なモデルかテスト
cold startで少ないデータから予測をはじめられる
・1クリックデプロイ
エンドポイントを含むインフラをローンチ
自動スケール
・リアルタイムレコメンドのフロー
ブラウザ
リアルタイムにイベントデータをAmazon Personalizeに投げる
レコメンドを取得するWeb APIをキック
APIサーバ
PersonalizeのAPIをキック
・パーソナライズとレコメンデーションで顧客体験を向上
高い精度 / リアルタイム / 簡単に使える / 全てのプロダクトに対応
->
顧客の意図の変化に追従
自動で機械学習
SageMakerで生成したアルゴリズムを利用できるようになる予定
●Save the Date をやります！
7/8(月) @目黒
■感想
Forecast, Personalize すごいですね！機能やライフサイクルを管理するしくみとして作り込んでいた部分が、どんどんサービス化、関数化されてきてAPIの組み合わせだけで、アイデアを実現できる状態が近づいているのを感じました！
組み合わせるためには、間をつなぐしくみが必要になるのは確実なので、この場のような、ノウハウを共有して頂ける機会は、より重要な位置づけになっていきそうですね。
登壇者の皆さん、運営の皆さん ありがとうございました！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。