1.
Hadoopデータ基盤と
Multi-CloudなML基盤への
取り組みの紹介
2019/10/05 【マイクロアド】〜ネット広告を支える技術を知る〜
#microad_CAMPHOR
MicroAd, Inc.
システム開発本部 基盤技術開発グループ インフラチーム
永富安和

2.
Profile:
Name: 'Yasukazu Nagatomi（やっさん）'
Company:
Location: 'Kyoto'
Role:
- 'Infrastructure Engineer (Hadoop/Container)',
- 'CloudNativeDays in Japan実行委員',
- 'Rancher JP / Cloud Native JP Organizer',
Favorites: [ '美味い日本酒', 'Craft Beer', 'Terrarium']
SocialMedia:
- Twitter: '@yassan168'
- GitHub: 'yassan' 2

3.
データ基盤について
3

4.
#microad_CAMPHOR
データ基盤運用する上での課題
4
大量のストリームデータ（約6TB/day）のETL処理を滞りなく実行し、
利用可能なデータとして提供出来るようにする
1. ストリームデータを欠損無く処理して確実にSink出来る事
2. ETL処理の運用コストを如何に最小にするか
3. 蓄積したたデータが利用可能な状態でなければならい

5.
#microad_CAMPHOR
データ基盤運用する上での課題 その１
5
大量のストリームデータ（約6TB/day）のETL処理を滞りなく実行し、
利用可能なデータとして提供出来るようにする
1. ストリームデータを欠損無く処理して確実にSink出来る事
➢ FluentdでログをKafkaに流し、Flumeを使ってHDFSへSinkする
➢ 複雑なETLが必要な場合は、Spark Streaming を用いて対応
➢ Kafkaを用いる事でログをキューイング出来るので
Consumer先（Sink先）に障害があっても途中からやり直しが効く
2. ETL処理の運用コストを如何に最小にするか
3. 蓄積したたデータが利用可能な状態でなければならい

6.
#microad_CAMPHOR
Cloudera Manager
ログ転送
データ基盤の概要
6
広告配信サーバ等
各種サーバ
：
Topic
Topic
：
Topic
Topic
： Topic
Topic
：
管理・監視

7.
#microad_CAMPHOR
その他のKafkaを使った工夫
● パーティション数の増加にスケールの限界がある為、
ひとつの大きなクラスタでは無く複数の中規模クラスタを用途に合わせて複
数使う戦略を取った。
7

8.
#microad_CAMPHOR
その他のKafkaを使った工夫（トピック運用）
基本的に時系列データはYYYYMMDDのプレフィックスをつけた
● データの再ロードの粒度を日付単位にできる
● 日別にTopicを使い捨てる事でPartition数の変更等の運用が不要
● Partition数の変更にはPartitionリアサインが必要だが
オンラインでやるとデータがロストしたりするのを回避したかった
● YYYYMMDDであれば毎日作りかえる形となるので、
Partition数の増減が作り変えのタイミングで変更できる
● データの制約により時系列にできないトピックでも、上記の理由と同様に
v1などのバージョニングをおこなう
● 時系列なTopicの作成はDigdagバッチで実行している
● 毎日3日先の日付のtopicを作成している
→土曜にジョブかコケても即日対応しなくてもよいように
8

9.
#microad_CAMPHOR
データ基盤運用する上での課題 その２
9
大量のストリームデータ（約6TB/day）のETL処理を滞りなく実行し、
利用可能なデータとして提供出来るようにする
1. ストリームデータを欠損無く処理して確実にSink出来る事
2. ETL処理の運用コストを如何に最小にするか
➢ Digdagを用いる事で、バッチが定義しやすく、UIがあるので状況が確認
出来て、リトライも楽に出来る（とは言え数が多くなると辛いみも）
➢ Digdagやバッチ処理自体は、Dockerを用いてバッチサーバのリソース
に影響しない作りにした
➢ ジョブやバッチ間の依存は、DigdagのS3_waitオペレータを使うこと
で、S3にファイルをフラグの代わりにして依存を解決した
3. 蓄積したたデータが利用可能な状態でなければならい

