PSGI – Perl Server Gateway Interface

スライド

tokuhiromさんとmiyagawaさんのコラボレーション。PSGIは仕様でPlackは実装。HTTP::Engineには仕様とAPIと実装が全て入っていたのでこれを分離しましたよ、というお話。YAPCの1週間前ぐらいから開発し始めていてすごい勢いで実装されているらしいです。PlackはいわゆるReference Implementationですが、かなり速いという話でした。Reference Implementationという用語を聞いて、JavaのServlet APIをなんとなく思い出しました。

シックスアパートフレームワーク

shigetaさん
スライド

Six ApartではMTフレームワーク, ArcheTypeの2種類のフレームワークがある。
MTではMTオブジェクトがData::ObjectDriverを継承している。Data::ObjectDriverはSix ApartのCTOの人が作っているORマッパ。memcachedによるwrite-throughキャッシュが実装されてたり、shardingもサポートされている。たしか2年前ぐらいのYAPCでセッションやってたと思います。

驚きだったのは、TypepadではHTML::Templateを使っているということ。普通はTTとか最近だったらText::MicroTemplateのような高機能なものを使うと思うのですが、ななぜあえてHTML::Templateなんでしょうか。っていうのを質問すれば良かったと今になって後悔。

API Design

sartak – Shawn M Mooreさん。Mooseのコミッター。
スライド

• Moose
• Path::Dispatcher
• HTTP::Engine
• Dist::Zilla
• IM::Engine

今日はこれらのプロジェクトが持つクールなAPIの話をします。大事なのはテストをたくさん書くこと！なぜならテストを書けば使いやすいAPIかどうかわかる！あとはMooseなどの話。HTTP::Engineは新しいサーバのInterfaceが出てきても一行書き換えれば対応可能なところが素晴らしい、と言っていました。
英語だったので話の内容の半分も理解できなかったのが無念…

Modern Catalyst

hidekさん。最近DeNAに転職した? らしい。スライド

• Catalyst 5.8について
• Mooseベースになった
• M,V,Cの名前空間がdepreatedになった
• NEXTが…
• Catalyst::PluginなnamespaceのプラグインをCPANにあげるとmstにおこられるw

他のセッションでも「Catalyst 5.8使ってます」という話をちらほら聞いたのですが、Mooseベースになったら速度が遅くなったりしてないのかな、というのが気になっています。

ark – framework inspired by Catalyst

KAYACのtypesterさん。スライド

• KAYACでは大量に自社サービスを作っている。
• Catalystでもいいんだけど、もうちょっとライトなWAFがよかったのでHTTP::Engineをベースに作った。
• CGIモードでも割とサクサク動くようになってる。
• CGIの場合はクラスはlazy loadingするように工夫
• あとdispatch tableのキャッシュもしている
• テンプレートはText::MicroTemplate::Extendedというものを使うのが推奨されている。もともとはMojo::Templateをokuさんが切り出したもので、それを拡張している。
• Ark::Models – CLIスクリプトからでもModelを使える仕組み。あとlazy loadingをやったり。
• Ark::Form – HTML::Shakanベース
• KAYACのArkで作られたサービスの一部はなんとソースコードが公開されている！
• いなめなヶ崎
• im.kayac.com

Ark、Catalystとほぼ互換っていうのがいいなぁというのと、日本のモバイル対応版が早くリリースされないかな、って思いました。モバイル対応はもう必須になりつつあるような世の中なので、そのあたりのベストプラクティスを積み上げていってほしいなぁと。

優しいモダンなWAFの作り方

dannさん。スライド

• モダンなWAFとは？
  • プラガブル – Plagger
  • サーバ抽象化 – PythonのWSGI
  • フルスタック – Rails
