Web API のすすめ
    ~巨人にさらなる力を~

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

名前
    Yuji Shimada
    嶋田裕二
仕事
    DeNA
CPAN
    XAICRON
twitter
    @xaicron
blog
     http://blog.livedoor.jp/xai...
謝罪
サブタイトルはただの
 あおり文句です
今日は 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 を書くのは
      別に怖くない
もちろん、なれてないうちは、イケ
てないものが出来ちゃうかもしれ
      ないけど、
新しいものを常に追求した方が楽
    しいでしょ!!
:-)
ご清聴ありがとうございました
Upcoming SlideShare
Loading in...5
×

Web API のすすめ

3,121

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,121
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Web API のすすめ"

  1. 1. Web API のすすめ ~巨人にさらなる力を~ 2010/10/16 YAPC::Asia 2010 @xaicron
  2. 2. 自己紹介 名前 Yuji Shimada 嶋田裕二 仕事 DeNA CPAN XAICRON twitter @xaicron blog http://blog.livedoor.jp/xaicron/
  3. 3. 謝罪
  4. 4. サブタイトルはただの あおり文句です
  5. 5. 今日は Web API の話をします
  6. 6. が、コードとかは ほとんど出てきません
  7. 7. 15時から講堂でやるやつは コードいっぱい出てきますので 見に来てね!!
  8. 8. 一口に Web API と言っても いろいろありますね
  9. 9. public に使えるもの Google Map とか 認証が必要なもの twitter 内部的に使ってるもの Gmail
  10. 10. それぞれの特徴
  11. 11. public なもの ユーザー登録とかなしで、http(s) 経由 で直接使える どれくらいのアクセスがくるのか予想を つけ辛い
  12. 12. 認証が必要なもの ユーザー登録が必要 AccessToken とかがもらえて、それを 使ってアクセス ユーザー数からアクセスがある程度わ かる 不正なユーザーとか BAN できる
  13. 13. 内部的に使ってるもの 自分のところのページを非同期にする ために同一ドメイン内とかで Ajax 通信 ユーザーは自分ではつかわない アクセス数は、ユーザー数でわかる
  14. 14. いろいろなものがある
  15. 15. 全体に共通して言えること
  16. 16. 速さが重要
  17. 17. Web API は速くないと 全く使う気が起きない
  18. 18. 内部 API の場合は非同期でペー ジを表示してるだけだから、 そんなに速くなくてもよくね?
  19. 19. ページの描画が 10% 遅くなるだけ でアクセス数が(ry
  20. 20. というのは置いておいても
  21. 21. 速いに越したことはないよね!
  22. 22. 正直、Web API はもう流行ってな いんじゃないか疑惑
  23. 23. 参考: http://yusukebe.com/archives/10/10/04/210341.html
  24. 24. 引用: “実際に「使える」Web APIは限られていることからマッシュ アップはツンダ”
  25. 25. その API が流行るかどうかは誰 にもわからない
  26. 26. もしかしたら何かで流行るかもし れないし
  27. 27. とりあえず作ってみようぜ!
  28. 28. 高速な Web API の実現方法
  29. 29. 既存の WAF を使わない
  30. 30. 前夜祭で @tokuhirom が言ってい たこと
  31. 31. 徳永 「WAF は全部コードが読める ものじゃないと使えない」
  32. 32. Agree
  33. 33. 自分がわかっていないものを使っ て、 問題が起こったときにn
  34. 34. 速いものを作るには、特化したも のを作るしかない
  35. 35. PSGI のおかげで
  36. 36. ここ一年で Web アプリを取り巻く 環境は劇的に変わった
  37. 37. いまはツールが充実している
  38. 38. ore-ore WAF を作るのは難しくな い
  39. 39. 既存の WAF だと機能過多な場合 がほとんど
  40. 40. Web API では用件が シンプルなので
  41. 41. Controller をがんばる必要が ない
  42. 42. 1:1
  43. 43. でマッピングできる
  44. 44. detach とか forward みたいな 機能すら不要
  45. 45. Web API に限ったことではないけ ど
  46. 46. Web App を作る上では、 Controller と Model は完全に分離 すべき
  47. 47. 結局はちょっと高機能な dispatcher としてしか使っていない
  48. 48. なら無駄な機能を削ぎ落としたや つを自分で書いた方がいい
  49. 49. さらに、Web API では View らしい View はない
  50. 50. ほとんどすべての場合で、 JSON を返せばみんな幸せ
  51. 51. 一時期、XMLとか、なぜかYAMLと かを返すものもありました
  52. 52. 誰もうれしくない
  53. 53. みんなで幸せになりましょう
  54. 54. ここまでのまとめ
  55. 55. Plack Router::Simple JSON
  56. 56. あたりを使って、イカした ore-ore WAF を書きましょう
  57. 57. ちょっとしたものなら本当に すぐ書けるよ
  58. 58. 第一部 〜完〜
  59. 59. 第二部 〜実践編〜
  60. 60. よし、たぶん高速な dispatcher は 書けるはずだお!
  61. 61. とはいえ、dispatch にかかる時間 は通常は全体の処理の 数%程度!
  62. 62. 本当に必要なのは Model の チューニングですね
  63. 63. 通常、ちゃんとチューニングされた Perl コードであれば
  64. 64. 多くのボトルネックは DB 接続の ようなものになる
  65. 65. 残念ながらそうならないケースもち らほら
  66. 66. どんな場合にも言えることだけど、 最も効果の出やすいチューニング は
  67. 67. method 呼び出しを減らすこと
  68. 68. ただし、過剰に減らして可読性が 下がってもしょうがない
  69. 69. Devel::NTYProf を使ってちゃんと ボトルネックを見つける
  70. 70. 次に、オブジェクトの生成を減らす
  71. 71. 例えば、ORM を使っていて、それ がかなりのオブジェクトを生成して いるのであれば、使用をやめる
  72. 72. ただし、生の DBI をそのまま使う のはやはり面倒
  73. 73. 最近は
  74. 74. DBIx::Connector -> (DBIx::DBHREsolver ->) DBI
  75. 75. みたいにラップして使うのがいい 気がしている
  76. 76. もちろん、ORM でも十分に速度を 出すことも可能なので
  77. 77. その辺りはよしなに使い分ければ いいと思います
  78. 78. 必ず使うクラスがあり、それを毎回 new しているような場合
  79. 79. Object::Container のようなものに 入れて singleton にしておくのがい い
  80. 80. 最近の Object::Container は preload オプションとかついたので
  81. 81. さらに使いやすくなっている はず!
  82. 82. run する前に 読み込んでおけば、 CoW が効くのでメモリーも抑えら れて一石二鳥
  83. 83. ここまでのまとめ
  84. 84. Plack Router::Simple JSON Object::Container DBIx::Connctor (DBIx::Skinny)
  85. 85. 当然、ここの部分は API の用件に よってかなりぶれがあり、一概にこ れがいいとはいません
  86. 86. が、一般的に、今言ったことを守っ ておけば、コード事態がボトルネッ クになる確立はだいぶ減ると思い ます
  87. 87. というわけで
  88. 88. 第二部 〜未完〜
  89. 89. 第三部 〜運用編〜
  90. 90. 多分、次で @fujiwara さんが 超絶詳しく説明してくれます
  91. 91. 第三部 〜期待〜
  92. 92. だけではさすがにあれなので
  93. 93. まぁ基本的なことですが
  94. 94. まぁ基本的なことですが
  95. 95. 当然、必要な場所でログはとりま しょう
  96. 96. Log::Dispatch がデファクトなので 素直に使っておくのがいいです
  97. 97. Syslog n
  98. 98. ここまでのまとめ
  99. 99. Plack Router::Simple JSON Object::Container DBIx::Connecter (DBIx:: Skinny) Log::Dispatch
  100. 100. あたりを使って薄いものをつくれば いいですね!
  101. 101. それ Amon2 で出来るよ!
  102. 102. って感じですが、あれは普通に参 考になるので一度はソースを読ん だ方がいいです
  103. 103. まとめ
  104. 104. 今の時代、 ore-ore WAF を書くのは 別に怖くない
  105. 105. もちろん、なれてないうちは、イケ てないものが出来ちゃうかもしれ ないけど、
  106. 106. 新しいものを常に追求した方が楽 しいでしょ!!
  107. 107. :-)
  108. 108. ご清聴ありがとうございました
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×