10.
#microad_CAMPHOR
PostgreSQL
S3
DigdagとDockerを用いたバッチの運用
10
Docker
Digdag Server Host 01
Aジョブ用
Bジョブ用
・・・
Digdag
Server
Docker
Digdag Server Host XX
Aジョブ用
Bジョブ用
・・・
Digdag
Server
Aジョブ用
イメージ
Bジョブ用
イメージ
ジョブをコンテナ化しているので
どこで動かしても問題無い
ホストの
縮退が可能バッチはどちらかの
Digdag Serverで動く
S3のファイルを
フラグ的に使って
ジョブ間の依存を解決

11.
#microad_CAMPHOR
データ基盤運用する上での課題 その３
11
大量のストリームデータ（約6TB/day）のETL処理を滞りなく実行し、
利用可能なデータとして提供出来るようにする
1. ストリームデータを欠損無く処理して確実にSink出来る事
2. ETL処理の運用コストを如何に最小にするか
3. 蓄積したたデータが利用可能な状態でなければならい
➢ 1テーブルのサイズがデカイので、列指向フォーマットで必要な列のみ
取り出せるように（ORCやParquetの利用）
➢ Hiveだけでなく、ユースケースに応じてImpalaも活用

12.
#microad_CAMPHOR
HDFSファイルのフォーマットの工夫
● 挿入速度優先なら行指向のAvro、参照速度優先なら列指向のParquetやORC
○ ただし、ParquetのStruct型やORCのComplex型（→列に入れ子する。1カラムにJSON埋め
込んでネストしてしまう）の場合、入れ子の列については抜き出しできないので注意が必要
● 列指向に関しては、Yahoo! Japanの Yosegi も非常に良い感じ
○ 圧縮効率のよいカラムナフォーマット 〜 Yosegi や ORC のエンコード方式調査 - Yahoo! JAPAN Tech Blog
● フォーマットの詳しい話は、以下に全部詰まってます
○ カラムナフォーマットのきほん 〜データウェアハウスを支える技術〜 - Retty Tech Blog
● 選ぶ際にも注意が必要
○ 圧縮フォーマットにも注意。圧縮効率高めると比例して、追加や参照の性能が下がる。
○ マニアックなもの選ぶとHadoopエコシステムに対応できなくて詰む
■ Hiveでは読めるけど、Impalaでは読めない等の制限事項があったりとか
例：CDH v5系ではImpalaではORCが読めない
● 1ファイルサイズが非常に小さい場合、特に 128MB 未満の場合、性能劣化が
顕著なのでその場合はまとめる方が良い（256MB程度には） 12

13.
#microad_CAMPHOR
何故HiveとImpalaを使い分けるのか？
クエリ実行時間だけでは、HiveよりもImpalaが圧倒的に有利。
理由は、HiveはMapReduceジョブとしてクエリ実行時に動いているので
（Sparkに変更も可能。TezとかLLAP）どうしても遅くなる。
分析用HadoopクラスタではHive→Impalaに変えただけで、
クエリ実行時間が 36倍速くなった（約30分→約50秒弱）。
ただし、Impalaの特性上、リソース確保出来ない場合はすぐにエラーとなるので
バッチ処理には扱いにくく、Hiveはコケにくい。
なので、以下のように使い分けるのもあり。
バッチ用途→Hive
分析などのアドホックなクエリ実行→Impala
13

14.
#microad_CAMPHOR
その他にも…
● 利用頻度の高いデータをSSDのあるDataNodeに入れて、
頻度の低くなったものをHDDのDataNodeに移動するなどの調整
● バッチと分析のジョブがリソース喰い合いになってバッチをコケさせないよ
うにする為に、YARNの実行をフェアスケジューラを使って制御
○ さらに、Impalaのリソースの配分をアドミッションコントロールで制御なども可能
（Impalaの利用がこれからなので特にまだこれはやってない）
14

15.
その他の工夫
15

