AWS Summit Tokyo 2019 お客様セッション振り返り

Analytics on Cloud

• データをデータレイクに集めて、多様な活用につなげる
• 分析や活用技術はいつでも変えられる
• 分析はスケールアウト可能な技術で実現

• 4フェーズ

  • 収集
  • データレイク（保存）
  • 分析
  • 活用・可視化

AWSでのデータ収集、分析、そして機械学習

データ活用の目的

• データに基づいて意思決定をするために、過去を蓄積することで、現在を理解し、未来を予測する

ECサイトのデータ活用例

• 売上実績から、

  • 商品・地域を決める
  • 価格を決める
  • 価格を変える
  • レコメンドする

データに基づいた意思決定に必要なこと

• 十分な質と量のデータ
• データ分析や機械学習を行う仕組み
• 評価指標とそれを計測する仕組み

データに基づいた意思決定のステップ

• ステップ

  • ビジネス課題
  • データ収集
  • データ分析 or 機械学習
  • 評価
• シーズからではなく、ビジネス課題からスタートする
• ループを回して評価し、データ活用が役立つことを確かめる

最も時間がかかるのはどこか？

• データを蓄積する部分
• 蓄積した過去のデータは資産
• 捨ててしまったデータ = 失われた時間

やりたいことは後から必ず変わる、増える

• データの取捨選択をせず汎用的に蓄積することが大切
• だからデータレイク！

データレイクをデータ活用の基盤とする

• 全てのデータを一箇所に集めて、そのままの形式で保存
• データレイクからデータを読みだして、新しいデータ活用を素早く簡単に実行

データレイクに最適なAmazon S3

• データを任意のファイル形式で保存
• 容量の上限なし
• 高い耐久性：99.999999999%
• 低コスト：$0.025/GB/月
• 多様な権限管理や暗号化によるセキュリティ
• APIにより様々なプログラミング言語やサービスと連携

何からやるべきか？

• データ活用は、常にビジネス課題からスタート

  • データを早く集め始めることが重要だが、それを目的化してはいけない
• まずは、一本のデータ活用フローを作ってみる

データ活用フロー設計のポイント

• 万能なツールは存在しない

  • 適切なツールを適切な対象に適用

• やりたいことは変わる

  • やりたいことに集中して素早く試行錯誤ができるようにマネージドサービスで作る

• 扱いたいデータ量も変わる

  • スケールアウトするようにサーバーレスで作る

誰がどのようにデータを利用するか？ - 分析基盤

• Amazon Athena

  • SQLで分析
  • 分析環境を意識せず利用者が簡単に利用

• Amazon Redshift

  • SQLで分析
  • 管理者がクラスターを運用
  • 利用者はデータを分析

• Amazon EMR

  • Hadoop / Sparkで分析
  • アプリケーションをエンジニアが分析

誰がどのようにデータを利用するか？ - 分析ツール

• Amazon QuickSight

  • BIの画面で分析

• Amazon Elasticsearch

  • 多数の表にまたがる分析
  • リアルタイムに分析

• Amazon SageMaker

  • Jupyter Notebookを使いPythonで分析

Amazon QuickSight

• サーバーレスのBIサービス
• ブラウザのみで全機能が利用可能
• インメモリの計算エンジンを持っている
• 手元のファイルをアップロードして分析することもできる
• S3上のデータを定期的に取り込むこともできる

QuickSight + Athena

• 大規模データであってもサーバーレスでBI環境を実現
• QuickSightが直接Athenaをクエリ

目指すデータ活用から必要なデータ収集を考える

• どのデータを、どこから、どのくらいの細かさと頻度で集めるか
• 後から増やせないので、可能な限り細かくデータを取る方がいい

• ログデータ

  • Amazon Kinesis Data FirehoseでバッファリングしてS3に入れる

• Amazon RDSにあるリレーショナルデータ

  • ダンプしてS3に置く
  • AWS GlueでデータベースからS3にバルクで入れる
• 任意のデータをSDKで直接S3にPUTもできる

必要であればデータ変換（ETL）を行う

• JSON / XMLのような半構造化データをParquetのような構造化データに変換
• 日付のフォーマットやカラムの外れ値処理などのデータ整形
• 複数のデータソースから収集したデータの結合

ETL処理もサーバーレスが基本方針

• AWS Lambda

  • 15分以内の小規模な処理
  • S3に置かれたら逐次処理

• AWS Glue Python Shell

  • 中規模な処理
  • データをまとめて処理

• AWS Glue Spark Job

  • 大規模な処理
  • データをまとめて処理

