BLOG::はるかさん

はるかさん のブログです。近況情報や技術的な話題など。

書きました: サーバ/インフラエンジニア養成読本 ログ収集~可視化編

ということで、技術評論社から発売されるサーバ/インフラエンジニア養成読本 ログ収集~可視化編の執筆に参加させて頂きました。 来月の2014年8月8日発売になります。

サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)

サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)

これまでにも雑誌に記事を掲載させて頂いたりしたけど、広告記事書いたの初めてな気がする……さて、今回のログ収集~可視化編では、Fluentd、Elasticsearch、Kibanaを使用したログ収集から解析までを解説しています。4つの特集記事で構成されており、全編書き下ろしです。4人でそれぞれ特集を1つずつ担当しました。

はじめは@suzu_vさんによる「特集1 ログ解析からはじめるサービス改善」です。特集1では、ログ解析を行う必要性について、実例を挙げてわかりやすく解説されています。これからログ解析を行っていくうえで、どのような方針をとれば良いか、どのような問題点があるか、非常にわかりやすく解説されており、とてもためになりました。広告における実例も掲載されており、非常に読みごたえがある内容になっています。

すずけんさんによる解説もありますのであわせてどうぞ。

「特集2 ログ収集ミドルウェアFluentd徹底攻略」は、@yoshi_kenさんによるFluentdの解説になります。Fluentdによる堅牢なログ収集の仕組みをつくるための運用方法について詳しく解説されています。また、ほとんどのFluentdプラグインを網羅している逆引きFluentdプラグインは便利そうです。

「特集3 Elasticsearch入門」は、@johtaniさんによるElasticsearchの解説になります。Elasticsearchはその基本機能である検索エンジンとしての使用方法がメインですが、今回はデータストアとしてのElasticsearchに注目して解説されています。実際に運用する上で役に立つツールやTipsについても触れられており、Elasticsearchを運用していく上でも役に立ちますし、Kibanaを使うために運用しないといけなくなったエンジニアの方も必見です。また、ElasticsearchとHadoopの連携についても解説されており、Hadoop等を利用した解析基盤を構築する場合の参考になるかと思います。

自分は「特集4 可視化ツールKibanaスタートガイド」を執筆させていただきました。Kibanaの持っている一通りの機能について解説しています。 Kibanaには本当にたくさんの機能があって、別に全てを使わなくても十分便利なのですが、実はいろいろなパネルや機能があって様々な使い方が出来ます。 普段ダッシュボード代わりに使っている方も、ログ検索だけに使っている方も、Kibanaの使い方の幅が広がることになれば幸いです。 また、特集4は全ページカラーページになっていますので、それぞれのパネルのサンプルとしてもお使いいただけます。

今回本を書くにあたってKibanaのパネルを1つ1つ触っていったのですが、かなり機能が多くていまさら驚きました。普段使うパネルといえばTableとHistogram、Termsくらいではないでしょうか。bettermapとか使うところなさそうだけど、うまく要件に当てはまればすごい便利な気がしました。本文中では触れてないですが、個人的に便利なのはtextパネルです。Kibanaは重いクエリを結構カジュアルに発行することができるので、パネルの使い方とか、指定範囲とかをメモ書きしておくと非常に便利です。

さて、Fluentd、Elasticsearch、Kibanaという3つのプロダクトをつかった構成はログ解析において主流の1つになりつつあるように思いますが、それぞれの運用ノウハウを集めた情報というのは意外に少ないように思います。ログ解析において必要なそれぞれのポイントをおさえた本としては貴重な情報になることを期待しています。これからログ解析を始める方も、既に始められている方も、本書がログ解析の有用性を広げる一助になれば幸いです。

可視化ツール現状確認会に参加してきました。 #可視化

昨日2014年6月4日に開かれた可視化ツール現状確認会に参加してきました。会場のVOYAGE GROUPさんカジュアルウォーターの提供ありがとうございました。

20140605095555

上の画像はジョークですよ、もちろん。Keynoteはすばらしい3Dグラフの数々を描画できることをはじめて知りました。

さて、いつもだったら発表スライドを貼るんだけど、あまりに短い時間でつくったので、スライドを貼らずに要点だけかいつまんで説明しようと思います。だいぶエモいかんじになったんですが、言いたかったことはこの1枚のスライドです。なお分類は適当なので適宜修正してください。たぶんETLとかBIとかに強い人だと、スライド上方のレイヤーをきちんと分類できる気がします。

20140605012005