16.
#microad_CAMPHOR
16
HDFSで使っているタイプのH/W紹介
Hadoopクラスタには、以下のようなマルチノードクラスタを用いて
1ラックあたりの集積度を上げて効率化しています。

17.
ML基盤について
17

18.
#microad_CAMPHOR
状況説明（機械学習をとりまく環境）
● ML基盤などは無い
● Tensorflow（Keras）の利用が進んでいる
● 機械学習モデルの作成から利用までALLオンプレ環境
※扱うデータは数十PBもある
● 入札アルゴリズムやアドフラウド対策などで
機械学習が期待されていて日々研究している
● （機械学習だけじゃないが）BigQueryを分析用で
割と使っていて今後も拡大路線
18

19.
#microad_CAMPHOR
課題
1. 実験用環境の調達に対してリードタイムが長い
○ オンプレあるある。余剰が常にあるとは限らない。
2. ミドルウェアを気軽に変更して試したい
○ Jupyter NotebookのKernelを好きなように変えたいとか、TFのVer.等。
3. 学習モデルのデリバリーのフローが確立していない
（案件単位でバラバラ）
○ 毎日新しいデータで学習モデルを更新して、本番へ投入したい
4. 新しいモデルを本番でお試しするのが難しい
○ 3により、リリースするにも関係部署との調整が大変
19
特にコレ！

20.
#microad_CAMPHOR
解決への算段 ＆ 野望
● 気軽に試せてスケールアウトも可能な環境としクラウド（GCP）を活用
○ Kubernetes使うならGKEならまだ敷居は低いはず
○ 別途BigQueryの利用が広がっているのでクラウドはGCPでOK
● TensorFlow Servingが、Servingした学習モデルに対して、
Multi Model＆ Multi Version扱えるので、お試し利用しやすい環境を
整えやすい（はず）
● Kubeflow pipelineでデリバリまでのフローを確立する（はず）
更に、、、
これを皮切りに、コンテナ化が進んでいる他のシステムのKubernetes移行も
進めていきたい（docker-compose運用では厳しくなってきた）
20

21.
なぜ Rancher を選んだのか？
21

22.
#microad_CAMPHOR
Rancherとは？
22
Rancher Labsが開発するOSSで、Kubernetesクラスタ管理機能を持つ。
オンプレやパブリッククラウド上に構築したKubernetesだけでなく、
パブリッククラウドのマネージドKubernetesなどのクラスタをまとめて管理する
事が可能。
また、RKEというKubernetesクラスタをシンプルに構成出来るToolなども開発。

23.
#microad_CAMPHOR
なぜ Rancher を選んだのか？
1. 今後オンプレとクラウドの両方のKubernetesクラスタ管理が見込まれた
○ オンプレならRKEがあるし、クラウドはGCP・AWS・Azureなど選択肢が多い
2. 可能な限りロックインされたくない
○ 最悪、Rancher無くてもなんとかなる（後で引き返せる）
3. Kubernetes強い人がいない＆採用も困難なので有償サポートでカバーしたい
○ Kubernetes強い人を採用するとか世界規模で大変
○ Rancherの有償サポートは対象範囲が幅広い
■ OS、Docker・Kubernetes、flannel、canal、nginx-ingress-controller、
マネージドKubernetes（AKS/GKE/EKS）、Rancherで使うPrometheus and Grafana等
cf. Rancher Labs Support and Maintenance – Terms of Service
○ 初期コストはそれなりにするけど、月割で考えたら割と許容出来る
後、個人的にはデジタルサイネージへのk3sへの期待
23

24.
なぜ Kubeflow を選んだのか？
24

25.
#microad_CAMPHOR
Kubeflowとは
Kubernetesとそのエコシステムを使って構成したML基盤そのもの。
NoteBookからTraining、ハイパーパラメータのTuning、Pipeline、Serving向け
に何でも揃っている。
Deploy Kubeflow https://deploy.kubeflow.cloud/ を使うとGKE上に以下が構成される。
25
Ingress
Central Dashboard
Dashboards
TFJob Pipelines
KatibNotebooks
TensorbordArgo
Operators
TFJob Pytorch
Argo Katib
Serving
TF-Serving
Seldon
cf. Deploy using UI
お試し程度なら、"Setup Endpoint later”
にしてPort Forwardする方が簡単。
cf. KubeCon + CloudNativeCon Europe 2018: Kubeflow Deep Dive

