BLOG::はるかさん

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

Norikra meetup #2で発表してきました #norikra

Norikra meetup #2でNorikraをログ解析に使うというごくごく一般的な内容の発表をしてきました。主催の@tagomorisさん、会場を提供頂いた:DeNAさん、皆様ありがとうございました。1年前に導入を検討し始めて、別に特段変わったこともしてないし、すごくヘビーに使っている訳でもないので、ゆるくまとめようとおもったらかなり時間余ってしまいました……

speakerdeck.com

最初MongoDBのcapped collectionに入れていたのが、Elasticsearch/Kibanaが流行してElasticsearchが全文検索以外に使われ出したり、ログ解析のトレンドはすごい勢いで変わってきているように感じます。Stream processingを行う方法にはFluentdのプラグインを用いる方法がありましたが、使っているfluent.confの中にfluent-plugin-numeric-counterとかfluent-plugin-numeric-monitorとかそういう集計処理を行うような処理があるようだったら、Norikraを導入することで便利になるかもしれません。

Norikra自体はログ解析以外にもストリーム処理を行うアプリケーションに組み込んで利用するにもとても便利で、@shunsukeaiharaさんの事例や、@fujiwaraさんの事例はとても参考になります。Listener pluginを使えばFluentdを使わなくてもNorikraによるストリーム処理を組み込んだアプリケーションができそうです。

ログ解析に関しては、解析に使える基盤はだいぶ出そろってきた感じがあります。次は可視化であったりとかオフラインに落とすところだったりとか、前処理であったりとか、そのへんもう少し工夫が必要かなと最近感じているところです。

CoreOS Meetup Tokyo #1 で発表してきました #coreosjp

昨日2015/04/09開催されたCoreOS Meetup Tokyo #1で登壇させて頂きました。ホストして頂いたみなさん、会場を提供頂いたフリークアウトさん、ありがとうございました。rktの話題もキャッチアップできたし、CoreOSのリリースの仕組みにも触れられて良かったです。CRIUすごくおもしろいし未来かんじました。

speakerdeck.com

pixivでCoreOSを運用してみて、こういうこと考えないといけないよね、って思ったことを雑多に羅列しておきました。CoreOSでクラスタを用意するのは良いんですが、デプロイの仕組みだったり、オーケストレーションの仕組みだったり、ロギングの仕組みだったり必要で、結局PaaSにあるような機能は必要になるよね、っていうのが結論で、そうなったときに、本当に毎回全部用意する必要があるのかどうか、ちゃんと考えないといけないのでは、と最近考えています。で、pixivマンガでは試験的にCoreOSを使ってみているわけですが、DockerのホストOSとしてはちょうど良いサイズ感であるものの、そもそもコンテナをデプロイする運用に持ってくためには結構考えないといけないことあるなってかんじです。例えば、一般的なアプリケーションだと、次のタスクは間違いなく必要になりますね。

  • デプロイメント
  • オーケストレーション
  • ロギング
  • セキュリティチェック

これらを自ら構築しても良いし、Kubernetesのようなものを使っても良いわけですが、IaaS使うのであればインスタンス単位でブルーグリーンするのが簡単なのでは、と思ったりもします。HerokuのようなPaaSであればもっと簡単ですね。CoreOS自体はコンテナのホストOSとしては悪くないサイズ感だし、IaaS上のインスタンスとしては適切なサイズであると思うので、クラスタリングやオーケストレーションのことや、自動アップグレードのことも忘れて、単純にコンテナのホストOSとして使うところから始めるのがいいのではないでしょうか。

Butter 0.2.0をリリースしました。

年度初めいかがお過ごしでしょうか。入社式やら新歓やら進級やらご多忙のなかお過ごしのことかと思います。さて、Idobata™の大規模アップデートに伴い、対応したButter v0.2.0をリリースしました。今回のアップデートに伴い古いバージョンのButterはうまく動作しなくなっていますのでご注意ください。