何が言いたかったかと言うと、僕らが本当に知りたいことには距離があって、それを知るには"可視化ツール"という単一のツールを考えるのではなくて、保存するログの内容から形式、転送方法、集計方法、グラフ描画まで様々なレイヤーのことを考えないといけないよね、ということです。要は考えることはたくさんあって、そのなかから最適解を選ばないといけないというのが、可視化ツールの現状じゃないかと思っています。様々なツールが出そろってきて、そろそろサーバにログインしてログをtail | grepする時代じゃないよね、というのは良い方向だと思います。

可視化というと、僕らに近いレイヤー、それこそKibana/Esのようなフルスタックの分析ツールであったり、RRDTool、D3.jsといった技術に目が行きがちですが、本当にほしかったものは単にログが転送されて、それが目に付くところにある、という事実です。分析やグラフ描画はExcelでやってるのが実際だったりするのです。

さて、自分はインフラチームのエンジニアで、サーバモニタリングを行うことはあっても、ビジネスロジックに近い分析を行うことはあまりありません。では、モニタリングだけのためにデータを集めているかというとそんなことはなく、ビジネスロジックにも十分に使用できる基盤の構築を目指しています。となると一番意識しないといけないのは、自分が使いやすいツールを用意するとかではなく、本当にデータが欲しい人の手元に、欲しい形式でデータがあるということになります。Kibana/Esの構成はある程度のログ量までであれば、ログを全文検索し、簡単な集計グラフを描くこともできておすすめですが、すべてのケースに当てはまるわけではありません。

ということで、現在は単にグラフにできて便利だね、ではなく、必要としている人のところに如何にデータを届けるかを考えて設計するようにしています。このような観点からインフラを見ているエンジニアの方がいらっしゃれば知見をお伺いしたいところです。

確認した現状

どこまで書いて良いのかわからないので、適当なメモ。発表に関しては下記ページがよくまとまっています。

Kibanaかっこいい

弊社ではLightが主流なので、Kibanaに対して"黒い"というイメージをあまり持っていなかった。黒いのそんなにみやすいと思わないけど、社内でも一定の支持を得ているので、黒ベースでも良いのかもしれない。

RRDtoolすごい

RRDtoolすごそうなのうすうす気づいていたけど、本当にすごかった。こういうのが気軽にHTTP APIで実現できるとうれしい。某社は実現している模様だった。GrowthForecastもより多彩なグラフを描けるAPIになるとうれしい。

Pentaho CE 便利そう

Pentaho試そうと思っていたけど、勝手に無償版だと機能少ないようなイメージを持っていたけど、そんなことなく、普通に便利そうだった。ちゃんと試したい。

現状としては、どの分野においても高度化が進んでいて、もはや人間がどうこうできるレベルじゃない感じでした。もうプログラミング言語がどうだとか、PerlとかPythonだからいやだとか言ってる場合じゃないです。無理だったら外に投げるしかありません。

眠いのでこのあたりで終わりにします。

Butter v0.1.1リリースとButterの仕組みについて

f:id:harukasan:20140324233541p:plain

バグフィックス版であるButter v0.1.1をリリースした。OS X 10.8対応（ただしOS X 10.8で検証していない）と、Hookからのメッセージが通知されないバグをなおした。

昨日も少し書いたけど、ButterはRubyMotionで書かれている。ソースコードはMIT Licenseで公開しているので、下記リポジトリを参照して欲しい。

Butterの仕組みはとてもシンプルで1枚のWebViewを貼り付けているだけである。では、どうやってNotification Centerへの通知を実現するかというと、WebView.windowScriptObjectを使用して、JavaScriptコードを注入している。注入したJavaScriptでIdobataのpusher APIをbindし、そこからnativeコードのメソッドを呼び出すことにより通知を実現している。

実際のところIdobataクライアントというよりはIdobata専用ブラウザに近い。コードの行数としても300行くらいしかない。

基本的に1つのウインドウに複数の機能が備わってるのは嫌いで、ブラウザの拡張としてではなく単一アプリケーションとして実装したかった。UXとしてもブラウザの1ページよりもDock上で分離していた方が、チャットに集中できて良い。こういうhackは比較的手軽で満足度も高いのでさくさくとやっていきたい。

誕生日を祝う

今年も無事26歳になることができました。3月26日生まれの皆さま、誕生日おめでとうございます。 去年1年はすごい勢いで過ぎていきましたが、どんどん加速していきそうです。 ひとまず3月末締め切りになるものに対して危機感を覚えながら生きていく所存です。

なお、ウィッシュリストはこちらになります。

idobata.ioの非公式Macクライアント、Butterをリリースしました

f:id:harukasan:20140324233541p:plain

