たたみラボ

  • about
  • member
  • r&d
  • blog
  • tatamicast

blog

RSS

ETech2006レポート(初日 チュートリアル)

icon March 8, 2006 2:15 PM by funami このエントリーを含むはてなブックマーク

フナミタカオです

アメリカ、サンディエゴで開催中の、Etech 2006に参加しています。
なれない、英語にどっぷりで、かなり消耗しながらも、面白いネタがたくさんあって、非常に内容の濃いカンファレンスです(まあ、一部例外もあるけれど、それもまた、ためになる)

初日(3月6日)に行われた、チュートリアルセッションについて、レポートします。

[チュートリアル] フリッカーの作り方~拡大もやりやすく、しかも安く

Scaling Fast and Cheap - How We Built Flickr
Cal Henderson, Flickr/Yahoo!
Date: Monday, March 06
Time: 8:30am - 5:00pm
Location: Elizabeth F


会場の雰囲気です

朝の8時30分から夕方5時まで、ランチと、小休憩をはさみつつ、6時間以上のロングセッションでした。フリッカーの開発者がじきじきに、拡大がやりやすく、それでいて、できるだけ安く、Webアプリケーション=Flickrを開発するかという話です、
Flickrは、最近話題になってきているので、ここでは説明しませんが、昨年のEtechで、話題を振りまいたサービスです。その後Yahooに買収されました。

関連記事:ブロガーに人気の写真共有サイト『Flickr』
http://hotwired.goo.ne.jp/news/culture/story/20041213203.html

このサービスの売りは、インフラと開発のコストをを極限まで下げながらも、一億枚の写真を保管し、キーワードをつけ、画像加工という重い処理も走らせることができるようにしているところです。また、写真は日々増加してゆきますが、いくら大きくなっても、きちんと速度、容量を担保し、それでいて、コストも最小限ですむようになっています。

講師
講師は、フリッカーの設計・開発者のCal Henderson氏

彼の著作
Building Scalable Web Sites: Building, Scaling, And Optimizing the Next Generation of Web Applications
Cal Henderson
Oreilly & Associates Inc (2006/05)
Amazon.co.jp で詳細を見る

最初の結論
最初に、釘をさしたのは、Flickrの作り方は
「大量の人」+「大量の時間」+「大量のお金」
ではありません。

ということ。安く作るためには、旧来の開発手法(ウオーターフォール的な手法)ではつくれないとのことです。サービス開始後の要望変化や、ユーザーの反応に迅速にこたえるためにも、重厚長大はやりかたは、向いていないと共感しました。

規模と概要
・ユーザー 200万人以上
・画像ファイル 1億以上
・2005年5月にYahooga買収
・本拠地 サンタクララ


ハードウエア
・200台のマシン
・Dell,HP,NetApp(ストレージ)
・cpuはi386とx86_64

PCにLinuxを入れて動かしている、負荷分散の仕組みも、高額なハードウエア方式をさけて、ソフト方式でなるべくやっているとのこと。
ポイントは、やはり、PCを並べてるというところ。


ソフトウエア
カナダのケーキにたとえて
上  フルーツ   - 表現          = CSS(スタイルシート)
   クリーム    - マークアップ     = Smarty
   カスタード   - ページごとのロジック = PHP
   ゼリー     - ビジネスロジック   = PHP
下  スポンジ   - データベース     =MySQL

ここででてくる MySQL,PHP、Smartyともに開発環境、実行環境は無償なので、安さを実現しています。
ここを、Sun + Oracle + Javaとかにすると、一気にインフラ費・開発費は急上昇ということになりますね。
ちなみに、OSはLinux WebサーバーはApache 2 これもともに無償です。


インフラまとめ
・ハードは、PCベースで
・ソフトは、原則無償のもので構成

だからお安いのです。
当然...


開発のルール
・ソースのバージョン管理ツールを利用する
 CVS,Subversion等の管理ツールを使う。

・開発中もすぐに実行できるようにしておく
 開発環境、本番実行前テスト環境、本番環境の3環境
 各環境から、次の環境に移行(インストール)するのは、ツールで行う(手動でやったりはしない)。
 