f:id:harukasan:20150401171515p:plain

2015-04-02追記: 既にButter v0.2.1がリリースされています

事前に@ursmさんにリリース後対応を一部やって頂いていましたので比較的簡単に対応することができました。ご協力ありがとうございました。ついでにRubyMotionのバージョンを上げたり、Xcodeのバージョンが上がったりしていますので安定性も向上しているような気がしています。

Butterを知らない方に説明しておくと、Idobata™のMac OS X用クライアントアプリケーションです。主な機能は以下の通りです。

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

通知機能とブラウザと分離される点の2点のみがウリの簡単なアプリケーションですが、皆様のIdobataコミュニケーションの一助になれば幸いです。

平成に追いつきました。

ということで27歳になりました。3月26日生まれの皆様、お誕生日おめでとうございます。まもなくアラサーと呼ばれる年代にさしかかってる気がしますが、やってることはそんなに変わらないですね。去年も3月末締め切りに追われていた気がしますが、今年も追われています。10年後も同じこと言ってそうです。

f:id:harukasan:20150319201056j:plain

今年はbeer@harukasanというイベントをはじめました。先週第1回を開催しましたが、いろんな話が聞けて非常に濃い時間を過ごせてとても良かったです。セゾンビールおいしかったです。小さいイベントですが、今年の目標として毎月続けていきますので、よろしくお願いします。来週には来月のイベントを立てる予定です。

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

春のインターンシップ講義で発表しました #pixiv

弊社で現在開催中の春のインターンシップ、pixiv SPRING BOOTCAMP 2015でインターン生向けに行った講義資料になります。今回もインフラチームで〜みたいなかんじで言われたんですが、他の講義でシステム構成のこととかスケーリングの話とかだいぶされてしまったので、全く違う話をしようかな、と思ったらだいぶエモーショナルな感じになりました。一応インフラの話してますよ。

インフラエンジニアは死んだ、と言われる昨今ですが、もう少し広義にとらえると、違った視点で問題が見えてくるんじゃないの、と思って今回スライドを作ってみました。ただし、時間がなかったので、IaaSの話しかできてなくて残念ですね。

講義中質問で、「こういうインフラの知識はどうやったら身につくのか」というのがあったんですが、スライド中にもあるようにインフラ自身は価値を生むことはないので、サービスをつくる上で必要に迫られてやることになるのではないかと思います。何も考えずに自分ができることをやり続ければよい、ということです。

大規模サービスのスケーリングについては昨夏話しましたのでそちらをご参照ください。

画像変換Nightを開催しました #imgconv

もう2週間も前になってしまいましたが、画像変換Nightというイベントを開催しました。共同主催の @cubicdaiya さん、 @yoya さん、発表者の皆様、会場を提供していただいたGREE株式会社の皆様、そして参加していただいた皆様、誠にありがとうございました。

発表資料一覧

今回の発表資料はすべてconnpassのイベントページにまとめています。

また当日のTwitterまとめがあります。

ImageMagickの話が多いのかなーと思ってたら、多種多様な内容で、Webサービスの運用からテクニカルな話まで相当濃くてめっちゃよかったです。次があったら画像フォーマットのもう少しテクニカルな話ができればな、と思います。

サムネイルマスタとgo-thumber

今回ハナの発表だったため、まず一般的なWebサービスの画像投稿処理についてまとめつつ、いくつかの問題を解決するためにマスタ画像を用意する話をしました。実際には、ユーザーが投稿する画像フォーマットは本当に多種多様であるため、きれいなマスタ画像を作るのもそれなりに大変だったりします。そこはImageMagickに頼っているんですが、マスタ画像さえできてしまえば、後の処理はそれほど大変じゃなかったりします。

第2回もやります(おそらく)

