夏サミ2013 hadoopを使わない独自の分散処理環境の構築とその運用

Summit Developers

Developers Summit 2013 Summer

Hadoopを使わない独自の分散処理環境の構築とその運用

前橋孝広株式会社インターネットイニシアティブ

プラットフォームサービス部

プラットフォーム開発課

A3 #natsumiA3

Summit Developers


自己紹介

名前: 前橋孝広所属: 株式会社インターネットイニシアティブ(IIJ)

Summit Developers


本日の話

分散システム開発の動機

開発したものの機能と仕組みについて

システムの構築と運用

Summit Developers


分散システム開発の動機

ISPにおいて、サービスの状態把握は必須そのために大量のログデータを扱う必要がある

http://www.flickr.com/photos/ctbto/8443792513/

Summit Developers


ISPにおける大規模データ

•  ほぼすべて時系列データ •  分析したい項目や抽出条件は多岐にわたる

例: トラフィックデータ

フィルタリングログ

時系列Webアクセス数

Webアクセス数割合

Summit Developers


例: トラフィック情報(NetFlow)のデータ I I Jのバックボーンを流れるトラフィックの情報は膨大な量となる

!me router bytes pkts proto src AS dst AS src port dst port src ip dst ip …

1388253400 172.16.100.1 1433 1 6 2497 9999 80 4321 192.168.0.1 192.168.9.8

1388253400 172.16.0.10 987 1 6 1234 1000 25 2224 10.168.20.1 10.168.20.1

1388253400 172.16.100.2 555 1 6 9999 2497 2345 80 192.168.0.7 10.18.80.1

1388253400 10.16.10.1 12 1 1 1111 2222 22 22345 10.168.1.1 10.168.30.1

1388253400 172.16.0.1 1490 2 17 2222 1234 22345 24 172.16.9.7 10.68.20.1

1388253401 172.16.1.10 1309 1 6 3333 5555 8080 8765 192.168.0.1 172.16.9.79

1388253401 192.168.10.1 538 1 6 1111 2497 5787 80 10.218.0.1 192.168.9.1

1388253401 172.16.99.8 333 1 1 9999 1000 70 15588 10.68.0.1 172.16.9.72

1388253401 10.16.98.7 981 1 17 4444 2222 80 11557 192.168.0.1 172.16.90.3

1388253401 172.16.10.1 1433 1 6 1234 4321 7078 12345 172.16.0.1 172.16.4.71

…

約30項目

数億 /day

Summit Developers


巨大なログデータの処理といえば

Summit Developers


MapReduce とは?

mapとreduceの2段階にわけてデータ処理 ① map – 抽出・変換 ② reduce – 集約・集計

Summit Developers


Hadoop相当のものを自作

IIJ社内専用非公開

オープンソース

Summit Developers


Hadoopを使わず自作した理由

•  Hadoopはバッチ処理に特化している

•  自社開発でノウハウをためるため

•  用途を特化して作ればより効率のよいものが作れる

•  やってみたかったから

Summit Developers


分散処理の原理は難しくない

分散処理従来型処理

データはあらかじめ各ノードに分散配置

各ノードで並列実行

Summit Developers


Hadoopはバッチシステム

Summit Developers


Hadoopが向いている処理

•  24秒の遅延が気にならないような巨大なバッチ処理

•  やることが決まっている定型処理

Summit Developers


やりたいこと

•  サービス運用者は、試行錯誤により、より深いデータ分析を行う

•  分析に必要なパラメータは多様であり、事前に網羅することは困難　→　定型でない

データを生のまま保存し、オンデマンドで抽出・集計を行う必要がある

Summit Developers


開発したものの機能と仕組み

Summit Developers


開発したもの(1) ddd

大量の時系列データ(例: NetFlow生データ)を蓄積し要求に応じて短時間で検索・集約結果を返す

Summit Developers


ユーザインタフェース

クエリパラメータ入力

グラフ化

アドホッククエリ(定型的でない、一回限りの問い合わせ)が大半

Summit Developers


dddの特徴

•  時系列データに最適化した分散ファイルシステム→ 対象データの格納位置を瞬時に特定

•  自動レプリケーションによるデータ冗長化

•  楽観的タスクスケジューリング – 応答待ち時間の短いMapReduce

詳しくは… 電子情報通信学会論文 Vol.J93-D,No.7,pp.1072-1081,Jul. 2010., 「大規模データ処理のための分散システムの実装とその応用」

Summit Developers


MapReduceによるグラフ生成

map: 複数ノードで並列に抽出・集計処理

reduce: 結合

要求があってから生データに対して分散処理を開始してグラフ化

Summit Developers


応答速度

•  極めて小さいデータを、何もせずに素通しするのにかかる時間

Hadoop ddd

19秒 0.12秒

Summit Developers


2000タスクの処理時間グラフ

•  台数が増えると処理時間が減少

Summit Developers


2000タスクの処理時間グラフ(対数)

•  台数が増えると、多少オーバーヘッドは出てくる

Summit Developers


開発したもの(2) pmux

•  pipeline mulPplexer に由来 •  オープンソースとして公開

•  GitHub – hSps://github.com/iij/pmux – hSps://github.com/iij/pmux/wiki

•  Gluster Forge – hSps://forge.gluster.org/pmux

Summit Developers


pmuxとは?