・バグの追跡ツールを利用する
 FogBugz(シンプル、有料、PHP,ASP)
 Mantis(複雑、無償、PHP)
 等のツールを使い、各バグに優先順位をつけて管理する。

・コーディングルールを守る
 ファイル名、ターぶる名、関数名、変数名、インデント等、

・Unitテストを行う
 ただし、Webアプリの単体テストは難しい。そんなときは、Web自動循環のCPANのWWW::Mechanizeライブラリをしようするといい。
認証が必要なページに自動ログインして、情報を抜き取ったり、フォームに自動的に値を埋め込んで実行できたりします。Formにエントリーして、その結果をみるというテストでは、結構使えると思います。


ユニコード、セキュリティについて
一般的な話として、ユニコード(10分くらいしていた。アメリカじゃUnicodeもUTF-8もメジャーじゃないので、きちんと話す必要があったのでしょうね。)、クロスサイトスクリプティング、SQLインジェクションの話がでました。
こちらも、知ってれば普通ですが、知らないと、セキュリティホールになるので、ここも丁寧に解説されていました。

ボトルネック
・CPU使用率
・不要処理(コードプロファイラで実行状況を調べる)
・スポットチェック(SQLの処理時間を一行単位で計測する)
・ディスクの読み書き
・メモリのスワップ

ボトルネックの可能性は、上記のようなところなので、計測ツール等でちぇっくしようということでした。特別なことじゃなくて、一般的なことだったのが印象的。
すごく特別なことをしているわけでもないのですね。

スケーリング
サービスやユーザー数の拡大に合わせて、容量、性能を向上させることですが、その際にメンテナンスがやりやすいことが重要。
ハードウエア的には、より高速な、CPUや、ディスクに変更することや、今1台でやっている処理を複数台でやらせたりすることになる。
マシンを増設するたびに、セットアップのコストや、電源、ポートの用意を忘れてはいけない。

DBのスケーリングは気になるところですが、MySQLの機能である、MySQL Repricationを基本使っているようです。
そのほか、ディスク、PHP、ネットワーク、ファイルI/Oも考慮すべきということですが、これらも、特別すごいことをやっているわけではなくて、リファレンスに書かれていることを地道に行っているようでした。(ちょっと、英語に自信ないのですが、特別な秘密はなくて、いろんなところで語られていることを行っているようです)


まとめと感想
やすくて、拡張性のあるインフラにしたいのであれば、PCベース、無償ソフトベースでインフラをくむことで実現できる。
そのためには、仕様を理解して地道にやっていく姿勢が必要なんだと思いました。
お金をかければ、非常に堅牢なものができるかもしれませんが、
ユーザーと企業がフラットな関係になってきている、Web2.0の世界ではサービスの価格もどんどん低下してゆきます。ですのでインフラにコストをかけすぎるとビジネスモデルが作れなくなります。まれな障害については、ここはトレードオフですよね。
銀行システムなら問題だけど、日記や写真共有なら許される範囲であれば、コストが安い方向で行きたいものです。
Flickrのような会社は、小規模で小回りが利くところがいいのですよね。

たたみラボでは、ぜひ、従来の方式に縛られずに、Flickrの視点で、予算、インフラ、サービス内容を考えてゆきたいです。

日本に帰ったら、とりあえず、PCの自作と、Linux,Apachのインストール、MySQLのレプリケーションを試してみようと思います。


   
  


COMMENTS

うゎ~、すごく聞きたかったです。このレポートだけでもわくわくしています。帰国したらいろいろと聞かせてください。

March 8, 2006 10:16 PM by 大井宏友  

SMARTY+PHP+MYSQLでFlickr級のサービスがつくれるんですね。負荷分散などパフォーマンスチューニングについてSun +Oracle+Javaで考慮しなくていいはずもないし。
タタミでも安いPCを数台用意して実験してみたいかも。

March 9, 2006 7:22 PM by 丸子良太  

POST COMMENT




(書式を変更するような一部のHTMLタグを使うことができます)

必ず利用規約に同意いただいた上で送信ください。

ページトップへ



(C) RECRUIT MEDIA COMMUNICATIONS CO., LTD.