26.
#microad_CAMPHOR
なぜ Kubeflow を選んだのか？
1. ML開発に必要なものが揃って（まだ全部じゃないけど）いた
2. 実験用の環境をJupyterHubを使って用意しやすそう
3. Tensorflow Servingをサポート
4. PipelineツールとしてArgoをベースとした Kubeflow Pipeline がある
5. Tensorflow（Keras）だけじゃなく、要望のある Seldon-core にも対応
6. 多くを望まなければGCPのAIプラットフォームもある
ただし、kubeflowはまだ発展途上。
今すぐ使う場合は、最悪、部分的に使うとか、割り切りが必要。
また、Rancher Catalogのkubeflowはv0.1でとても古いので使えない。
Helmでは対応中。Kubeflow公式はKustomizeを使ってGitOps的な方法を推奨。
26

27.
どう取り組んでいるのか？
27

28.
#microad_CAMPHOR
基本方針
● 最低ラインを確保する
○ 一番解決したい事、何が目的だったかを忘れない
● いつでも辞められるようにする
○ 運用実績が無いものだらけなので最悪戻せる場所は確保
● 無理をしない・一気に進めない
○ （ちょっとくらいは良いけど）背伸びしないで身の丈にあった速度で進める
28

29.
#microad_CAMPHOR
どう取り組んでいくのか？
事前準備
● オンプレ環境からGCSへ整形＆絞ってキレイにしたデータをGCP上に蓄積
○ GCPで学習モデルを作成出来る用意
● GCEを使って従来手法で学習モデルを作成
○ 好きなように実験が可能
● 作成した学習モデルをGCSへ格納して、オンプレ側から取得して、
従来通りServingして利用する
一番の課題だった「実験環境のリードタイムの短縮」をこれで確保
まずは引き返せる場所を確保した。
29

30.
#microad_CAMPHOR
第１フェーズ：GCPで今まで通り＋TF-Serving
30
TF-Serving 中継App
各種システム
NFS
modelのexport
HDFS
ml models ＆
training data
Modeling ＆ Traning
各種システム
各種システム
GCP On-Premise
GCP↔オンプレ間は
Cloud VPN を利用
TF-Servingを
docker-composeで構成
GCE
TF-Serving：Tensorflow Serving
GCS
バッチ処理で
ETL＆GCSに
input/output

31.
#microad_CAMPHOR
第２フェーズ：モデル作成をKubeflowに置き換え
31
ml models ＆
training data
Modeling ＆ Traning
GCP On-Premise
始めはSingleNodeから始
めて、HAへシフト
TF-Serving 中継App
各種システム
NFS
modelのexport
HDFS
各種システム
各種システム
バッチ処理でETL＆
GCSに
inputo/output
RancherでGKE 及びKubeflowを管理。
JupterHubで実験してモデルが実装出来た
ら、Kubeflow Pipelineでパイプラインを作成

32.
#microad_CAMPHOR
第３フェーズ：ServingをRKEでKubernetes化
32
ml models ＆
training data
Modeling ＆ Traning
GCP On-Premise
RKEでオンプレ上に
Kubernetesクラスタ構築
TF-Serving 中継App
各種システム
NFS
modelのexport
HDFS
各種システム
各種システム
バッチ処理でETL＆
GCSに
inputo/output
TF-Serving
TF-Serving
中継App
中継App

33.
進捗どうですか？
33
まさか…

34.
#microad_CAMPHOR
進捗ダメでーす
34
ml models ＆
training data
Modeling ＆ Traning
GCP On-Premise
TF-Serving 中継App
各種システム
NFS
modelのexport
HDFS
各種システム
各種システム
バッチ処理でETL＆
GCSに
inputo/output
Rancher使わずにArgoCDを
使ってGitOps的にデプロイ
出来るよう対応中。
絶賛 構築中。Cloud VPNで内部IP経由ではGKEと
まともに通信出来ず。
Private Clusterでの対応検討中。

