[cwt2017]infrastructure as...

Infrastructure as Codeを活用したF.O.Xのクラウドビッグデータ環境の変化

自己紹介

茂木高宏(もてきたかひろ)

サイバーエージェントグループ

株式会社 CyberZ F.O.X 事業

SRE Engineer

Twitter: @tkmoteki

2014年サイバーエージェント入社。株式会社CyberZで

F.O.X事業部インフラ全体の仕事をやりつつ、ビッグデータ関連の設計/構築/開発/運用

を担当。事業部所属全エンジニアのインフラ/クラウド系技術の育成も担当。

本セッションについて

● 前提知識○ パブリッククラウド(AWS)の基礎知識○ Hadoopの基礎知識

● 対象聴講者○ 全体 Hadoopクラスタ設計者/運用者○ 後半クラウドビッグデータ環境/Hadoop利用者

一歩進んだ事例を紹介

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

Force Operation X(F.O.X)概要

レポーティング1

アプリ解析機能2

マーケット分析3

リターゲティング機能4

スマートフォン広告におけるマーケティング統合プラットフォーム

F.O.X位置づけ

メディア連携数

1,300

計測端末数

1.2億台

導入アプリ数

6,500

F.O.X サーバ

メディア

App Store スマホ

2. リダイレクト

1. 広告click

3. Install

4. 初回起動

5. 広告成果を連絡

F.O.X連携メディア

Facebook Mobile

Measurement PartnerTwitter Official

Partner

App Attribution

Partner

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

弊社分析アプリケーション

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 )

弊社のHadoopユーザとして立ち位置

● 弊社はWeb事業会社

● Webエンジニアが、ビッグデータ(Hadoop)環境を利用した開発や運用管理を行う(専任はいない)

● オンプレミス環境から数年Hadoop運用実績あり(初心者ではない)

● HadoopのOSSコミュニティ貢献はほぼない(上級者ではない)

● 中間層的なHadoopユーザ

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

Infrastructure as Code(IaC)とは?

13

ソフトウェア開発のプラクティスをインフラのプロビジョニング等の自動化に活かすアプローチ

● 一般的に可能な事(例)

○ 使い捨て可能、再現可能な基盤環境(ペットと家畜)

○ 統一的な基盤環境

○ 変更に対してスケーラブルな基盤環境○ …

一般的なWebシステムのIaCライフサイクルとツール(例)

VCSコミット ビルド(サーバパッケージ)

デプロイ(インフラ環境動的作成)

インフラ環境動的破棄/入替え

ダイナミックなインフラプラットフォーム

動的アップデート

継続的インテグレーション

Image

AWS

CloudFormation

環境・運用補完

モニタリング /

サービスディカバリ

定義(コード)

VCSコミット ビルド(サーバパッケージ)

デプロイ(Hadoop環境動的作成)

Hadoop環境動的破棄/入替え

ダイナミックなインフラプラットフォーム

動的アップデート

継続的インテグレーション

Image

環境・運用補完

Hadoop IaC

ライフサイクル/ツール(クラウド環境)

Cloudera Manager

Cloudera Director

(CDH)

ジョブスケジューラデプロイシステム

Cloudera Director

定義(コード)

Hadoop IaCサポート

Cloudera Director

Cloudera Altus

Amazon EMR

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

Cloudera Directorとは?(1)

異なるGUI, 設定, API

同じGUI, 設定,

API Cloudera

Director

複数GUI AWSアカウントA

/クラスタA

AWSアカウントA

different region/クラスタC

単一のGUICloudera

Director

AWSアカウントA

/クラスタA

AWSアカウントA

different region/クラスタC

● CDH,Cloudera Manager(CM)をクラウド環境で、迅速にプロビジョニングするアプリケーション

● 複数のパブリッククラウドへ統一インタフェースで横断的にプロビジョニング可能○ 統一インタフェース: IaCサポート GUI / configファイル, API

● CDH, CMのライフサイクル管理(Persistent / Transient Cluster)、状態を統合的に把握可能

Cloudera Directorとは?(2)

19

項目/使い方 Cloudera

Director Server

Cloudera Director

Client

Cloudera Director

Server + ClinetAPI

用途 テスト環境向け テスト環境向け 本番環境向け 特殊用途

プロビジョニング GUI CLI

• HOCONベースのconfig

CLI + GUI

• HOCONベースのconfig

• GUIへ状態投入

-

対象 • 新規CM + 新規CDH

• 新規CM + 新規CDH

• (既存CM) + 新規CDH

• 新規CM + 新規CDH

• (既存CM) + 新規CDH

-

オペレーション GUI CLI GUI -

高度な設定☓ ○ ○ -

Cloudera Directorとは?(3)

Other Region

Tokyo Region

Tokyo RegionTokyo 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 ZAWS account Z

Cloudera Manager X

Persistent Cluster Y

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

Hadoop利用した開発体制の課題:

オンプレミス環境(過去)

developers X