機械学習の活用

• データ

  • 過去を蓄積する

• 学習

  • 未来・未知を予測し

• 推論

  • 意思決定をする

機械学習を活用する意味を考える

• 機械学習も常にビジネス課題からスタート
• 機械学習で解ける（解けそうな）問題を理解する

• 注力する領域を決める

  • 機械学習のすべてを、自社で行う必要があるとは限らない
  • クラウドサービスやアルゴリズム・モデルの公開化が進み、実装の難易度は下がる一方データの重要性は増している

QuickSight ML Insights

• 専門家不要で使えるインサイト（洞察）機能を提供

• 機械学習ベースの異常検知

  • 自動的に異常値を発見して報告

• 機械学習ベースの予測

  • 過去の値から将来を予測

• 自動ナラティブ

  • わかりやすい文章で分析結果を提供

AWSが提供する機械学習サービスのスタック

• AIサービス

  • 機械学習の深いスキルなしに機械学習をアプリケーションに組み込める

• MLサービス

  • 機械学習のモデルを高速に開発・学習・デプロイできる
• MLフレームワーク&インフラストラクチャ

解きたい問題とスキルに合わせてツールを選択

• 推論のAIサービス

  • 学習されたモデルを利用
  • Amazon Rekognition
  • Amazon Translate

• 学習と推論のAIサービス

  • サービスでモデルを学習して利用
  • Amazon Personalize
  • Amazon Forecast

• MLサービス

  • アルゴリズムを実装/利用して自分でモデルを学習
  • Amazon SageMaker

まとめ

• 常にビジネス課題からスタート
• データレイクはデータ活用の基盤
• 目的と使う人に合ったツールを選択

データレイク構築における成功の秘訣 〜マインドと進め方、設計ベストプラクティス〜

データレイクとは

• 将来、必要な時に分析できるよう明細データを捨てずに蓄積する「湖」
• 多様なフォーマットのデータをそのまま保存できるストレージ
• 全てのデータを一元的に保存できる容量無制限のストレージ

ゴミ溜めになるのではないか？

• データとともにメタデータを登録しないと後で活用できない

データレイクはDWHを拡張する

• データウェアハウスに加えてビッグデータ処理なども可能に

  • 明細データを捨てずに蓄積
  • 多様なフォーマットを保存可能
  • 容量無制限なため一箇所に集約

Amazonのビジネスとデータ活用

• Amazonはグローバルに様々なビジネスを展開
• そこから生まれる大量のデータを分析してビジネス判断

• 多様な分析要件と大きなワークロード

  • 分析ユーザーとユースケースは多種多様
  • 38,000のデータセット
  • 80,000ユーザー

マインドと進め方

• Working Backworkds
• スモールスタート
• ハンズオン・トレーニング
• PoC ドリブン

情報系案件でよくある課題

• ステークホルダーが多く、全員の同意を得るのが難しい

  • 情報系担当
  • 上流システム
  • 経営層
  • 情報セキュリティ部門
  • データ提供先
• 調整するうちに本来のゴールから離れ使われない基盤に

Working Backwords

• 全てはお客様を起点に逆算して考える。"Andes"も同じアプローチ
• ステークホルダーの目線を合わせる。迷子になったら立ち戻る

• ワークショップ

  • プレスリリースを作る
  • FAQを作る
  • お客様体験を詳細に詰める
• ProServeによる有償ワークショップ支援も可能

スモールスタート

• AWSサービスや分析アプリの進化は速い
• 将来を見越した完璧な要件定義・技術選定・標準化にこだわり過ぎない
• まずは必要なデータ活用フローを作り、必要に応じて活用

ハンズオン・トレーニング

• 座学だけではなく、ハンズオンで体感しないとわからない
• エンジニアだけでなくIT戦略の意思決定に関わるステークホルダーも
• 地味に意思決定に効いてくる

PoCドリブン設計

• クラウドはアジャイル型開発と相性が良いが

• ウォータフォール型開発でもPoCドリブンで速く高品質な設計

  • 正式な本番・開発用とは別にサンドボックス用AWSアカウントを用意
  • 検討や方式設計など初期フェーズからPoCで試しながら設計

ベストプラクティス1 - S3のデータをSQLで分析

• やりたいこと

  • S3のファイルをSQLで分析したい
  • Redshiftのコストを抑えたい

• 解決策

  • Athena、EMRでSQLでS3のデータを分析
  • Redshiftで腹持ちするものとSpectrumでS3を参照するものを使い分け

