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