10 things to start data analytics on AWS

Webinar delivered on July 2, 2020. A ten-step framework for starting data analytics on AWS, covering business goals, presentation layer, data sources, ETL, scaling, security, governance, cost optimization, and migration. Slides in Japanese.

Transcript

1. © 2020, Amazon Web Services, Inc. or its Affiliates. Shota Yamazaki Senior Solutions Architect Amazon Web Services Japan AWSでデータ分析を始めるのに必要な10のこと ⼀つずつポイントを⾒てみましょう
2. © 2020, Amazon Web Services, Inc. or its Affiliates. ⼭﨑 翔太 ソリューションアーキテクト • ⼤⼿Web系のお客様を担当 • 好きな⾔葉 • “There is always a better way.” by Thomas A. Edison • 好きなAWSサービス • Amazon Kinesis Family • AWS Lambda
3. © 2020, Amazon Web Services, Inc. or its Affiliates. AWSでデータ分析を始めるのに必要な10のこと 1. ビジネスゴールを定める 2. プレゼンテーションレイヤを決める 3. 必要なデータソースを明確にする 4. データの加⼯⽅式を決定する 5. 新しい分析に広げていく 6. スケーラビリティを確保する 7. ⾼いセキュリティを確保する 8. ガバナンスと使いやすさを両⽴する 9. コストを最適化する 10.AWS にデータ分析の仕組みを移⾏する
4. © 2020, Amazon Web Services, Inc. or its Affiliates. 1. ビジネスゴールを定める
5. © 2020, Amazon Web Services, Inc. or its Affiliates. データに基づいた意思決定に必要なこと ビジネス課題からスタートする 1. ビジネス課題
6. © 2020, Amazon Web Services, Inc. or its Affiliates. データ分析で解決するビジネス課題の例 • どこに何が売れているかをより早く知り、営業活動を効率化したい • 何がいくつ売れているかを把握して、仕⼊れの効率を改善したい • 需要を可視化・予測することで、原材料の廃棄率を下げたい • ユーザーの購⼊履歴から商品をレコメンドし、購⼊率・契約率を上げたい • 会員の⾏動を元に退会率を予測して、退会を抑⽌する施策を打ちたい • サイトを利⽤するユーザーの⾏動パターンから、導線を改善したい • トラフィックのパターンを可視化して、システムのセキュリティを⾼めたい ・・・
7. © 2020, Amazon Web Services, Inc. or its Affiliates. 必要なメカニズム 1. 定量的に測定可能なアウトプット “どこに何が売れているかをより早く知ることで、 営業活動を効率化し、営業担当者当たりの売上を20%向上する” 2. ツールとプロセス “営業担当者とマネージャーが⾃分の担当セグメントの売り上げ傾向を、 モバイル端末からダッシュボードで⾒ることが出来るツール” 3. 継続的にプロセスを改善する仕組み
8. © 2020, Amazon Web Services, Inc. or its Affiliates. まず、データを集計・可視化し、簡単な仮説検証をまわす 最初から明確な評価指標を持つことは難しい 得られたデータをもとに、 徐々に施策と評価指標を 明確にしていく データの蓄積 データレイク 過去・現在の可視化 ダッシュボードでデータを⾒られる形に さまざまな集計軸で分析 BI ツールや SQL 等 機械学習による 予測や判断の⾃動化
9. © 2020, Amazon Web Services, Inc. or its Affiliates. 何から始めるべきか︖ データベース まずは、データ分析で解決する ビジネス課題 と ビジネスゴール を決める ログファイル Amazon S3 意思決定と評価 ⼩さく始めて、⼀本の データ活⽤フロー を作ってみる 将来的な拡張を前提に、データレイク にデータを溜めていく 効果を定量的に評価して、施策を⾒直すフィードバックサイクルを回す
10. © 2020, Amazon Web Services, Inc. or its Affiliates. ビジネスゴールが定まったら、 まず⼀本のデータ活⽤フローを作ってみましょう
11. © 2020, Amazon Web Services, Inc. or its Affiliates. 2. プレゼンテーションレイヤを決める
12. © 2020, Amazon Web Services, Inc. or its Affiliates. ビジネスゴールを計測するためのプレゼンテーションレイヤ 定量的に測定可能なアウトプット “どこに何が売れているかをより早く知ることで、 営業活動を効率化し、営業担当者当たりの売上を20%向上する” ツールとプロセス “営業担当者が⾃分の担当セグメントの売り上げ傾向を、 モバイル端末からダッシュボードで⾒ることが出来るツール” ビジネスユーザーでも⼿軽に利⽤可能なBIツールが必要
13. © 2020, Amazon Web Services, Inc. or its Affiliates. 誰がどのようにデータを利⽤するか︖
14. © 2020, Amazon Web Services, Inc. or its Affiliates. データの利⽤形態によって分析ツールを選ぶ • データサイエンティスト が活⽤ • Jupyter Notebook を 使い Python で分析 • ビジネスユーザーが参照 • BIの画⾯で分析 • グラフィカルに可視化 BI SQL Client / 分析ツール ノートブック環境 • データアナリストが活⽤ • 多数の表に跨がる分析や リアルタイムに近い分析 Amazon QuickSight Amazon Elasticsearch Service Amazon SageMaker
15. © 2020, Amazon Web Services, Inc. or its Affiliates. データの利⽤形態によって分析基盤を選ぶ • Hadoop/Sparkで分析 • アプリケーションを エンジニアが実装 • 管理者がクラスターを管理 • SQLで分析 • アドホックに分析 • 分析環境を意識せず 利⽤者が簡単に利⽤ クエリサービス データウェアハウス Hadoopクラスター Amazon Athena Amazon Redshift Amazon EMR • SQLで分析 • 定常的に or バッチで分析 • 利⽤者はデータを分析 • 管理者がクラスターを管理
16. © 2020, Amazon Web Services, Inc. or its Affiliates. 構成例１︓QuickSight のみで簡単BI Amazon QuickSight CSV CSV S3上のデータを 定期取り込み CSV CSV ⼿元のファイルを アップロード ブラウザで BIを利⽤ Amazon S3 CSV CSV インメモリ計算エンジン
17. © 2020, Amazon Web Services, Inc. or its Affiliates. 構成例２︓QuickSight + Athena で⼤規模対応 ⼤規模データであってもサーバーを⽴てずにBI環境を実現 Amazon QuickSight ⼀部のデータは QuickSightに 取り込んで⾼速化 ブラウザで BIを利⽤ Amazon S3 直接 Athena をクエリ Amazon Athena CSV CSV 表 表 CSV CSV
18. © 2020, Amazon Web Services, Inc. or its Affiliates. 誰がどのようにデータを利⽤するかによって 必要な分析環境を選ぶ データレイクにデータを溜めていれば、 複数の環境を作ったり、後から変えたり増やしたりできる
19. © 2020, Amazon Web Services, Inc. or its Affiliates. 3. 必要なデータソースを明確にする
20. © 2020, Amazon Web Services, Inc. or its Affiliates. 必要なデータがどこにあるかを洗い出す
21. © 2020, Amazon Web Services, Inc. or its Affiliates. データを収集する粒度と頻度を決める • どのデータを、どのくらいの細かさで集めるかを決める • あとから増やすことは難しいので、可能な限り細かく データを取る • どのデータを、どのくらいの頻度で集めるかを決める • 更新頻度を上げるとコストや設計の難易度も上がるため、 ビジネスゴールに基づいて妥当な頻度を考える • ニアリアルタイム（数秒〜数分の遅延） • １時間おき • ⽇次 • ⽉次
22. © 2020, Amazon Web Services, Inc. or its Affiliates. データソースと更新頻度に応じて取り込み⼿段を選択する Amazon Kinesis Data Firehose Amazon S3 Amazon RDS ストリームデータの バッファリング AWS IoT Core バルクインポート CLI/SDK 直接S3にPUT シンプルに仕組みを作る場合や 既にファイル連携の仕組みがある場合には有効 DB on EC2/オンプレ Amazon CloudWatch Logs ログデータ IoT データベース ダンプファイル AWS Glue データファイル Amazon AppFlow SaaS API呼び出し
23. © 2020, Amazon Web Services, Inc. or its Affiliates. 必要なデータがどこにあるかを洗い出す データを収集する粒度と頻度を決める データソースと更新頻度に応じて 取り込み⼿段を選択する
24. © 2020, Amazon Web Services, Inc. or its Affiliates. 4. データの加⼯⽅式を決定する
25. © 2020, Amazon Web Services, Inc. or its Affiliates. 必要なデータ加⼯処理（ETL）の例 • ⽇付のフォーマットやカラムの外れ値処理などのデータ整形 • 複数のデータソースから収集したデータの結合 • JSON / XML のような半構造化データを Parquet のような構造化データに変換
26. © 2020, Amazon Web Services, Inc. or its Affiliates. ETL処理はサーバーレスを中⼼に考える
27. © 2020, Amazon Web Services, Inc. or its Affiliates. AWSのサービス形態 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運⽤設計 スケールアウト設計 ミドルウェア導⼊ OS導⼊ アプリケーション開発 オンプレミス 独⾃構築 on EC2 マネージドサービス 開発者が担当 AWSが担当 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運⽤設計 スケールアウト設計 ミドルウェア導⼊ OS導⼊ アプリケーション開発 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運⽤設計 スケールアウト設計 ミドルウェア導⼊ OS導⼊ アプリケーション開発 サーバーレス 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運⽤設計 スケールアウト設計 ミドルウェア導⼊ OS導⼊ アプリケーション開発
28. © 2020, Amazon Web Services, Inc. or its Affiliates. サーバーレスで⾏うETL処理の使い分け AWS Lambda AWS Glue Python Shell AWS Glue Spark • 実⾏時間の制限なし • 複数のワーカーで並列分散処理 • 数100GB以上の⼤量データ処理 も可能 • 実⾏時間の制限なし • Lambda に⽐べて利⽤できる メモリ量が多い（1GBまたは16GB） • Athena、Redshift、EMR に対する SQLベースの処理も可能 • 実⾏時間に最⼤15分間の制限あり • 豊富なトリガーを持ち、 S3に配置されたタイミングで 逐次処理することも可能 • Python以外の⾔語も選択可能 ⼩規模処理 中規模処理 ⼤規模処理 データの規模やETL処理の中でやりたいことによって使い分ける データを加⼯するPythonのコードのみを実装 NumPy、SciPy、Pandas などのライブラリも利⽤可能 PySpark や Scalaで実装 必要なものはコードのみ
29. © 2020, Amazon Web Services, Inc. or its Affiliates. まとめ︓シンプルなデータ活⽤フローの例 Amazon Athena Amazon QuickSight AWS Glue ETL処理 Amazon Kinesis Data Firehose Amazon S3 Amazon RDS ログデータ Amazon S3 データベース バッファリング ブラウザで BIを利⽤ AWS Glue バルクインポート
30. © 2020, Amazon Web Services, Inc. or its Affiliates. 5. 新しい分析に広げていく
31. © 2020, Amazon Web Services, Inc. or its Affiliates. やりたいことは後から必ず変わる、増える そのとき、シンプルにやりたいことを 実現できる⽅法を選択する
32. © 2020, Amazon Web Services, Inc. or its Affiliates. シンプルなソリューションの例︓QuickSight ML Insights QuickSightが機能の⼀部として 機械学習の活⽤を提供 1. 機械学習ベースの異常検知 ⾃動的に異常値を発⾒して報告 2. 機械学習ベースの予測 過去の値から将来を予測 3. ⾃動ナラティブ ⼈が読める⽂章で分析結果を提供
33. © 2020, Amazon Web Services, Inc. or its Affiliates. 機械学習も解きたい問題とスキルに合わせてツールを選択 Amazon SageMaker 学習済のモデルを利⽤ サービスでモデルを学習して利⽤ 推論のAIサービス 学習と推論のAIサービス MLサービス アルゴリズムを実装/利⽤して ⾃分でモデルを学習 • Amazon Rekognition • Amazon Translate … • Amazon Personalize • Amazon Forecast …
34. © 2020, Amazon Web Services, Inc. or its Affiliates. 分析基盤を「育てていく」という考え⽅ Athena や Redshift などの分析基盤を⼀度選択したとしても ずっとそのまま使い続ける必要はない ワークロードもデータの中⾝も プロジェクトの状況や時間の変化とともに変わっていく その変化に応じて 分析基盤で利⽤するサービスも切り替えていくことを 前提として考える
35. © 2020, Amazon Web Services, Inc. or its Affiliates. 例１︓Athena から始まる分析基盤の変遷 Athena で CSV にクエリ 分析基盤の⼀部を Redshift に 切り替え 事業が軌道に乗って 分析ユーザー数が増加 Glue で Parquet 変換 データ量が増⼤して クエリ実⾏時間がかかるように 分析ユーザ数増加 Personalize で 配信内容の カスタマイズ 分析に基づいた 施策の実施
36. © 2020, Amazon Web Services, Inc. or its Affiliates. 例２︓Redshift から始まる分析基盤の変遷 オンプレ DWH から Redshift に移⾏ S3 に⽣データ 新サービスのデータ を既存のマスタと 紐づけて Athena で クエリを実⾏ 新サービスの ローンチ Forecast で 商品の需要予測 新しい施策の 実施 S3 データレイクの活⽤
37. © 2020, Amazon Web Services, Inc. or its Affiliates. 最初から⼤きく始める必要はない 新しいデータ活⽤を広げていくタイミングで、 シンプルにやりたいことを実現できる⽅法を選択する 分析基盤に求められることは 時間やステージによって変わってくるため、 分析基盤も変化に対応して拡充していく
38. © 2020, Amazon Web Services, Inc. or its Affiliates. 6. スケーラビリティを確保する
39. © 2020, Amazon Web Services, Inc. or its Affiliates. 分散処理 と サーバーレス でスケーラビリティを確保する
40. © 2020, Amazon Web Services, Inc. or its Affiliates. • クラウドのメリットは、必要なときに必要な分だけリソースを使えること • 分散処理できる技術を採⽤することで、スケーラビリティを確保出来る • マネージドサービス または サーバーレス を利⽤することで、 複雑なクラスター管理が不要となる 分散処理できるサービスを活⽤ AWS Glue Spark DWH クエリエンジン Amazon Redshift Amazon Elasticsearch Service Amazon SageMaker ETL処理 検索/可視化 機械学習 Amazon Athena
41. © 2020, Amazon Web Services, Inc. or its Affiliates. サーバーレスとは プロビジョニングや管理対象の サーバを持たない 使⽤量に応じて ⾃動でスケールする アイドル状態では コストがかからない 可⽤性や耐障害性が ビルトインで備わっている
42. © 2020, Amazon Web Services, Inc. or its Affiliates. データ分析に関連するサーバーレスサービスの例 AWS Glue ストレージ （データレイク） 計算ロジック ETL処理 AWS Lambda AIサービス （画像認識 など） Amazon QuickSight Amazon Athena Amazon Kinesis Data Firehose Amazon S3 Amazon AppFlow Amazon Rekognition ストリームデータの 取り込み クエリエンジン BI SaaSデータの 取り込み
43. © 2020, Amazon Web Services, Inc. or its Affiliates. まとめ︓シンプルなデータ活⽤フローの例 Amazon Athena Amazon QuickSight AWS Glue ETL処理 Amazon Kinesis Data Firehose Amazon S3 Amazon RDS ログデータ Amazon S3 データベース バッファリング ブラウザで BIを利⽤ AWS Glue バルクインポート 全ての要素をサーバーレスで実現 分散処理 と サーバーレス でスケーラビリティを確保する
44. © 2020, Amazon Web Services, Inc. or its Affiliates. 7. ⾼いセキュリティを確保する
45. © 2020, Amazon Web Services, Inc. or its Affiliates. 誰が、どのデータの、どの部分を⾒ることができるのか 詳細な権限管理はデータレイクの重要なポイント
46. © 2020, Amazon Web Services, Inc. or its Affiliates. 権限管理の全体像 Amazon Athena Amazon QuickSight AWS Glue ETL処理 Amazon Kinesis Data Firehose Amazon S3 Amazon RDS ログデータ Amazon S3 データベース AWS Glue Amazon Redshift Spectrum Load
47. © 2020, Amazon Web Services, Inc. or its Affiliates. 権限管理の全体像 Amazon Athena Amazon QuickSight AWS Glue ETL処理 Amazon Kinesis Data Firehose Amazon S3 Amazon RDS ログデータ Amazon S3 データベース AWS Glue データカタログ Amazon Redshift Spectrum Load
48. © 2020, Amazon Web Services, Inc. or its Affiliates. 権限管理の全体像 Amazon Athena Amazon QuickSight AWS Glue ETL処理 Amazon Kinesis Data Firehose Amazon S3 Amazon RDS ログデータ Amazon S3 データベース AWS Glue データカタログ Amazon Redshift Glueデータカタログの IAMポリシーで、テーブル 毎に誰がメタデータを ⾒られるかを管理可能 Athenaにアクセスする ユーザーの誰がどのS3上の データにアクセス出来るか をIAMにより管理可能 S3のバケットポリシーに より、AthenaやRedshiftを 介さず直接S3にアクセス することの禁⽌が可能 Redshiftではユーザー毎に 表レベルおよび列レベルの アクセス制御が設定可能 QuickSightではユーザー毎に 表(列)レベルおよび⾏レベルの アクセス制御が設定可能 IAM IAM IAM QuickSight ユーザー管理 IAM IAM IAM Spectrum Load Redshift ユーザー管理
49. © 2020, Amazon Web Services, Inc. or its Affiliates. 例︓QuickSight の⾏レベルセキュリティ ユーザに⾒せる情報を ⾏レベルでコントロール どのユーザ / グループにどのデータを ⾒せるかは、管理表で制御 JaneはState=WA or ORが閲覧可能 SusanはState=CAのみ閲覧可能
50. © 2020, Amazon Web Services, Inc. or its Affiliates. 加⼯前・加⼯済の各々のデータに対して 複数のレイヤーで詳細な権限管理を⾏えることは データレイク構成の⾮常に⼤きなメリット しかし、よりシンプルに管理したい場合はどうすべきか︖
51. © 2020, Amazon Web Services, Inc. or its Affiliates. AWS Lake Formation における権限管理 Grant 選択
52. © 2020, Amazon Web Services, Inc. or its Affiliates. 表レベルおよび列レベルの権限付与 ユーザー 1 ⼀部の列のみ アクセス可能 ユーザー 2 全ての列に アクセス可能 列レベルのアクセス制御の指定
53. © 2020, Amazon Web Services, Inc. or its Affiliates. 複数のレイヤーで詳細な権限管理を⾏えることは データレイク構成の⾮常に⼤きなメリット よりシンプルに管理したい場合には、 AWS Lake Formation の権限管理機能を活⽤
54. © 2020, Amazon Web Services, Inc. or its Affiliates. 8. ガバナンスと使いやすさを両⽴する
55. © 2020, Amazon Web Services, Inc. or its Affiliates. • データカタログとは • 物理的なデータの場所（S3上の場所）と、データの構造（列、型など）や アクセス⽅法の関係性を定義し、データを検索可能にするもの • AWS Glue データカタログ • Athena、Redshift Spectrum、EMR からS3上の半構造データにアクセス する場合の、データカタログとして利⽤することが可能 • AWS Lake Formation データカタログ • Lake Formation が、Glue のデータカタログをラップした形で、 統合的なデータカタログ機能を提供 蓄積したデータをカタログとして⼀覧化
56. © 2020, Amazon Web Services, Inc. or its Affiliates. Glue / Lake Formation データカタログ利⽤の流れ Amazon Athena Amazon QuickSight AWS Glue Amazon Kinesis Data Firehose Amazon S3 Amazon RDS ログデータ Amazon S3 データベース AWS Glue データカタログ Amazon Redshift Spectrum AWS Lake Formation
57. © 2020, Amazon Web Services, Inc. or its Affiliates. 例︓Athena からのアクセス Glue / Lake Formationで 定義されたデータカタログ （データベース、テーブル） データカタログで 定義されたテーブル名 によるアクセス
58. © 2020, Amazon Web Services, Inc. or its Affiliates. ビジネス⾯のメタデータを合わせてカタログ化 Amazon Athena Amazon QuickSight AWS Glue Amazon S3 データカタログ Amazon Redshift Spectrum Amazon DynamoDB AWS Lake Formation 物理メタデータを管理 AWS Lambda Amazon API Gateway ビジネス⾯のメタデータを格納 • データの種類 • 所有する部署 • 更新頻度 • データの機密度 • 物理メタデータが持つ スキーマの変更可能性 など • 両メタデータを統合して⼀覧化 • データをサブスクリプション
59. © 2020, Amazon Web Services, Inc. or its Affiliates. データのカタログ化には、 Glue や Lake Formation のデータカタログを活⽤する 物理メタデータに加えて、 ビジネス⾯のメタデータも管理して、 ⼀緒に⼀覧できるようにしていく
60. © 2020, Amazon Web Services, Inc. or its Affiliates. 9. コストを最適化する
61. © 2020, Amazon Web Services, Inc. or its Affiliates. コスト最適化に向けた考慮事項 1. オンデマンド化と並列化 2. サーバーレス化 3. S3ストレージクラスの選択 4. リザーブドインスタンスや スポットインスタンスの活⽤
62. © 2020, Amazon Web Services, Inc. or its Affiliates. 1. オンデマンド化と並列化 • 常時起動している必要がないリソースは必要な時のみ起動 • ETL処理やデータ連携のバッチ処理など • 稼働台数を増やして並列化することで、処理時間を短縮 • クラウドでは、1台のマシンで10時間かかる処理と、 10台のマシンで1時間かかる処理で、必要なコストは同じ
63. © 2020, Amazon Web Services, Inc. or its Affiliates. 2. サーバーレス化 プロビジョニングや管理対象の サーバを持たない 使⽤量に応じて ⾃動でスケールする アイドル状態では コストがかからない 可⽤性や耐障害性が ビルトインで備わっている サーバーレスの特徴
64. © 2020, Amazon Web Services, Inc. or its Affiliates. 3. S3ストレージクラスの選択 S3 Standard S3 Standard-IA S3 One Zone-IA S3 Glacier S3 Intelligent-Tiering S3 Glacier Deep Archive ⾼頻度 低頻度 低コスト 通常のコスト アクセス頻度とコストの最適なS3ストレージクラスを選択 古いデータは低コストのストレージクラスに順次移動
65. © 2020, Amazon Web Services, Inc. or its Affiliates. 4. リザーブドインスタンスやスポットインスタンスの活⽤ • 開発フェーズ 〜 テストフェーズ • Pause/Resume によって夜間などにはクラスターを停⽌しながら 運⽤し、オンデマンドでコストを最適化 • 本番稼働後 • 1年もしくは3年のRIを購⼊し、コストを最適化 Amazon Redshift におけるリザーブドインスタンス活⽤の例
66. © 2020, Amazon Web Services, Inc. or its Affiliates. まとめ︓コスト最適化に向けた考慮事項 1. オンデマンド化と並列化 2. サーバーレス化 3. S3ストレージクラスの選択 4. リザーブドインスタンスや スポットインスタンスの活⽤
67. © 2020, Amazon Web Services, Inc. or its Affiliates. 10. AWS にデータ分析の仕組みを移⾏する
68. © 2020, Amazon Web Services, Inc. or its Affiliates. データ分析の仕組みを丸ごと移⾏する検討の前に、 データを Amazon S3 にも転送し、 AWS上でデータ活⽤のサイクルを回してみる
69. © 2020, Amazon Web Services, Inc. or its Affiliates. AWSへのデータの移⾏⽅式 • ⼩規模のデータであれば、ファイルにまとめてインターネット経由で S3 に転送するなどシンプルな移⾏が可能 • 継続的に⼤量のデータを移⾏する場合には、AWS Direct Connect や VPN 経由で転送 • 数100TB〜ペタバイトオーダーのデータを⼀度に 移⾏する場合には、AWS Snowball を検討
70. © 2020, Amazon Web Services, Inc. or its Affiliates. AWSへの移⾏パス • リフト＆シフト • 既存のアーキテクチャを採⽤して、クラウドにそのまま移⾏を完了し、 そのあとで、随時変更していくアプローチ • リアーキテクティング • クラウドのメリットを最⼤化するために再設計するアプローチ • 例︓Hadoop のワークロードを EMR ではなく Glue や Athena に移⾏する • ただし、研究、計画、実験、教育、実装、導⼊の、プロセスが必要 • ハイブリッド • 既存の仕組みに対して、リフト＆シフトアプローチを採⽤ • 新しいアプリケーションでは、再設計されたアーキテクチャを使⽤
71. © 2020, Amazon Web Services, Inc. or its Affiliates. データウェアハウス移⾏の流れ 評価 アセスメント PoC データウェアハウス マイグレーション • データウェアハウス資産の棚卸し • データ容量、ワークロードや周辺 システムに関する整理 • SQL、データベースオブジェクト の移⾏難易度レポートの取得 （SCT のアセスメントレポート） • パフォーマンス、運⽤、移⾏性、 コスト、移⾏⽅式の PoC を実施 • PoC の結果から移⾏プロジェクトの スケジュールを⾒直し • AWS プロフェッショナルサービス、 パートナーを含め移⾏プロジェクト の体制決め • データウェアハウスの移⾏ • システムの統合 • テスト • 最適化 主に Redshift への移⾏、場合によっては Athena 等への移⾏も検討
72. © 2020, Amazon Web Services, Inc. or its Affiliates. Hadoop環境の移⾏ • データ移⾏アプローチ • データ、カタログ、アプリケーションの移⾏ • 永続的リソースと⼀時的なリソースの使⽤ • セキュリティポリシー、アクセス制御、監査ログの設定 • 価値を最⼤化しつつ、コストの⾒積もりと最⼩化 • ⾼可⽤性と災害復旧のためのクラウド活⽤ • ⼀般的な管理タスクの⾃動化 https://d1.awsstatic.com/whitepapers/amazon_emr_migration_guide.pdf Amazon EMR Migration Guide
73. © 2020, Amazon Web Services, Inc. or its Affiliates. データ分析の仕組みを丸ごと移⾏する検討の前に、 データを Amazon S3 にも転送し、 AWS上でデータ活⽤のサイクルを回してみる DWH や Hadoop などの、 具体的な移⾏対象がある場合には、 移⾏パスを定義して、順番に着⼿する AWSにも是⾮ご相談下さい
74. © 2020, Amazon Web Services, Inc. or its Affiliates. AWSでデータ分析を始めるのに必要な10のこと 1. ビジネスゴールを定める 2. プレゼンテーションレイヤを決める 3. 必要なデータソースを明確にする 4. データの加⼯⽅式を決定する 5. 新しい分析に広げていく 6. スケーラビリティを確保する 7. ⾼いセキュリティを確保する 8. ガバナンスと使いやすさを両⽴する 9. コストを最適化する 10.AWS にデータ分析の仕組みを移⾏する
75. © 2020, Amazon Web Services, Inc. or its Affiliates. ありがとうございました︕