msgpack-inspect を作った - たごもりすメモ
MessagePackはJSONぽいけどバイナリでデータサイズが小さく抑えられ、またシリアライズ/デシリアライズが比較的高速であるとして広く使われておるところであります。なんか #linedevday にいるせいで口調がおかしいな。 が、バイナリなせいでデータを作ったあとその内容が正しいかどうか確認するのがいまいち面倒くさく、いちいちunpackするスクリプトを書いて中身を見る必要がある。JSONみたいに目で見て思った通りの表現になっているかどうかを判別するのは普通の人間にはなかなか難しい*1。 このため開発時にデータがバグってるのかコードがバグってるのかが分かりづらく、MessagePackを利用したアプリケーションおよびサービスを開発する上で問題になっていた。 ので、MessagePackのバイナリデータを食わせると内容を分かりやすくダンプしてくれるツールを作った！ のです！ msgp
fluentdとシステム設計の小ネタ - たごもりすメモ
あるいは http://yugui.jp/articles/879 へのreply。 システム監視をfluentdに統合してしまうべきか否か システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。 それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。 Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく
"Hbase at Facebook" に行ってきた - たごもりすメモ
名称表記が揺れてて微妙だけど Hbase at FaceBook on Zusaar このイベントに行ってきた。Facebookの人は "HBase Tokyo meetup" と認識していたようだ。 内容のまとめはやらないので、以下の各ページなどをご覧になると良いのではないでしょうか。 Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB… Hbase at FaceBookのまとめ - Togetterまとめ FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編） － Publickey FacebookがHBaseを大規模リアルタイム処理に利用している理由（後編） － Publickey セッションの内容と自分が考えたことと人としゃべったことをいっしょくたにここに書いておく。
fluentd のベンチマークとってみたよ！ - たごもりすメモ
入出力プラグインをrubyで書けるのがじつにいい感じの fluentd がいい感じに見える。 fluent/fluentd · GitHub ので使えるかどうか、使えるとしたらどれくらいのノードを用意すればいいのかについて考えるため、とりあえずベンチマークをとってみた。 結論 以下非常に長くなるので結論だけ書くと、大変使える感じ。現状だとほとんど何も考えずにデータ中継させても秒間1万メッセージ、100Mbpsくらいまでは処理できる。効率よくなるよう流す側も考えてやれば 300Mbps を超えるデータの転送に成功した。だいぶいい感じ。 なおこれは in_scribe および out_scribe を使用した場合で、開発者 @frsyuki によるとMessagePackでのデータ転送の場合はこの倍くらい出るらしい。 もちろんこれは右から左に流しただけなので現実にタグによるルーティングだとかロ
UserAgent判定器 Project Woothee はじめました - たごもりすメモ
UserAgent判定ライブラリはCPANに数多くあるし他の言語でも似たようなものだと思うが、ライブラリや言語をまたがって一致した結果を返してくれるようなものは存在しない(と思う)。が、特にHadoopを使うようになってJavaの事情をある程度無視できなくなってくると、これがたいへん問題に思えてきた。Javaで書かれたUserAgent判定ロジックが欲しいが、普段書くコードはJavaではない*1ので、他の言語でも全く同じように判定してくれるライブラリが欲しい。結果が食い違っていたり、新しいUserAgentを判定したいときに片方だけ対応されて片方は置き去りになったりすると大変困る。 ということで、作った。v0.1.0。現状ではJavaとPerlの実装がある*2。 https://github.com/tagomoris/woothee https://github.com/tagomori
Hoopの性能を確認してみたらもうlibhdfsとかオワコンでHoop使えって結果になった - たごもりすメモ
前に書いた エントリ の通りHoopが有望な感じだったんだけどどのくらいの性能が出るのか見てみないことには本番投入して性能出ませんでした乙、ということになりかねない。ので見てみた。 なお検証に関係する環境としては以下の通り。ちなみに前はCDH3u1で試してたけど、今回はCDH3u2 (JDK6u29) on CentOS5。メモリが問題になることは全くないので全て省略。 ベンチ用サーバ Intel Xeon 4Core HT 2.4GHz データ中継サーバ (deliver) Intel Xeon 4Core HT 2.4GHz Hadoop NameNode (+JobTracker) (namenode) Intel Xeon 1Core HT 3.16GHz Hadoop DataNode + TaskTracker x9 Intel Xeon 1Core HT 3.16GHz Ho
Hive Client Webアプリケーション shib をつくった - たごもりすメモ
(2013/04/02追記 see: http://d.hatena.ne.jp/tagomoris/20130402/1364898063 ) まだ完成度がいまいちだからなーと思ってエントリ書いてなかったんだけどLTでしゃべっちゃったので、ちゃんと書いておく。 Hiveにクエリを発行して結果を確認するためのWebアプリケーションを社内用途で作ってるんだけど、普通に他でも使えると思うので公開してあります。 tagomoris/shib · GitHub シブ と読みます。 セットアップ方法はドキュメントを参照のこと。起動してブラウザでアクセスするとこんな画面が出てくる。 使いかたは見ればわかる、と思う。たぶん。クエリは参照専用(SELECTのみ)。 __KEY__ とか __KEY1__ とかがプレースホルダですよってくらいかな。エディタ内でプレースホルダを書くとプレースホルダを置換する値
RAIDレベルの話: 1+0と6はどっちが安全か？ - たごもりすメモ
仕事でちょっくら12台のHDDを使ったRAIDアレイを組むんだけど、その折にちょうどTwitterで「RAID-1+0にしないとRAID-6とか怖くて使えませんよ！」というウソ八百な内容のWebページのURLを見掛けたので、いいかげんそのような迷信が消え去ってもよかろうと思って書くことにした。 1重ミラー設定のRAID-1+0は安全性においてRAID-6に劣る。ただし、正しく運用されている場合に限る。*1 知っている人はずっと前から知っている事実ではあるんだけど、某巨大SIerなんかでも高い方が安全に決まってる的な残念な脳味噌の持ち主がいっぱいいて「いやあデータの安全性を考えるとRAID-1+0」とか考えもなしにクチにし、そっちの方がディスクがいっぱい売れて嬉しいストレージベンダーもニコニコしながら否定せず売りつけて去っていくといううわなにをす(ry まあそんな感じで。ちなみに正しくない運
ソースコードビューア GlassDolphin for iPad/iPhone 本当に本当に完成！(ただし審査待ち - たごもりすメモ
えー、先日のエントリでお知らせしたときにはかなり時間かかるかなと思ったら、意外にもあれこれさくさくと上手くいきまして、本日再度AppStoreに提出いたしました。しかもなんと機能使い勝手その他、全く低下しておりません。バイナリを作成するときの構成を変えただけ(使う上では全く関係ない)。 ということで！ めでたく！ AppStoreの中の人の審査を通れば On Sale ですよ！ まあそっちの審査もかなり不条理なことが色々起きるらしいけどねハハハ！ スクリーンショットはめんどいんで前のの使い回しと、あと追加でいちおうもうちょっと貼っておきますヨ！ 審査通過をもう少々お待ちください！ ちなみに技術的(というかなんというか……)な経緯については別のエントリを起こすので、そっちで。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
