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.

Hadoopデータ基盤とMulti-CloudなML基盤への取り組みの紹介

560 views

Published on

「Hadoopデータ基盤とMulti-CloudなML基盤への取り組みの紹介」
2019/10/05 【マイクロアド】〜ネット広告を支える技術を知る〜 #microad_CAMPHOR
https://camphor.connpass.com/event/146724/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Hadoopデータ基盤とMulti-CloudなML基盤への取り組みの紹介

  1. 1. Hadoopデータ基盤と Multi-CloudなML基盤への 取り組みの紹介 2019/10/05 【マイクロアド】〜ネット広告を支える技術を知る〜 #microad_CAMPHOR MicroAd, Inc. システム開発本部 基盤技術開発グループ インフラチーム 永富安和
  2. 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. データ基盤について 3
  4. 4. #microad_CAMPHOR データ基盤運用する上での課題 4 大量のストリームデータ(約6TB/day)のETL処理を滞りなく実行し、 利用可能なデータとして提供出来るようにする 1. ストリームデータを欠損無く処理して確実にSink出来る事 2. ETL処理の運用コストを如何に最小にするか 3. 蓄積したたデータが利用可能な状態でなければならい
  5. 5. #microad_CAMPHOR データ基盤運用する上での課題 その1 5 大量のストリームデータ(約6TB/day)のETL処理を滞りなく実行し、 利用可能なデータとして提供出来るようにする 1. ストリームデータを欠損無く処理して確実にSink出来る事 ➢ FluentdでログをKafkaに流し、Flumeを使ってHDFSへSinkする ➢ 複雑なETLが必要な場合は、Spark Streaming を用いて対応 ➢ Kafkaを用いる事でログをキューイング出来るので Consumer先(Sink先)に障害があっても途中からやり直しが効く 2. ETL処理の運用コストを如何に最小にするか 3. 蓄積したたデータが利用可能な状態でなければならい
  6. 6. #microad_CAMPHOR Cloudera Manager ログ転送 データ基盤の概要 6 広告配信サーバ等 各種サーバ : Topic Topic : Topic Topic : Topic Topic : 管理・監視
  7. 7. #microad_CAMPHOR その他のKafkaを使った工夫 ● パーティション数の増加にスケールの限界がある為、 ひとつの大きなクラスタでは無く複数の中規模クラスタを用途に合わせて複 数使う戦略を取った。 7
  8. 8. #microad_CAMPHOR その他のKafkaを使った工夫(トピック運用) 基本的に時系列データはYYYYMMDDのプレフィックスをつけた ● データの再ロードの粒度を日付単位にできる ● 日別にTopicを使い捨てる事でPartition数の変更等の運用が不要 ● Partition数の変更にはPartitionリアサインが必要だが オンラインでやるとデータがロストしたりするのを回避したかった ● YYYYMMDDであれば毎日作りかえる形となるので、 Partition数の増減が作り変えのタイミングで変更できる ● データの制約により時系列にできないトピックでも、上記の理由と同様に v1などのバージョニングをおこなう ● 時系列なTopicの作成はDigdagバッチで実行している ● 毎日3日先の日付のtopicを作成している →土曜にジョブかコケても即日対応しなくてもよいように 8
  9. 9. #microad_CAMPHOR データ基盤運用する上での課題 その2 9 大量のストリームデータ(約6TB/day)のETL処理を滞りなく実行し、 利用可能なデータとして提供出来るようにする 1. ストリームデータを欠損無く処理して確実にSink出来る事 2. ETL処理の運用コストを如何に最小にするか ➢ Digdagを用いる事で、バッチが定義しやすく、UIがあるので状況が確認 出来て、リトライも楽に出来る(とは言え数が多くなると辛いみも) ➢ Digdagやバッチ処理自体は、Dockerを用いてバッチサーバのリソース に影響しない作りにした ➢ ジョブやバッチ間の依存は、DigdagのS3_waitオペレータを使うこと で、S3にファイルをフラグの代わりにして依存を解決した 3. 蓄積したたデータが利用可能な状態でなければならい
  10. 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. 11. #microad_CAMPHOR データ基盤運用する上での課題 その3 11 大量のストリームデータ(約6TB/day)のETL処理を滞りなく実行し、 利用可能なデータとして提供出来るようにする 1. ストリームデータを欠損無く処理して確実にSink出来る事 2. ETL処理の運用コストを如何に最小にするか 3. 蓄積したたデータが利用可能な状態でなければならい ➢ 1テーブルのサイズがデカイので、列指向フォーマットで必要な列のみ 取り出せるように(ORCやParquetの利用) ➢ Hiveだけでなく、ユースケースに応じてImpalaも活用
  12. 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. 13. #microad_CAMPHOR 何故HiveとImpalaを使い分けるのか? クエリ実行時間だけでは、HiveよりもImpalaが圧倒的に有利。 理由は、HiveはMapReduceジョブとしてクエリ実行時に動いているので (Sparkに変更も可能。TezとかLLAP)どうしても遅くなる。 分析用HadoopクラスタではHive→Impalaに変えただけで、 クエリ実行時間が 36倍速くなった(約30分→約50秒弱)。 ただし、Impalaの特性上、リソース確保出来ない場合はすぐにエラーとなるので バッチ処理には扱いにくく、Hiveはコケにくい。 なので、以下のように使い分けるのもあり。  バッチ用途→Hive  分析などのアドホックなクエリ実行→Impala 13
  14. 14. #microad_CAMPHOR その他にも… ● 利用頻度の高いデータをSSDのあるDataNodeに入れて、 頻度の低くなったものをHDDのDataNodeに移動するなどの調整 ● バッチと分析のジョブがリソース喰い合いになってバッチをコケさせないよ うにする為に、YARNの実行をフェアスケジューラを使って制御 ○ さらに、Impalaのリソースの配分をアドミッションコントロールで制御なども可能 (Impalaの利用がこれからなので特にまだこれはやってない) 14
  15. 15. その他の工夫 15
  16. 16. #microad_CAMPHOR 16 HDFSで使っているタイプのH/W紹介 Hadoopクラスタには、以下のようなマルチノードクラスタを用いて 1ラックあたりの集積度を上げて効率化しています。
  17. 17. ML基盤について 17
  18. 18. #microad_CAMPHOR 状況説明(機械学習をとりまく環境) ● ML基盤などは無い ● Tensorflow(Keras)の利用が進んでいる ● 機械学習モデルの作成から利用までALLオンプレ環境 ※扱うデータは数十PBもある ● 入札アルゴリズムやアドフラウド対策などで 機械学習が期待されていて日々研究している ● (機械学習だけじゃないが)BigQueryを分析用で 割と使っていて今後も拡大路線 18
  19. 19. #microad_CAMPHOR 課題 1. 実験用環境の調達に対してリードタイムが長い ○ オンプレあるある。余剰が常にあるとは限らない。 2. ミドルウェアを気軽に変更して試したい ○ Jupyter NotebookのKernelを好きなように変えたいとか、TFのVer.等。 3. 学習モデルのデリバリーのフローが確立していない (案件単位でバラバラ) ○ 毎日新しいデータで学習モデルを更新して、本番へ投入したい 4. 新しいモデルを本番でお試しするのが難しい ○ 3により、リリースするにも関係部署との調整が大変 19 特にコレ!
  20. 20. #microad_CAMPHOR 解決への算段 & 野望 ● 気軽に試せてスケールアウトも可能な環境としクラウド(GCP)を活用 ○ Kubernetes使うならGKEならまだ敷居は低いはず ○ 別途BigQueryの利用が広がっているのでクラウドはGCPでOK ● TensorFlow Servingが、Servingした学習モデルに対して、 Multi Model& Multi Version扱えるので、お試し利用しやすい環境を 整えやすい(はず) ● Kubeflow pipelineでデリバリまでのフローを確立する(はず) 更に、、、 これを皮切りに、コンテナ化が進んでいる他のシステムのKubernetes移行も 進めていきたい(docker-compose運用では厳しくなってきた) 20
  21. 21. なぜ Rancher を選んだのか? 21
  22. 22. #microad_CAMPHOR Rancherとは? 22 Rancher Labsが開発するOSSで、Kubernetesクラスタ管理機能を持つ。 オンプレやパブリッククラウド上に構築したKubernetesだけでなく、 パブリッククラウドのマネージドKubernetesなどのクラスタをまとめて管理する 事が可能。 また、RKEというKubernetesクラスタをシンプルに構成出来るToolなども開発。
  23. 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. 24. なぜ Kubeflow を選んだのか? 24
  25. 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. 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. どう取り組んでいるのか? 27
  28. 28. #microad_CAMPHOR 基本方針 ● 最低ラインを確保する ○ 一番解決したい事、何が目的だったかを忘れない ● いつでも辞められるようにする ○ 運用実績が無いものだらけなので最悪戻せる場所は確保 ● 無理をしない・一気に進めない ○ (ちょっとくらいは良いけど)背伸びしないで身の丈にあった速度で進める 28
  29. 29. #microad_CAMPHOR どう取り組んでいくのか? 事前準備 ● オンプレ環境からGCSへ整形&絞ってキレイにしたデータをGCP上に蓄積 ○ GCPで学習モデルを作成出来る用意 ● GCEを使って従来手法で学習モデルを作成 ○ 好きなように実験が可能 ● 作成した学習モデルをGCSへ格納して、オンプレ側から取得して、 従来通りServingして利用する 一番の課題だった「実験環境のリードタイムの短縮」をこれで確保 まずは引き返せる場所を確保した。 29
  30. 30. #microad_CAMPHOR 第1フェーズ: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. 31. #microad_CAMPHOR 第2フェーズ:モデル作成を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. 32. #microad_CAMPHOR 第3フェーズ: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. 進捗どうですか? 33 まさか…
  34. 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. まとめ 35
  36. 36. #microad_CAMPHOR まとめ データ基盤 ● Hadoopエコシステムを活用し、 ETL処理はDigdag&Dockerを使って運用コストを下げる工夫を行っている ML基盤 ● Rancherを活用してGCPとオンプレのKubernetesクラスターを管理し、 kubeflowを用いたML基盤へ行く為に、段階を踏んで進めている 大事なのは、何が本当の課題かを見極めて、解決策を取る事 36
  37. 37. #microad_CAMPHOR 今回のお話以外にも… 今回の話以外にも、もっとオンプレ特有なネットワークエンジニアリングによっ た事もやっています。 ホワイトボックススイッチとCumulus Linuxを使った話 - MicroAd Developers Blog その他にも、BGPとかAS取得しているとか、ディープなネットワークの世界も。 (私は詳しくないですが…) 37
  38. 38. Appendix 38
  39. 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. 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. 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. 42. QA用 42
  43. 43. #microad_CAMPHOR バッチで使うコンテナのオーケストレータ 43 使ってないです。 ホストOSにDockerとdocker-composeを入れて後、Systemdを使ってコンテナを 起動しています。 Digdag Server自身もDockerで動いていて、ジョブの実行は、Digdag Serverコ ンテナ内でDockerを起動してジョブを実行しています。 詳しくは、 以下の記事を参考に Systemdとdocker-composeでカジュアルにdockerを運用する - Qiita

×