Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Design for Serverless ETL Pipeline (48:9)

861 views

Published on

Serverlessconf Tokyo 2018で発表したスライドです。
リクルートライフスタイルのデータ分析基盤のサーバーレスなバッチシステム、リプレースの話。
アスペクト比はまさかの 48:9 。後ほど16:9もアップロードします。

Published in: Technology
  • Be the first to comment

The Design for Serverless ETL Pipeline (48:9)

  1. 1. The Design for Serverless ETL Pipeline データ分析基盤のレガシーなデータロードを サーバレスでフルリプレースするまでの道のり 株式会社リクルートライフスタイル 山田 雄・秋本 大樹・白鳥 昇治
  2. 2. ■山田 雄(ヤマダ ユウ) @nii_yan 株式会社 リクルートライフスタイル ネットビジネス本部データマネジメントG SIerにて主に組込み系の開発に従事したのち、フリーランスとして独立。フリーラ ンスの間に、シミュレーションシステムの開発や、大手ECサイトのメールマーケ ティング用分析基盤の構築を経験。2015年リクルートライフスタイルへ転職。リク ルートライフスタイルの共通分析基盤を構築する傍ら、chatbotの開発や、メール マーケティングにも関わる。 ビッグデータ周りの技術が好物。あと焼きそばも好物。
  3. 3. 会社紹介
  4. 4. 一生のうち、数回つかうサービス LIFE EVENT 日常的に、つかうサービス LIFE STYLE
  5. 5. 一生のうち、数回つかうサービス LIFE EVENT 日常的に、つかうサービス LIFE STYLE
  6. 6. リクルートライフスタイルの データ分析基盤の歩み
  7. 7. 2014 2015 2016 2017 2018 ✔TreasureData を一部 BQ へ移行 ✔RedshiftSpectrum 導入 ✔Redshift をsingle クラスタへ ✔BigQuery 導入 ✔NetezzaEOSL ✔DataLake 構成導入 ✔Exadata 導入 ✔Hadoop 除却 ✔TreasureData 導入 ✔Redshift のノード拡張 ✔オンプレ- AWS 間に専用線導入 ✔Redshift のノード拡張 ✔Netezza のスケール検討 ✔Netezza のスケールアウト完了 ✔Redshift のノード拡張 ✔Redshift の multi クラスタ導入 2013 ✔リクルート分社化 ✔独自の分析基盤 Hadoop 提供スタート ✔Netezza, Redshift 導入
  8. 8. Spectrum Oracle Exadata SPSS aginity CHEETAH DIGITAL Adobe Analytics CSV 外部データ アクセスログ アプリログ HPB JLN HPG 事業データ BigQuery IBM Watson Campaign Automation
  9. 9. ■秋本 大樹(アキモト ダイキ) 株式会社 リクルートライフスタイル ネットビジネス本部データマネジメントG 2011年新卒としてSIerに入社。 2014年にゲーム会社に転職。ゲームデータを集積する分析基盤の構築、および 社内KPI算出の自動化を行う。 2017年12月よりリクルートライフスタイルに転職。現在は次期ETL基盤の構築と クラウドAIサービスの社内導入に奮闘中。 最近のいち推しサービスはGoogleColaboratory 趣味は将棋を見ること。竜王戦が楽しみすぎてしょうがない。
  10. 10. ■白鳥 昇治( シロトリ ショウジ)     株式会社 リクルートライフスタイル ネットビジネス本部データマネジメントG インフラエンジニアとしてオンプレミスKubernetes環境の開発・運用に従事後、 2017年にリクルートライフスタイルに入社。 データエンジニアとしてデータ分析基盤やサーバーレスな機械学習基盤の開発・ 運用などに携わる。 Docker ❤ Kubernetes ❤ CD/CI ❤ Serverless ❤ BigData 夢は山でペンション経営。 @irotoris
  11. 11. レガシーな構成のつらみ
  12. 12. 技術のツギハギ ● 自前サーバで動くシェルで書かれたレガシーなコード ○ 800行を超えるシェルスクリプトファイル ● 複数システムをツギハギするスケジュール実行 ○ 終了するタイミングを見計らって後続の処理を実行 ● データ量に関連した処理の長時間化 Shell Script 自前サーバ AWS GCP
  13. 13. データ間の依存関係 ● 後続のマート作成で用いるテーブルは優先度を高めてロード する必要がある。 ● データマート間にも依存関係がある。 ● 現在はJP1での「イベント受信」機能を用いて優先度を実現し ている。 優先度高 ロード 優先度低 ロード マートA 作成 マートB 作成 マートC 作成 JP1
  14. 14. スケジュール実行での運用がつらい ● 障害発生時のリカバリが大変。 ● 1つの実行単位に複数のテーブルを含めており、テーブル単 位でのロードができていない。 ● 前の処理の時間をずらすと、後続の処理も合わせて時間を ずらす必要がある。JP1
  15. 15. 自前サーバでの開発がつらい ● テスト環境がないので気軽にテストできない。 ● 本番に影響が出るので古いバージョンでの開発を強いられ ている。 ● 800行を超えるシェルスクリプトのメンテが辛すぎる。 古いパッケージ シェルスクリプト 本番に影響が出る
  16. 16. つらみを解消したい そう、それがMigaloo Project
  17. 17. The Design for Serverless ETL Pipeline
  18. 18. と、その前に
  19. 19. 前回のServerlessconf Tokyo !!
  20. 20. 前回のServerlessconf Tokyo !! ● サーバーレスにしてサーバー管理を極力少なく ● イベントドリブンでオーケストレートする構成 ● 自動リトライとアラートを作り込んで ● 運用0を目指しました
  21. 21. 前回のServerlessconf Tokyo !! Q.「いま運用どうですか?」 データ量:増えてる 機械学習バッチのリソース使用量:増えてる
  22. 22. 前回のServerlessconf Tokyo !! Q.「いま運用どうですか?」 データ量:増えてる 機械学習バッチのリソース使用量:増えてる A.「全然、運用ないです」
  23. 23. 前回のServerlessconf Tokyo !! A.「全然、運用ないです」 ● Slackのアラート確認はしてるけど、だいたい自動リトライ済み ● データ量も処理量も増えてるけどデータ量に応じてスケールする ● システムモニタリング用途のAmazon Elasticsearch Serviceのリソー ス見直しの運用を実施
  24. 24. 前回のServerlessconf Tokyo !! うまくいったので今回もLet's Serverless!!
  25. 25. The Design for Serverless ETL Pipeline
  26. 26. アーキテクチャ設計思想 ● サーバー管理が極力少ないパイプラインと実行環境 ● イベントドリブン & 疎結合なアーキテクチャ ● スケーラビリティと処理の並列数の管理 ● イベント(データ)のステータス管理と活用 ● 運用が楽になるロギング・モニタリング
  27. 27. File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus Serverless ETL Pipeline +Runtime +Runtime
  28. 28. Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus Serverless ETL Pipeline +Runtime +Runtime File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3)
  29. 29. Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus Serverless ETL Pipeline +Runtime +Runtime File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Data Source Data Lake Data Warehouse
  30. 30. EventStatus Serverless ETL Pipeline Data Lake (S3) Redshift / Spectrum BigQuery File/Log (CSV/JSON) HPB JLN HPG Database Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) +Runtime +Runtime
  31. 31. EventStatus Serverless ETL Pipeline Data Lake (S3) Redshift / Spectrum BigQuery File/Log (CSV/JSON) HPB JLN HPG Database Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) +Runtime +Runtime ETL Pipeline + Runtime ETL Pipeline + Runtime ETL Pipeline + Runtime
  32. 32. アーキテクチャ設計思想 ● サーバー管理が極力少ないパイプラインと実行環境 ● イベントドリブン & 疎結合なアーキテクチャ ● スケーラビリティと処理の並列数の管理 ● イベント(データ)のステータス管理と活用 ● 運用が楽になるロギング・モニタリング
  33. 33. Runtime Pipeline(Load to DataLake) Event サーバーレスなパイプラインと実行環境 ● パイプラインはStep Functionsなどのワークフローエンジンと AWS Lambdaをベースに処理を定義 ● 実行環境はスケーラブルなAWS Batch、Glue、GKE ● 要件により一部はオンプレサーバーを利用。これもワークフ ローからイベントドリブンで実行可能な状態で設計 ● ※オンプレのケース:大量データの圧縮処理してからデータ転送 スケール スケールOKスケール
  34. 34. Runtime Pipeline(Load to DataLake) Event サーバーレスなパイプラインと実行環境 スケール Runtime スケールOKスケール ● パイプラインはStep Functionsなどのワークフローエンジンと AWS Lambdaをベースに処理を定義 ● 実行環境はスケーラブルなAWS Batch、Glue、GKE ● 要件により一部はオンプレサーバーを利用。これもワークフ ローからイベントドリブンで実行可能な状態で設計 ● ※オンプレのケース:大量データの圧縮処理してからデータ転送 パイプラインはフルサーバレスで定義 コンテナベースでオンデマンドに起動する実行環境 要件によりサーバーをサーバーレスっぽく使う
  35. 35. アーキテクチャ設計思想 ● サーバー管理が極力少ないパイプラインと実行環境 ● イベントドリブン & 疎結合なアーキテクチャ ● スケーラビリティと処理の並列数の管理 ● イベント(データ)のステータス管理と活用 ● 運用が楽になるロギング・モニタリング
  36. 36. Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus Serverless ETL Pipeline +Runtime +Runtime File/Log (CSV/JSON) HPB JLN HPG Database Event Data
  37. 37. Serverless ETL Pipeline Redshift / Spectrum BigQuery Pipeline(Load to Redshift) Pipeline(Load to BigQuery) +Runtime +RuntimeEventStatus Data Lake (S3) File/Log (CSV/JSON) HPB JLN HPG Database Runtime Pipeline(Load to DataLake) Event Data
  38. 38. Redshift / Spectrum BigQuery File/Log (CSV/JSON) HPB JLN HPG Database Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus Serverless ETL Pipeline +Runtime +Runtime Data Lake (S3) Event Data
  39. 39. BigQuery Pipeline(Load to BigQuery) +RuntimeEventStatus Data Lake (S3) Runtime Pipeline(Load to DataLake) Serverless ETL Pipeline Redshift / Spectrum File/Log (CSV/JSON) HPB JLN HPG Database Pipeline(Load to Redshift) +Runtime Event Data
  40. 40. BigQuery Runtime Pipeline(Load to DataLake) EventStatus Serverless ETL Pipeline File/Log (CSV/JSON) HPB JLN HPG Database Data Lake (S3) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) +Runtime +Runtime Redshift / Spectrum Event Data
  41. 41. File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus Serverless ETL Pipeline Runtime Event EventEvent Event Event +Runtime +Runtime 1イベント=1データがどこかに到達したとき イベントドリブン=データが到達したときに次の処理が実行される
  42. 42. File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus +Runtime Event Message Event Message Event Message +Runtime 疎結合なパイプライン
  43. 43. File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus 疎結合なパイプライン +Runtime Event Message +Runtime Event Message
  44. 44. 疎結合なパイプライン File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus +Runtime +Runtime リトライ上限を超え て失敗したイベント はDLQへ 別のパイプラインの 失敗は影響しない 後から来るイベント には影響しない
  45. 45. File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus +Runtime +Runtime ここだけ修正してデ プロイ 疎結合なパイプライン
  46. 46. File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus +Runtime +Runtime ここだけ修正してデ プロイ 各パイプラインの起動にSQSを挟むことで パイプライン同士を疎結合に保ち 1. 障害発生時の影響を小さくする 2. 小さく素早い変更を可能にする 疎結合なパイプライン
  47. 47. アーキテクチャ設計思想 ● サーバー管理が極力少ないパイプラインと実行環境 ● イベントドリブン & 疎結合なアーキテクチャ ● スケーラビリティと処理の並列数の管理 ● イベント(データ)のステータス管理と活用 ● 運用が楽になるロギング・モニタリング
  48. 48. Runtime Pipeline(Load to DataLake) Event パイプラインとスケーラビリティ ● マネージドなパイプラインにより無限のスケーラビリティを確 保 Event Event スケールします ×1,000 スケールします ×1,000 ×1,000
  49. 49. Runtime Pipeline(Load to DataLake) Event ● マネージドなパイプラインにより無限のスケーラビリティを確 保 ● しかしデータロード先がRedshiftなど処理がスケールしない 場合、イベントの同時処理の制御が必要 Event Event しんどい パイプラインとスケーラビリティ
  50. 50. Pipeline(Load to DataLake) Event ● マネージドなパイプラインにより無限のスケーラビリティを確 保 ● しかしデータロード先がRedshiftなど処理がスケールしない 場合、イベントの同時処理の制御が必要 ● SQSの処理中のメッセージ数をポーリングし、処理中の同時 実行数を確認、指定された同時実行数の場合は処理しない 制御を実現 Event Event いま処理が最大並列数に達し てるので、このメッセージはまた 後で実行しよ。 セーフ パイプラインとスケーラビリティ ×1,000
  51. 51. Pipeline(Load to DataLake) Event ● マネージドなパイプラインにより無限のスケーラビリティを確 保 ● しかしデータロード先がRedshiftなど処理がスケールしない 場合、イベントの同時処理の制御が必要 ● SQSの処理中のメッセージ数をポーリングし、処理中の同時 実行数を確認、指定された同時実行数の場合は処理しない 制御を実現 Event Event いま処理が最大並列数に達し てるので、このメッセージはまた 後で実行しよ。 セーフ パイプラインとスケーラビリティ ×10,000 DWH、RDBMSなどの処理がスケールしない環境の場合 SQS + Lambda + CloudWatch Eventで パイプラインの並列度をコントロール
  52. 52. Pipeline(Load to DataLake) Event ● マネージドなパイプラインにより無限のスケーラビリティを確 保 ● もちろんロード処理の宛先がスケールする場合は並列度を 気にせず実行できる ×1,000 Event Event 一気に1,000イベント いくぞッ! 余裕 パイプラインとスケーラビリティ
  53. 53. アーキテクチャ設計思想 ● サーバー管理が極力少ないパイプラインと実行環境 ● イベントドリブン & 疎結合なアーキテクチャ ● スケーラビリティと処理の並列数の管理 ● イベント(データ)のステータス管理と活用 ● 運用が楽になるロギング・モニタリング
  54. 54. Pipeline(Load to DataLake) Event イベントとデータのステータス管理 ● 各パイプラインで、現在のイベントと処理ステータスを一元的 にDynamoDBで管理 ○ システム:Lamndaの2重発火による重複起動を制御 ○ システム:データロード後のマート作成実行を制御 ○ ユーザー:データロード完了時間(=データ鮮度)を確認 EventStatus このデータは 処理中だよ このデータは 処理完了だよ UpdateStatus
  55. 55. Pipeline(Load to DataLake) Event イベントとデータのステータス管理 ● イベントとステータスの変更履歴をRDSで管理・分析 ● DynamoDB Streamsでアイテムの変更をRDSへストリーミン グインサート ● メンバのスキル的にSQLによる分析が可能→RDSに決定 EventLogEventStatus Update
  56. 56. Pipeline(Load to DataLake) Event イベントとデータのステータス管理 ● イベントとステータスの変更履歴をRDSで管理・分析 ● DynamoDB Streamsでアイテムの変更をRDSへストリーミン グインサート ● メンバのスキル的にSQLによる分析が可能→RDSに決定 EventLogEventStatus Update システム間連携、ユーザビリティのためステータスを管理 ステータスログはデバッグ用に正規化して保全しておく
  57. 57. アーキテクチャ設計思想 ● サーバー管理が極力少ないパイプラインと実行環境 ● イベントドリブン & 疎結合なアーキテクチャ ● スケーラビリティと処理の並列数の管理 ● イベント(データ)のステータス管理と活用 ● 運用が楽になるロギング・モニタリング
  58. 58. アプリケーションログとシステムモニタリング ● ログはDatadogに集約。重要な通知はSlackへ。 ● Lambda、AWS Batch、On-Premiseの様々な実行環 境のプログラムログを一元的に検索可能。 Logging Alert
  59. 59. アプリケーションログとシステムモニタリング ● マネージドサービスのメトリクスのアラートもDatadogに集 約。重要な通知はSlackへ。 Metrics Alert
  60. 60. アプリケーションログとシステムモニタリング ● マネージドサービスのメトリクスのアラートもDatadogに集 約。重要な通知はSlackへ。 Metrics Alert Datadogでログとメトリクスを 一元的に管理・検索・モニタリング
  61. 61. File/Log (CSV/JSON) HPB JLN HPG Database Redshift / Spectrum BigQuery Data Lake (S3) Runtime Pipeline(Load to DataLake) Pipeline(Load to Redshift) Pipeline(Load to BigQuery) EventStatus +Runtime +Runtime ● サーバー管理が極力少ないパイプラインと実行環境 ● イベントドリブン & 疎結合なアーキテクチャ ● スケーラビリティと処理の並列数の管理 ● イベント(データ)のステータス管理と活用 ● 運用が楽になるロギング・モニタリング Serverless ETL Pipeline
  62. 62. リプレースの際の教訓
  63. 63. 既存の運用に設計が引きずられる ● 運用をなるべく変えないようにすると、既存のインターフェー スに引きずられてサーバ依存の設計になりがち。 ● 運用も含めてリプレースの対象だという共通認識を作る。た だしこれには運用者の同意も必要なので事前の調整が必 須。 慣れた運用からの脱却 ログの保存先の変更 新しいツールの学習
  64. 64. スコープの肥大化 ● システムのリプレースにおいては、今までのつらみを解消し ようとしてスコープが肥大化しがち。 ● 要望を明文化して残しておき「やるやらない」の判断をしてか らプロジェクトを進めるようにする。 新しいシステムが全てを叶えてくれるわけではない。 スコープ スコープ あれもやりたい これもやりたい 一度リストに集約 そのままだと 膨れ上がる スコープの範囲を 明確化する
  65. 65. エンジニア募集中!! It’s easier to ask forgiveness than it is to get permission. Development follows your heart.

×