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

by Yuki

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© DMM.com ちょっと昔のデータレイク(Warehouse?) • オンプレとAWSを利用した、いわゆるハイブリッドの構成 • オンプレとクラウドでデータが一致しない • 謎の2重3重転送 • データがあっちにもこっちにも • Aプロダクトはオンプレのデータ、BプロダクトはS3から • 運用も高負荷、複雑がゆえ属人化（属人さえしていないプロダクトも） • あれは、あそこで、これはここだから、順番は。。ry • IT Oriented たった5,6名のチームが全社の要望を全て受けている 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© DMM.com DMM.comデータレイクコンセプト • Single Source of Truth (SSoT) • 複数クラスタでデータの重複保持もNGできる限り一個に集める • Self-Service • 湖に来る人の装備に応じて、提供するAccess Layerを変更 • メタデータの拡充を通してより利用しやすい環境をめざす • データディスカバリー • データ品質の可視化 • 利用者自身でデータを見つけて、データを利用して、アウトプットを出す 9

Slide 10

Slide 10 text

© DMM.com DMM Data Center 10 Cloud DNS Cloud Dataﬂow 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以外でのアクセス

Slide 11

Slide 11 text

© DMM.com このスライドでの用語 • Access Layer • データレイク外との境界線 • curl、sql、aws cli、ワークフローからでもアクセスできる • Consumer Layer • データレイクを利用する人 • レコメンド、ML、検索、メルマガなどのエンジニア軍団 • API GateWayやS3 • 他アカウント • Fargate上のアカウントを通してデータ取り込みを行う先 • アナリスト • Redash(or NoteBook)を通して分析業務を行う • 本スライドでは便宜的にRedashを通してアクセスする人を指します • Producer Layer • いわゆる中の人たちが管理している領域 • データが生成される場所 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© DMM.com Athena SQLの雄 • 元々オンプレのprestoクラスターの移行先として選択 • オンプレのリソースパツパツprestoサーバ15台を葬った救世主 • 全社利用しているBIツールRedashのバックエンド • 入社と同時にアカウントが発行される • 別本部管轄のmetabaseのバックエンドにもなっている • 扱っているフォーマット • orc(オンプレ時の主要フォーマット) • parquet(現在の標準。ツールの連携性を高めるため) • avro(特にBigQueryと連携する時にはとても便利) • csv(くっ、早く脱却したい) • CTASは解放していない • EMRを利用してETL(中間テーブル作成が主)する形式 15

Slide 16

Slide 16 text

© DMM.com Athena SQLの雄 • ワークグループの分割 • デフォルトだとprimaryというグループしかない • コストの確認 • リソース分割 • 1.75TB以上データスキャンするとクエリをkill • 全て通してあげたい気持ちはありつつ。マルチテナントのつらみ • 1.75なのは現状のスキャン状況を鑑みて • Glue Data Catalogをちゃんと使う • hiveだけしか読めない、Athenaだけしか読めないようなテーブル定義にしない • avroフォーマットやexternalのつけ忘れ、HiveのViewなど 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© DMM.com Glue Crawler • テーブル定義作成 • 内製ツールを使ってテーブル定義作成=>適用=>諸々手動が入りバラバラ • Glue Crawlerを使ってデータからテーブルの定義を作成 • Hive(Spark)、Athenaでも読める形で生成してくれる • 有名なのはAvro • AvroはSerdeプロパティの指定仕方は2種類 • avro.schema.literal <- hive、athenaに両対応しているが、作成が地獄 • avro.schema.url　<- スキーマのURLを指定すればいいだけだが、athena未対応 18

Slide 19

Slide 19 text

© DMM.com S3 データレイクの中心 • 際限なくデータを貯水するところ • オンプレでは都度削除の算段を立てていた • DMM.comデータレイクのSSoT • 外部アカウントからのデータや外部への出入り口 • データ連携用のバケット • 実行ファイル(jar,py,sql)のデプロイ先 • GitHub ActionsやCircleCIで連携 • 管理用ファイルの配置先 • Terraform • アクセスログ 19

Slide 20

Slide 20 text

© DMM.com S3 データレイクの中心 • 結果整合性への対策 • 実行毎のディレクトリを作成しできる限り新規作成になるように • スローダウンへの対策 • 同時に様々なデータ利用者から同じデータへのアクセスは当たり前 • ファイルまとめたり(大きくても5GBくらい)、パーティション化 • Spark SQLのヒント文は忘れずに付加する • S3のサーバーアクセスログを取得する • audit用 • 現在はテーブルの参照頻度を図るために利用 • ライフサイクル • 利用者が多いのでアクセスログを数日ためておくと数十TBに • 14日経過後に削除をする運用 20

