Web API のすすめ

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 を書くのは

別に怖くない

もちろん、なれてないうちは、イケてないものが出来ちゃうかもしれ

ないけど、

新しいものを常に追求した方が楽しいでしょ！！

:-)

ご清聴ありがとうございました