Cloudera World Tokyo 2015の発表資料 https://clouderaworld.tokyo/session/

1. niconicoにおける
継続的なデータ活用の
ためのHadoop運用事例
株式会社ドワンゴ
共通基盤開発部
志村 誠

2. 自己紹介
> 志村誠
– 株式会社ドワンゴ
プラットフォーム事業本部 共通基盤開発部
– 2011年に入社以来ずっと，Hadoop基盤の開発，運用，
データ分析を担当

3. 会社紹介

4. 会社概要
> 2014/10にKADOKAWAとdwangoが経営統合
> 2015/10にカドカワに商号変更
> niconico事業はdwango傘下

5. niconicoの基礎データ

6. agenda

7. agenda
> データ活用の方針
> 第1フェーズ
– 課題
– システム
– データ活用
> 第2フェーズ
> 第3フェーズ
> まとめ

8. データ活用の方針

9. 必要な人が誰でも分析できるように
> エンジニアに限らず，データを集計する必要
がある社員は誰でも自分自身が触れるよう
にする
> 分析部署だけで，社内の全部署のニーズを
すべて満たすことは不可能
> 業務で必要な人が，学習して自ら集計でき
るように育てていく

10. サービスを横断した分析の必要性
> niconicoは，動画と生放送を中心として，数
多くのファミリーサービスが存在している
> なにもしなければ，各部署で縦割りの分析
をするしかない
> そこでメインのHadoopクラスタにデータを集
約して，横串での分析をできる体制が必要

11. 2015/11 現在のシステム構成

12. ポイント
> Webフロント経由でのアクセス
> システム間連携はAPIを提供
> CI環境の整備
> 仮想化によるアプリケーションサーバの冗
長性確保
> 統一されたフォーマットでログの自動取得
> 内製システムによるバッチ実行制御
> Hive経由での可視化基盤との連携

13. この形に至るまでの
経緯を順に
おみせします

14. フェーズ
1
(2011-2013)
フェーズ
2
(2013-2015)
フェーズ
3
(2015-)
今後
システム構
成
• 導入期
• 負債を生成
• 発展期
• 取扱ログ
100種類以
上
• 部分的な負
債解消
• 大規模な構
成変更
• 負債の解消
• 運用の自動
化
• スケールの
担保
• 新規のミド
ルウェアを
検証 & 投
入
• ストリーム
データへの
対応
データ活用 • 導入期
• パワーユー
ザの育成
• 普及期
• 利用ユーザ
200人以上
• 可視化基盤
の導入
• 組織全体で
同じ数字を
みる体制作
り
• 様々な用途
に応じた
データ活用
フェーズ毎のサマリ

15. 第1フェーズ
2011-2013

16. 課題

17. 統一データ基盤の必要性
> ファミリーサービスが多数あり，それらを同
一のプラットフォーム上に載せて分析できる
ようにしたい
> 大半のデータについて，各サービス内で閉
じていた
> サービス横断的にユーザの動向を把握でき
る必要がある

18. システム構成

20. クラスタ
> CDH3u0
– NN1台 + コールドスタンバイ
– 単一障害点だらけ
> ディスクの枯渇
– 想定より遥かに蓄積速度が早い
– レプリケーション2での運用
> 運用
– 人の手による暖かみある運用

21. Pig
> サービスごとにビジネスロジックが入り込ん
でおり，アドホックな前処理が多数発生
> 仕様変更が数多く発生するため，Hiveテー
ブルを定義するのが，（当時は）難しかった
> 上記を整備するための知見と工数の蓄積が
なかった

22. 内製Webフロント
> はじめから，各サービスの企画担当者が直
接触れることを想定していた
> 当時のHueは非常に機能が少なく，機能要
件を満たさなかった
> 業務要件に合わせて作り込んだため，Hue
への乗り換えに際して大きな障害となる

24. 実行ログの
確認
ジョブ実行
スタック
ジョブの
表示

26. ファイルの閲覧，削除
ディレクトリの表示，移動
ディレクトリ作成，ファイルアップロード

27. データ活用

28. パワーユーザーの育成
> 各サービスの分析担当エンジニアと，分析
部署が主に使用
> 各種環境の整備
– Pigの導入資料を用意
– 開発環境をVMで提供
– 各サービス向けに勉強会を開催

29. 第2フェーズ
2013-2015

30. 課題

