大规模画像配信支Perl.pptVIP

大規模画像配信を支えるPerl YAPC::Asia Tokyo 2009 株式会社ミクシィ 長野雅広 自己紹介 長野雅広（Masahiro Nagano） 株式会社ミクシィ開発部　システム運用グループアプリケーション運用チーム　所属 Blog: http://blog.nomadscafe.jp/ PAUSE ID: KAZEBURO /kazeburo/ WEB+DB PRESS連載中 大規模Webサービスの裏側 inside mixi’s backend 連載内容 vol.50 静的コンテンツの負荷分散 vol.51 巨大トラフィックを支えるインフラ vol.52 テラスケールのデータベース運用（設計編） vol.53 テラスケールのデータベース運用(運用編) アジェンダ 画像配信システムの概要 携帯向け画像変換＆配信 画像配信システムの概要 配信する画像の種類 mixiのコンテンツ ユーザコンテンツ mixiのコンテンツ ページ構成部品 広告画像＆Flash mixiのコンテンツの配信 特徴 数が少ない～1,000ファイル 大量のリクエスト 配信方法 rsyncで数台のWebサーバに同期 DNS RR or L4 LoadBalancerで分散 Apacheの設定＆チューニング ユーザコンテンツ プロフィール画像 コミュニティ?ロゴ画像 日記の写真 アルバムの写真 コミュニティの掲示板の写真 ユーザコンテンツの特徴 数が多い プロフィール画像：3300万ファイル 写真画像：10億～ファイル アクセスも多い プロフィール画像：3億req/day 写真画像： 1億5000万req/day 写真画像配信システム ImageCluster ImageCluster システム図 アップロード側 アップロード側: converter mod_perl アップロード側: converter mod_perl MappingDB(ImageCluster Manager DB) 表示側（1） Squid Cache 表示側(2) proxy mod_perl MogileFSと比較して Pros 実装を理解している ストレージ障害時の復旧が明確 Cons JPEG only 手作業が多い 2台以上への冗長性 モバイル画像配信 モバイルの伸び モバイル画像配信の特徴 画像について ファイルサイズ 画面サイズ 転送?コピーライトフラグ 配信方法 動的生成 画像変換と配信システム Perｌで画像操作を行う CPAN Image::Magick GD Imager Image::Epeg Image::Imlib2 !CPAN fork,exec, IRC::Run 速度比較 640x480 = 256x192 JPEGの圧縮率は85% Commentは削除済み Image::Magickの場合 Imagerの場合 Imlib2の場合 Epegの場合 速度比較結果 Epegはとても速い、けど サムネイル生成用で画質がとても悪い 画質比較 画質比較 画質と速度 速度 Epeg Imlib2 Imager Image::Magick 画質（個人的感覚） Image::Magick Imlib2 Epeg Imlib2を採用 Pros 高速 画質良し Cons 開発続いている？ CMYK/グレースケールのJPEGを正しく処理できない カラーコンポーネント数を高速に判断する JPEGのヘッダーに含まれる マーカがFFC0からFFC3の「Start Of Frame」内に縦横サイズとともに記録 カラーコンポーネント数”3”がRGB カラーコンポーネント数を高速に判断する おまけ：JPEGの判断 Image::JpegCheck Image::Size +高速化 WWW::Curl libcurlのperl binding LWPとinterfaceが異なる WWW::Curl::SimpleだとLWP互換 WWW::Curl vs LWP WWW::Curl vs LWP 現状システムのパフォーマンス QuadCore CPU * 2 サーバ6台 7500万req/day (peek 2600req/sec) まとめ mixiの大規模画像配信はPerlが支える Imlib2を利用して画像のリアルタイム変換 高いパフォーマンスと安定性、柔軟性を実現 WEB+DB PRESSの連載もお願いします。 ご清聴ありがとうございました 質問ありましたらどうぞ use Image::Epeg qw(:constants); my $epeg = Image::Epeg-new( $srcfile ); $epeg-resize