•  標準入出力を介して MapReduce するためのコマンドラインツール(Hadoop Streaming相当)

$ pmux --mapper="grep PATTERN" *.log

例: 分散grep

分散ファイルシステム上にあるファイル群

Summit Developers


GlusterFSとは?

FUSEでマウントして普通のファイルシステムとして見える

Summit Developers


ファイル名に応じて分散

clientからは、ひとつのファイルシステムとして見える

Summit Developers


ちょっと宣伝

•  IT検証ラボ -‐-‐ 分散ファイルシステムのGlusterFS：こんなとき、どうなる – hSp://itpro.nikkeibp.co.jp/arPcle/COLUMN/20130104/447701/

Summit Developers


pmuxの分散処理の原理

•  例えば次のようなコマンド

•  *.log が複数ノードに分散して配置されていれば、各ノードで並列に処理できる

$ grep PATTERN *.log

Summit Developers


ファイルがあるノードで処理を実行

Summit Developers


結果を集める

Summit Developers


実際はもう少し複雑

Summit Developers


使用例: ステータスコード集計

Apache ログから特定パターンの行だけ抜き出し、そのステータスコードを集計

$ pmux --mapper='grep PAT |cut -d" " -f 9’ \ --reducer='sort|uniq -c’ /mnt/glusterfs/*.log 176331 200 106360 206 809 400 21852 403 533 404 27 406 805 416 25 500

Summit Developers


使用例: word count

$ pmux --mapper=map.rb --reducer=reduce.rb \ --file=map.rb –-file=reduce.rb \ /mnt/glusterfs/*.txt

#! /usr/bin/ruby -an $F.each {|f| print "#{f}\t1\n"}

#! /usr/bin/ruby -an BEGIN {$c = Hash.new 0} $c[$F[0]] += $F[1].to_i END {$c.each {|k, v| print "#{k} #{v}\n"}}

map.rb

reduce.rb

コマンドライン

Summit Developers


デバッグとテスト

•  多数のノードを前提とした分散システムのデバッグは超大変

•  ネットワークをモック化 – 複数ノード環境をシミュレーション

•  テストへの組み込み – 継続的インテグレーション(CI)ツールによって自動実行

Summit Developers


実環境でしかわからないこと

•  実環境でしか再現できないトラブルもある •  ノード間通信の集中に起因

– コネクション数限界 •  net.core.somaxconn

– パケットの消失 • スイッチのバッファの限界を超える？

　　　ノード間の通信をキューを使って制御

Summit Developers


自作した甲斐はあったのか

•  答えは、もちろん「YES」 •  サービスや社内システムのバックエンドで活用中　(定型、非定型処理両方)

•  分散処理のボトルネックやトラブルシュートに関するノウハウの蓄積ができた

•  ビッグデータに関する新サービスへの応用予定

Summit Developers


運用

Summit Developers


分散処理プラットフォーム dplat

•  IIJ社内に対し、分散システムの基盤を提供 •  社内向けPaaSのようなもの

– ddd, GlusterFS, pmux などが使用可能

•  サービスごとにクラスタを分けて運用

Summit Developers


サービスのバックエンドとして利用

データ

アウトプット

データ

アウトプット

dplat

トラフィック解析システムバックエンド

セキュリティレポートサービス

Summit Developers


ノードの設置場所

東京

大阪

松江広域分散によりデータの喪失を防ぐ

Summit Developers


松江データセンターパーク

IT module air-‐condiPoning unit

Summit Developers


ITモジュールの中身

•  IZmo S(スリム)：ラックを傾斜配置 – 他に IZmo W(ワイド)もあり

Summit Developers


運用の基本思想

•  楽をする – いろいろ自動化

•  機材は壊れることを前提 – 適切な冗長化で壊れても良いようにする

• 障害が起きても基本は放置 → あとで修理

•  監視とモニタリングは、しっかりやる

Summit Developers


サーバについて(1)

•  サーバはネットワークブート – OSなどのシステムはメモリファイルシステム

– 再起動すると設定はすべて消える – → 設定情報の外部化/バージョン管理

•  起動後に Chef で必要な物がインストール

•  サーバ仮想化技術は使っていない

Summit Developers


サーバについて(2)

•  HDDは搭載しているが、データ格納用途のみ – RAIDによる冗長化はしていない

•  dddやGlusterFSのレベルで冗長化 – 故障時はノードごと切り離されるがデータは消失しない

•  故障はそれなりに起こる – ハードディスク、NIC、メモリ、電源、etc

Summit Developers


監視

•  死活監視、ポート監視 •  ディスク残量監視

•  分散ファイルシステムの読み書き監視

•  MapReduceジョブの実行時間監視

Summit Developers


モニタリング

•  ファシリティレベル – 温度、消費電力 etc

•  各種リソース – ディスク、メモリ使用量 etc

•  アプリケーションレベル – 各APIコール数

– タスク実行状況詳細 etc

Summit Developers


まとめ

•  ISPは、サービス状態の把握のため巨大なログデータを扱う必要がある

•  分散処理システムを独自に開発 – 定型でない処理に対応

•  運用 – 今どきの普通のやり方

– モニタリング重視

夏サミ2013 hadoopを使わない独自の分散処理環境の構築とその運用

Technology

mapper

izmo

usr bin ruby

print

netflow

github