今回懇親会の余剰金が多めに発生しており、その後2次会もできていないため精算しきれずにいます。そのため第2回も開催したいと考えていますが、それなりに準備が大変なので、忘れた頃にやってくる、ぐらいでご期待ください。また、第2回を開催したい方、いらっしゃいましたらお手伝いいたしますので、ご連絡ください。

振り返り

Keep

  • 発表内容めっちゃよかった。
  • 事前にこちらから声をかけて発表内容集めたのよかった。
  • 会場がめっちゃよかった。
  • さっさと解散して片付けしたの手間少なくてよかった。
  • ピザを当日に頼んだので、あまりが出たりしなかった。

Problem

  • 主催者で打ち上げができてない。
  • 当日ドタバタしてた。会場準備時にやることを事前に整理しておくべき。
  • 会場担当の人と直接連絡取れるホットラインを持っておくべきだった。メッセージを中継してもらうだけ余計な手間だった。
  • ポテチを開けるタイミングが遅かった。もう少しはやくパーティー開けして回ればよかった。
  • ピザもう少し多くてよかった。余剰金が結構でてしまった。
  • 懇親会の時疲れ切ってて、あんまり話せなかった。

Try

  • 第2回をやる。
  • 会場ホスト以外のスタッフを募集してみる。

go-libwebpとgo-libjpegをつくった

libwebpとlibjpegのGo bindingであるgo-libwebpとgo-libjpegをつくった。

それぞれWebPとJPEGファイルのデコード/エンコードに対応している。どちらもimage.Imageを扱うことが出来てimage/jpegやimage/pngと同じ感覚で使えるインターフェースにしている。たとえばgo-libjpegのサンプルコードは次のような感じ。

package main

import (
    "bufio"
    "image/png"
    "log"
    "os"

    "github.com/pixiv/go-libjpeg/jpeg"
)

func main() {
    // Decoding JPEG into image.Image
    io, _ := os.Open("in.jpg")
    img, err := jpeg.Decode(io, &jpeg.DecoderOptions{})
    if err != nil {
        log.Printf("Decode returns error: %v\n", err)
        return
    }

    f, _ := os.Create("out.png")
    b := bufio.NewWriter(f)
    png.Encode(b, img)
    b.Flush()
    f.Close()
}

画像をimage.Imageで扱えるのでimage/pngや他のライブラリとのやりとりも簡単。既にimage/jpegを使ってる場合も少しの書き換えで使える。便利。

性能面では、go-libjpegはimage/jpegに比べて1.9倍くらい速い。簡単なベンチマークでは次のような感じだった。

BenchmarkDecode                 1000      26345730 ns/op  # go-libjpegを使ってYCbCrにデコード
BenchmarkDecodeIntoRGB           500      30886383 ns/op  # go-libjpegを使ってRGBにデコード
BenchmarkDecodeWithNativeJPEG    300      49815928 ns/op  # image/jpegを使ってYCbCrにデコード

libjpeg-turboを使うともっと速くて、OS X上でhomebrewのlibjpeg-turbo 1.3.1を使うと次のようになった。image/jpegに比べて5倍くらい速い。

BenchmarkDecode                 2000       9557646 ns/op
BenchmarkDecodeIntoRGB          1000      12676414 ns/op
BenchmarkDecodeWithNativeJPEG    300      45836153 ns/op

オプションによってはさらに速いはずだ。どちらのライブラリもいくつかのオプションは渡せるようになっていて、go-libjpegは縮小デコード (imagemagickのヒントオプションとか言われてるやつ)に、go-libwebpは縮小とクロッピングに対応している。

ただし、あまりデバッグされていないし、最低限のテストしかないし、バージョンも切ってないけど、これからプロダクションで使う予定があるのでそれなりにバグはとれていくと思う。たぶん。プロダクションで動いた暁にはpixivのエンジニアブログに書こうと思います。JPEGのサブサンプリングやWebPのYCbCrまわりで結構はまったけど、それは別の機会にQiitaにでもまとめよう。