• パフォーマンスを引き出す3つのポイント

  • フィルタ条件に使うキーでパーティション分割
  • 読み込み量を減らすためParquetなどの列指向フォーマットに変換
  • ファイルサイズを小さくしすぎない（128MB〜数GB程度）

ベストプラクティス2 - S3バケットの分け方

• 検討項目

  • データレイクを設計しているがS3バケットを分ける指針がわからない

• 指針

  • 人が見て直感的にわかりやすい単位で分ける
  • バケット単位の設定を変えたい場合はバケットを分ける
  • バケット単位のサービス上限に達しないように分ける

• 例

  • 収集用バケットと蓄積用バケット

ベストプラクティス3 - マルチアカウント構成

• 検討項目

  • データレイク用アカウントを作るか、既存アカウント内に作るか

• 推奨案

  • データレイク用アカウントを作る

ベストプラクティス4 - S3バケット間コピー

• 検討項目

  • アカウント間のデータ連携をどのように行うか

• 推奨案

  • バケット間でコピー

• メリット

  • 高速で同一リージョン内ではデータ転送料金はかからない
  • VPC間の通信設定は不要（VPC Peering等）

ベストプラクティス5 - S3クロスアカウントアクセス制御

• 検討項目

  • バケットポリシーやIAM信頼ポリシーにアカウントIDを記述すると肥大化

• 推奨案

  • バケットポリシーで aws:PrincipalOrgID でアクセス管理
• aws:PrincipalOrgID で記述すると
• 一行の記述で同じOrganization内のアカウントからアクセス可能

ベストプラクティス6 - SSE-KMSによる暗号化

• やりたいこと

  • 情報漏洩対策・規制対応のためS3を暗号化したい

• 解決策

  • SSE-KMSを利用

• メリット

  • セキュリティ・パフォーマンス
  • サーバーサイド暗号化のためS3側でデータの絞り込みが効く
  • 万が一S3でパブリック公開してもアクセス不可
  • KMSにアクセスできなければ、バケットに対してアクセス権があってもデータは見れない

ベストプラクティス7 - S3パブリック公開禁止

• S3 Block Public Acess有効化
• アカウントレベルでS3 Block Public Accessを有効化

ベストプラクティス8 - SCPによる特定操作の禁止

• 作業ミスを防ぎたい

次世代BI - 機械学習ベースの洞察をあらゆるユーザーへ提供するAmazon QuickSight

特徴

• サーバー管理不要
• エンドツーエンドのBIソリューション
• 容易なスケール
• ML Insights
• 支払いは実際に使用した分のみ
• ダッシュボードへの埋め込み

トレンド1

• 組織内の「誰もが」、単なる「概要」でなく、活用可能な「インサイト」を求めている
• モダンなBIは大規模なレポーティングも必要

セッション単位課金

• Author

  • $18 / ユーザー / 月

• Reader

  • $0.3 / セッション
  • 最大で $5 / ユーザー / 月

One Platform：データ&アナリティクス

• 目的に合わせて選択可能なサービス群

トレンド2

• 隠れたインサイトをより簡単に認識し、適切んタイミングで、適切なアクションを実行

ML Insights

• 機械学習による異常検知
• 機械学習による予測

• 自動ナラティブ

  • わかりやすい文章によるサマリ機能

トレンド3

• どこでも、いつでも分析が可能に

既存アプリへの組み込みダッシュボード

• iframeで埋め込む
• セキュリティ機能を効かせて埋め込むことができる
• イントラネットやSaaSに組み込める
• あくまでQuickSightの権限を持っている人に見せる用なので注意

感想

今までWeb・アプリのログ分析はGoogle Analyticsで見るくらいで、それ以外のBIツールや機械学習は考えたこともなかった。

確かに、サービスを改善しようとするときもユーザーの声であったり、チームメンバーの意見ベースだったりとなかなかデータ・ドリブンにできていなかった。

• データはとりあえずS3上に構築したデータレイクに整理して格納。
• Athena・QuickSightを使って可視化

このあたりがスモールステップで始めやすそうなので、7・8月で導入できたらと思う。

今日特に印象に残ったのが「常にビジネス課題からスタートせよ」という教訓だった。

「流行に乗ってデータレイクを作りたい」「こんなデータ集めてみた」というスタートでは、そもそも目的が後付けになってしまってうまくいかないということだろう。

Amazon / AWSのように、ユーザーファーストで課題から逆算して手段を選ぶ意識を常に持ち続けたい。

re:Capも気づけばあと1日。

明日はIoT&Machine Learningでこれまた楽しみなテーマなので、最後まで学び尽くしたい。