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の組み合わせだけで、アイデアを実現できる状態が近づいているのを感じました！

組み合わせるためには、間をつなぐしくみが必要になるのは確実なので、この場のような、ノウハウを共有して頂ける機会は、より重要な位置づけになっていきそうですね。

登壇者の皆さん、運営の皆さん ありがとうございました！