セルフサービス型データ分析ジョブプラットフォーム設計プラクティス / cndt2021_kojisuganuma

•マスターテキストの書式設定 
第 2 レベル 
第 3 レベル 
第 4 レベル 
第 5 レベル
マスタタイトルの書式設定
1
クラウドネイティブ × 持続可能
セルフサービス型データ分析ジョブプラットフォーム
設計プラクティス
株式会社リクルート
菅沼孝二 
Cloud Native Days Tokyo 2021
(C) Recruit Co., Ltd. All rights reserved.

View Slide

2
❏ 発表について補足
❏ 発表資料は後日公開されます
❏ 発表当日リアルタイムに質問に回答します
❏ 非同期で質問・コメントしたい場合
❏ Twitter DM : @kojisuganuma
❏ Twitter Hash Tag : #CNDT2021_C
ご視聴いただきありがとうございます！

View Slide

3
3
自己紹介　菅沼孝二社会人歴 5 年
所属　　　　　株式会社リクルート　データ推進室
2016年 -
新卒
メディア・ゲーム・広告関連事業会社
広告データ収集基盤開発・広告効果モデリング
2017年 -
中途
株式会社リクルートライフスタイル
データ分析・モデリング・実装 / データプラットフォーム開発・SRE
2021年 -
（統合）
株式会社リクルート
データプラットフォーム開発・SRE・採用関連
3
Hobby & Ability 資産形成 / 子育て
Resolution 経済的自立 / エンジニアリングで社会に貢献

View Slide

発表のアウトライン
4
4
● スコープ
○ データ分析向けジョブプラットフォーム
○ データ活用の業務プロセス
○ それを取り巻くエンジニア・データサイエンティスト・データプランナー
● ゴール
○ スケーラブルな業務運用プロセス設計
■ データ施策・プロダクト利用者の数に運用負荷を比例させない
○ 信頼性が高いプロダクト開発
■ 高いスケーラビリティ・回復性・障害耐性を持つプロダクト
○ 持続可能なプロダクト開発
■ ワークフローエンジンを実装詳細を隠蔽し、プロダクトの変更容易性を維
持する

View Slide

5
5
Agenda
1. 事業・組織について
2. チーム・プロダクトについて
3. 直面した問題と設計プラクティス
4. 実装と運用
5. 新たな課題・今後の展望
6. まとめ
5

View Slide

6
6
Agenda
4. 実装と運用
6. まとめ
6

View Slide

主な事業領域
(C) Recruit Co., Ltd. All rights reserved. https://recruit-saiyo.jp/present/
7

View Slide

ビジネスモデル
8
https://recruit-holdings.com/ja/about/business/
個人ユーザーと企業クライアントが出会う場を作り出し
より多くの最適なマッチングを実現
8

View Slide

データ推進室
データ推進室の取り組み
9
9
事業領域A
事業領域Aデータ
ソリューション
データエンジニアリング・データマネジメント
事業領域C
事業領域B
事業領域Bデータ
事業領域Cデータ

View Slide

10
10
Agenda
4. 実装と運用
6. まとめ
10

View Slide

データ活用プロセス
11
11
collect transform delivery
analyze modeling
app web server storage database
Illustration designed by Freepik From Flaticon

View Slide

私たちのチーム・プロダクトの位置付け
12
12
collect transform delivery
analyze modeling
app web server storage database
販促領域・SaaS 領域・その他 (※2021年時点)

View Slide

