ヤフーにおけるHadoop Operations #tdtech

Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
2018.05.22 @PLAZMA Data Platform Day
ヤフー株式会社データ＆サイエンスソリューション統括本部
安達寛之
ヤフーにおける
Hadoop Operations

Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 2
自己紹介
安達寛之 (Hiroyuki Adachi)
2016.04
ヤフー株式会社新卒入社
2016.10-2018.03
Hadoopのバージョンアップ自動化、
チューニング、運用の自動化など
2018.04-
Hadoop運用チームのリーダー

アジェンダ
3
ヤフーとそのデータ基盤
ヤフーのHadoop環境とHadoopチーム
Hadoopの運用の自動化
これからの成長に向けて

Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
ヤフーとそのデータ基盤

Yahoo! JAPAN
5
Over 100 services
71.3B PV/M
90M DUB
43M MAU

ビジネスの拡大とデータの増加
6

ビジネスの拡大とデータの増加
7

データ基盤
8
Hadoop
RDB DWH
Object
Storage
KVS Presto
4,100
nodes
120
PB
900
DBs
300K
query/day
25B
files
2,000
nodes
60
nodes

マルチビッグデータドリブンカンパニー
スパコン「kukai」
9
データフォレスト構想
https://linotice.tumblr.com/post/164962607234/20170904 https://dataforest.yahoo.co.jp/

ヤフーのHadoop環境と
Hadoopチーム

Hadoopクラスタの構成
11
HDP 2.3 + Ambari 2.4
1500 Nodes
Type1 (DN/NM): Xeon E5-2683v3*2, 128GB
Type2 (DN/NM): Large data disk
Type3 (NM): No data disk

クラスタコンポーネント
12
HDFS
YARN
Map
Reduce
Tez Spark
Hive Pig SparkSQL
Hive
Server2
Oozie
File System
Resource Management
Execution Engine
Query Processing
API HttpFS

データ量とワークロード
HDFS使用量は約37PB
50-60TB/dayで増加
13
YARNは平均80%のリソースを使用
マルチテナント環境
ETL/eコマース/広告/検索/…
2-3万job/day

Hadoopチームの変遷
14
0
5
10
15
20
2016H2 2017H1 2017H2 2018H1
Teammembers
Dev Ops DevOps UserSupport
バージョン
アップ自動化
自動化
の拡大
自動化ツール
の安定化
DevOps
の加速
サポート
の強化

Hadoopチームの変遷
15
バージョンアップの自動化をタスクフォース
として3ヶ月で実施
定常運用にも自動化を拡大
開発したツールを安定化
運用チームと合体しDevOpsサイクルを加速
ユーザーサポートチームを切り出して注力

運用の自動化の事例
17
1. クラスタバージョンアップの自動化
2. セキュリティ対応の自動化
3. 不良ノード対応の自動化

1. クラスタバージョンアップ

背景
19
バージョンアップ作業実績
（Meta情報更新を含むメジャーバージョンアップ）
12時間*10人で実施
何時間も人が張り付き、同じ作業を繰り返していた
メンテナンス中ユーザの利用不可
ビジネス影響大
事前・事後の運用の調整も必要

目的
20
1. ユーザ影響を出さない
ジョブ実行・HDFSの読み書きを失敗させない
提供コンポーネントの動作を保証する
2. 運用コストの削減
HA構成や大量のスレーブノードで同じ作業がある
自動化できるものは自動化する

方法
21
1. ユーザ影響を出さない
HDFSのブロック情報を監視してタイミングを制御
HA構成を活用した安全なリスタート
2. 運用コストの削減
AmbariのAPIを使ってオペレーションをコマンド化
Ansibleでバージョンアップフローを自動化

ambari-
agent
Data
Node
Node
Manager
ambari-
agent
Data
Node
Node
Manager
ambari-
agent
Data
Node
Node
Manager
ambari-
agent
Resource
Manager
AmbariとHadoopクラスタ
22
Web
UI
REST
API
ambari-
agent
Resource
Manager
ambari-
agent
Name
Node
ambari-
agent
Data
Node
Node
Manager
ambari-
agent
Name
Node
ambari-
agent
…

Ansible
23
構成管理ツールの一種
バージョンアップ全体のフローをコントロール
Chefと比較して
学習コストが低い
順序制御がやりやすい
エージェントレス
- hosts: cluster
become: true
tasks:
- name: start ambari-agent
service: name=ambari-agent state=started

バージョンアップフロー
24
Master
ZK, JN, NN, RM, ATS, JHS
Tool
HS2, HMS, Oozie, HttpFS
Client
HDFS, YARN, MapReduce2,
Hive, Oozie, Pig, Spark
Slave
DataNode, NodeManager
$ ansible-playbook –i hosts playbooks/upgrade.yml
HAを
活用
LB
制御
ブロック
情報から
タイミング
を制御