• Angelos::PSGI::Engine
• Plack::Requestを使ってる
• HTTP::Routerを使ってる
• シンプルなWAFなら2,3時間あれば作れちゃう！
• 次、WAFの拡張部分の作り方(プラグイン)
• コアは小さく
• 拡張可能な箇所を限定(Controller, View, Middleware, Request, Response)
• Hookポイントを明確にする
• プラグインの種類は大きく分けると2種類
• RequestやResponseのライフサイクルへのHook系
• メソッドはやす系
• 適切なデフォルトセットの提供することが重要
• そうしないとUnicode化するためのTIPSが乱立したり、Inflate/Deflateするための(ry
• HTTP::EngineやPlack、HTTP::RouterなどのモジュールのおかげでWAF作りがかつてないほど簡単になっている！

Arkの話も聞いてて思ったのですが、Sinatraみたいなレベルであれば本当に2,3時間で作れそうな気がしました。これからフレームワーク戦国時代の幕開けですね。そして懇親会でも直接dannさんに言ったのですが、Angelosを早くリリースしてほしいです… (切実)

Booking.com & Perl

Cristina Nunesさん(from リスボン,ポルトガル)。スライド

Class::DBI(frozen version)
HTML::Mason
HTML::Template (forked version)
• Perl 5.8.8
• Class::DBI
• HTML::Mason
• HTML::Template(forked version)
• なぜPerl? –> 簡単で速い
• なぜHTML::Template? –> 簡単
• なぜClass::DBI? –> 聞き取れず(一番聞きたかったのに)
• Apache + mod_perl
• MySQL
• memcached
• git
• Jabber
• 将来のゴール
  • Perl upgrade
  • Modules upgrade
  • Apache + mod_perl upgrade (to 2.x)
  • MySQL upgrade (to 5.1 or 5.4)
• フロントエンドのWeb Server: 100台以上
• MySQLサーバ: 100台以上
• データセンターにあるサーバは700台以上
• IT at Booking.com
  • Perl developers
  • Java developers
  • Network engineers
  • Sysadmins (社内SEみたいなものかな)
  • Web designers
• 世界に25オフィスある
• 1900人の従業員
• 71000L hosts over 70 countries
• 4500+ distribution partners
• 24 languages available on website

Booking.comって初めて知ったのですが、ヨーロッパのホテルはかなり網羅されているという情報がIRCで流れてました。なんでいまだにClass::DBI使ってるんだろう、と思いましたが、mod_perlのバージョンも1.x系なので、やっぱりサーバの台数が多いとアップグレードも大変なのでしょうね。「Booking.comという会社は著名なPerl hackerを何人も抱えている会社なのです」という牧さんの補足がありました。

Key Value Store with O/R Mapper

yappoさん。スライド

• Key Value StoreとO/R Mapperの合わせ技 –> Data::Model
• Data::ModelはいわゆるO/R Mapper
  • DBI, memcached protocol, Perl hash, Perl code, Gearman
  • Q4Mにネイティブ対応
  • 透過キャッシュ
  • MixinによるSchemaクラスの拡張
  • ちょっとなういイテレータ
• なんで既製品では駄目だったのか？
  • Class::DBI – DBICに移行する方向になってる。偉大なる先輩に感謝
  • DBIx::Class – 過去に使っていたがあまりいい思い出がなかった
  • Rose::DB, Jifty::DBI – 見る時間があまり取れず…
  • DBIx::Moco – ドキュメント少ない。実際にサービスで投入されているものと公開されているモジュールの差異が激しい
  • Data::ObjectDriver – Six Apart謹製。意外とテスト少ない＆document少ない。ただしコードは大分参考にさせてもらった
  • DBIx::Skinny – 日本のPerl ORM専門家のもの。シンプルなスキーマに対して「生SQL書けます」はあまり魅力的じゃなかった。
• 結局調べているうちにORM作成のポイントがわかってきたので自分で作ることにした
• ORMはSchema, Iterator, Row, SQL, DBの5つのものがあればよい
• Data::Modelのデモ(詳しくはスライドを参照)
• TokyoCabinetをストレージとして使う場合、データを小さくした方がキャッシュにのったり色々嬉しいので、データは圧縮して小さくするべし。
• Perl標準のStorableはデータ効率が悪いことで有名 –> 代わりにMessagePackを使用(これがすごいらしい)
• KVSがストレージならALTER TABLEが必要なくなる。FriendFeedの例のようにすれば、スキーマなくても大丈夫
• MessagePackがとにかくすごいらしい

まずスライドがFiciaだったのが驚きでした。なるほど、そういう使い方できるんですねー。途中のData::Modelのチュートリアルでは、その高機能さ(透過キャッシュやMasterSlave、column_sugar)に驚きました。自分でもオレオレORM作ってるのですが、相当レベル違うなと感激しましたです。その他、MessagePackがすごい使えそう、というのがよくわかりました。圧縮のアルゴリズムがカリカリ過ぎです。

simple or mapper DBIx::Skinny

nekokakさん。スライド

• なぜ自分でORMapperを作ったか？
• DBIx::Classが微妙…
  • 便利だけど発行されるSQLが微妙
  • パフォーマンスが出なかったりする
  • 生成されるオブジェクトがでかすぎるため重い
  • カスタマイズしようにもソースがでかすぎる
  • DBICで速度でない場合は生SQL書くことがあるが、Inflateとかしてくれない
• 生SQL書いてinflate/deflateしてくれるライトなものでいいんじゃないか、というところにたどりついた
• DBIx::Skinnyのデモ
• relationshipは特に何もしない
• コアは小さく、がモットーなので、拡張したい人はラッパーを書けばいい
• 何人かの人に興味持ってるみたいなので、Skinnyみたいな方向性はありなのだなと思った。

ちょいと前にSkinnyのバグを見つけたのでメールでパッチ送ったりしていて、ちょうどYAPC当日にnekokakさんと直接お話させてもらう機会があったのですが、いやー非常に嬉しかったです。懇親会でもお話しさせてもらったのですが、やっぱり生SQL全然ありだよね、と思いました。もともと自分がSkinnyに興味を持ったのは、自分が3年前ぐらいに会社で作ったO/R Mapperと非常に設計思想が似ていて、「へー」と思ったのがきっかけです。(もちろんSkinnyの方がAPI的にも非常に洗練されているのですが…)

というわけで、自分もDBIx::Thinというのを作っているのですが、早く安定板をリリースしないと。とにかくエンジニアとしてはとても刺激になったセッションでした。

『Ficia』インフラとPerlにまつわるエトセトラ

hirose31さん＠えとらぼ。スライド

• Linux 2.6, Apache2, mod_perl 2.0
• mod_perl 2のメモリ関連のチューニング
• 推測するな計測するべし(ps, top)
• fork(2) – Copy On Write
• /proc/PID/smaps (kernel >= 2.6.14) – 共有領域: Shared_Clean + Shared_Dirty
• いわゆる親プロセスと子プロセスの共有メモリ領域の話
• id:naoyaさんの日記が詳しい
• 使うモジュールは親プロセスで起動時に(startup.plなどで)ロードする –> 子プロセス独自のメモリ領域にロードしないので節約になる
• Apache起動直後は共有率99%。時間が経つと共有率が40%ぐらいになり、プロセスのメモリ消費量が多くなる
• 使用しているモジュールの一覧をどうやって取得するか？
• Apache2::Status –> Loaded Modules で一覧を確認
• あと親プロセスでモジュールをロードしておくと、コンパイル済みで即戦力になるのでオーバヘッドが少ないらしい
• サイズがもりもり太っているモジュールを探す方法 – Apache2::Status + B::TerseSize
  。Memory Usageで一覧を確認
• nagiosで少しでもswapしたらメールを飛ばすようにしている
• 以降、httpd.confの話
• StartServers != {Min,Max}SpareServers
• 忙しい時はMaxに。ヒマになったらStartServersの数に戻る –> forkするのがむだ？だったら最初から全プロセス起動しておいた方がいい
• /etc/init.d/httpd stop
• stopしたのに新規リクエストが来ちゃう(ロードバランサーのヘルスチェック後とか)
• start – 起動時からフルでプロセスを起動するので、start直後にリクエストが来ると負荷が高くなってしまう。一定時間おいてからロードバランサーに入れる必要がある。
• ロードバランサーのヘルスチェックのURLを動的なものにしておき、フラグファイルがあったら200を返すようにするとか。
• あとはmatrixの話

mod_perlのチューニングのような話は、最近はみんなFastCGIに移行しているのかあまり聞かないので、非常にためになりました。あと、StartServersで最初から一気にプロセス立ち上げておく技は昔考えたことあったのですが、LBのヘルスチェックとか面倒だなぁと思って挫折した経験があります。なるほど、ヘルスチェックのURLを動的にしてフラグファイルで管理っていうのは全然ありだなと思いました。というかRubyのpassengerとかはそんな感じの実装になってますね。

一日を通しての感想

おそらく初めて丸一日ぶっ通しでセッションを聴いたのですが、最後の方はやはり集中力がもたなくていいセッションでもあまりちゃんと聴けなかったのが残念です。ただ、エンジニアとしてのモチベーションは上がりまくりで、懇親会中も「早く家帰ってコーディングしたい」と実は思ってました。あと酔った勢いでDBIx::Skinnyのポスグレ対応とかしたのですが、バグとかテストを sfujiwara さんに面倒見てもらったようで、非常に恐縮でした…

個人的に非常に参考になったのは、Ark、Data::Model、DBIx::Skinny、Ficiaのインフラでした。WAF, ORMapper, インフラの話が聴けて大満足です。

DeNA loves Perl

notoさん。スライド

• DeNAはエンジニアは100人ぐらいで半分ぐらいはモバゲー
• 今回のYAPCでも3人がセッションで発表している。(hidek, zigorou, matsuda)
• 最初のbiddersはJava+Oracleだった
• モバオクを川崎さんが作る時に初めてPerlをつかった
• Perlは読みやすい、実行速度も速い
• 最近はmyDNSのDNS RRの代わりにLVSを使うようになった
• memcachedも使っている
• MySQLのshardingもしている。モバゲーでは90個ぐらいに分割されている
• mobamail
• モバイルのメール配信 – キャリアの都合で接続がdenyされることがある。大量に送り続けるとdenyされる
• キャリアのMXレコードは異様に少ない
  • docomo.ne.jp – 4IP
  • ezweb.ne.jp – 1IP
  • softbank.ne.jp – 1IP
• キャリアのメールサーバが少ないから、送信側で送信先を分散できない
• mobamail – Perlで実装したモバイルメール向けの配信サーバ。配信するだけなのでMTAじゃない(SMTP受ける方は実装してない)
• コネクションを貼るところでIO::Selectを使っている
• キャリアの制限の範囲内でなんとか最速で配信できるようにする。キャリアごとに細かい設定ができるように。
• SIELLA Engine – より速い。さらに自分たちで設定しなくても楽。最近はこっちを使っている(ズコー)
• (話は変わって)モバゲーのオープン化について
• OpenSocial + Game API 法人に解放
• 10/5 にフォーラム。来年1月以降に一般公開
• DeNAのエンジニアのポリシー – ビジネスの成功にコミットすること
• お金で解決しない。技術で「安く、早く」
• ビジネスの成功を重視しているので、きれいな技術が二の次になっているのは否めない
• 100人近くPerlエンジニアがいるのにCPANコミットがない
  • 他社の特許侵害のリスク(一部上場しているので目をつけられてしまう)
  • やりたい人がいたら推奨しようとしているが…
• DeNAのPerlでの開発方針
  • 「一筆書き文化」：再利用せいや汎用性の設計に時間をかけるくらいならそういうことは考えずに書く方が速い
  • サービス単位の独自性・機動性重視＝モジュールの共有なし
  • 割り切りの思想、逆転の発想、これでサービスを速くリリースしてきた面も
• 今後の展望
  • 大きな開発チームでのポリシー
  • more test code
  • MobaSiFの次のバージョン
• DeNAで一緒にコードを書きましょう!
  • as DeNA software engineer / architect
  • as developer of moba-ga town
  • as CPAN author

携帯向けのメール配信でSIELLA Engineを使っているのが驚きでした。ああいうモバイル向けのパッケージ製品って他にもKlabのアクセルメールとか良さそうなのいっぱいあるし、やっぱり餅は餅屋にって感じなのでしょうか。

モバゲーのAPIがオープン化されるということは、PC向けにFlashでゲームも作れるのかな？というのが気になりました。現状モバゲーのPCサイトってモバイル版のはりぼてみたいなものなので、これを機にPCサイトも盛り上がるといいのかなぁと。

endeworksでのWeb Appの作り方

33rpmさん(船木太郎さん)。スライド

• 牧さんが代表の会社です。
• 特別なことはやっていない
• 開発サーバは用意していない(個人のMac上で開発)
• Test::FITesque が最近の流行り（読み方よくわからない）
• ディプロイ – git pullするだけ。ディプロイツールといったものは使用していない
• Apache+FCGI – daemontoolsでFCGIのプロセスを管理
• Catalystを使用
• Mooseを使用 – Catalyst 5.8をプロダクション環境で使用
• APIモジュール
• CatalystのModelを使用しない
• CatalystのModelは当たり前だけどCatalyst依存
• ModelはWebという枠組みの外、たとえばCLIやWorkerからも呼び出したいことが多い
• MyApp::API::* という名前空間
  • 中身はORM+アプリケーションロジック
  • キャッシングのロジックもここ
• DIコンテナは？ – アプリケーション全体で共有されるインスタンスはRegistryというモジュールに格納
• Registry – メモリ上のKVSに保存するだけのsingleton object
• Formの作成はHTML::FormFuを使用
  • 生成されるHTMLに不満
  • HTML::FormFuのValidatorはとてもよくできているので、レンダリングはさせないでValidatorだけ使うというのが最近の流行
• pixis(フレームワーク)の説明(githubで公開されている)
  • WebサービスやSNSでありがちなメッセージ管理などのソーシャル機能をまとめたフレームワーク
  • Catalyst 5.8依存
  • 依存モジュールが多い