社内でIdobataを使う機運が高まってきている。普段Safariを使っているとIdobataの通知のためだけにGoogle Chromeを使うのは億劫なのでクライアントアプリを作った。主な機能は次の通り。

  • ブラウザを起動せずにidobataを閲覧することができます
  • Notification Centerにメッセージが通知されます
  • メッセージの通知はすべて、もしくは@mentionのみに切替ができます
  • WebViewがSafariとcookieを共有するため、Safariとログイン状態が共有されます

ソースコード、ダウンロードはGithubよりどうぞ。

はじめてRubyMotionでちゃんとしたアプリケーションを書いたけど、意外とはまりどころ少なくできた。でもObjective-Cのリファレンスを読んでRubyに変換しながら書くのは結構大変だ。あとせっかくのOSSなのに、RubyMotionを持っていないとビルドできないのが悲しい。

コード署名するためにMac Developer Programに登録したけど、相変わらず日本語ユーザーアカウント名ではAppleにお金を払うことができずサポートに対応してもらった。相変わらず手動対応のようだけど、ASCII以外の文字列Validationしてユーザに再入力させればいいだけなんじゃないのかな、と思うけどそう簡単じゃないんだろうそうだろう。

ひとまず欲しい機能は実装したので、今後はひとまずbugfixとリファクタリングだけになる模様。もしくは永和システムマネジメントさんに引き取っていただけるのを期待しております。

デザインを変えました

見る人がみればすぐわかるけど、このブログははてなブログで運用されている。これまではてなで提供されてるデザインをカスタマイズして使っていたんだけど、DOMが多くて、どのmarginが効いてるのかとか、どこでtext-alignされてるのかとか毎回調べないといけなくて四苦八苦してた。

2カラムレイアウトにしようと思ったのだけど、さすがにoverrideする方法では辛くなったので自分で書いた。harukasan.jpはMiddlemanで作っているので、ディレクトリに適当に突っ込んで、SCSSをbuildしてもらうようにした。ソースはここに置いてある。

DOMが結構難しくて、本文の下にあるシェアボタンをposition:absoluteで持ってきてmarginに置く様なことをしている。他のブログもこんなかんじで持ってきてるんだと思う。できればDOMの並び替えができれば良いんだけど、作り込むの大変だし、サービスの本質ではない気がする。

はてなブログでは1つしかないものには積極的にid attributeが使われていて、class attributeと区別されている。id attributeを使うのはそんなに悪くないと思うけど、CSSを書くときにid attributeとclass attributeを区別する理由は特にない。できればすべてclass attributeで書きたいので、id attributeと同じ値のclass attributeがついていると嬉しい。 あと、オフィシャルのテーマでも触れられてないけど#box1ってなんなんだろうか。

自作サーバ同窓会に参加してきました

もう1週間前になりますが、3月5日に開かれた自作サーバ同窓会に参加してきました。主催の@stanakaさん、会場提供頂いたフリークアウトさんありがとうございました。自作サーバカンファレンスが開かれた当時、私はまだ大学生でしたが、現役の方に話してもらいたい、ということで誘って頂けました。皆様ありがとうございます。

スライドにもありますが補足しておきますと、弊社ではデータセンターで自作サーバを動かすということはしておらず、自社サーバールームのルミナスラックで運用しており、プロダクション環境の自作サーバは既に引退しています。19インチラックにベニヤ版を突っ込むようなことはしていません。補足おしまい。

行き着く先はクラウドなのか

何かとクラウドと比べられがちだけど、クラウドを使わない理由は、データセンターのコストをそれより低くできているだとか、サービスの適正がクラウドよりもオンプレに向いているだとかそういうことである。pixivはクラウドよりも安くできる基盤が既にできあがっているので使っていないだけで、Amazon EC2も使っているし、他社のクラウドを使うこともある。発表中に自社データセンターにデータ解析基盤を作りたいと発言したけど、クラウドの基盤も一緒に検討している。結局向き不向きである。

台数が増えてきたらクラウドに行った方が良いかというと、そんなことはなくて、基盤整備するのに必要なコストはあまり変わらないんじゃないかな。ただ、このようなクラウドを使うのか、オンプレを使うのかという議論は、ハードウェア、ネットワークの調達、見積りに対して造詣が深く、その上に基盤を構築できるエンジニアがいて初めて成り立つのであって、そういうエンジニアがいないときは素直にクラウドを選ぶしかないんだと思う。

自作サーバをやるべきか

19インチラックに自作サーバを押し込むの全くおすすめしないし、今ではプロダクション環境で使うとかあり得ないなーと思うけど、今日も福利厚生として自作サーバラックを増やしましょう、みたいな話題があったので、弊社の自作サーバはなかなかなくなりそうにない。勉強するために本を買うのと一緒で、エンジニアがハードウェアを勉強できる場所を作るのはとても良いことだ。検証環境にもなるし、そんなに高くないし。あと、こういう経験もできないですしね。