ローファイ日記

出てくるコード片、ぼくが書いたものは断りがない場合 MIT License としています http://udzura.mit-license.org/

Nishitetsu.rb をやります。という話

以前より id:nagachika さんとやろうと言っていたミートアップ、今年ついにやります。

fukuokarb.doorkeeper.jp

ジョイナス！

で、Nishitetsu.rbっちなん？

という方も多いと思うのでバックグラウンドを説明すると、

  • Tokyu.rb | Doorkeeper というコミュニティが東京にある
  • Tokyu.rbは、Tokyu沿線のRuby技術者がオフラインで集まって、お酒やご飯を楽しもう！というイベントとなっています というもの
  • 同じようなコンセプトのルビースト会合を福岡でもやりたいね
  • 向こうがTokyuならこっちはNishitetsuでは？？

という感じです。Nishitetsuであれば、沿線はもちろん、福岡全土にバスが走っていますので、福岡だいたい全土のRubyistのご参加をお待ちしております。

今回は、Rubyらしく火鍋（会場も西鉄薬院駅近くですね）ですが、今後美味しいお店と聞けばNishitetsu沿線かバス停沿いのどこでも開催できればなあと思っていたりします。

ジョイナス！

RubyWorldConference 2015 でOpenStack Ruby Wrapperの話などをした

話しました。

www.slideshare.net

111枚、なんとか収まりましたと言いつつ後半は早口...

書いてある通り、OpenStack Ruby Wrapper "YAO" と、その周りのツールたちとで、まずはペパボ周りの人たちのためのOpenStackエコシステムをOSSで作ってるみたいな話です。

github.com

バージョンも地道に 0.2.1 となり、対応APIも増えてきました。ロゴも、5人いるカレー四天王の一人 id:Horaotoko によるものを採用し、何だか勢いが出てきた感じします。

horaotoko.hatenablog.jp

この分野でセカンドシーズンをやり始めている経緯はスライドに書いてある通りです。ぜひご利用ください！パッチ、事例紹介もウェルカム！です。

松江、久しぶりだったんですが、街と自然が美しく、良いなと思いました。懇親会の食事も美味しかったです。まあ福岡もおいしいんですが。とにかく日本海最高です。

久しぶりに会うRubyist、ついにお会いできたRubyist、インターネットの妖精だと思っていた人にひょっこり遭遇する、などなど、出会いと再会に恵まれるイベントでした。

Let's use computer!!!

fluent-plugin-json_expanderというものを作ったんだ

github.com

やりたいこと

  • データとして流れてくるJSONの中身を見て、動的にアウトプットを編集したい。

こういうことができます

こういう設定を書いておく。

<match access.summary>
  type json_expander
  subtype growthforecast

  <template>
    gfapi_url http://127.0.0.1:5125/api/
    graph_path ${data[mothor_host]}/${data[vhost]}/${key_name}
    name_keys count_2xx,count_3xx,count_4xx,count_5xx
  </template>
</match>

すると、こういうデータが流れてきたときに、

// tag = access.summary
{
  "mother_host": "kvm001.udzura.jp",
  "vhost": "front.udzura.com",
  "count_2xx": 1234,
  "count_3xx": 567,
  "...": "..."
}

受け取って、内部でtemplateからこういうoutputを生成して、そこに流し込んでくれます。この場合はout_growthforecastに受け流す。

type growthforecast

gfapi_url http://127.0.0.1:5125/api/
graph_path kvm001.udzura.jp/front.udzura.com/${key_name}
name_keys count_2xx,count_3xx,count_4xx,count_5xx

オプションなど詳細は READMEをどうぞ。

背景、作ってみて思ったことなど雑感

hb.matsumoto-r.jp

松本リーなんとかさんがこういった検証を進めていて、その一環でぼくに"""圧"""がきたのでgrowthforecastの設定がより便利になるよう作った。もちろん、vhostごとに集約先のログファイル名を変えたい、しかも動的にやりたいんだ！！１、といった場合にも有効だと思う。

プラグインの製作の過程では、 id:tagomoris さんの先行実装、というかforestがめちゃくちゃ参考になった。感謝してもしきれません...。

github.com

このへんとかですね。

おかげで、Fluentdの内部実装にも若干詳しくなり、なるほど綺麗な設計だなと思うなどした。いつかまとめるかもしれない。。

制限事項

レコードごとに内部でアウトプットを作る（または使い回す）、という実装のため、いったんEventStreamとChainをその都度その都度ダミーで作って流し込む、という実装方針にしている。

このへんです。

このおかげで、多分タグやレコードをつかけえてフォワードする系のやつがうまく動かないかもしれない。一方、先ほどのout_growthforecastのような、データの流れの終端となるようなoutput pluginはちゃんと動くと思われる。この辺り、もっといい感じの実装方針があれば是非プルリクいただきたいところ。

稼働実績

先ほどの記事の通り、 id:matsumoto_r さんの自宅サーバで動作している。なのでプロダクション投入されていると言って差し支えないだｒ