13
13
データプラットフォームの
設計・構築・運用
データマネジメント
高度なデータパイプライン
の設計・構築
...
の設計・構築・運用
特徴量エンジニアリング
MLモデリング
データビジュアライズ
データ開発
...
高度なML・数理モデリング
データ探索
データ基礎分析
データ開発
...
データ戦略の立案・推進
データ開発
データ探索
...
各種職務による
エンジニアリング
MLOps
DevOps
SRE
セキュリティ
...
MLOps
機械学習理論
データ加工
データ抽出
データ可視化
...
機械学習理論
数理最適化理論
統計・検定理論
データ加工
データ抽出
データ可視化
...
データ戦略立案・推進
仮説設計・効果検証設計
データ加工
データ抽出
データ可視化
...
Data Planner
Data Scientist
ML Engineer
ディレクター・
マーケター・事
業開発など
Software Engineer
Data Engineer
Role
Capability Posision
データ活用人材の Posision & Role & Capability
※ Role 及び Capability はあくまでも一例です。組織・チームによって異なります。

View Slide

14
14
データプラットフォームの
設計・構築・運用
の設計・構築
...
の設計・構築・運用
MLモデリング
データ開発
...
高度なML・数理モデリング
データ探索
データ開発
...
データ戦略の立案・推進
データ開発
データ探索
...
MLOps
DevOps
SRE
セキュリティ
...
MLOps
機械学習理論
データ加工
データ抽出
データ可視化
...
機械学習理論
数理最適化理論
統計・検定理論
データ加工
データ抽出
データ可視化
...
データ戦略立案・推進
仮説設計・効果検証設計
データ加工
データ抽出
データ可視化
...
Data Planner
Data Scientist
ML Engineer
ディレクター・
マーケター・事
業開発など
Software Engineer
Data Engineer
Role
Capability
Data Platform
Architect
Data Solution Architect
Service
Developer
Posision
データ活用人材のカテゴライズ

View Slide

15
15
Data Platform Architect
Software Engineer / Data Engineer
ML Engineer / Data Scientist / Data Planner
Service Developer
ディレクター・マーケター・事業開発など
カスタマー・クライアント
データプラットフォームの提供
データソリューションの提供
データによるサービス品質の向上
事業価値
データによる事業価値創出の構造

View Slide

16
16
Data Platform Architect
Software Engineer / Data Engineer
ML Engineer / Data Scientist / Data Planner
Service Developer
ディレクター・マーケター・事業開発など
カスタマー・クライアント
データプラットフォームの提供
データソリューションの提供
データによるサービス体験の向上
事業価値
私たちのチーム・プロダクトの位置付け

View Slide

17
17
Agenda
4. 実装と運用
6. まとめ
17

View Slide

データプラットフォームのよくある問題
18
18
✔ インフラの信頼性が低く、データ処理リクエストの増加
に処理が追いつかなかったり、メンテナンス時・障害時
に単一障害点起因のダウンタイムが発生してしまう
✔ 開発体験の悪いデータプラットフォームは、利用者から
の問い合わせ数が増大し、その対応で工数が溶ける
✔ データ施策・プロダクト利用者が増加するほど、データ
エンジニア工数不足がボトルネックになる
✔ プロダクトが大きく成長するにつれて、各種コードの依
存関係が複雑になり、あらゆる変更が困難になる

View Slide

19
19
運用がスケールしない
データプラットフォーム
”データから価値を生み続けるには
” より一部修正して再掲
データ活用の取り組みにおける
「運用がスケールしない」
業務プロセスのスキーム
①　コミュニケーションコスト / 専門性の違いに　　
よる生産性低下
②　エンジニアのリソース上限が
　　データ施策の推進のボトルネックに
③　プロダクトの機能開発・自動化・信頼性向上　　
に開発リソースを十分に割けない
①
② ③
データ
サイエンティスト
データ
プランナー
エンジニア

View Slide

20
20
実装・デプロイ・運用がセルフサービス化
されたデータプラットフォーム
データ活用の取り組みにおける
「価値創出がスケールする」
業務プロセスのスキーム
①　開発・デプロイ・運用のセルフサービス化
　　により変更反映のリードタイムを削減
②　エンジニアによるデータ施策個別の
　　開発コストをゼロに
③　エンジニアはデータプロダクトの
　　機能開発・自動化・信頼性向上に集中
データ
データ
プランナー
エンジニア
① ②
③

View Slide

