Elasticsearch, Kibanaを5.6.2から6.1.2にupgradeした
といっても上書きupgradeじゃなくて新旧2つのElasticsearchにdouble writeして切り替えました。
うちの環境だとfluentd→kafka→kafka-fluentd-consumer→fluentd→Elasticsearchという経路でElasticsearchに書き込んでいます。
fluentdは0.12系を使っています。
kafkaが間にあるのでこの機会にmulti worker試したいなと思ってkafka以降の経路でfluentd 1を入れようとしたんですが、以下の理由から0.12を使いつづけています。
まあこれから試す人はfluentd 1で良い気はします。
fluentdのCPU使用率が上がった。
https://github.com/fluent/fluentd/issues/1801
もっともこの問題は現状解決されているはず。僕の環境ではすでに0.12で運用始まっているので試せてないですが。
fluent-plugin-record_modifierとfluent-plugin-prometheusがmulti worker未サポートだった。
prometheusに関してはもうサポートしたっぽい。https://github.com/fluent/fluent-plugin-prometheus/pull/44
record_modifierはfluentdのログを集めてきて下記のようにtagを書き換えるために使ってます。
<match fluent.**> @type record_modifier tag "fluentd" include_tag_key yes tag_key "loglevel" hostname ... portnum ... </match>
Elasticsearchのclient側の話としては、fluent-plugin-elasticsearchが依存しているelasticsearch-rubyに互換性が無いように見えたのでruby環境を完全に分けました。
https://github.com/elastic/elasticsearch-ruby
Java clientに関しては5.4でも6.1で動きました。
一部JavaScriptからElasticsearch APIをたたいているところがあって、そこはContent-Type指定が必要でした。
https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_rest_changes.html#_content_type_auto_detection
Elasticsearch本体側の話をすると、うちの環境ではindexというかshardが多すぎて日付が変わるタイミングでのindexingでエラーが出るので事前にバッチで翌日のindexを作るということをしていました。
ま、そもそもindex多すぎるのってどうなのっていうのをdiscussで聞いてみたらやっぱり減らせみたいな話になりました。
https://discuss.elastic.co/t/how-to-handle-many-indices/102803
そこでElasticsearch 5.4.2まではshard数をnode数にしてたんですが、それを変えて一部サイズが大きいindexに関しては1 shardがだいたい50GB以下になるようにshard数を指定して、それ以外はshard数を1にしました。
これにより今までは3万近くあったshardが2000ちょっとに減りました。
50GBという数字は
https://www.elastic.co/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
を参考にしました。
TIP: Avoid having very large shards as this can negatively affect the cluster's ability to recover from failure. There is no fixed limit on how large shards can be, but a shard size of 50GB is often quoted as a limit that has been seen to work for a variety of use-cases.
あとmaster専用nodeを用意したところ、日付が変わるタイミングでのindexingでエラーが出なくなったのでバッチも減らせそうです。
今までは全nodeをmaster/data兼用にしてました。
ただmaster専用にするとcerebroに表示されないという問題があります。
Elasticsearch 5.4.2と6.1.2の違いですぐ気付いたのがindexのサイズです。
5.4.2の時は16億ドキュメントで4.2TBでしたが、6.1.2だと3.1TBに減っています。
その辺の改善はここが詳しそう
https://www.elastic.co/blog/minimize-index-storage-size-elasticsearch-6-0
他にもrestart時のrecoveryが早くなっている模様
この辺かな。https://www.elastic.co/blog/elasticsearch-sequence-ids-6-0
searchも早くなっているけど、まあ台数も倍なのでそれの影響が大きいはず。
とはいえ性能改善も入っている模様
https://www.elastic.co/blog/index-sorting-elasticsearch-6-0
他にはCPU使用率のばらつきが減ってますね。
kibanaに関してはindex patternをバッチで作っている部分があって、そこはkibanaのAPIを使うように変更しました。
https://github.com/elastic/kibana/issues/3709
ベジタブルマラソン走ってきた
記録はネットタイムが1時間47分39秒、ちなみに去年が1時間49分33秒。2年前が1時間44分17秒、3年前が1時間42分7秒です。
去年よりは早かったのでまあよしとします。衰えは隠せないですが、走っている時はエイドのキュウリ、ミニトマト、パイナップル、オレンジを少々、走り終わった後は豚汁、熊谷駅ではうどん、を食べて帰ってきました。去年と同じだな。
この大会は12時スタートで人数もそんなに多くなく気軽に参加できる良い大会です。
4年連続で参加してますが、毎回良い天気です。今年は若干風が強かったかも。
今日が走り納めです。今年はフルを6回、ハーフを2回、30kmを1回走りました。
来年はちょっとフルを減らそうかなと思ってます。
2017年振り返り
今日が仕事納めでした。
今年も相変わらずデータエンジニアリング業をしていて、大きなところではHadoopクラスタのアップグレード作業を2回やりました。
クラスタが2つあるから2回。とりわけ3年使ってたクラスタをHDP 2.1から2.5.3にしたのは大きいところで現在も運用中です。
最近datanodeがGC頻発して調子悪かったのですが、heap増やして今は大丈夫そうです。
Presto, Elasticsearch, Kibana, Azkabanといったところも随時アップグレードしています。やはり新しいものはいいですね。
今年はyanagishimaが大きく進化したとしでもあります。進化した理由はUIの専門家にjoinしてもらったからです。
飲み会の席で頼んだらOKしてもらいました。飲み会重要。
社内でもyanagishimaユーザはかなり増えてDAU 100人ぐらいいってます。
Hadoopクラスタの運用事例やyanagishimaをstrataで発表してきて、結構質問も出て嬉しかったですが、
僕の英語力がイマイチで質疑応答がうまくできず。。来年も引き続き英語勉強しないとダメですが、ちょっと伸び悩んでいます。
現在はレアジョブをやりつつNHK実践ビジネス英語を聞いたりしてます。
ランニングは引き続きやってて、だいたい週二回走ってますが、こちらもフルマラソンのタイムは低迷中で、シーズンに1回サブ4出せるかどうかという状況です。
英語とランニングは来年なんとかあしたいなあ。
仕事の方はバッチ系はこなれてきたのでリアルタイム系に重点を移そうかなという気持ちです。
KafkaとFlinkは僕はそんなにやってないんですが、身近にあるしそろそろやっていこうかなという気持ちです。
バージョンがちょっと古いのでこちらもアップグレードしていきたい気持ちです。
障害を恐れずアップグレードしていく気持ちが大事
Strata Data Conference in Singaporeで発表してきた
abstractやスライドは下記からたどれます。
https://conferences.oreilly.com/strata/strata-sg/public/schedule/detail/62948
2014年5月に異動してから新規に構築したHadoopクラスタの3年にわたる歴史を紹介しております。
Hadoopに初めて触ったのが6年前にSIerにいたときで、孫請けで某所に客先常駐で入ったときまで遡ります。
それから転職して異動して、自分が構築したHadoopクラスタや開発したOSSプロダクトについて海外で英語で発表できるようになったのは感慨深いものがあります。6年は長すぎじゃね？という話もありますが。
英語に関しては正直まだ厳しくて、プレゼンのヒアリングはほぼ出来てなくてスライドとかろうじて聞き取れた単語から想像するだけです。
発表に関しては事前準備ができるのでまだいいですが、質疑応答はちょっと難しくてよく聞き取れないこともありました。英語発表は今回で3回目ですが、今回の持ち時間は今までで最長の40分でした。事前リハーサルでは30分で発表が終わったので、残りは質疑応答に回そうと思っててだいたいその通りになりました。
今回のカンファレンスは機械学習やSparkやクラウドといったネタが多くて、僕のようにオンプレミス環境でHadoop使ってデータエンジニアリング業やってる話はレアだったのですが、思ったより多くの方に参加していただいてありがたいかぎりです。質問も結構でました。
GrabのエンジニアがPresto使ってて、彼らとは情報交換したり、オフィスに遊びにいかせてもらいました。ありがたい限りです。ひとりで行くのも寂しかったんで、ついでに他の人（日本人）も誘ったんですが、僕より英語できるし間が持つので誘ってよかったw ありがとうございました。
Hadoopでトラフィックが多いと言われたのでtcpdump使って調べてみた
8:20から9時ぐらいまで断続的にoutboundトラフィックが増えてなんでだろって思ったのでtcpdumpしてみた。
やり方は下記参照
定期的にtcpdumpをある期間だけ実行したいという時 - その手の平は尻もつかめるさ
Hadoopのdatanodeマシンを一つ使って以下のようにcronに仕込んでみた。
20 8 * * * /usr/sbin/tcpdump -w /data1/\%Y\%m\%d\%H\%M\%S.pcap -W1 -G300 > /data1/tcpdump.log
どれだけキャプチャするかは迷った。あんまり短いとわからないだろうし、かといって長すぎるとdiskを圧迫するから。
平常時に試しに1分でやったら378MBだったけど、トラフィックがはねているときだと予想がつかなかったのでとりあえず5分にして出力先は比較的容量があるdatanodeのHDFSがあるパーティションにした。
最悪でもdatanodeが1台ぽしゃるだけだからまあ大丈夫だろうと予想しました。
5分でやったところ結果は44GBでした。注意点としては、僕の環境、CentOS7ではrootじゃないと実行できなかったですね。
あと結果を分割するのにtcpsliceがうまく動かなかったのでtcpdumpで下記のように1GB単位で分割しました。
tcpdump -r 20171127082001.pcap -w /data1/work/aaa -C 1000
これも最初パーミッションで怒られたので/data1/workを777にしました。
あとは/data1/work/aaa1, /data1/work/aaa2みたいにファイルが分割されるのでこれをwiresharkにくわせました。
wiresharkの統計 -> HTTP -> 要求をみると/webhdfs/v1/apps/hive/warehouse/hoge.db/piyo/yyyymmdd=20140101/...みたいなリクエストがあってどうもパーティション指定せずに全期間scanしちゃってるっぽいのでこれが原因かなと。うちの環境だとhiveのexternalでwebhdfs使ってるんですよね。
そんな感じです。
