1. Web API のすすめ
~巨人にさらなる力を~
2010/10/16 YAPC::Asia 2010
@xaicron

2. 自己紹介
名前
Yuji Shimada
嶋田裕二
仕事
DeNA
CPAN
XAICRON
twitter
@xaicron
blog
http://blog.livedoor.jp/xaicron/

3. 謝罪

4. サブタイトルはただの
あおり文句です

5. 今日は Web API の話をします

6. が、コードとかは
ほとんど出てきません

7. 15時から講堂でやるやつは
コードいっぱい出てきますので
見に来てね！！

8. 一口に Web API と言っても
いろいろありますね

9. public に使えるもの
Google Map とか
認証が必要なもの
twitter
内部的に使ってるもの
Gmail

10. それぞれの特徴

11. public なもの
ユーザー登録とかなしで、http(s) 経由
で直接使える
どれくらいのアクセスがくるのか予想を
つけ辛い

12. 認証が必要なもの
ユーザー登録が必要
AccessToken とかがもらえて、それを
使ってアクセス
ユーザー数からアクセスがある程度わ
かる
不正なユーザーとか BAN できる

13. 内部的に使ってるもの
自分のところのページを非同期にする
ために同一ドメイン内とかで Ajax 通信
ユーザーは自分ではつかわない
アクセス数は、ユーザー数でわかる

14. いろいろなものがある

15. 全体に共通して言えること

16. 速さが重要

17. Web API は速くないと
全く使う気が起きない

18. 内部 API の場合は非同期でペー
ジを表示してるだけだから、
そんなに速くなくてもよくね？

19. ページの描画が 10% 遅くなるだけ
でアクセス数が（ry

20. というのは置いておいても

21. 速いに越したことはないよね！

22. 正直、Web API はもう流行ってな
いんじゃないか疑惑

23. 参考:
http://yusukebe.com/archives/10/10/04/210341.html

24. 引用:
“実際に「使える」Web APIは限られていることからマッシュ
アップはツンダ”

25. その API が流行るかどうかは誰
にもわからない

26. もしかしたら何かで流行るかもし
れないし

27. とりあえず作ってみようぜ！

28. 高速な Web API の実現方法

29. 既存の WAF を使わない

30. 前夜祭で @tokuhirom が言ってい
たこと

31. 徳永 「WAF は全部コードが読める
ものじゃないと使えない」

32. Agree

33. 自分がわかっていないものを使っ
て、
問題が起こったときにn

34. 速いものを作るには、特化したも
のを作るしかない

35. PSGI のおかげで

36. ここ一年で Web アプリを取り巻く
環境は劇的に変わった

37. いまはツールが充実している

38. ore-ore WAF を作るのは難しくな
い

39. 既存の WAF だと機能過多な場合
がほとんど

40. Web API では用件が
シンプルなので

41. Controller をがんばる必要が
ない

42. 1:1

43. でマッピングできる

44. detach とか forward みたいな
機能すら不要

45. Web API に限ったことではないけ
ど

46. Web App を作る上では、
Controller と Model は完全に分離
すべき

47. 結局はちょっと高機能な
dispatcher としてしか使っていない

48. なら無駄な機能を削ぎ落としたや
つを自分で書いた方がいい

49. さらに、Web API では View らしい
View はない

50. ほとんどすべての場合で、
JSON を返せばみんな幸せ

51. 一時期、XMLとか、なぜかYAMLと
かを返すものもありました

52. 誰もうれしくない

53. みんなで幸せになりましょう

54. ここまでのまとめ

55. Plack
Router::Simple
JSON

56. あたりを使って、イカした
ore-ore WAF を書きましょう

57. ちょっとしたものなら本当に
すぐ書けるよ

58. 第一部 〜完〜

59. 第二部 〜実践編〜

60. よし、たぶん高速な dispatcher は
書けるはずだお！

61. とはいえ、dispatch にかかる時間
は通常は全体の処理の
数%程度！

62. 本当に必要なのは Model の
チューニングですね

63. 通常、ちゃんとチューニングされた
Perl コードであれば

64. 多くのボトルネックは DB 接続の
ようなものになる

65. 残念ながらそうならないケースもち
らほら

66. どんな場合にも言えることだけど、
最も効果の出やすいチューニング
は

67. method 呼び出しを減らすこと

68. ただし、過剰に減らして可読性が
下がってもしょうがない

69. Devel::NTYProf を使ってちゃんと
ボトルネックを見つける

70. 次に、オブジェクトの生成を減らす

71. 例えば、ORM を使っていて、それ
がかなりのオブジェクトを生成して
いるのであれば、使用をやめる

72. ただし、生の DBI をそのまま使う
のはやはり面倒

73. 最近は

74. DBIx::Connector ->
(DBIx::DBHREsolver ->)
DBI

75. みたいにラップして使うのがいい
気がしている

76. もちろん、ORM でも十分に速度を
出すことも可能なので

77. その辺りはよしなに使い分ければ
いいと思います

78. 必ず使うクラスがあり、それを毎回
new しているような場合

79. Object::Container のようなものに
入れて singleton にしておくのがい
い

80. 最近の Object::Container は
preload オプションとかついたので

81. さらに使いやすくなっている
はず！

82. run する前に 読み込んでおけば、
CoW が効くのでメモリーも抑えら
れて一石二鳥

83. ここまでのまとめ

84. Plack
Router::Simple
JSON
Object::Container
DBIx::Connctor (DBIx::Skinny)

85. 当然、ここの部分は API の用件に
よってかなりぶれがあり、一概にこ
れがいいとはいません

86. が、一般的に、今言ったことを守っ
ておけば、コード事態がボトルネッ
クになる確立はだいぶ減ると思い
ます

87. というわけで

88. 第二部 〜未完〜

89. 第三部 〜運用編〜

90. 多分、次で @fujiwara さんが
超絶詳しく説明してくれます

91. 第三部 〜期待〜

92. だけではさすがにあれなので

93. まぁ基本的なことですが

94. まぁ基本的なことですが

95. 当然、必要な場所でログはとりま
しょう

96. Log::Dispatch がデファクトなので
素直に使っておくのがいいです

97. Syslog n

98. ここまでのまとめ

99. Plack
Router::Simple
JSON
Object::Container
DBIx::Connecter (DBIx::
Skinny)
Log::Dispatch

100. あたりを使って薄いものをつくれば
いいですね！

101. それ Amon2 で出来るよ！

102. って感じですが、あれは普通に参
考になるので一度はソースを読ん
だ方がいいです

103. まとめ

104. 今の時代、
ore-ore WAF を書くのは
別に怖くない

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

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

107. :-)

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