1月 012013
 

なんかTwitterを眺めていたら2012年のまとめみたいな記事が流れてたので僕も書いてみようかなと

大まかな流れ

Varnish尽くし
いやまぁいつも通りですね!
というのはそうなんですが、個人的に大きな出来事は

  • VMODの作成&公開
  • ログ読みツールの作成
  • varnish-miscのMLデビュー
  • 同人誌をVarnishSoftwareに送る
  •  
    です

    VMOD

    VMODは5つほど作成しました。

  • Varnishで簡単にリダイレクトができるVMOD作ってみた(vmod_redirect)@2月
  • X-Forwarded-ForをACLと突き合わせてみる(Varnish)@4月
  • VarnishでPOST・COOKIE・GETを扱うためのVMODを作ってみた(vmod-parsereq)@6月
  • VarnishでAmazon S3の認証ヘッダを作るVMODを作ってみた@7月
  • LDAPで認証したり情報を取得するVMODを作ってみた@8月
  •  
    この中で特に反響が大きかったのがvmod_redirectとvmod_parsereqです。

    vmod_redirectを作った理由はVCLのポリシーを壊さずに拡張するというPoCでした。
    VCLは柔軟性があるし、なんかポリシーなんてあるの?といった感じに思う人もいるかと思いますが
    超えてはならない一線みたいなポリシーを感じる作りになっています。

    僕がそれを顕著に感じたのが、リダイレクトの処理です。
    以下が公式が紹介しているリダイレクトを行うVCLの内容です。

    
    sub vcl_recv {
      if (req.http.user-agent ~ "iP(hone|od)") {
        error 750 "Moved Temporarily";
      }
    }
    
    sub vcl_error {
      if (obj.status == 750) {
        set obj.http.Location = "http://www.example.com/iphoneversion/";
        set obj.status = 302;
        return(deliver);
      }
    }
    
    

    一回VCL_Errorに飛ばして、そこから書き換えてリダイレクトするようなコードになります。
    リダイレクトは利用頻度が(おそらく)高いわけですから
    一つ関数を用意して処理すればいいと考える人も多いと思います。
    しかし、それを許さないところに超えてはならない一線を感じました。

    それならポリシーを壊さずにやってやろうと思って作ったのがvmod_redirectでした。
    目的は1行でVCLのポリシーを破壊せずにリダイレクトまでしてしまうということです。
    実際にユーザ見えではvcl_errorには記述する必要がないのですが
    内部ではフックすることで以下の記述のVCLを動かしています。

    
    sub vcl_error {
      if (obj.status == 301 || obj.status == 302 || obj.status == 303) {
        if(req.http.X-VMODREDIRECT-Location){
          set obj.http.Location = req.http.X-VMODREDIRECT-Location;
          return(deliver);
        }
      }
      /* ユーザが記述したvcl_errorの内容 */
    }
    
    

    正直この手法は穴を突いたものだと感じていて
    バージョンアップでふさがれるのも覚悟したのですが
    MLに投げたところ中々反応がよく、最終的にはVarnishSoftwareが商用サポートしています。
    あっ、許された?と勝手に考え、ここからどんどん他ののVMODを作っています。

    またvmod_parsereqというPOSTなどのリクエストをパースするVMODも作りました。
    これに関しては@dai_yamashitaさんにはかなりご協力をいただき感謝しています。
    初期のバージョンはかなりバグだらけで涙目になったのですが
    さまざまなログ取りをお願いしたり、実際にお会いしてその場でバグ取りもしました。
    おかげさまでいいもの仕上がったんじゃないかなと思っています。
    また、先日ロンドンであったVUG6-DevDayのディスカッションにおいて取り上げられるなど
    正直英語とかで尻込みせずに行っとけばよかったと後悔しました。

    さらにうれしい事にVarnish Security Firewallの一部として使われています。
    実際に使われるまでにはノルウェー・ブラジル・日本(僕)間でディスカッションをしながらやったのですが
    海外のOSSな人とやり取りしながら作っていくという経験は非常に面白くよかったなと思います。
    正直かなり英語でもどかしく感じたので今年こそはスラッとできるように!と決意を新たにしています。
    本当に毎回VarnishSoftwareのRubénさんには助けられまくりです、ありがとうございました。

    ログ読みツール

    varnishlogを見やすくするツールを作ってみた
    varnishlogが見づらいのでそれを見やすくするツールを作ってみました。
    実はこれ元々qpstudyでLTの前座用に作ったモノでした。

    スライドまで作ったのですが何か用事があってqpstudyには行けずにお蔵入りかなーと思ってたんですが
    せっかく作ったし公開するかーと公開してみたらVarnishSoftwareのニュースレターにも掲載されました。
    ニュースレターは購読してるのでメール来て読んでたらいきなり僕の名前が出てきてかなりビビりましたw
    これに関してはかなりコードが汚いので書き直します。
    今年は巳年なのでPythonでーなんて考えていますw

    MLデビュー

    投稿した内容はそこまで多くはないのですが、投稿したおかげで僕が認知されたっぽく
    さまざまな人と交流するきっかけになりました。
    初めての勉強会(qpstudy)に行った時もそうなんですが、最初の一歩はかなり勇気はいるものの
    いざやってしまえば
    「もっと早くやればよかった!」
    と考えています。
    まぁ英語はやらないといけませんが!

    同人誌をVarnishSoftwareに送る

    突然G+の方でVarnish本の現物ってどうやって買うの?といわれて半分混乱しながらEMSで送りました。


    EMSってすごく早いんですね、確か三日ぐらいで届いた気がします。

    まとめ

    去年もVarnishばっかやっていたわけですが(ブログでは)
    全体をまとめると海外デビューというのが大きいです。
    それと同時に英語力が足りないなど様々な自身の問題点に気づいた年でした。
    もっと英語力を挙げてVarnishはもちろんほかのOSSなどでも貢献できればいいなと考えています。

    まぁそんなこんなで今年もどうかよろしくお願いします。


     Posted by at 4:38 午前
    12月 162012
     

    なんとなく突然の死ジェネレータを使って退職しましたと呟いてみたら
    ネタと思われたのか、数人の方から「リアルな話ですか?」とリプライが帰って来ましたが本当に退職です。
    正確には有給消化中で年内は在籍しています。

    僕がクルーズに入社した2009年当時はまだ社名はウェブドゥジャパンでオフィスも麹町で
    ブログ、携帯公式コンテンツなどが主力コンテンツでしたが
    今ではモバゲー向けのソーシャルゲームとコマースを主力でやってます。
    いろいろ環境が激動するなかでコードを書くことはもちろん、
    ネットワークまで幅広い分野で貴重な経験をさせていただきました。

    何やってたの?

    ・社内PHPフレームワーク
    ・画像生成~配信(Varnish)
    ・集計
    ・パフォーマンス関連の調査など
    ・ネットワーク(直近3ヶ月ぐらい)

    など、他にも(Redisとか)やりたい放題を他のエンジニアの協力の下やっていましたが
    軸はフレームをやりつつサービス開発側とインフラ側の間で両者を繋ぐ仕事をしていました(と思ってる)
    開発とインフラが考えていることは最終的なゴールは同じなものの、
    それを行うために意識している点・導き出す手段はかなり異なります。
    その意識していることを両者で共有できて手段を最適化できればその相乗効果は計り知れないです。
    数あるSAPの中ではサーバの台数などは結構頑張ってる方で上手く役に立てたんじゃないかなと考えています
    (もちろんまだまだ改善できる点はあります)

    何で退職するの?

    kamipoさんのつぶやきに触発されたわけではないですが、確かに
    「今の会社では入社して嫌なことがなかったかというと嘘になりますが、本気で嫌で辞めたいと思ったことは一度もありませんでした」
    というのは確かです。
    まぁ、偶に地獄のミサワ風に
    「あー辞めたいわー会社超辞めたいわー」
    という気持ちになることはもちろん有りました。

    主な理由としては
    ・海外でも働けるエンジニアになりたい
    ・技術の幅を広げたい
    があります。

    海外については以前から漠然と考えていましたが、
    Varnish関係で海外の人とやり取りする中で具体的イメージが湧いてきました。
    別に海外で有名になるんだ~ということではなく
    海外でも普通に働けるように様々な技術を身に着けたいなと考えています。
    また、今のクルーズは僕にとっては非常に居心地がよかったのですが
    このままクルーズで働くよりも飛び出したほうが
    自分の技術の幅が広がり、新しいことができるのではないかと考えたからです。
    今年で30ということもあり、攻めるならそろっとやらないとというものありますが。

    最後に

    僕はクルーズで3社目で以前の会社でのキャリアも重要なのですが、
    その中でもクルーズではVarnishに出会う・インフラ・WAFをやるといった様々な事をやり、
    エンジニアである僕を形成するコアなところが作られたと考えています。
    時には失敗もありましたがその後も様々なチャレンジをさせてくれたクルーズに感謝します。

    狭い業界なので勉強会などでお会いすることもあるかと思いますが今後とも宜しくお願い致します。


     Posted by at 5:30 午後
    3月 022010
     

    ネタストック
    書いとかないと忘れるので・・・
    軽そうなやつから記事書こうかしら

    ↑重そう
    億レベルのレコードでのinsertなどの性能劣化比較(inno/isam/inno(pat)/isam(pat))
    MYSQLバルクインサートの件数での劣化具合
    InnoDBのレコード数によるcount系処理のio負荷について
    MYSQL不適切なパテーションでのペナルティ(io)
    ディストリビューションでのxfsのパフォーマンス比較
    varnishの負荷状態においてのpurgeによる負荷(regex含む)
    hiphophp(これは検証から・・・)
    thrift
    高負荷環境での正規表現コスト
    Nginx-FCGI(UnixDomain) Nginx-FCGI(TCP)で超軽いPHP環境での負荷変化とレイテシ TCPはlocalhost/自分のIP/別サーバ
    Nginx consistent hashing構築
    varnishのpurge関連(複数ドメイン)
    Nginx-Varnish構成でlocal/別サーバ構成でどれぐらい転送レートのペナルティを受けるか
    高負荷テスト Apache/Apache(mod_cache)/Nginx/Nginx(ncache)/Varnish
    ↓軽そう


     Posted by at 10:21 午後