[CWT2017]Infrastructure as Codeを活用したF.O.Xのクラウドビッグデータ環境の変化
Download as PPTX, PDF1 like4,250 views
Cloudera World Tokyo 2017の登壇資料 http://www.clouderaworldtokyo.com/ ○ 概要 ForceOperationX(F.O.X)は、国内で初めてスマホアプリ向け広告効果計測を実現するサービスとして提供し、国内導入シェアNo.1まで成長しました。オンプレミス環境から、ビッグデータ(Hadoop)環境のクラウド移行を行い、Clouderaを利用したinfrastructure as code(IaC)な環境にし、以下の変化が起きました。 * 開発体制: IaCでシステムに対して柔軟な開発体制が選択できスケーラブル * アーキテクチャ: ビジネス要件の変化に強く、本番と同等環境でHadoop検証が可能 * データ共有: 複数クラスタ間のデータ共有が容易となりデータ活用性向上 * 運用オペレーション: BlueGreenDeploymentで安全なHadoopアップグレード。IaCで新クラスタサービスインが、オンプレミス環境と比較すると数日->数十分で実現 これらについて紹介します。
[CWT2017]Infrastructure as Codeを活用したF.O.Xのクラウドビッグデータ環境の変化
- 2. 自己紹介 茂木 高宏(もてき たかひろ) サイバーエージェント グループ 株式会社 CyberZ F.O.X 事業 SRE Engineer Twitter: @tkmoteki 2014年サイバーエージェント入社。株式会社CyberZで F.O.X事業部インフラ全体の仕事をやりつつ、ビッグデータ関連の設計/構築/開発/運用 を担当。事業部所属全エンジニアのインフラ/クラウド系技術の育成も担当。
- 3. 本セッションについて ● 前提知識 ○ パブリッククラウド(AWS)の基礎知識 ○ Hadoopの基礎知識 ● 対象聴講者 ○ 全体 Hadoopクラスタ設計者/運用者 ○ 後半 クラウドビッグデータ環境/Hadoop利用者 一歩進んだ事例を紹介
- 4. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 5. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 7. F.O.X位置づけ メディア連携数 1,300 計測端末数 1.2億台 導入アプリ数 6,500 F.O.X サ ーバ メディア App Store スマホ 2. リダイレクト 1. 広告click 3. Install 4. 初回起動 5. 広告成果を連絡
- 8. F.O.X連携メディア Facebook Mobile Measurement Partner Twitter Official Partner App Attribution Partner
- 9. F.O.Xビッグデータ環境利用形態 データ収集 9 最大30万RPS 処理(ETL/集計/保存) 分析/可視化 計測サーバ 休眠・復旧分析 アクション(イベント)分析 KPI分析 国別分析 ユーザー分析売上分析 プラットフォーム 総UU: 15億~ DAU: 7億~ query: 200/day(batch) ストレージ total data : 750TB total cpu : 960core total memory:7320GB RDB 弊社 分析アプリケーション
- 10. F.O.Xビッグデータ環境の移行 パブリッククラウド AWSへ移行 オンプレミス環境 ● 2017年6月に移行完了 ● ETL/定常集計のメインクラスタへClouderaエンタープライズ を導入 ● ビッグデータ(Hadoop)環境をクラウド移行とInfrastructure as Codeを導入し様々な変化/課題解決 ○ 移行に関してはCloudera E-Sessionsで登壇 ( https://jp.cloudera.com/more/news-and-blogs/e-japan-series.html )
- 11. 弊社のHadoopユーザとして立ち位置 ● 弊社はWeb事業会社 ● Webエンジニアが、ビッグデータ(Hadoop)環境を利用した開 発や運用管理を行う(専任はいない) ● オンプレミス環境から数年Hadoop運用実績あり(初心者では ない) ● HadoopのOSSコミュニティ貢献はほぼない(上級者ではない) ● 中間層的なHadoopユーザ
- 12. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 13. Infrastructure as Code(IaC)とは? 13 ソフトウェア開発のプラクティスをインフラのプロビジョニン グ等の自動化に活かすアプローチ ● 一般的に可能な事(例) ○ 使い捨て可能、再現可能な基盤環境(ペットと家畜) ○ 統一的な基盤環境 ○ 変更に対してスケーラブルな基盤環境 ○ …
- 15. VCSコミット ビルド (サーバパッケージ) デプロイ(Hadoop環 境動的作成) Hadoop環境動的破 棄/入替え ダイナミックなインフラ プラットフォーム 動的アップデート 継続的インテグレーション Image 環境・運用補完 Hadoop IaC ライフサイクル/ツール(クラウド環境) Cloudera Manager Cloudera Director (CDH) ジョブスケジューラ デプロイシステム Cloudera Director 定義(コード)
- 16. Hadoop IaCサポート Cloudera Director Cloudera Altus Amazon EMR
- 17. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 18. Cloudera Directorとは?(1) 異なる GUI, 設定, API 同じ GUI, 設定, API Cloudera Director 複数GUI AWSアカウントA /クラスタA AWSアカウントA different region/クラスタC 単一のGUI Cloudera Director AWSアカウントA /クラスタA AWSアカウントA different region/クラスタC ● CDH,Cloudera Manager(CM)をクラウド環境で、迅速にプロビジョニングするアプリケーシ ョン ● 複数のパブリッククラウドへ統一インタフェースで横断的にプロビジョニング可能 ○ 統一インタフェース: IaCサポート GUI / configファイル, API ● CDH, CMのライフサイクル管理(Persistent / Transient Cluster)、状態を統合的に把握可能
- 19. Cloudera Directorとは?(2) 19 項目/使い方 Cloudera Director Server Cloudera Director Client Cloudera Director Server + Clinet API 用途 テスト環境向け テスト環境向け 本番環境向け 特殊用途 プロビジョニング GUI CLI • HOCONベースの config CLI + GUI • HOCONベースの config • GUIへ状態投入 - 対象 • 新規CM + 新規 CDH • 新規CM + 新規CDH • (既存CM) + 新規 CDH • 新規CM + 新規CDH • (既存CM) + 新規 CDH - オペレーション GUI CLI GUI - 高度な設定 ☓ ○ ○ -
- 20. Cloudera Directorとは?(3) Other Region Tokyo Region Tokyo Region Tokyo Region Tokyo Region Cloudera Director Server Cloudera Director Server へ状態投入 プロビジョニング Cloudera Director Client Y Cloudera Director Client Z Transient Cluster Z-1 Transient Cluster X Cloudera Manager Z AWS account X Cloudera Manager Y 既存Cloudera Managerへ紐付け AWS account YAWS account AWS account Z AWS account Z Cloudera Manager X Persistent Cluster Y
- 21. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 22. Hadoop利用した開発体制の課題: オンプレミス環境(過去) developers X team developers Y team 全社共通の infra team性能問題/ ノード増設依頼 状況 Hadoop設定変更/反映 障害対応 依頼確認作業 インフラチーム -> 開発チームへ Hadoop構成変更 確認作業 開発チーム -> インフラチームへ 障害対応 課題 ● 開発チームからは環境がブラックボックス ● 連携に支障があり、障害対応にロス ● 新規開発のスピードが出ない
- 23. Hadoop利用した開発体制の課題解決: クラウド環境(現在) developers X team developers Y team ファシリテータ 性能問題/ ノード増設 Hadoop設定変更/反映 障害対応 相談+α 開発チーム -> ファシリテータ 開発チーム 状況 課題解決 ● IaCでブラックボックス解消 ○ IaCは開発エンジニアが積極的でインフラレイヤ ーまでレビュー可能 ○ インフラ増設が開発エンジニア自身で可能 ● 連携/障害対応のロス削減し、新規開発スピードアップ
- 24. Hadoop利用した開発体制の変化 マイクロサービス増減 マイクロサービスが チーム移動(体制移管) 環境増減 (prd/stg/dev..) システム増強 クラウド アカウント増減/移行 チーム体制に対してビッグデータ環境がスケーラブル ビッグデータ環境に対してチーム体制がスケーラブル ● IaCだと柔軟に開発体制の選択が可能 ○ 例) 担当チーム変更のためアカウント移行 ○ Cloudera Director configファイルを数行変更してプロビジョニング -> 既存 環境破棄 ビジネスのグロース
- 25. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 26. データ利用の課題: オンプレミス環境(過去) ● データをクラスタごとのlocal diskへ保持 ○ HDFS(hdfs://)を使用 ● データ共有が煩瑣 ○ 別物理環境、別Hadoopディストリーシューション、別データストア間でのデ ータ共有 ● ラック/ネットワーク周りの物理環境まで考えると、HDFSは運用負荷高い ● サーバに状態(不揮発性のデータ)を持つため、動的に環境を置き換えるIaCが不可 状況 課題
- 27. データ利用の課題解決: クラウド環境(現在) ● データをオブジェクトストレージへ保存 ○ 計算機リソースとデータストレージを切り離す ○ サーバに状態を持たないため、動的に環境を置き換えるIaCに柔軟に対応 ● HDFS(s3a://, s3://)を使用 ● データ活用性が向上 ○ S3 locationを指定してデータアクセス ○ 別クラウド(アカウント)環境、別Hadoopディストリーシューション、別デー タストア間のデータ共有が容易 状況 課題解決
- 28. データ利用の変化: マルチディストリービューションのデータ共有 ● オブジェクトストレージ利用で簡単にデータ 共有 ● AWS+CDHのマルチディストリービューショ ンを導入 ● AWSマネージドサービスからもデータ共有 ○ CDH Hive on S3でwrite、EMR presto on S3でread ○ EMR Hive on S3でwrite、CDH Impala on S3で read ○ CDH Impala on S3でwrite、Athenaでread ● マルチディストリービューション&AWSマネージドサービス間でHiveMetaStore が共有できず課題(CDH Hive on S3とEMR Hive on S3, CDH Hive on S3とAWS Athena時) Amazon S3 Amazon EMR Amazon EMR Amazon Athena
- 29. データ利用の変化: オブジェクトストレージS3使用時の性能関係 ● エコシステムの選択性重視でストレージフォーマットParquet採用 ● S3のプロトコル(CDH -> s3a://, EMR,Athena -> s3://) ○ CDHでs3n://等使うと性能劣化 ● partition増で性能劣化の対応 ○ 例) 大量のpartitionもつテーブルのreadするクエリ / 大量のpartitionまたがってwrite するクエリ / リペアテーブル ○ S3のLIST処理がネック ○ partition数を削減 ● write heavyなクエリの性能劣化の対応(例: Hive on S3) ○ CDH5.9以前からhive on s3可能だが性能劣化し本番導入出来なかった ○ CDH5.9, 5.10, 5.11で改善しCDH5.10から本格的に本番導入出来た ○ S3 table write時にHiveのtemporaryデータ(scratchdir)を一時EBS(hdfs)へ書きその後 S3へ書戻し(hive.blobstore.use.blobstore.as.scratchdir=false) ○ S3 write処理のパラレル化(hive.mv.files.thread, hive.mv.file.threads) ○ S3Aコネクタチューニング(fs.s3a.threads.core, fs.s3a.threads.max, fs.s3a.max.total.tasks, fs.s3a.connection.maximum)
- 30. データ利用の変化: データの保持方法 ● Rawデータとparquet変換済 データでS3バケットを分離 ● parquet変換済データ(S3バ ケット)は作成したHadoop クラスタごと1:1の関係性 Amazon S3 データストア Amazon S3 rawデータ ETL Amazon Athena 分析データ アクセス ● マルチディストリービューション&AWSマネージドサービス間でS3のコン システンシー関連で課題(CDH Hive on S3でwriteしてAWS Athenaでread時) tsv Parquet 中間データ
- 31. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 32. ● リソース管理(YARN)の負荷 ○ 新チーム/新プロジェクト相乗りでキャパシティ再見積もり(既存処理を考慮) ○ 各種Metastore等の負荷 ● 本番想定のテストが出来ない ● 新規Hadoopクラスタのサービスインが数日… アーキテクチャの課題: オンプレミス環境(過去) 結果、属人化 ● Hadoopクラスタを複数の開発チーム/プロジェクトで相乗り使用 ○ リソース管理(YARN) ● 本番環境と同等のテスト環境がない 状況 課題
- 33. アーキテクチャの課題解決: クラウド環境(現在) ● 複数の開発チーム/プロジェクトで相乗りしないマイクロHadoopクラスタ設計(リ ソース管理撤廃) ○ チーム別/目的別で分け ● コードベース定義を使用、本番Hadoopクラスタと同等の検証環境を動的生成(IaC) ● Hadoopクラスタテンプレートを用意、新規マイクロHadoopクラスタを迅速にサ ービスイン(IaC) ● リソース管理の負荷削減 ● 検証環境を使用し、ライトユーザが安全にテスト可能(本番データ複製) ● 新規Hadoopクラスタのサービスインが数日 -> 数十分 状況 課題解決
- 34. アーキテクチャの変化: マイクロHadoopクラスタ構成 S3(生成中間データ)S3(rawデータ) Amazon RDS (集計データ) ~調査/分析~ 集計アプリ ~ETL/集計クラスタ~ ~集計クラスタ~ Amazon RDS(metadata) 他分析アプリ developers X developers Y Amazon RDS (集計データ) 集計アプリ developers A Amazon RDS(metadata)
- 35. アーキテクチャの変化: 本番Hadoopクラスタと同等環境の実現 Cloudera Director 同一 configファイル 本番環境用 環境変数 テスト環境 本番環境 テスト用環境 変数 ● コードベース定義を使用し本番Hadoopクラスタと同等の検証Hadoopクラスタを動的生成 ● Cloudera Director confファイルを最大限活用 ○ 目的別に分解/階層分け、各種parameterを環境変数で分離 ○ 統一的なHadoop環境の実現
- 36. 36 アーキテクチャの変化: Hadoopクラスタのバージョニング ClouderaManager ClouderaDirector GIthub ● Githubを正としてプロビジョニングした環境にversionを定義 ○ 特定のversionをロールバック可能 ○ 環境の再現性が可能なHadoop環境を実現
- 37. アーキテクチャの変化: Hadoopクラスタテンプレート github ● Hadoopクラスタテンプレートを用意して、新規マイクロHadoopクラスタを迅速(数十分)に サービスイン(IaC) ○ 反復可能なHadoop環境を実現 ○ 使い捨て可能なHadoop環境を実現
- 38. F.O.X概要/クラウド移 行1 Infrastructure as Code とCloudera Director２ 開発体制の課題解決と変化 データ共有の課題解決と変化４ アーキテクチャの課題解決と 変化５ 運用管理の課題解決と変化６ F.O.Xの課題解決と変化 What? 3 アジェンダ
- 39. 運用管理の課題: オンプレミス環境(過去) ● 運用オペレーションほぼ手動 ○ クラスタverision update、ノード増設 ○ サーバ内部の構成管理を行い、サーバ外部の構成管理は行っていない ● 追加設定は既存環境へ上乗せ ● 安全かつ効率なクラスタ運用オペレーションが出来てない ○ 物理マシンがあってもノード増設に数日…(レガシーな環境) ● 追加設定を既存環境へ上乗せるため、設定依存問題 状況 課題
- 40. 運用管理の課題解決: クラウド環境(現在) ● IaC管理の環境 + 運用オペレーションをコード化 ○ サーバ内部&サーバ外部を構成化 ○ クラスタのノード増設を簡略化 ○ クラスタupdateをHadoopクラスタ Blue Green Deploymentへ ● IaCでクラスタのノード増設が数日 -> 数十分で実現 ● Hadoop環境を動的に入れ替えるため、設定依存問題が発生しない 状況 課題解決
- 41. Cloudera Director configファイル 本番環境 環境変数定義 独自tool オペレーション configファイル 運用管理の変化: 運用オペレーションのコード化 ● 運用オペレーション コード化のため独自ツール(ztool)を開発 ○ Hadoop以外の各種クラウドコンポーネントと結合 ○ Cloudera Managerを使用したラッパー(Hadoop config動的投入) ○ 構成を司るCloudera Directorとシームレスに連携
- 42. Hadoop Cluster Update Hadoop Cluster Blue Green Deployment Hadoop Cluster Distributed Clone Hadoop Cluster Migration Hadoop Cluster Orchestration Hadoop Cluster Auto-Scaling Hadoop Cluster Auto-Healing Hadoop Event-Driven Cluster 運用管理の変化: 運用オペレーションの例
- 43. Hadoop Cluster Update Hadoop Cluster Blue Green Deployment Hadoop Cluster Distributed Clone Hadoop Cluster Migration Hadoop Cluster Orchestration Hadoop Cluster Auto-Scaling Hadoop Cluster Auto-Healing Hadoop Event-Driven Cluster 運用管理の変化: 運用オペレーションの例
- 44. 44 運用管理の変化: Hadoop Cluster Update 概要 Hadoop Clusterへノード増減する オペレーション ユースケース 性能スケール… ボタンポチポ チで20台増設,
- 45. 概要 Hadoop Clusterを入れ替えるオペレーション ユースケース CDH version up, Hadoop Cluster側の構成設定変更, OSレイヤの各種パッチ適用 運用管理の変化: Hadoop Cluster Blue Green Deployment ELB(proxy) S3 RDS (metadata) Cloudera Director Client parameter 集計/分析 アプリ SET A(Blue) running SET A(Green) wait Blue Green DeployMent ③ create switch already exists Cloudera Director config file ~Production環境~ ① 投入 ② submit
- 46. 概要 雛形なHadoop Clusterを複製する ユースケース それぞれのチームの開発者レベルでCleanで競 合しないHadoop Cluster環境を用意 運用管理の変化: Hadoop Cluster Distributed Clone S3 RDS (metadata) Cloudera Director Client parameter 集計/分析アプリ ③ create Cloudera Director config file ~テスト環境~ Hadoopクラスタ の雛形 HadoopクラスタA Hadoop クラスタ B ③ create 集計/分析アプリCloneClone User A User B ① 投入 ② submit User B User A S3 location: identity-id/ RDS schema: identity_id
- 47. 運用管理の変化: クラウドでのCloudera Managerのメリット ● エコシステム/ジョブの可視性 ○ ジョブの実行時間が伸びていないか?、エコシステムの状態はどうか? ● エコシステム運用オペレーション ○ クラウド特有の動的ノード追従(activeノードの位置まで追従) ○ ゴシッププロトコル不要 ● 監視系 ○ ノード単体よりも全体の傾向把握(クラウドだと要求高い) ● ログ検索 ○ 検索性(EMRのようなオブジェクトストレージ内のログを手動検索だと負荷高い) ● 日本語マニュアル ○ 運用時でのHadoopエコシステムのパラメータ変更、日本語で読める
- 48. 運用管理の変化 発展Tips: Hadoopクラスタの継続的インテグレーション ● CI(ジョブスケジューラとデプロイシステム)の選択肢 ○ Transientクラスタにすると開発ジョブ(バッチプログラム)との親和性が高い ○ 開発ジョブ実行前にTransientクラスタ起動 ○ Transientクラスタ起動ジョブを別に分け、ジョブスケジューラで管理 ● Cluster CI ○ IaCのインテグレーション ○ 開発ジョブ(バッチプログラム)のインテグレーションと連携 ● Data CI ○ ETLやジョブ開発、性能検証目的で使用 ○ データセットを本番環境から複製 ○ ライトユーザが安全/簡単に使える状態をCI ● Node CI ○ 金額的なマネジメントでノードをプランニングするCI
- 49. まとめ Infrastructure as Codeを活用したF.O.Xのクラウドビッグデータ 環境の変化について紹介 ○ 開発体制: IaCでシステムに対して柔軟な開発体制が選択できスケーラブル ○ アーキテクチャ: IaCでビジネス要件の変化に強く、本番と同等環境で Hadoop検証が可能 ○ データ共有: 複数クラスタ間のデータ共有が容易となりデータ活用性向上 ○ 運用オペレーション: IaCでオペレーションが、オンプレミス環境と比 較すると数日->数十分で安全に実現