#fluentdcasual #3 に参加してきた
昨日2013/12/13、DeNAさんにて開かれたFluentd Casual Talks #3に参加してきました。今回発表してないんですが、自分のスライドが3枚くらい画面に映ったのでだいたい満足しています。以下気になった発表の感想とかメモとか。
fluent-plugin-norikra
ずっと追っていると特に新しいことはなかったけど、EPLってやっぱ結構複雑だよなーと思った。ぱっとみSQLだけど、結構SQLじゃない。あと、Fluentdのニーズってログ転送と可視化のところが大きくて、その基盤がある程度できないと、ストリームでのデータ加工の重要性とかは見えてこないのかなーと思った。
ちなみに、NorikraとFluentdの連携方法とか使い方についてはQiitaにすごく丁寧な記事を書いたので参照にするとよいです。
FluentdでShadowサーバ用意したら捗った話(と性能検証の話)
buffer_chunk_limit周りのチューニングの話。ここらへんはFluentdで大量のログ流しはじめるとよく起こる話な気がするけど、ちゃんと検証したことなかった。自分がよく使っているのは次の様な設定。
flush_interval 1s buffer_chunk_limit 2m buffer_queue_limit 256
flush_intervalは1sに固定。buffer_chunk_limitは1秒で入力されるログが入るサイズで、最小にしている。buffer_queue_limitは最大メモリ使用量と相談しながら、何秒ログをバッファリングできるかを考えて決める。flush_interval 0sは試したことなかったので今度やってみよう。
Alternative Fluentd implementation in Go
FluentdのGo実装について。Fluentdプロトコル喋るGo実装ずっとつくりたいと思ってたのであとで参考にする。
Treasure Agent Monitoring Service
Treasure Dataが提供するモニタリングサービスについて。Fluentdの監視はバッチとかで行っているのだけど、各Fluentdにプラグインを入れておいて、そいつが監視サーバに情報を送るというアイデアは良いなーと思った。
Fluentd v11について
Fluentd v11について。マルチプロセスの標準対応とか、ラベルルーティングとか、タグ数珠つなぎしなくてよくなった点とかとても良い。ラベルルーティングとかどの程度使いこなせるのかなー、とか思いつつ期待している。
#pyfes 2013.11で発表してきました
はじめてSpeaker Deckを使っています。
さて、表題の通り先週の土曜日、先月末の11月30日、Python Developers Festa 2013.11で"pixivのインフラを支える技術"と題して、発表させて頂きました。流れとしてはid:cubicdaiyaの人が応募してまして、なんか2本立てはさすがにつらい、ということで話が回ってきたのであります。
ですます調おしまい。久しぶりの発表だったからか、前日4時間くらいしか寝てなかったからか、なぜだかやたらと緊張してたので、なに喋ったかあまり覚えていない。大変だったことといえば、発表時は全部薄いモザイクだったんだけど、公開用にすべて黒塗りに直す作業が大変だった。内容としては普段メインでやってる画像まわりとログ解析を中心に話した感じだけど、あらましになってしまって、あまり深い話ができなかったのが少し残念。中では結構泥臭いことをどろどろとしていたりもするので、そういうことも話せるとよいですね。pyfes楽しかったし、他ジャンルな発表ができる場はやはり良いなー、と感じた。
以下興味があったものの覚え書き。
Goハンズオン
午前中はGoのハンズオンに参加させてもらってたけど、結構ねむくてあたふたしてる感じだった。チャネルをmapに入れて管理するテクニック、すごく使えそうだった。あと、go runで気軽に実行できるの、やっぱり便利だなー、と思った。
HTTP 2.0
ハフマンで圧縮したり、前回のリクエストヘッダとの差分を送ったり、すごいがんばってる感じを受けた。特に前回との差分をやりとりするには、サーバとクライアントが常に同じ状態をもっていないといけなくて、すごく大変そう。ただ多重化まわりはかなり改善されてるので、上に乗る身としてはすごく良いなーと思った。
git-flowは死んだ
subversionすごいし、ちゃんと進化してることを知ったので、うちのsubversionもバージョンアップしたいと思った。
記述したいのはサーバの状態なのか、セットアップ手順なのか
id:catatsuyが石狩DCでLTしていたように、 弊社のセットアップスクリプトもserverspecで管理されるようになった。 これによりセットアップスクリプトもテスト駆動になり、JenkinsによるCIでテストされるようになった。 手でセットアップしてみないと合ってるかどうかわからない時代は終わりを告げた。
そして世の中はImmutable Infrastructureに向かい始めている。 これは仮想化技術により、サーバをつくったり壊したりが簡単になったので、 冪等性とか考えずに新しいサーバをつくってバシッと切り替えれば、変に悩まなくてもすむよね、 ということだと理解している。 弊社はオンプレだけど、サーバのセットアップってのは毎日のようにやっていて、 セットアップしては壊してを繰り返している。
で、話は戻るのだけど、serverspecとかconfigspec、chef、ansibleの記述を見ていると、 どれも状態を記述してるという点は一緒だと気づいた。 どういうことかというと「サーバにアプリケーションをインストールすること」を記述するのではなく 「サーバにアプリケーションがインストールされている」ことを記述するのである。 当たり前のことなのかも知れないけど、普段手続き型言語の世界で生きているとはっとすることであった。
さて、とはいえ、いつもはいろいろ検証しながら必要なパッケージをまとめて、サーバのセットアップ手順を作っている。 これはとても手続き的な作業で、最終的な状態を把握するのは難しいし、 必要なパッケージさえ入れば、必要じゃないものが入っていてもあまり困らない。 ここで本当に必要なのは、サーバの完全な状態を記述できる言語なのか、テスト可能な手続き型言語なのかといわれると、 実は後者なのでは、という気がしていて、そのようなアイデアを練っていたりする。
試験前には掃除をしたくなるよね
harukasan.jp、3度目のリニューアルである。
以前のharukasan.jpはRuby on Railsでできていたわけだけど、Webアプリケーションの宿命として常にメンテナンスし、新しくしていく必要がある。このコストは非常に大きいし、記事を書くモチベーションを削ぐ要因になっていた。
新しいharukasan.jpはポートフォリオであることを意識してデザインした。発表のスライドや、他の記事等をまとめている。発表したときの感想記事を書き忘れることが多いので、せめて発表スライド一覧がわかるようにした。
このはてなブログは技術系の話題を書くのに使う予定。放置中のはるかさん@はてなブログもあるのだけど、それは気が向いたら更新する感じにしたい（つまり放置ということだ）。こっちも放置になる気がするけど、モチベーションが続くうちは更新するはずだ。