31. クラスタ乗換の必要性
> ディスクの枯渇
– 2年間で扱うログが100種類以上に増加
– サーバスペック自体を見直す方向に
> インフラ構成の見直しに伴うDC移設
– DC間のデータ転送が必要なため，帯域を絞りたい
– Hadoop1.0系のdistcpだと，利用帯域を設定できない
– 自作バッチを開発して，帯域を絞りながらデータ転送
を行うことに

32. 初期構成の負債
> 内製アプリケーションの運用負荷
– Hueの充実
– 継続的にメンテナンスコストがかかる
> クラスタ管理
– ClouderaManagerに載せるためには，既存アプリの大
幅な作り替えが必要
– 時間と開発コストの面で見送りに…

33. システム構成

35. システム構成
> CDH3u6 → CDH4.3
– NN2台のマスタースレーブ構成
– 単一障害点もある程度解消
> ノード構築作業の自動化
– Chefレシピを作成
> 内製アプリケーションのリファクタリング
– コンポーネントの集約
– Jenkinsを用いたCI環境の構築

36. データ活用

37. 部署の統合
> Hadoop開発の部署と，分析の部署が一つ
にまとまる
– 開発と連動した分析体制の整備
– 結果の可視化までをシステム化
> 内製の可視化基盤
– Python製のバッチ機構
– Pig + MySQL + Shiny の構成
– 基本的なKPIは全社員がインタラクティブに確認可能

39. 条件毎に
フィルタ
グラフ共有
データDL
比較軸の
設定

40. 分析環境の整備
> Pig開発効率の向上
– ドメイン知識を詰めたUDFをまとめたjarファイル
– 名前と型をつけて各ログをロードするpigマクロ群
– 標準コード規約
– 4桁行規模のPigスクリプトも多数
> 知見の蓄積と共有
– 各サービスで行った分析結果をconfluenceで共有
– 分析担当者が集まって情報共有をおこなうミーティン
グを定期的に開催

41. ユーザーの規模
> アカウントを持っているユーザが200人以上
> 主な分析用途
– 新しい施策を打つ際の，現状の確認
– 打った施策の成果確認
– サービスごとの，さまざまな定常バッチ
– システムのパフォーマンス測定
> 業務プロセスの変更が痛みを伴う規模に…

42. 第3フェーズ
2015-

43. 課題

44. 大規模な構成変更の必要性
> 運用コスト増大を解消
– 内製アプリケーションからの脱却
– クラスタの一元管理と監視・運用の省力化
– 新しいミドルウェアの導入コスト低減
> システム構成の見直し
– ラックやサーバ配置，ネットワーク等の最適化
– YARN化に伴う各種構成の変更
> 上記を踏まえてClouderaサポート導入

45. 構成変更手順
1. 別クラスタをClouderaManagerで構築
2. distcpで現行クラスタのデータを新クラス
タにコピー
3. 既存クラスタと新クラスタの両方に日々の
ログデータを流し込む
4. YARNと既存アプリケーションの検証

46. データコピー時の問題
> CDH4から，HDFSファイルのcheck sumが変更さ
れた
– CDH3まではCRC32で，CDH4以降はCRC32C
> 両方のcheck sumを含んだディレクトリをdistcp
するとエラーで落ちる
– distcpの際にcheck sumを指定する必要があるため
> 結局エラーが出た箇所に関して，データを整形
した時期を確認して個別にdistcp

47. システム構成

49. システム構成
> CDH5.4.1
– NN2台のHA構成
– ClouderaManagerで構成管理
> 内製アプリケーションの整理
– 各アプリケーションを疎にしてOSS等に置き換え
– HueやTableau
> 冗長性の担保
– 各アプリケーションはlxcでコンテナ化
– fluentdクラスタによるログの取り込み
– まだいくつか，冗長化しきれていないコンポーネントもある

50. バッチジョブの省力化
> バッチジョブは
– ややこしい処理が多い
– 処理自体の追加や変更も多い
– ジョブ間の依存関係も多く存在する
> 内製バッチフレームワークの開発
– コンポーネントの組み合わせでフローを表現
– その組み合わせをjsonで記述するだけ

51. ストリーミング基盤の構築
> fluentdクラスタの構築
– 大半のログは，統一フォーマットでfluentdに送って集
約する形に
– 従来のログは順次fluentdに移行していく
> リアルタイム集計基盤の構築
– lxcコンテナ上に，fluentd/Norikra/InfluxDB/Grafanaを
1セットとして構築
– 各サービスごとに，必要に応じてコンテナを立てて，集
計が行えるように