21
21
運用がスケールしない
データプラットフォーム
データ
データ
プランナー
エンジニア
実装・デプロイ・運用がセルフサービス化
されたデータプラットフォーム
データ
データ
プランナー
エンジニア
関心の分離 & セルフサービス化
データ活用の業務プロセスとプロダクトデザインを最適化
データサイエンティスト・データプランナーの関心
エンジニアの関心

View Slide

22
ALL OK？ → NO!!!!!
❏ Developer からの問い合わせ対応が大変！

View Slide

23
23
開発体験が悪い
セルフサービス型データプラットフォーム
「開発体験が悪い」
①　開発・運用時のデバッガビリティが悪く
　　問い合わせが殺到
②　プロダクトの機能開発・自動化・信頼性向上　　
に開発リソースを十分に割けない
データ
データ
プランナー
エンジニア
①
②

View Slide

24
24
開発体験が良い
「開発体験が良い」
データ
データ
プランナー
エンジニア
②
①　実行ログ検索性の向上・データ施策ごとの
　　リソースモニタリングダッシュボードの提供
　　・docs 拡充・docs 自動生成・etc.
②　セルフサービス開発のデバッガビリティの
　　改善により問い合わせ対応工数を削減
①
③
③　エンジニアはプロダクトの
　　機能開発・自動化・信頼性向上に集中

View Slide

25
25
開発体験が悪い
セルフサービス型データプロダクト
データ
データ
プランナー
エンジニア
開発体験が良い
セルフサービス型データプロダクト
データ
データ
プランナー
エンジニア
開発体験（Developer Experience）の最大化
利用方法がわからない時・問題の発生時も自立的に理解を深められる仕組みを提供

View Slide

26
❏ データ施策数の増加に伴ってアーキテクチャ上のボトル
ネックが浮き彫りに！

View Slide

27
27
「 Non-Scalable & Non-Reliable」
Infrastructure
②　単一障害点となるコンポーネントが存在し、メ　　
ンテナンス（ソフトウェア/ノードアップグレー　　
ド等）時や障害時にダウンタイムが発生する
①　ジョブ実行に必要なコンポーネントである　　　
ワーカー・スケジューラー・ウェブサー　　　　
バー、及びノードが事前に決められた台数の　　
み起動しており、リクエストが急増すると期　　
待する時間内に処理が始まらない
job worker
job scheduler
job webserver
③　単一のゾーンにのみコンポーネント群が存在　　　
し、ゾーンレベルの障害耐性がない
zone
node

View Slide

zone
node
28
28
「 Scalable & Reliable」
Infrastructure
②　単一障害点となるコンポーネントが存在せず、
　　メンテナンス・障害時に系全体ではダウンタイ　　
ムが発生せず、かつ回復性を持つ
①　ワーカー・スケジューラー・ウェブサー　　　　
バーやノードの全てがリクエストの増減に応　　
じてオートスケーリングする
job worker
job scheduler
schedulable spot
Scalable & Reliable
③　複数のゾーン（もしくはリージョン）に跨って
　　コンポーネントが冗長化されており、ゾーンレ　　
ベルの障害耐性を持つ
④　クラウドファースト・コンテナ化・ポータブ　　　
ル・完全なコード管理・マイクロサービス化・
　　リリース自動化・etc...
job webserver

View Slide

29
29
クラウドネイティブ化
ビジネス・組織・外部環境の変化に頑健なインフラストラクチャ設計
job worker
job scheduler
job webserver
zone
node
zone
node
job worker
job scheduler
schedulable spot
Scalable & Reliable
job webserver

View Slide

30
❏ プロダクトが大きくなると、変更容易性が悪く
なり、開発生産性が低下！

View Slide

