ビックデータ最適解とAWSにおける新しい武器

462 views

Published on

CTO Night & Day 2016 winterでのモーニングセッションの資料です!

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
462
On SlideShare
0
From Embeds
0
Number of Embeds
146
Actions
Shares
0
Downloads
4
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

ビックデータ最適解とAWSにおける新しい武器

  1. 1. ビックデータ最適解とAWSにおけ る新しい武器 アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 桑野 章弘
  2. 2. ⾃⼰紹介 桑野 章弘(くわの あきひろ) ソリューションアーキテクト 主にメディア系のお客様を担当しております。 渋⾕のインフラエンジニア(仮)しておりま した 好きなAWSのサービス:ElastiCache 好きなデータストア:MongoDB
  3. 3. Introduction AWSにはビックデータでも様々なサービスがあ ります、それらサービスを使⽤して最適なビッ グデータ処理基盤を構築する場合のベストプラ クティスについてまとめていきます
  4. 4. ビッグデータ処理基盤 on クラウド:変わらないこと • データを収集して、分析し、可視化 • 分析では、標準的な技術・OSSや商⽤ソフトウェアを活⽤ • AWSのマネージドサービスを活⽤することでより便利に 収集 分析 可視化 データを収集 ⼤規模データ を⾼速に分析 ⼈間が参照し やすい形に
  5. 5. クラウド+ビッグデータ:ポイント データは加⼯せず全期間を残す スケールアウトで解決する CLOUD BIG DATA +
  6. 6. #2. データは加⼯せず全期間を残す これまで: ディスクが⾼価で上限があ る データはサマリーだけ、も しくは期間限定で保存 処理できる内容は固定的 On クラウド: 安価・上限無しのストレー ジ オリジナルデータを全て残 す 処理対象・処理内容はビジ ネスに合わせて変わる インフラ管理者の仕事: データを活⽤して新しい課題に素 早く対応できるインフラを⽤意す る。個別リクエストへの対応 インフラ管理者の仕事: ストレージを溢れさせず、時 間内に処理が終るようにサイ ズや処理内容を調整する
  7. 7. データレイク 多様なデータを⼀元的に保 存 データを失わない サイズ制限からの開放 決められた⽅法(API)です ぐにアクセスできる →システム全体のハブ センター データ ⾮構造化ファイル テキストファイル RDBMS データレイク API呼び出しによる連携
  8. 8. ⼤規模データ分析に必要な基盤 • データを消さずにデータレイクに集め、分析に つなげる 収集 データレイク (保存) 分析 可視化 データを収集 し、データレイ クへ格納 全期間保存。 共通APIでア クセス ニーズ #1 分析 可視化 ニーズ #2API
  9. 9. スケールアウトで解決する スケールアップもスケールアウトも クラウドでは容易 …しかしスケールアップには限界が ある(CPU、メモリ) スケールアウト可能なテクノロジー =規模の増加に耐えうる設計 S XL スケールアップ スケールアウト
  10. 10. スケールアウト ≠ ⾼価 クラウドではスケールアウトがコスト・時間の両⾯で効率的 必要な時に必要なだけノードを追加できる ノードを増やしても利⽤時間が短くなればコストは同じ 処理時間 8時間 処理時間 2時間 JOB 16ノードに 拡張 JOB 4ノード×8時間 =32 16ノード×2時間 =32
  11. 11. ⼤規模データ分析 on クラウド(ここまでのまとめ) データをデータレイクに集め、多様な分析につなげる 分析はスケールアウト可能なインフラの上で 収集 データレイク (保存) 分析 可視化 データを収集 し、データレイ クへ格納 全期間保存。 共通APIでア クセス 可視化 スケールアウト 可能な技術 分析 スケールアウト 可能な技術API
  12. 12. AWS+ビッグデータ分析基盤
  13. 13. EC2があれば何でも出来るけど… マネージドサービスで管理負荷を低減可能 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運⽤設計 スケールアウト設計 ミドルウェア導⼊ OS導⼊ アプリケーション作成 オンプレミス 独⾃構築 on EC2 AWSマネージドサービス お客様がご担当する作業 AWSが提供するマネージド機能 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運⽤設計 スケールアウト設計 ミドルウェア導⼊ OS導⼊ アプリケーション作成 電源・ネットワーク ラッキング HWメンテナンス OSパッチ ミドルウェアパッチ 定形運⽤設計 スケールアウト設計 ミドルウェア導⼊ OS導⼊ アプリケーション作成
  14. 14. 分析保存 Amazon Glacier Amazon S3 Amazon DynamoDB Amazon RDS/ Aurora AWSマネージドサービス:ビッグデータ AWS Data Pipeline Amazon CloudSearch Amazon EMR Amazon EC2 Amazon Redshift Amazon Machine Learning AWS IoT AWS Direct Connect 収集 Amazon Kinesis Amazon Kinesis Firehose Amazon Elasticsearch Amazon Kinesis Analytics Amazon QuickSight AWS DMS New!!! New!!! Snowball 可視化 Amazon EC2 Amazon Athena New!!!
  15. 15. 例)オンプレミスのデータをAWSで分析する データ・ソースがオンプレミスのDC内に複数 多種多様なシステムからEXPORTしたデータをAWSへ転送(定期的) 10年間以上のデータを保存して分析できるようにしたい(例:数100TB〜) 多くの利⽤者は直近1年間のデータしか分析しない(例:数10TB) 収集 データ レイク 分析 可視化 EXP ? ? ? ?
  16. 16. データ収集 データの収集 様々なサービスを利⽤してデータを蓄積する APP Amazon S3 Kinesis Firehose Fluentd、Firehose、 Snowball、、、様々な 方法でS3にデータを送 信する
  17. 17. データレイク on AWS あらゆるデータが集まるス トレージ 構造化データだけではなく ⾮構造化データも 様々なデータを跨いで分析 可能 Amazon S3が最適 EMR/Redshift等で活⽤ 低頻度アクセスストレージ /GlacierでTiered DB 各種クライアント メディア ファイル 多様な データベース サーバ Amazon Kinesis Amazon S3 Amazon Glacier Amazon EMR Amazon Redshift Amazon Machine Learning Amazon Athena
  18. 18. 全てのログはS3へ貯め続ける S3はAWSのデータのハブ(=データレイク)と して⾮常に重要な役割を担っている あとから⾃由に分析処理(ETL)を変更可能 S3の耐久性で安全に保存可能 消したログは⼆度と帰ってこない ⾮常に安価にデータを保存できる(Glacierや、 低頻度アクセスストレージも併⽤可能)
  19. 19. ElastiCache インメモリDB RDS RDB DynamoDB NoSQL Amazon S3 汎用ファイル データレイク Amazon Glacier 長期保存 階層化による格納 ホットデータ: 応答速度重視 限定範囲のデータ コールドデータ: 容量当たりの単価重視 膨⼤なデータ
  20. 20. スケールアウト可能な分析サービス Amazon Redshift マネージドRDBMS SQL(標準) スケールアウト可能 Amazon Elastic MapReduce (EMR) マネージドHadoop Hadoop/Spark(標準) スケールアウト可能 OR マネージド, 標準技術, スケールアウトが選択の鍵
  21. 21. Amazon Redshift 特徴 データサイズ:最⼤2PBまで拡張可能 超並列(MPP)、カラムナ型DBエンジン による⾼速SQL処理 スケールアウト可能。最⼤128台 PostgreSQLとの互換性 使った分だけの利⽤料⾦。従来のデータ ウェアハウスの1/10のコストで実現 フルマネージドのデータウェアハウスサービス 10Gb Ether JDBC/ODBC Redshift ⼤規模分散処理 で分析SQLを⾼ 速実⾏
  22. 22. SQLを分散処理(スケールアウト) SELECT * FROM … SQLをコンピュート ノードへ配信 CPU CPU CPU CPU CPU CPU リーダーノード コンピュートノード ノードに直結した⾼ 速ストレージ
  23. 23. SQLを分散処理(スケールアウト) SELECT * FROM … CPU CPU CPU CPU CPU CPU リーダーノード コンピュートノード ノードに直結した⾼ 速ストレージ
  24. 24. SQLを分散処理(スケールアウト) SELECT * FROM … SQLをコンピュート ノードへ配信 CPU CPU CPU CPU CPU CPU リーダーノード コンピュートノード 分散して SQLを処理 ノードに直結した⾼ 速ストレージ
  25. 25. フルマネージド型のRDBMS 運⽤管理に必要な機能をビルトイン S3からの⾼速ロード&アンロード ⾃動バックアップ&リストア モニタリング データの再編成 クエリの解析 :
  26. 26. Amazon Elastic MapReduce (EMR) ⼤規模データ処理をHadoop/Sparkなどの 分散処理フレームワークを使って効率的に処理 AWS上の分散処理サービス • 簡単かつ安全にBig Dataを処理 • 多数のアプリケーションサポート 簡単スタート • 数クリックでセットアップ完了 • 分散処理アプリも簡単セットアップ 低コスト • ハードウェアへの投資不要 • 従量課⾦制 • 処理の完了後、クラスタ削除 • Spotインスタンスの活⽤ Hadoop 分散処理アプリ 分散処理基盤 Amazon EMRクラスタ 簡単に複製 リサイズも1クリック Spotも利⽤可能
  27. 27. EMRFS: S3をHDFSの様に扱う “s3://” と指定するだけでHDFSと同様にS3にア クセス 計算資源とストレージを分離でき コスト⾯でもメリット⼤ クラスタのシャットダウンが可能 クラスタを消してもデータをロストしない 複数クラスタ間でデータ共有が簡単 データの⾼い耐久性(S3) EMR EMR Amazon S3
  28. 28. EMRで稼動するSQLエンジン SQLエンジン操作アプリ ストレージ YARN Map Reduce Tez Spark Hive Spark SQL Presto JDBC/ODBC HiveMetastore HDFS EMRFS Hue Zeppelin SELECT…
  29. 29. データ分析プラットフォーム⽐較 Amazon Redshift Amazon EMR 分類 大規模データ処理に特化したマネー ジドRDBMS Hadoop/Spark等分散処理フレームワー クのマネージド環境 処理系 SQL(PostgreSQLと互換性) アプリケーションに依存:Hive、Pig … Presto等でSQLでの分析も可能 スケールアウト 可能 可能 ストレージの種類 高速なローカルストレージ HDFS、もしくはEMRFSでS3上のデータ を取り込まずにアクセス ノードとストレージの分 離 ノードとストレージは同時に増加・削 減 ストレージに影響を与えずにノード増減が 可能(EMRFSの場合) 最大処理サイズ 2PB(圧縮後) 上限無し(EMRFSの場合) 処理レイテンシー Low • Presto (Low) • Hive (Midium~High) 運用管理 運用管理に必要な機能がビルトイン 分散処理系+OSSアプリ環境を容易に 分析ツール、ETL等 JDBC/ODBC+プッシュバック対応等 ネイティブレベルでの対応 JDBC/ODBC経由もしくはHive メタストア 経由で多くの環境がサポート
  30. 30. 分析サービスの選択例 Amazon Redshift SQL処理に特化・⾼速 ローカルディスク上で 処理 Amazon Elastic MapReduce (EMR) ⾃由にアプリケーションを 選択 EMRFSでS3データにアク セス S3に直接アクセスできるEMRFSを 使い、データレイク上の全期間の データ分析に活用 頻繁にアクセスされるホットデータを 格納し、高速なSQLアクセス機能を 活用して分析
  31. 31. 分析に必要なプリプロセスをどこで実⾏するか? AWSに転送前のオンプレミス環境で実施 スケールアウトが困難 データレイクをオンプレミス側に⽤意する必要がある S3上のファイルをElastic MapReduceで変換 スケールアウト可能なインフラで処理 ⾔語・アプリを柔軟に選択可能 データレイクを含むAWSサービスへの接続性 Redshift内でSQLで変換 スケールアウト可能 Redshift内に取り込んだデータのみ操作可能
  32. 32. EMR:プリプロセス処理に向く⾼い接続性 例)Spark on EMRとAWSサービスとの連携 Amazon EMR Amazon S3 (データレイク) DynamoDB Amazon RDS Amazon Kinesis Amazon Redshift Elastic Search Service EMRFS Streaming Data Connector Copy from HDFS EMR-DynamoDB Connector JDBC(SparkSQL ) Elastic Search Connector
  33. 33. 例)プリプロセスの構成例 Amazon RedshiftAmazon EMR• ⾮構造化データの構造化・整形 • 構造化データのフィルタリング • S3へ変形済データを出⼒ サマリー テーブル ファクト テーブル マート・サマ リー表の更新を SQLで実⾏ Amazon S3 全データ 変形済データ
  34. 34. Amazon Athenaリリース! Amazon S3に置いたデータをインタラクティブにSQL実⾏可能 AthenaはPrestoで提供するSQL Engineが利⽤でき、JSON, CSV, ログファイル, 区切り⽂字のあるテキストファイル, Apache Parquet, Apache ORCに対してクエリが可能 ペタバイトクラスのデータに対するクエリをサポート、データを S3から取り込む⼿間はない、ANSI-SQLもサポート JDBCでのアクセスも可能 バージニア、オレゴンで利⽤可能 スキャンしたデータ1TBあたり$5の料⾦(⽶国)
  35. 35. Athenaを活⽤することでプリプロセスの部分が⼤幅に 簡略化される Hadoop関連の知識も必要無い Amazon RedshiftAmazon Athena• ⾮構造化データの構造化・整形 • 構造化データのフィルタリング • S3へ変形済データを出⼒ サマリー テーブル ファクト テーブル マート・サマ リー表の更新を SQLで実⾏ Amazon S3 全データ 変形済データ
  36. 36. マネージド故の様々な活⽤⽅法 S3に貯めたデータから必要な 結果を取得する アクセスログなどのある程度 定型的なログの集計処理 データアクセス量課⾦なので、 クラスタを⽴ち上げるよりも 価格が抑えられる場合もある 36
  37. 37. Athena Tips Amazon Athenaはリージョンまたいだ Amazon S3バケットにもクエリできるので、東 京リージョンにあるS3にもアクセス可 転送量とレイテンシが許容できるなら今からでも使⽤可能 37
  38. 38. Athena Tips Amazon S3の標準 - 低頻度アクセスの活⽤ Amazon Athenaで何回もクエリしないようなデータには、 Amazon S3の標準 - 低頻度アクセスにすることで耐久性等は標 準そのままに、容量単価を節約 38
  39. 39. Athena Tips Amazon Athenaの課⾦対象は処理したサイズ ではなくスキャンしたサイズ データを単純に圧縮するだけで安価に パーティションで対象ファイルを絞ったり、列指向フォーマッ ト(ORC、Parquet)にすることでもっと安くすることも可能 39
  40. 40. FeedBackお願いします! 40
  41. 41. 可視化部分は⽤途に応じて選択可能 EC2+BIツール 多彩なパートナーソリュー ション・OSSをEC2上で活 ⽤ Amazon QuickSight 専⾨家不要のBIサービス AWS内外のデータソース にアクセス
  42. 42. 分析 分析データレイク 選択の例:全体図 データをAWSへ転送、S3で収集&保存、データレイクとする ホットデータ(直近データ)分析環境としてRedshift 全期間データ分析環境としてEMR 収集 可視化 Presto /EMR Redshift QuickSight EXP Amazon S3 BI+EC2 Direct Connect プリプロセス EMR 全データ 変形済 Athena
  43. 43. 事例で⾒るビッグデータ処理 on AWS
  44. 44. 事例:Nasdaq様 Redshift/EMRを使い分け Redshift:300TB分の直近データ EMR+Presto+S3:全期間データ 共通のSQLで アクセス re:Invent 2015発表資料 BDT314 「A Big Data & Analytics App on Amazon EMR & Amazon Redshift 」より引用
  45. 45. 事例:Finra様 750億イベント/⽇の処理基盤 • S3をデータ共有サービスとして定義し、EMRやRedshiftからアク セス re:Invent 2015発表資料 BDT305 「Amazon EMR Deep Dive & Best Practices」より引用
  46. 46. Finra様:DWHアプライアンスとHive/Tez+S3⽐較 S3に置いたままのデータをHive/Tez on EMRでアクセス DWHアプライアンスとの⽐較で⼗分な速度を実現 re:Invent 2015発表資料 BDT305 「Amazon EMR Deep Dive & Best Practices」より引用
  47. 47. 事例:スマートニュース様 マネージド・サービスを中⼼とした技術選択 http://www.slideshare.net/smartnews/20160127-building-a-sustainable-data-platform-on-aws より引用
  48. 48. スマートニュース様(Batch~Serving~Output部 分) S3に⼊った⽣データをEMRでETL処理 レポート:データはRDS→BIツール 広範囲分析:RC File形式でS3に格納し、Presto→BIツール http://www.slideshare.net/smartnews/20160127-building-a-sustainable-data-platform-on-aws より引用
  49. 49. App Server ア プ リ ケ シ ョ ン Web Server トランザクショ ナル・データ ロ ギ ン グ デ バ イ ス コ レ ク タ Android iOS Kinesis Producer ファイル データ ストリーム データ S3 RDS Dynamo DB Amazon Redshift Kinesis Stream Lambda Pig Hive Kinesis Consumer AmazonElasticMapReduce AWS IoT 収集 分析 可視化 Quick Sight IoT Device 保存 EC2 分析SW
  50. 50. まとめ:変化を織り込んだビッグデータ処理基盤 最適なツールを選択する データは消さずにオリジナルを残す スケールアウトで解決する
  51. 51. ビックデータ最適解と AWSにおける新しい武器

×