52. データ活用

53. 分析→可視化プロセスの強化
> 可視化までの手間を削減
– MapReduce/Pig
– Hive経由でTableauによる可視化
> 全体のレベル向上への取り組み
– パワーユーザーの育成
– Excelで行われていたことをTableauへ自動化
– 分析内容や使い方の共有会

54. 準エンジニア手当
> 会社全体として，ソフトウェアエンジニアリン
グの知識を向上させるための取り組み
> 非エンジニア向け
> 準エンジニア試験を受けて合格すると，手
当がもらえる
> 前回実施分では試験範囲にPigも

55. まとめ

56. 今後の方向性

57. 過度のPig依存からの脱却
> Pig特有のつらみ
– バージョンが0.1変わっただけで仕様が大きく変わるた
め，過去に開発したPigスクリプトが最新版で動作しな
いことがザラ
– テストフレームワークが充実しておらず，一定規模以
上の定常バッチには向いていない
> Spark/Impalaへの移行
– バッチ処理はSparkで記述
– 短めのクエリはImpalaで実行

58. Pig 0.11 → 0.12で生じた主な変更
> メタ変数の展開形式が変更
– %DECLARE `${hoge}` がPigのメタ変数と認識されるように
– %DECLARE `${hoge}` とエスケープ処理が必要に
> グローバル変数の導入
– %DECLARE 変数がマクロ内部でも認識されるように
– マクロ内変数を一律で M_XXXX と変更
> replicated joinの動作不具合
– MRにおけるmap side joinで，処理が高速なため多用していた
– すべてskewed joinに変更し，使用をやめた
> EXEC, RUNコマンドの変数引き渡し
– 呼びもとのpigスクリプトで定義された%DECLARE変数が，呼び先のpigスクリ
プトの同名変数を上書して実行
– EXEC, RUNの使用をやめた

59. ストリーミングの強化
> 流量が多すぎると，1台のNorikraでは対応
できない
– NorikraエンジンのEsperは，dual 2GHzの85%使用時で，
70Mbit/s程度のストリームデータ処理が限度
– Norikraを多段に重ねれば，データ量の増加にもある
程度対応できるが，それだと今度は運用が辛い
> ストリーミング処理も分散処理できるように
しないといけない
– Kafka + Spark Streamingの構成による検証を進める

60. スケジューラの強化
> 複数のバッチ間の依存関係を制御できるよ
うに
– 中間データA, Bがおわってから，集計処理X, Y, Zを走
らせたい，といったケース
> 各ユーザが勝手に，Pig/Hive/Tableau連携
を定義してスケジュール実行できるように
– セルフサービスBIをサポートしていく仕組みづくり

62. 長期運用から
得た知見

63. 初期設計は非常に大事
> 各コンポーネントを疎にしておく
– コンポーネント単位で後から差し替えられるように
– 中途半端に密な内製アプリケーションを作ると，後か
らのOSS差し替えが非常につらい
> データフォーマットの統一
– いったん社内で広く使われ始めたログのフォーマット
を後から変更するのは，とてもコストが高い
– ちゃんと初期の時点で設計しておく
– 業務プロセスに合わせて中間データをつくり，そこで
フォーマット変更の差異を吸収

64. 運用コストを下げる
> システム内で単一障害点をなくす
– 各アプリケーションサーバやDBサーバなど，Hadoopク
ラスタ以外の全てにおいて同様
> 自動化，並列化，
– 監視，デプロイ
> 内製コンポーネントはできるだけ作らない
– まずは既存のミドルウェアを探す
– 作るなら，OSSの部分と疎になるように切り分ける

65. 分析体制の作り方
> パワーユーザを育てる
– 何もしないで勝手に社内の人たちが分析してくれるほど，
世の中は甘くない
– まずはスモールに，分析で問題解決ができる部署と協力
関係を築いて，そこで成果を出す
– 全社展開していくのは，ある程度スモールな成果が出て
から
> サービスレベルは慎重に決める
– 低すぎると，そもそも使ってもらえない
– 高すぎると，長期的な運用に差し支えがでる
– 最初は若干低めに現実的なSLAを定め，後から徐々に上
げていく

66. 以上