team

developers Y

team

全社共通のinfra team性能問題/

ノード増設依頼

状況

Hadoop設定変更/反映 障害対応

依頼確認作業

インフラチーム -> 開発チームへHadoop構成変更確認作業

開発チーム -> インフラチームへ

障害対応

課題

● 開発チームからは環境がブラックボックス● 連携に支障があり、障害対応にロス● 新規開発のスピードが出ない

Hadoop利用した開発体制の課題解決:

クラウド環境(現在)

developers X

team

developers Y

team

ファシリテータ性能問題/

ノード増設Hadoop設定変更/反映 障害対応

相談+α

開発チーム -> ファシリテータ

開発チーム

状況

課題解決

● IaCでブラックボックス解消○ IaCは開発エンジニアが積極的でインフラレイヤーまでレビュー可能

○ インフラ増設が開発エンジニア自身で可能

● 連携/障害対応のロス削減し、新規開発スピードアップ

Hadoop利用した開発体制の変化

マイクロサービス増減

マイクロサービスがチーム移動(体制移管)

環境増減(prd/stg/dev..)

システム増強

クラウドアカウント増減/移行

チーム体制に対してビッグデータ環境がスケーラブル

ビッグデータ環境に対してチーム体制がスケーラブル

● IaCだと柔軟に開発体制の選択が可能○ 例) 担当チーム変更のためアカウント移行○ Cloudera Director configファイルを数行変更してプロビジョニング -> 既存環境破棄

ビジネスのグロース

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

データ利用の課題:

オンプレミス環境(過去)