Slide 21

Slide 21 text

© DMM.com Glue Data Catalog • テーブルの定義を格納 • テーブルのtimelinessをGlue Catalogの情報として保存 • 利用者（他システム）はその時間を見て、処理を開始する • これができる前はワークフローの順番を見て処理を開始していた • 以前は簡単にテーブルの生成順を変更できず改善の妨げになっていた • 上記以外メタデータは全てGlue Data Catalogと統合 21

Slide 22

Slide 22 text

© DMM.com ガッツリつかってますよEMRさん • 結構頑張れるプロダクトそれがEMR • フルマネージドしすぎで頑張れずヤキモキすることはない • 中身はHadoopなのでオンプレ経験があると危機回避しやすい • 直近のアップデートで常駐クラスタとしてかなり使いやすくなった • Stepが並列して実行できるようなったり • Historyサーバーが永続化されていたり • 当時対抗としてGlueのETL(ver1.0)を利用しようと画策 • 10分単位での課金やSpotを利用できない点を考慮し選択肢から除外 • 現在のver2.0は課金体系が1分単位になっており人当たりが優しくなっている印象 • EMRはオンプレ時代の1/8くらいのスペックで運用 • オンプレ時代は一台あたりメモリ350GB　CPU 37を20台用意 • これでも当時は容量上限の危機に晒されビクビクし眠れない毎日 22

Slide 23

Slide 23 text

© 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チーム

Slide 24

Slide 24 text

© 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

Slide 25

Slide 25 text

© DMM.com EMR 2000 overのjobと戦う • EMRに依存しない処理と分別する • sqlに依存するだけではなくembulk採用によりシンプルにしている • シンプルにできそうなパターンのヒント • HiveのDynamic Partitionを使ってない • 複数のrawデータを合成しているパターン • 適度にクラスターを分割する • 強いクラスター1台より、毎時で動く処理などは分けた方がいい • コンカレンシーは255までいけるもののそんなパターンを使うのは稀 • マスターノードのボトルネックもある • スケールアウトより、アップして短時間で処理しちゃう方が早くて安いこともある • クラスターの起動時のプロビジョニングの時間は6mくらいかかる • DataProc(20秒ほど)と比べるとちょっとスロー目 25

Slide 26

Slide 26 text

© DMM.com EMRの設定時に気をつけていること • ちゃんとVPCにS3エンドポイントつける • これを忘れるとデータがインターネットを飛び交う羽目に • EMRは利便性の観点から、Public Subnetに配置 • オートスケーリングにはそこまで頼らない • 閾値は結構難しい。最後の最後の砦くらいで考えておくのがベター • 5.31からマネージドのスケーリングはあるものの • ストレージはちゃんと積んであげる • ストレージを積んでいないとHiveやSparkのDiskSpill時に容量不足のノードが unhealthyと判定されクラスターが継続不能となる • 全ての処理がS3で完結するわけでなく処理中にLocalDiskに書き出している • 本番環境では1ノードには1.25TB必ず積むようにしている • メモリが足りなくてもストレージで何とかカバーしてくれる場面もある 26

Slide 27

Slide 27 text

© DMM.com EMRの設定時に気をつけていること • 譲れない設定は、起動時のclassiﬁcationで入れて提供/利用 • スモールファイル系の設定(例:"hive.merge.smallﬁles.avgsize": "320000000") • 地雷系(yarn.nodemanager.vmem-check-enabled) • いくらSelfでも譲りすぎない • スポットをちゃんと使う(Max Ondemand) • データレイクではCoreは2~3台（非スポット） • Taskノードについては絶対にSpot • 仮にTaskノードが死んでも、Coreの1.25TB のディスクがどうにかしてくれる 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© DMM.com SageMeker + EMRの組み合わせは勝ち確 • ノートブックが使えるサービスは実は結構ある • SageMaker + EMR • フロント部分はSageMaker • 実行のバックエンドとしてEMRを利用する • Glueの開発者エンドポイント • 月1万円くらいのSageMake + EMRに比べると割高 • いくらDPUをあげても何度かJobをサブミットすると戻ってこないことが頻発した • EMRノートブック • 複数人で共有できない • SageMaker単体 • メタデータ連携がやり辛い 29

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 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

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© DMM.com ECS(fargate) • 他アカウントとのデータストアパターンに対応するための方式 • 様々なデータソースに対応すべく、データソースごとにイメージを作成 • RDS、S3、今後はGCS、BigQueryなども予定 • 今まで一つのVM上で詰め込んでいて、アップデートの際のざわざわする • ピアリング接続などネットワーク的にも柔軟に対応 Mysql dump用 RDS用 S3用 34