31
31
ジョブスケジューラー・ワークフローエンジン
の実装詳細
ワークフローの定義
データ処理ロジックの構築
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
import datetime
from airflow.models import DAG
from airflow.contrib.operators.bigquery_operator import BigQueryOperator
from airflow.contrib.operators.bigquery_to_gcs import BigQueryToCloudStorageOperator
# define DAG
dag = DAG(
"bq-to-gcs-job",
default_args={...},
schedule_interval=datetime.timedelta(days=1),
catchup=False,
)
# define Task1
create_bq_table = BigQueryOperator(
dag=dag,
task_id="create-bq-table-task",
sql="""select … from `google_cloud_project.dataset_src.table_src` … """,
destination_dataset_table="google_cloud_project.dataset_dst.table_dst",
use_legacy_sql=False,
)
# define Task2
bq_table_to_gcs = BigQueryToCloudStorageOperator(
dag=dag,
task_id="bq-table-to-gcs-task",
source_project_dataset_table="google_cloud_project.dataset_dst.table_dst",
destination_cloud_storage_uris="gs://bukcet/path/to/object.csv",
)
# define task dependecy
create_bq_table >> bq_table_to_gcs
データを集計し、
ストレージに保存する
実行コンテキストや、
依存関係などの定義
Apache Airﬂow
よくある問題
● バージョンアップデートが大変...😑
● 別のワークフローエンジンに移行するのが超大
変......😂
なぜ発生するの？
● データ処理ロジックの構築が『実装詳細に依存』
● ワークフローの定義が『実装詳細に依存』
Apache Airﬂow による実装例を基に
変更容易性に関する問題を探るワークフローの定義
データ処理ロジックの構築

View Slide

32
32
「実装の詳細に依存する」
Layered Architecture
①　アプリケーションレイヤもドメインレイヤも
　　インフラストラクチャレイヤの依存している
インフラストラクチャレイヤ
ドメインレイヤ
アプリケーションレイヤ
Job Scheduler や Workflow Engine の
機能を提供するツール（実装詳細）
(ex) Apache Airflow / Kubeflow Pipelines
データ処理のロジック
②　インフラストラクチャレイヤの変更影響がア　　
プリケーションレイヤやドメインレイヤ全体　　
に波及するため、変更容易性が低い

View Slide

33
33
①　インフラストラクチャレイヤもアプリケー　　　
ションレイヤもドメインレイヤに依存する
「抽象に依存する」
Layered Architecture
逆転 ②　インフラストラクチャレイヤの変更影響がド　　
メインレイヤやアプリケーションレイヤに波　　
及しないため、変更容易性が高い

View Slide

34
34
依存性逆転の原則
変更容易性を維持するために、実装の詳細に依存させず抽象に依存するように設計
逆転

View Slide

35
35
Agenda
4. 実装と運用
6. まとめ
35

View Slide

Kubernetes Cluster
36
36
Airflow DB
Cloud SQL
Cloud SQL
Proxy
Airflow DAGs/Logs
Cloud Storage
Airflow
Webserver
Airflow
Scheduler
Cloud Load
Balancing
Cloud Armor
Identity-Aware
Proxy
Airflow Worker (by Task)
Task Container (by Task)
Job CI/CD
Cloud
Logging
Kubernetes Engine
region cluster
Cloud
Build
Container
Registry
Developer
ジョブプラットフォーム
アーキテクチャ像

View Slide

セルフサービス化 × 優れた開発体験
を実現する工夫
37
37
各種
スクリプト
+
Job
Manifest
Job CI/CD
Project CI/CD
Project
Manifest
project
repository/team
role/docs
自動生成
Job
自動登録
project
dashboard
自動生成
Project
申請フォーム
Job
Infrastructure
Cloud
Logging
Maintainer
Developer
Pick up!
・ジョブ開発運用に必要なリソース生成の自動化
・ジョブ登録・更新の自動化
Project Owner
各種
k8s/cloud resource
自動生成

View Slide

