Embed Size (px)
DESCRIPTION
Citation preview
Web API のすすめ~巨人にさらなる力を~
2010/10/16 YAPC::Asia 2010@xaicron
自己紹介
名前Yuji Shimada嶋田裕二
仕事DeNA
CPANXAICRON
twitter@xaicron
blog http://blog.livedoor.jp/xaicron/
謝罪
サブタイトルはただのあおり文句です
今日は Web API の話をします
が、コードとかはほとんど出てきません
15時から講堂でやるやつはコードいっぱい出てきますので
見に来てね！！
一口に Web API と言ってもいろいろありますね
public に使えるものGoogle Map とか
認証が必要なものtwitter
内部的に使ってるものGmail
それぞれの特徴
public なもの
ユーザー登録とかなしで、http(s) 経由で直接使えるどれくらいのアクセスがくるのか予想をつけ辛い
認証が必要なもの
ユーザー登録が必要AccessToken とかがもらえて、それを使ってアクセスユーザー数からアクセスがある程度わかる
不正なユーザーとか BAN できる
内部的に使ってるもの
自分のところのページを非同期にするために同一ドメイン内とかで Ajax 通信ユーザーは自分ではつかわないアクセス数は、ユーザー数でわかる
いろいろなものがある
全体に共通して言えること
速さが重要
Web API は速くないと全く使う気が起きない
内部 API の場合は非同期でページを表示してるだけだから、そんなに速くなくてもよくね？
ページの描画が 10% 遅くなるだけでアクセス数が（ry
というのは置いておいても
速いに越したことはないよね！
正直、Web API はもう流行ってないんじゃないか疑惑
参考:http://yusukebe.com/archives/10/10/04/210341.html
引用:“実際に「使える」Web APIは限られていることからマッシュ
アップはツンダ”
その API が流行るかどうかは誰にもわからない
もしかしたら何かで流行るかもしれないし
とりあえず作ってみようぜ！
高速な Web API の実現方法
既存の WAF を使わない
前夜祭で @tokuhirom が言っていたこと
徳永 「WAF は全部コードが読めるものじゃないと使えない」
Agree
自分がわかっていないものを使って、
問題が起こったときにn
速いものを作るには、特化したものを作るしかない
PSGI のおかげで
ここ一年で Web アプリを取り巻く環境は劇的に変わった
いまはツールが充実している
ore-ore WAF を作るのは難しくない
既存の WAF だと機能過多な場合がほとんど
Web API では用件がシンプルなので
Controller をがんばる必要がない
1 : 1
でマッピングできる
detach とか forward みたいな機能すら不要
Web API に限ったことではないけど
Web App を作る上では、Controller と Model は完全に分離
すべき
結局はちょっと高機能な dispatcher としてしか使っていない
なら無駄な機能を削ぎ落としたやつを自分で書いた方がいい
さらに、Web API では View らしい View はない
ほとんどすべての場合で、JSON を返せばみんな幸せ
一時期、XMLとか、なぜかYAMLとかを返すものもありました
誰もうれしくない
みんなで幸せになりましょう
ここまでのまとめ
PlackRouter::SimpleJSON
あたりを使って、イカしたore-ore WAF を書きましょう
ちょっとしたものなら本当にすぐ書けるよ
第一部 〜完〜
第二部 〜実践編〜
よし、たぶん高速な dispatcher は書けるはずだお！
とはいえ、dispatch にかかる時間は通常は全体の処理の
数%程度！
本当に必要なのは Model のチューニングですね
通常、ちゃんとチューニングされた Perl コードであれば
多くのボトルネックは DB 接続のようなものになる
残念ながらそうならないケースもちらほら
どんな場合にも言えることだけど、最も効果の出やすいチューニング
は
method 呼び出しを減らすこと
ただし、過剰に減らして可読性が下がってもしょうがない
Devel::NTYProf を使ってちゃんとボトルネックを見つける
次に、オブジェクトの生成を減らす
例えば、ORM を使っていて、それがかなりのオブジェクトを生成しているのであれば、使用をやめる
ただし、生の DBI をそのまま使うのはやはり面倒
最近は
DBIx::Connector ->(DBIx::DBHREsolver ->)
DBI
みたいにラップして使うのがいい気がしている
もちろん、ORM でも十分に速度を出すことも可能なので
その辺りはよしなに使い分ければいいと思います
必ず使うクラスがあり、それを毎回 new しているような場合
Object::Container のようなものに入れて singleton にしておくのがい
い
最近の Object::Container は preload オプションとかついたので
さらに使いやすくなっているはず！
run する前に 読み込んでおけば、CoW が効くのでメモリーも抑えら
れて一石二鳥
ここまでのまとめ
PlackRouter::SimpleJSONObject::ContainerDBIx::Connctor (DBIx::Skinny)
当然、ここの部分は API の用件によってかなりぶれがあり、一概にこ
れがいいとはいません
が、一般的に、今言ったことを守っておけば、コード事態がボトルネックになる確立はだいぶ減ると思い
ます
というわけで
第二部 〜未完〜
第三部 〜運用編〜
多分、次で @fujiwara さんが超絶詳しく説明してくれます
第三部 〜期待〜
だけではさすがにあれなので
まぁ基本的なことですが
まぁ基本的なことですが
当然、必要な場所でログはとりましょう
Log::Dispatch がデファクトなので素直に使っておくのがいいです
Syslog n
ここまでのまとめ
PlackRouter::SimpleJSONObject::ContainerDBIx::Connecter (DBIx::Skinny)Log::Dispatch
あたりを使って薄いものをつくればいいですね！
それ Amon2 で出来るよ！
って感じですが、あれは普通に参考になるので一度はソースを読ん
だ方がいいです
まとめ
今の時代、ore-ore WAF を書くのは
別に怖くない
もちろん、なれてないうちは、イケてないものが出来ちゃうかもしれ
ないけど、
新しいものを常に追求した方が楽しいでしょ！！
:-)
ご清聴ありがとうございました