● データをクラスタごとのlocal diskへ保持○ HDFS(hdfs://)を使用

● データ共有が煩瑣○ 別物理環境、別Hadoopディストリーシューション、別データストア間でのデータ共有

● ラック/ネットワーク周りの物理環境まで考えると、HDFSは運用負荷高い

● サーバに状態(不揮発性のデータ)を持つため、動的に環境を置き換えるIaCが不可

状況

課題

データ利用の課題解決:

クラウド環境(現在)

● データをオブジェクトストレージへ保存○ 計算機リソースとデータストレージを切り離す○ サーバに状態を持たないため、動的に環境を置き換えるIaCに柔軟に対応

● HDFS(s3a://, s3://)を使用

● データ活用性が向上○ S3 locationを指定してデータアクセス○ 別クラウド(アカウント)環境、別Hadoopディストリーシューション、別データストア間のデータ共有が容易

状況

課題解決

データ利用の変化:

マルチディストリービューションのデータ共有

● オブジェクトストレージ利用で簡単にデータ共有

● 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

データ利用の変化:オブジェクトストレージ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)

データ利用の変化:

データの保持方法

● 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

中間データ

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

● リソース管理(YARN)の負荷○ 新チーム/新プロジェクト相乗りでキャパシティ再見積もり(既存処理を考慮)

○ 各種Metastore等の負荷

● 本番想定のテストが出来ない

● 新規Hadoopクラスタのサービスインが数日…

アーキテクチャの課題:

オンプレミス環境(過去)

結果、属人化

● Hadoopクラスタを複数の開発チーム/プロジェクトで相乗り使用○ リソース管理(YARN)

● 本番環境と同等のテスト環境がない

状況

課題

アーキテクチャの課題解決:

クラウド環境(現在)

● 複数の開発チーム/プロジェクトで相乗りしないマイクロHadoopクラスタ設計(リソース管理撤廃)

○ チーム別/目的別で分け

● コードベース定義を使用、本番Hadoopクラスタと同等の検証環境を動的生成(IaC)

● Hadoopクラスタテンプレートを用意、新規マイクロHadoopクラスタを迅速にサービスイン(IaC)

● リソース管理の負荷削減

● 検証環境を使用し、ライトユーザが安全にテスト可能(本番データ複製)

● 新規Hadoopクラスタのサービスインが数日 -> 数十分

状況

課題解決

アーキテクチャの変化:

マイクロHadoopクラスタ構成

S3(生成中間データ)S3(rawデータ)

Amazon RDS

(集計データ)

~調査/分析~

集計アプリ

~ETL/集計クラスタ~

~集計クラスタ~

Amazon

RDS(metadata)他分析アプリ

developers X

developers Y

Amazon RDS

(集計データ)

集計アプリ

developers A

Amazon

RDS(metadata)

アーキテクチャの変化:

本番Hadoopクラスタと同等環境の実現

Cloudera Director同一configファイル

本番環境用環境変数

テスト環境

本番環境テスト用環境変数

● コードベース定義を使用し本番Hadoopクラスタと同等の検証Hadoopクラスタを動的生成

● Cloudera Director confファイルを最大限活用○ 目的別に分解/階層分け、各種parameterを環境変数で分離○ 統一的なHadoop環境の実現

36

アーキテクチャの変化:

Hadoopクラスタのバージョニング

ClouderaManager

ClouderaDirector

GIthub

● Githubを正としてプロビジョニングした環境にversionを定義○ 特定のversionをロールバック可能○ 環境の再現性が可能なHadoop環境を実現

アーキテクチャの変化:

Hadoopクラスタテンプレート

github

● Hadoopクラスタテンプレートを用意して、新規マイクロHadoopクラスタを迅速(数十分)にサービスイン(IaC)

○ 反復可能なHadoop環境を実現○ 使い捨て可能なHadoop環境を実現

F.O.X概要/クラウド移行1

Infrastructure as Code

とCloudera Director２

開発体制の課題解決と変化

データ共有の課題解決と変化４

アーキテクチャの課題解決と変化５

運用管理の課題解決と変化６

F.O.Xの課題解決と変化

What?

3

アジェンダ

運用管理の課題:

オンプレミス環境(過去)

● 運用オペレーションほぼ手動○ クラスタverision update、ノード増設○ サーバ内部の構成管理を行い、サーバ外部の構成管理は行っていない

● 追加設定は既存環境へ上乗せ

● 安全かつ効率なクラスタ運用オペレーションが出来てない○ 物理マシンがあってもノード増設に数日…(レガシーな環境)

● 追加設定を既存環境へ上乗せるため、設定依存問題

状況

課題

運用管理の課題解決:

クラウド環境(現在)

● IaC管理の環境 + 運用オペレーションをコード化○ サーバ内部&サーバ外部を構成化○ クラスタのノード増設を簡略化○ クラスタupdateをHadoopクラスタ Blue Green Deploymentへ

● IaCでクラスタのノード増設が数日 -> 数十分で実現

● Hadoop環境を動的に入れ替えるため、設定依存問題が発生しない

状況

課題解決

Cloudera Director

configファイル

本番環境

環境変数定義

独自tool

オペレーションconfigファイル

運用管理の変化:

運用オペレーションのコード化

● 運用オペレーションコード化のため独自ツール(ztool)を開発

○ Hadoop以外の各種クラウドコンポーネントと結合○ Cloudera Managerを使用したラッパー(Hadoop config動的投入)

○ 構成を司るCloudera Directorとシームレスに連携

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

運用管理の変化:

運用オペレーションの例

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

運用管理の変化:

Hadoop Cluster Update

概要

Hadoop Clusterへノード増減する

オペレーション

ユースケース

性能スケール…

ボタンポチポチで20台増設,

概要

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

概要

雛形なHadoop Clusterを複製する

ユースケース

それぞれのチームの開発者レベルでCleanで競

合しないHadoop Cluster環境を用意

運用管理の変化:

Hadoop Cluster Distributed Clone

S3RDS

(metadata)Cloudera Director

Client

parameter

集計/分析アプリ

③ create

Cloudera Director

config file

~テスト環境~

Hadoopクラスタの雛形

HadoopクラスタA Hadoop

クラスタB

③ create

集計/分析アプリCloneClone

User A User B

①投入

② submit

User BUser A

S3 location: identity-id/

RDS schema: identity_id

運用管理の変化:

クラウドでのCloudera Managerのメリット

● エコシステム/ジョブの可視性○ ジョブの実行時間が伸びていないか?、エコシステムの状態はどうか?

● エコシステム運用オペレーション○ クラウド特有の動的ノード追従(activeノードの位置まで追従)

○ ゴシッププロトコル不要

● 監視系○ ノード単体よりも全体の傾向把握(クラウドだと要求高い)

● ログ検索○ 検索性(EMRのようなオブジェクトストレージ内のログを手動検索だと負荷高い)

● 日本語マニュアル○ 運用時でのHadoopエコシステムのパラメータ変更、日本語で読める

運用管理の変化発展Tips:

Hadoopクラスタの継続的インテグレーション

● CI(ジョブスケジューラとデプロイシステム)の選択肢○ Transientクラスタにすると開発ジョブ(バッチプログラム)との親和性が高い○ 開発ジョブ実行前にTransientクラスタ起動○ Transientクラスタ起動ジョブを別に分け、ジョブスケジューラで管理

● Cluster CI○ IaCのインテグレーション○ 開発ジョブ(バッチプログラム)のインテグレーションと連携

● Data CI○ ETLやジョブ開発、性能検証目的で使用○ データセットを本番環境から複製○ ライトユーザが安全/簡単に使える状態をCI

● Node CI○ 金額的なマネジメントでノードをプランニングするCI

まとめ

Infrastructure as Codeを活用したF.O.Xのクラウドビッグデータ環境の変化について紹介

○ 開発体制: IaCでシステムに対して柔軟な開発体制が選択できスケーラブル

○ アーキテクチャ: IaCでビジネス要件の変化に強く、本番と同等環境で

Hadoop検証が可能

○ データ共有: 複数クラスタ間のデータ共有が容易となりデータ活用性向上

○ 運用オペレーション: IaCでオペレーションが、オンプレミス環境と比

較すると数日->数十分で安全に実現