SlideShare a Scribd company logo
Web API のすすめ
    ~巨人にさらなる力を~

2010/10/16 YAPC::Asia 2010
         @xaicron
自己紹介

名前
    Yuji Shimada
    嶋田裕二
仕事
    DeNA
CPAN
    XAICRON
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と
  かを返すものもありました
誰もうれしくない
みんなで幸せになりましょう
ここまでのまとめ
Plack
Router::Simple
JSON
あたりを使って、イカした
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 が効くのでメモリーも抑えら
       れて一石二鳥
ここまでのまとめ
Plack
Router::Simple
JSON
Object::Container
DBIx::Connctor (DBIx::Skinny)
当然、ここの部分は API の用件に
よってかなりぶれがあり、一概にこ
   れがいいとはいません
が、一般的に、今言ったことを守っ
ておけば、コード事態がボトルネッ
クになる確立はだいぶ減ると思い
       ます
というわけで
第二部 〜未完〜
第三部 〜運用編〜
多分、次で @fujiwara さんが
超絶詳しく説明してくれます
第三部 〜期待〜
だけではさすがにあれなので
まぁ基本的なことですが
まぁ基本的なことですが
当然、必要な場所でログはとりま
      しょう
Log::Dispatch がデファクトなので
 素直に使っておくのがいいです
Syslog n
ここまでのまとめ
Plack
Router::Simple
JSON
Object::Container
DBIx::Connecter (DBIx::
Skinny)
Log::Dispatch
あたりを使って薄いものをつくれば
     いいですね!
それ Amon2 で出来るよ!
って感じですが、あれは普通に参
考になるので一度はソースを読ん
    だ方がいいです
まとめ
今の時代、
ore-ore WAF を書くのは
      別に怖くない
もちろん、なれてないうちは、イケ
てないものが出来ちゃうかもしれ
      ないけど、
新しいものを常に追求した方が楽
    しいでしょ!!
:-)
ご清聴ありがとうございました

More Related Content

Web API のすすめ