oinume journal

Scratchpad of what I learned

YAPC::Asia 2009に行ってきました(9.10)

2009/9/10,11に開催されたYAPC::Asia 2009に参加しました。今年はフレームワークやORM系のセッションがとても豪華で全部聞きたいなと思っていたので、迷うことなく有給を取って参加。というわけで殴り書きですがメモと感想を徒然に書いてみます。

 

PSGI - Perl Server Gateway Interface

スライド

 

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

スライド

 

 

 

 

  • Path::Dispatcher

 

 

 

 

  • Dist::Zilla

 

 

  • IM::Engine

 

 

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

英語だったので話の内容の半分も理解できなかったのが無念...

 

Modern Catalyst

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

 

 

 

 

  • Mooseベースになった

 

 

 

 

  • NEXTが...

 

 

 

 

他のセッションでも「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ベース

 

 

 

 

 

 

 

 

 

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

 

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

dannさん。スライド

 

 

 

 

  • モダンなWAFとは?

 

 

 

 

 

 

 

 

 

 

 

  • Angelos::PSGI::Engine

 

 

  • Plack::Requestを使ってる

 

 

  • HTTP::Routerを使ってる

 

 

  • シンプルなWAFなら2,3時間あれば作れちゃう!

 

 

 

 

  • コアは小さく

 

 

  • 拡張可能な箇所を限定(Controller, View, Middleware, Request, Response)

 

 

  • Hookポイントを明確にする

 

 

 

 

  • RequestやResponseのライフサイクルへのHook系

 

 

 

 

  • 適切なデフォルトセットの提供することが重要

 

 

  • そうしないとUnicode化するためのTIPSが乱立したり、Inflate/Deflateするための(ry

 

 

  • HTTP::EnginePlack、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)

 

 

 

 

 

 

  • HTML::Mason

 

 

  • HTML::Template(forked version)

 

 

  • なぜPerl? --> 簡単で速い

 

 

  • なぜHTML::Template? --> 簡単

 

 

  • なぜClass::DBI? --> 聞き取れず(一番聞きたかったのに)

 

 

 

 

 

 

 

 

  • git

 

 

 

 

将来のゴール

 

 

 

 

  • Modules upgrade

 

 

 

 

  • MySQL upgrade (to 5.1 or 5.4)

 

 

 

  • フロントエンドのWeb Server: 100台以上

 

 

  • MySQLサーバ: 100台以上

 

 

  • データセンターにあるサーバは700台以上

 

 

IT at Booking.com

 

 

 

 

 

 

  • 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

 

 

 

 

 

  • 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を作ったか?

 

 

 

 

 

  • 便利だけど発行されるSQLが微妙

 

 

  • パフォーマンスが出なかったりする

 

 

  • 生成されるオブジェクトがでかすぎるため重い

 

 

  • カスタマイズしようにもソースがでかすぎる

 

 

  • DBICで速度でない場合は生SQL書くことがあるが、Inflateとかしてくれない

 

 

 

 

  • SQL書いてinflate/deflateしてくれるライトなものでいいんじゃないか、というところにたどりついた

 

 

 

 

  • relationshipは特に何もしない

 

 

  • コアは小さく、がモットーなので、拡張したい人はラッパーを書けばいい

 

 

  • 何人かの人に興味持ってるみたいなので、Skinnyみたいな方向性はありなのだなと思った。

 

 

 

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

 

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

 

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

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

 

 

 

 

 

  • mod_perl 2のメモリ関連のチューニング

 

 

  • 推測するな計測するべし(ps, top)

 

 

  • fork(2) - Copy On Write

 

 

 

 

  • /proc/PID/smaps (kernel >= 2.6.14) - 共有領域: Shared_Clean + Shared_Dirty

 

 

  • いわゆる親プロセスと子プロセスの共有メモリ領域の話

 

 

 

 

  • 使うモジュールは親プロセスで起動時に(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するのがむだ?だったら最初から全プロセス起動しておいた方がいい

 

 

 

 

 

 

  • start - 起動時からフルでプロセスを起動するので、start直後にリクエストが来ると負荷が高くなってしまう。一定時間おいてからロードバランサーに入れる必要がある。

 

 

  • ロードバランサーのヘルスチェックのURLを動的なものにしておき、フラグファイルがあったら200を返すようにするとか。

 

 

  • あとはmatrixの話

 

 

 

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

 

一日を通しての感想

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

 

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