AWS データレイク事例祭り 登壇資料

AWS データレイク事例祭り 登壇資料です。

Transcript

1. © DMM.com DMM.comデータの湖 AWSデータレイク事例祭り DMM.com データ本部 斎藤 友樹 1
2. © DMM.com • 自己紹介 • DMM.comのデータレイクの変遷 • ちょっと昔話 • 最近のお話 • DMM.comとAWSサービスとの付き合い方 • 利用事例 • 気をつけていること アジェンダ 2
3. © DMM.com 斎藤 友樹 (サイトウ ユウキ) 2児のパパ 第2子が歩けるようになった データ本部 DRE (いわゆるデータエンジニア ) グループ リモートになって生産性爆上がり twitter @yuki_saito_en(前職では禁止されてた) 3 自己紹介 第2子 わたし 奥さん 第1子
4. © DMM.com DMM.com データレイク少し昔の話 4
5. © DMM.com ちょっと昔のデータレイク(Warehouse?) • オンプレとAWSを利用した、いわゆるハイブリッドの構成 • オンプレとクラウドでデータが一致しない • 謎の2重3重転送 • データがあっちにもこっちにも • Aプロダクトはオンプレのデータ、BプロダクトはS3から • 運用も高負荷、複雑がゆえ属人化（属人さえしていないプロダクトも） • あれは、あそこで、これはここだから、順番は。。ry • IT Oriented たった5,6名のチームが全社の要望を全て受けている 5
6. © DMM.com DMM.comちょっと昔のデータの湖 172 などなど。。。。 これらの組み合わせにより構成された10を超え る人智を超越したプロダクト郡 (本番のみ)　 * 2　 * 2　 * 2　 6
7. © DMM.com DMM.com データレイク今の話 7
8. © DMM.com 無事クラウド移行果たしました〜 8 他事業部のオンプレ資産活用 ための最低限の構成に (本番のみ)　 8
9. © DMM.com DMM.comデータレイク コンセプト • Single Source of Truth (SSoT) • 複数クラスタでデータの重複保持もNGできる限り一個に集める • Self-Service • 湖に来る人の装備に応じて、提供するAccess Layerを変更 • メタデータの拡充を通してより利用しやすい環境をめざす • データディスカバリー • データ品質の可視化 • 利用者自身でデータを見つけて、データを利用して、アウトプットを出す 9
10. © DMM.com DMM Data Center 10 Cloud DNS Cloud Dataflow Cloud Load Balancing Eagle Kubernetes Cluster Container Engine Cookie storage Cloud Bigtable Activity data storage Cloud Storage DMM.com データレイク redash Kubernetes Cluster Container Engine DMM.comのデータレイク エンジニア軍団 アナリスト 他 AWSアカウント 他 GCPアカウント Consumer layer Access Layer Access Layer (Producer Layer) (Producer Layer) legend: データパイプライン SQLでのアクセス SQL以外でのアクセス
11. © DMM.com このスライドでの用語 • Access Layer • データレイク外との境界線 • curl、sql、aws cli、ワークフローからでもアクセスできる • Consumer Layer • データレイクを利用する人 • レコメンド、ML、検索、メルマガなどのエンジニア軍団 • API GateWayやS3 • 他アカウント • Fargate上のアカウントを通してデータ取り込みを行う先 • アナリスト • Redash(or NoteBook)を通して分析業務を行う • 本スライドでは便宜的にRedashを通してアクセスする人を指します • Producer Layer • いわゆる中の人たちが管理している領域 • データが生成される場所 11
12. © DMM.com DMM.comデータの湖　サイズ感 提供 インターフェース 利用者数(人) テーブル数 実行クエリ数/ week 実行 job数/day api BIツール s3 VPC EMR (js) 1200 1000 over 20000 2000(1次生成) +　 1000(レコメンドな どの2次生成) = 3000 over 12
13. © DMM.com DMM.comデータレイク AWSサービスとの付き合い方 13
14. © DMM.com Access Layer(アナリスト向け) 14
15. © DMM.com Athena SQLの雄 • 元々オンプレのprestoクラスターの移行先として選択 • オンプレのリソースパツパツprestoサーバ15台を葬った救世主 • 全社利用しているBIツールRedashのバックエンド • 入社と同時にアカウントが発行される • 別本部管轄のmetabaseのバックエンドにもなっている • 扱っているフォーマット • orc(オンプレ時の主要フォーマット) • parquet(現在の標準。ツールの連携性を高めるため) • avro(特にBigQueryと連携する時にはとても便利) • csv(くっ、早く脱却したい) • CTASは解放していない • EMRを利用してETL(中間テーブル作成が主)する形式 15
16. © DMM.com Athena SQLの雄 • ワークグループの分割 • デフォルトだとprimaryというグループしかない • コストの確認 • リソース分割 • 1.75TB以上データスキャンするとクエリをkill • 全て通してあげたい気持ちはありつつ。マルチテナントのつらみ • 1.75なのは現状のスキャン状況を鑑みて • Glue Data Catalogをちゃんと使う • hiveだけしか読めない、Athenaだけしか読めないようなテーブル定義にしない • avroフォーマットやexternalのつけ忘れ、HiveのViewなど 16
17. © DMM.com Producer Layer 17
18. © DMM.com Glue Crawler • テーブル定義作成 • 内製ツールを使ってテーブル定義作成=>適用=>諸々手動が入りバラバラ • Glue Crawlerを使ってデータからテーブルの定義を作成 • Hive(Spark)、Athenaでも読める形で生成してくれる • 有名なのはAvro • AvroはSerdeプロパティの指定仕方は2種類 • avro.schema.literal <- hive、athenaに両対応しているが、作成が地獄 • avro.schema.url　<- スキーマのURLを指定すればいいだけだが、athena未対応 18
19. © DMM.com S3 データレイクの中心 • 際限なくデータを貯水するところ • オンプレでは都度削除の算段を立てていた • DMM.comデータレイクのSSoT • 外部アカウントからのデータや外部への出入り口 • データ連携用のバケット • 実行ファイル(jar,py,sql)のデプロイ先 • GitHub ActionsやCircleCIで連携 • 管理用ファイルの配置先 • Terraform • アクセスログ 19
20. © DMM.com S3 データレイクの中心 • 結果整合性への対策 • 実行毎のディレクトリを作成しできる限り新規作成になるように • スローダウンへの対策 • 同時に様々なデータ利用者から同じデータへのアクセスは当たり前 • ファイルまとめたり(大きくても5GBくらい)、パーティション化 • Spark SQLのヒント文は忘れずに付加する • S3のサーバーアクセスログを取得する • audit用 • 現在はテーブルの参照頻度を図るために利用 • ライフサイクル • 利用者が多いのでアクセスログを数日ためておくと数十TBに • 14日経過後に削除をする運用 20
21. © DMM.com Glue Data Catalog • テーブルの定義を格納 • テーブルのtimelinessをGlue Catalogの情報として保存 • 利用者（他システム）はその時間を見て、処理を開始する • これができる前はワークフローの順番を見て処理を開始していた • 以前は簡単にテーブルの生成順を変更できず改善の妨げになっていた • 上記以外メタデータは全てGlue Data Catalogと統合 21
22. © DMM.com ガッツリつかってますよEMRさん • 結構頑張れるプロダクトそれがEMR • フルマネージドしすぎで頑張れずヤキモキすることはない • 中身はHadoopなのでオンプレ経験があると危機回避しやすい • 直近のアップデートで常駐クラスタとしてかなり使いやすくなった • Stepが並列して実行できるようなったり • Historyサーバーが永続化されていたり • 当時対抗としてGlueのETL(ver1.0)を利用しようと画策 • 10分単位での課金やSpotを利用できない点を考慮し選択肢から除外 • 現在のver2.0は課金体系が1分単位になっており人当たりが優しくなっている印象 • EMRはオンプレ時代の1/8くらいのスペックで運用 • オンプレ時代は一台あたり メモリ350GB　CPU 37を20台用意 • これでも当時は容量上限の危機に晒されビクビクし眠れない毎日 22
23. © DMM.com ガッツリつかってますよEMRさん • 基盤の管理者以外でもチームごとにクラスターを保持 • 設定ファイルは解放して各チーム任意のタイミングでアップデート可能 • １日あたり全利用者含めて30〜40のクラスターが起動 • 1h 以内に停止するもの • １日に一度停止する常駐しているクラスター emr-5.29.1 presto spark2.4.4 emr-5.30.1 hive spark2.4.5 23 Aチーム Bチーム
24. © DMM.com EMR 2000 overのjobと戦う • Producer Layerで日にサブミットされるjobは3000を超える • データレイク中の人がsubmitする1次生成jobが2000 <-今回話すのはこちら • 1次生成物を使う2次生成jobが1000ほど • 移行を期にHive Jobをhive on Sparkに全て変更 • 並列性はSparkの方が上 • EMRのStep実行を利用 • Hiveだとたまに発生していたRenameエラーがなくなった 24
25. © DMM.com EMR 2000 overのjobと戦う • EMRに依存しない処理と分別する • sqlに依存するだけではなくembulk採用によりシンプルにしている • シンプルにできそうなパターンのヒント • HiveのDynamic Partitionを使ってない • 複数のrawデータを合成しているパターン • 適度にクラスターを分割する • 強いクラスター1台より、毎時で動く処理などは分けた方がいい • コンカレンシーは255までいけるもののそんなパターンを使うのは稀 • マスターノードのボトルネックもある • スケールアウトより、アップして短時間で処理しちゃう方が早くて安いこともある • クラスターの起動時のプロビジョニングの時間は6mくらいかかる • DataProc(20秒ほど)と比べるとちょっとスロー目 25
26. © DMM.com EMRの設定時に気をつけていること • ちゃんとVPCにS3エンドポイントつける • これを忘れるとデータがインターネットを飛び交う羽目に • EMRは利便性の観点から、Public Subnetに配置 • オートスケーリングにはそこまで頼らない • 閾値は結構難しい。最後の最後の砦くらいで考えておくのがベター • 5.31からマネージドのスケーリングはあるものの • ストレージはちゃんと積んであげる • ストレージを積んでいないとHiveやSparkのDiskSpill時に容量不足のノードが unhealthyと判定されクラスターが継続不能となる • 全ての処理がS3で完結するわけでなく処理中にLocalDiskに書き出している • 本番環境では1ノードには1.25TB必ず積むようにしている • メモリが足りなくてもストレージで何とかカバーしてくれる場面もある 26
27. © DMM.com EMRの設定時に気をつけていること • 譲れない設定は、起動時のclassificationで入れて提供/利用 • スモールファイル系の設定(例:"hive.merge.smallfiles.avgsize": "320000000") • 地雷系(yarn.nodemanager.vmem-check-enabled) • いくらSelfでも譲りすぎない • スポットをちゃんと使う(Max Ondemand) • データレイクではCoreは2~3台（非スポット） • Taskノードについては絶対にSpot • 仮にTaskノードが死んでも、Coreの1.25TB のディスクがどうにかしてくれる 27
28. © DMM.com SageMeker + EMRの組み合わせは勝ち確 • 神器ノートブック • 以前はSSHしてサーバー内で作業 • 移行のデータ整合性チェック • アドホックなデータ状況確認 • Jupyter Labを利用 • ノートブック連携やGit連携など便利機能盛りだくさん • hive spark 好きなプラグイン/マジックコマンドを入れて利用 28
29. © DMM.com SageMeker + EMRの組み合わせは勝ち確 • ノートブックが使えるサービスは実は結構ある • SageMaker + EMR • フロント部分はSageMaker • 実行のバックエンドとしてEMRを利用する • Glueの開発者エンドポイント • 月1万円くらいのSageMake + EMRに比べると割高 • いくらDPUをあげても何度かJobをサブミットすると戻ってこないことが頻発した • EMRノートブック • 複数人で共有できない • SageMaker単体 • メタデータ連携がやり辛い 29
30. © DMM.com Access Layer(エンジニア向け) 30
31. © DMM.com API Gateway • データ基盤に対するオペレーションをラップ化 • EMRのオペレーション • EMRの設定をバラして、パズル化することもできる(ようになる予定 ) • Glue Data Catalogのオペレーション • インターフェースの統一化 • ある程度整理されたワークフローが利用すればかなり強力 31
32. © DMM.com ワークフローとの連携が抜群 • ワークフローエンジンとAPI Gatewayの連携 • Digdagの組み込みであるhttpオペレータとの連動性が相性抜群 クラスターの起動 +create_cluster: http>: https://api.xxx/v2/cluster/name method: POST store_content: true timeout: 60 headers: - x-api-key: ${secret:api_key} content: cluster_name: activity_${session_time} content_format: json content_type: application/json クラスターの停止 +delete_cluster: _export: API_KEY: ${secret:i3_api_key} http>: https://api.xxx/v2/cluster/activity_${session_time} method: DELETE headers: - x-api-key: ${API_KEY} 32
33. © DMM.com 閑話休題：CHALICE 簡単にAPI Gatewayできる使わない手はないプロダクト。 ２０行書けばapiのエンドポイントからIAMまで御膳立てしてくれる。 33
34. © DMM.com ECS(fargate) • 他アカウントとのデータストアパターンに対応するための方式 • 様々なデータソースに対応すべく、データソースごとにイメージを作成 • RDS、S3、今後はGCS、BigQueryなども予定 • 今まで一つのVM上で詰め込んでいて、アップデートの際のざわざわする • ピアリング接続などネットワーク的にも柔軟に対応 Mysql dump用 RDS用 S3用 34
35. © DMM.com 35 Corporate Message