Kubernetes Cluster
38
38
Airflow DB
Cloud SQL
Cloud SQL
Proxy
Airflow DAGs/Logs
Cloud Storage
Airflow
Webserver
Airflow
Scheduler
Cloud Load
Balancing
Cloud Armor
Identity-Aware
Proxy
Airflow Worker (by Task)
Task Container (by Task)
Job CI/CD
Cloud
Logging
Kubernetes Engine
region cluster
Cloud
Build
Container
Registry
Developer
Pick up!
・Region Cluster / Private Cluster によるクラスタ冗長化・セキュア化
・Cluster autoscaling
・Cluster auotupgrade / Maintenance window による保守自動化
・Airflow Scheduler / Webserver / Cloud SQL Proxy の冗長化
　・Deployment / HPA 利用
　・Pod Anti Affiniity によるホスト・ゾーン分散
・Airflow Worker は Airflow Task 毎に on-demand 起動
　・Airlfow Kubernetes Executor 利用
・その他
　・フルコンテナ化によるポータビリティ
　・Datadog monitoring / alert による定常監視 & 障害検知
　・Terraform / k8s Manifest / Helm / Kustomize によるコード管理
クラウドネイティブ化を実現する工夫

View Slide

Job CI/CD (Backend: workflowengine-a)
39
39
39
39
Workflow
Definition
自動生成
なし
Dockerfile(s)
(1task-1image)
依存性逆転の原則を実現する工夫
各種
スクリプト
+
Job
Definition
Workflow Engine A
Workflow Engine B
Workflow Engine C
Non-Plugable
Component
Job CI/CD (Backend: plugable)
Workflow
Definition
Dockerfile(s)
(1task-1image)
各種
スクリプト
+
Job
Definition
Workflow Engine A
Workflow Engine B
Workflow Engine C
Plugable
Component
dependency
dependency
依存性を解決できていないワークフローエンジンの (非) 抽象化の例
依存性を解決したワークフローエンジンの抽象化の例
自動生成
自動生成
or
dependency

View Slide

Job CI/CD (Backend option: airflow)
40
40
40
40
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Job Definition
schema: job/v2 # define job
metadata:
name: bq-to-gcs-job
spec:
trigger: # { 実行スケジュール設定 (cron) }
tasks:
# define Task1
- name: create-bq-table-task
spec:
operator:
query:
runtimeVersion: v1
path: ./aa.sql # 別途実装する
output:
bigQuery:
tableId: google_cloud_project.dataset_dst.table_dst
truncate: { … }
partitioning: { … }
serviceAccount: sample-sa
# deine Task2
- name: bq-table-to-gcs-task
spec:
operator:
python:
image: python:3.9
path: ./bb.py # 別途実装する
resource: # { cpu/memory設定 }
dependsOn: # define task dependency
allOf:
status: success
callback:
onSuccess:
- slackNotification: # { 正常系slack通知設定 }
onFailure:
- slackNotification: # { 異常系slack通知設定 }
aa.sql bb.py
+
+
Airflow DAG
自動生成
Apache Airflow
Container
Registory
Dockerfile(s)
(1task-1image)
Plugable Component example
Backend option: Apache Airflow
push
deploy build
pull
Job
Definition

View Slide

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Job Definition
metadata:
name: bq-to-gcs-job
spec:
tasks:
# define Task1
spec:
operator:
query:
runtimeVersion: v1
output:
bigQuery:
truncate: { … }
# deine Task2
spec:
operator:
python:
image: python:3.9
allOf:
status: success
callback:
onSuccess:
onFailure:
Job CI/CD (Backend option: composer)
41
41
41
41
(C) Recruit Co., Ltd. All rights reserved. Illustration designed by Freepik From Flaticon
aa.sql bb.py
+
+
Airflow DAG
自動生成
Cloud Composer
Container
Registory
Dockerfile(s)
(1task-1image)
Backend option: Cloud Composer
pull
deploy build
push
Job
Definition