35.
まとめ
35

36.
#microad_CAMPHOR
まとめ
データ基盤
● Hadoopエコシステムを活用し、
ETL処理はDigdag＆Dockerを使って運用コストを下げる工夫を行っている
ML基盤
● Rancherを活用してGCPとオンプレのKubernetesクラスターを管理し、
kubeflowを用いたML基盤へ行く為に、段階を踏んで進めている
大事なのは、何が本当の課題かを見極めて、解決策を取る事
36

37.
#microad_CAMPHOR
今回のお話以外にも…
今回の話以外にも、もっとオンプレ特有なネットワークエンジニアリングによっ
た事もやっています。
ホワイトボックススイッチとCumulus Linuxを使った話 - MicroAd Developers
Blog
その他にも、BGPとかAS取得しているとか、ディープなネットワークの世界も。
（私は詳しくないですが…）
37

38.
Appendix
38

39.
#microad_CAMPHOR
参考情報
● ML基盤への取り組みについて
○ Rancher Day 2019での発表がベースになってます
■ スライド： オンプレ×Google Cloud PlatformなML基盤におけるRancherの活用
■ 動画は crash.academy にて公開予定らしいです
● データ基盤の話
○ MicroAdのデータ基盤 - MicroAd Developers Blog
○ Digdagを使ったジョブ管理 - MicroAd Developers Blog
○ オンプレでPrivate Registry使ったDockerイメージの運用について
○ カラムナフォーマットのきほん 〜データウェアハウスを支える技術〜 - Retty Tech Blog
● Kafka
○ Apache Kafkaの概要とアーキテクチャ - Qiita
○ O'Reilly Kafka
○ Apache Kafka 分散メッセージングシステムの構築と活用
○
● その他のオンプレな話
○ ホワイトボックススイッチとCumulus Linuxを使った話 - MicroAd Developers Blog
39

40.
#microad_CAMPHOR
参考情報
● Hadoop
○ YARN
■ Apache Hadoop YARNとマルチテナントにおけるリソース管理 （フェアスケジューラの話）
○ Impala
■ Apache Impalaパフォーマンスチューニング #dbts2018
■ Faster Performance for Selective Queries - Cloudera Blog
■ The Impala Cookbook
■ Hue 4.4 and its improvements are out! | Hue, the self service open source Analytics Workbench
for browsing, querying and visualizing data interactively
■ Impala SQL クエリのトラブルシューティングのセルフサービス | Hue - Hadoop User Experience - The
Apache Hadoop UI
○ 各コンポーネント（ロール）の配置について
■ Cloudera EDHクラスタをデプロイするベストプラクティス：パート1 「インフラストラクチャの検討」
■ Cloudera EDHクラスタをデプロイするベストプラクティス：パート2 「サービス、ロールのレイアウ
ト」
■ Cloudera EDHクラスタをデプロイするベストプラクティス：パート3 「クラウドに関する検討事項」
40

41.
#microad_CAMPHOR
参考情報
● Rancher
○ Rancher Labs
○ rancher/rke: Rancher Kubernetes Engine, an extremely simple, lightning fast Kubernetes installer that
works everywhere.
○ RancherによるKubernetes活用完全ガイド
● GitOps（ArgoCD）
○ RancherとGitOps的な話
● コミュニティ
○ Rancher JP - connpass
○ Cloud Native JP - connpass
41

42.
QA用
42

43.
#microad_CAMPHOR
バッチで使うコンテナのオーケストレータ
43
使ってないです。
ホストOSにDockerとdocker-composeを入れて後、Systemdを使ってコンテナを
起動しています。
Digdag Server自身もDockerで動いていて、ジョブの実行は、Digdag Serverコ
ンテナ内でDockerを起動してジョブを実行しています。
詳しくは、 以下の記事を参考に
Systemdとdocker-composeでカジュアルにdockerを運用する - Qiita