自動化の効果
25
停止時間と工数を大幅に削減！
その後のバージョンアップでも活用！
前回今回
クラスタ停止時間 12時間 7分
メンテナンス時間 12時間 72時間
工数 9人*12時間=108時間 3人*7時間=21時間

2. セキュリティ対応

セキュリティ対応
27
セキュリティ対応できていますか？
できている or やらないといけないけど、、、
ヤフーではYJ-CSIRTが脆弱性を一元管理
期限を定めて対応している
数千台あるサーバを種類に応じて、
期限内に人手で対応するのは難しい

セキュリティ対応の状況
28
自動化（ワンコマンド化）しました
DataNode/NodeManager
NameNode/ResourceManager
HiveServer2など
本番環境で稼働中

DN/NMの脆弱性対応の自動化
29
1. DataNode/NodeManagerのサービスアウト
i. ラベル付けして新規ジョブがアサインされないようにする
ii. DataNodeのデコミッション開始
iii. 実行中のコンテナ数が0になるまで待つ
iv. NodeManagerのデコミッション開始
v. デコミッション完了待ち
2. セキュリティアップデート＆リブート
3. DataNode/NodeManagerのサービスイン
i. リコミッション
ii. ラベルを削除して通常通りジョブがアサインされるようにする

NameNodeの脆弱性対応の自動化
30
Active
NameNode
Standby
NameNode
Cold
Standby
脆弱性対応
Save NameSpace
メタデータのコピー
NameNode停止
VIPの付け替え
NameNode起動
F/O -> ActiveF/O -> Standby

HiveServer2の脆弱性対応の自動化
31
Client
Load Balancer
HiveServer2

32
Client
Load Balancer
Established
Connection
Wait for jobs
to be finished
⚠️
HiveServer2

33
Client
Load Balancer
Established
Connection
Wait for jobs
to be finished
⚠️
HiveServer2

34
Client
Load Balancer
⚠️ Security
Update
HiveServer2

35
Client
Load Balancer
⚠️
HiveServer2

36
Client
Load Balancer
HiveServer2

自動化の効果
37
運用工数の削減
コンポーネント毎に1コマンド実行すれば良い
安全なオペレーション
適切なチェックを実施
手順の抜け漏れもない
期限内の対応
人手だと終わらないが自動だと昼夜を問わずできる

3. 不良ノード対応

背景
39
数百〜数千台あると普通に壊れる
ディスク and/or メモリ
不良DN/NMによる影響
HDFSのブロックが壊れるバグ（HDFS-9958）
ライブラリが読めなくてタスクが失敗する
明確な判断基準がない
故障度合いの判断、確認頻度がまちまち

故障度合いの定量化
40
dmesgなどから、ハードウェアのエラー
メッセージをスキャンし、スコアリング
域値以上のものを不良ノードとみなす
エラーパターン例スコア
section_type: PCIe error 50
section_type: memory error 20
CE memory scrubbing error 1

自動サービスアウト
41
host1.yahoo.co.jp
{
"ambari_agent_disk_usage": "OK",
"critical_disks": [
"/dev/sdg"
],
"gridops_disk_check": "WARNING",
"gridops_system_check": "CRITICAL",
"hdfs_status": "LIVE",
"registered_in_ambari": true,
"server_id": 358269,
"service_status": 7,
"system_check_severity": 1218,
"warning_disks": [],
"yarn_status": "RUNNING"
}
1. Report score
2. Fetch score
4. Decommission
bad node
3. Request for
decommission
DNs/NMs Ops server

自動化の効果
42
SLAの維持
故障を早期に検出し順次修理することができるので、
一定の性能を保つことができる
運用工数の削減
サービスアウト作業が大きく減る
不良ノードに起因した問い合わせ対応が減る

運用の自動化の振り返り
43
現在の課題>未来の課題=過去の課題
の順で受け入れられやすい
まずはスモールスタートから
本番でしか起きないこともあるので
リードオンリーモードは効果的

これからの成長に向けて

データ基盤
データの増加
新しくワシントン州にデータセンターを建設中
Erasure Codingに期待
NameNodeの負荷対策
Log Aggregation専用の小クラスタにオフロード
HDFS Federationに期待
コンテナ、機械学習、GPU、etc.

運用体制
46
スケーラブルに
クラスタが大きくなるから人も増やす、とはいかない
自動化できるものは自動化する
共通化できるものは共通化する
Infrastructure as Code
個別に変更を加えない
変化を恐れない（恐れなくていいようにする）

まとめ
47
Hadoopの運用を自動化
クラスタバージョンアップ工数削減
定期的なセキュリティ対応
不良ノード対応でSLAを維持
データ基盤と運用をよりスケーラブルに
データ利活用推進による需要増加への対応
基盤だけでなく人もスケールしないとついていけない

ヤフーにおけるHadoop Operations #tdtech

More Related Content

What's hot

Similar to ヤフーにおけるHadoop Operations #tdtech

More from Yahoo!デベロッパーネットワーク

ヤフーにおけるHadoop Operations #tdtech