View Slide

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Job Definition
metadata:
name: bq-to-gcs-job
spec:
tasks:
# define Task1
spec:
operator:
query:
runtimeVersion: v1
output:
bigQuery:
truncate: { … }
# deine Task2
spec:
operator:
python:
image: python:3.9
allOf:
status: success
callback:
onSuccess:
onFailure:
Job CI/CD (Backend option: argo)
42
42
42
42
(C) Recruit Co., Ltd. All rights reserved. Illustration designed by Freepik From Flaticon
aa.sql bb.py
+
+
Argo Workflow
Manifest
自動生成
Argo Workflows
Container
Registory
Dockerfile(s)
(1task-1image)
Job
Definition
Backend option: Argo Workflows
pull
deploy build
push

View Slide

直面した問題と設計プラクティス
43
43
✔ インフラの信頼性が低く、データ処理リクエストの増加
にインフラが追いつかなかったり、メンテナンス時・障
害時に単一障害点起因のダウンタイムが発生してしまう
✔ 開発体験の悪いデータプラットフォームは、利用者から
の問い合わせ数が増大し、その対応で工数が溶ける
✔ データ施策・プラットフォーム利用者が増加するほど、
データエンジニア工数不足がボトルネックになる
✔ プラットフォームが大きく成長するにつれて、各種コー
ドの依存関係が複雑になり、あらゆる変更が困難になる
問題設計プラクティス
✔ クラウドネイティブ化
✔ 開発体験 (Developer Experience)
の最適化
✔ セルフサービス化
✔ 依存関係逆転の原則の導入

View Slide

44

View Slide

45
45
Agenda
4. 実装と運用
6. まとめ
45

View Slide

新たな課題と今後の展望
46
46
課題
- インフラコストの肥大化
- アプリケーションコードの品質担保
- より高い隔離性が求められるデータの扱い
- より高いサービスレベルが求められる事業・施策の扱い
- etc...
展望
- リクルートのデータ活用をさらに高度化する機能拡張
- リクルートの全ての事業領域に展開するための非機能拡張
- etc...

View Slide

47
We're Hiring!!!
❏ Career Site
❏ 学生向けキャリアサイト
❏ 中途採用向けテクノロジー職
❏ Blog
❏ Recruit Data Blog
❏ Recruit Tech Blog
❏ Direct Message
❏ Twitter : @kojisuganuma
❏ Linkedin: Koji Suganuma

View Slide

48
48
Agenda
4. 実装と運用
6. まとめ
48

View Slide

まとめ
49
49
● スコープ
○ データ分析向けジョブプラットフォーム
○ データ活用の業務プロセス
○ それを取り巻くエンジニア・データサイエンティスト・データプランナー
● ゴール
○ スケーラブルな業務運用プロセス設計
■ データ施策・プロダクト利用者の数に運用負荷を比例させない
○ 信頼性が高いプロダクト開発
■ 高いスケーラビリティ・回復性・障害耐性を持つプロダクト
○ 持続可能なプロダクト開発
■ ワークフローエンジンを実装詳細を隠蔽し、プロダクトの変更容易性を維
持する
● プラクティス
○ セルフサービス化
○ 開発体験の最適化
○ クラウドネイティブ化
○ 依存性逆転の原則の導入

View Slide

•マスターテキストの書式設定 
第 2 レベル 
第 3 レベル 
第 4 レベル 
第 5 レベル
マスタタイトルの書式設定
50
Cloud Native Days Tokyo 2021

View Slide

セルフサービス型データ分析ジョブプラットフォーム設計プラクティス / cndt2021_kojisuganuma

セルフサービス型データ分析ジョブプラットフォーム設計プラクティス / cndt2021_kojisuganuma

Recruit
PRO

More Decks by Recruit

Other Decks in Technology

Featured

Transcript

セルフサービス型データ分析ジョブプラットフォーム設計プラクティス / cndt2021_kojisuganuma

セルフサービス型データ分析ジョブプラットフォーム設計プラクティス / cndt2021_kojisuganuma

Recruit PRO

More Decks by Recruit

Other Decks in Technology

Featured

Transcript

Recruit
PRO