メモリが太りそうな感じもするけど、いまのところそういうことは起こっていない模様。人柱求む。

そんな感じで、今月めちゃくちゃコードを公開した気がする。。

ソフトウェアをリプレースする前に考える三つのこと

個人的には三つの基準があるという話。

  1. そのソフトウェアが十分に古く、十分長い間保守されていないか
  2. そのソフトウェアを触れる人間が組織内に少なく、増やす手だても困難であるか
  3. そのソフトウェアで実現できることが、他の新しいソフトウェアでより容易に実現できるかどうか

1. についてはそうだろう、という感じだと思う。というかリプレイスの前提になると思う。バージョンが古いソフトウェアを使い続けると、脆弱性も出てくるし、一般的には開発の速度も低下する。

ただ、ここで重要なのは、2.や3.との兼ね合いかなと思っている。

例えば2.が1.より優先される場面というのもあるだろう。Hoge言語で作ったミドルウェアの保守について以下のような状況にあるとする。

  • 開発者が退職してしまった
  • Hoge言語に関するドキュメントが全然なくて学習が困難

という感じであればリプレースは検討に入れていいかもしれない。

しかし、ここで3.の観点も大事で、例えば古いからといってcronやlogrotateやらを別のミドルウェアにリプレースしようとする人はいないと思う。こういう場合は古い、ではなく枯れている、と呼ぶ。

とはいえ、最近のLinuxミドルウェアなんかを見ていると、枯れ果てたソフトウェアを平気でリプレースしかけてくる印象があり（典型的にはchronyやsystemdの登場）、もっと頭を柔らかくしないといけなそう。やっぱり「新しいソフトウェアでより容易に実現できる」のが大事なんだろう。

話戻って、ミドルウェアと違って言語に関しては、「変更し続ける」という観点が出てくるので、「枯れている」ことのメリットが少し小さくなる。例えばHoge言語に固有の優れた点があるのであれば（Erlangとかが連想されそう）頑張ってHoge言語を学習する方向でもいいと思うし、Hoge言語自体が古ければバージョンの高いHogeで書いても違うFuga言語で書いても書き直しという点では同じだろうし、そもそもそのミドルウェアを捨ててしまうのもアリかもしれない。

ここで感心しないパターンというのもあって、特に「自分がよく知らないからリプレースする」というのはあまりいい結果を生まない気がする。リプレイスはなんだかんだ多大なコストがかかるので、無知より、まだ好悪とか情熱とかでドライブされている方がうまくいくんじゃないだろうか...と思っている。

というのも、既存の技術情報について調べない、ということは、既存の 仕様 についてもよく調べずに思い込みで変更をぶっこんで意図しないトラブルを起こしがちな技術者の傾向の表出だと思われる。リプレースなので、トラブルは起こるだろうけれど、そういうものはコントロール可能な状態で起こさないといけない。

リプレースは大変だし、正解もないものなので、まずは冷静さが欲しいと思う。多分、0番目の基準が実はあって、「既存のシステムに対してリスペクトを持っている」という項目が必要なんではないか。

なお、やるな、という意味ではない。こういうことを言っておいてなんだけど、諸々コントロール可能なら積極的にやるべきと考える。

参考記事

myfinder.hatenablog.com

  • 何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること
  • ボトルネック以外触らない

至言。とはいえぼくは情熱とかその辺も許容するけど...。

どこぞでポエんだけど、せっかくなので書いてみる（たまには作った自慢じゃなくてウダウダとした考えのdumpもいいじゃない）。

最近書いたやつ @2015-10

monkfish

github.com

OpenStack環境で、テナントに所属しているインスタンスのネットワーク情報を参照して /etc/hosts を自動更新するやつ。内部DNSが使えないような構成の場合に便利かもしれない。

もともと、 id:lamanotrama さんのPerlのスクリプトでAWS向けの同じようなものがあって、それをGo言語でクローンして、それをOpenStackポートした。 gophercloud 最高だ！（ロゴが）

http://gophercloud.io

puppet-report_slack2

github.com

minne というプロジェットで雑に描いたPuppetのスラックレポーターを切り出した。こういう通知が来る。これは便利だと思う。

hi

「2」になってるのは、先行して同じようなモジュールがあったからだけど、それは動かなかったので自分で低依存で書き直した。puppetmaster/puppetserverどちらでも動く。Puppetのバージョンも2/3/4と動くと思われる（Ruby 1.8環境でマスターをあげている場合は、明示的に gem install json したほうがいい。というかREADMEに書こう。。）。

そういえばペパボに入っていつの間にか2年が過ぎた

udzura.hatenablog.jp

ペパボに入ってからのほうがアウトプット増えたのは間違いない。東京、福岡関係なく、毎日がチャレンジ（普通の意味で）です。

元気にやっております。

便利なリンクを共有します。僕と一緒に 106 South Indian に行きましょう