snapdish 画像配信について

ヴァズ株式会社　｜　本資料の無断での開示・複製・転送はご遠慮ください。

SnapDish 画像配信について2013/1/23

料理が楽しくなる写真共有サービス

『SnapDish 料理カメラ』

Wednesday, January 23, 13


本日のMENU前菜： SnapDish って？

メイン：現状と構成 (2013/01現在)

デザート：使ってみて



SnapDish って？



こんな感じ



冗談です。orz SnapDish UP されている、

自分が一番気に入っている

幻の写真、「そーせーじん」です。



サービス概要

料理が、食が、もっと楽しくなる！



201２/1２現在

開始から１年半

料理写真だけで約200万

もぐもぐ❤が約1200万



チーム　８人（みんな３０歳以上、半数は４０歳以上？？？）z　代表　総料理長　明太子LOVE❤

きよた（自分）iOS, WEB, インフラ全般珈琲LOVE❤　ままぞう　財務、人事、総務、酒LOVE❤

ファンキー　海外事業担当、パスタLOVE❤　　なるじぃ　Androidスペシャリスト、ぱんLOVE❤

あべちゃん　国内事業開発担当、お米LOVE❤　　　　ひよっし　Webスペシャリスト、まぐろLOVE❤

くらげや　グラフィクデザイン、日本酒LOVE❤



日常

毎日ランチを料理

みんなで美味しく食べる

昼・夜一生懸命働く

SnapDish ユーザーと同じ体験することで、ユーザー目線を鍛える！

開発・運営をしています！



本題



現状と構成



まず、現状から



こんな感じ



現状

2012/12月の数字

・AWS CloudFront (CDN) リクエスト数: 約9,400万転送量: 2.5TB

・AWS ELB (CloudFront Origin) リクエス数: 約3,000万

※S3は未計測



構成



こんな感じ

http://snapdi.sh/dish/50f4a8e2a060bd3c814fb634





こんな感じ

http://snapdi.sh/dish/50d870d3a060bd7c10ecb694





嘘です。orz



構成

AmazonCloudFront Amazon Simple

Storage Service(S3)

Internet 1. Image Server - instance m1.small x 4 - 6 - nginx 1.2.4 - nginx proxy cache on ramdisk - nginx image filter to resize image - nginx gridfs replicaset connect 2. DB Server - instance m2.4xlarge x 2 - PIOPS1000/Raid10 - MongoDB 2.2.1

3. MongoDB Arb Sever - instance m1.large x 1 (Running on Development Server)

4. AWS S3 Service

Elastic LoadBalancer

origin.snapdi.sh

Image Server on Instances

Rreplica Sets

MongoDB SECon Instance

MongoDB PRIon Instance

MongoDB Arbon Instance



　　

・S3とGridFSのハイブリッド運用

・GridFSはCloudFrontの配下のサーバーに設置 AWS CloudFront ↓↑ AWS ELB ↓↑ AWS EC2 Image Server on EC2 m1.small（4-6台） ↓↑ MongDB GridFS



　　

・Image Server の中身 Nginx Sample Config

　https://gist.github.com/4591707

1. キャッシュ層ramdiskにキャッシュ

2. 加工層　ngixn-image-filter を使って処理 3. 取得層　GridFSに繋いでデータを取得する

※多段にする理由は、Nginx-GridFSのIDの取得する際、　location の指定に正規表現が書けないから


https://gist.github.com/4591707

https://gist.github.com/4591707


使ってみて



こんな感じ

http://snapdi.sh/dish/50f736fda060bd3e9e762e08





悩ましい事が多いかも



GridFSじゃなくて、S3使えばよいんじゃないの？

と思う事がよくあります。でも、なぜ使っているのか、

1. 使ってみて、今まで大きな問題が起こっていない

2.当初、全て一人でやっていて、なるべく工数を押さえたかったので、サー　バーサイドの設定で全てできてしまうnginx-gridfsを使うことに

3. デザインも含め進化途中のアプリなので、画像のサイズがよく変わる事が　あり、設定でさくっと対応したかった

4. Androidは画像サイズを小さくして配信するなど、個別の対応が必要なの　で、サーバーサイドの設定で対応ができるのはメリット

5. S3は、移行したい時に移行すればよい



ちなみに、実際、配信している画像



実際配信している画像

・料理写真画像　ー＞ GridFS　1. 更新は不可/削除可能　2. サイズは、表示箇所によって様々　3. リサイズ・クロップ処理行う

・ユーザー画像　ー＞ GridFS（S3へ移行検討中）　1. 更新は可能/削除可能　2. サイズ、表示箇所によって様々　3. リサイズ・クロップ処理行う

・ユーザープロフィールカバー画像　ー＞ S3　1. 更新は可能/削除は不可　2. サイズ、プロフィールに対して３個　3. リサイズ・クロップ処理は一部行う



メリット：1. サーバーサイドで細かい調整ができて便利2. 画像の管理自体はとても楽3. 画像のメタ情報の管理も一括して行える4. 画像のサイズや大きさが定まらない場合5. 後で他のサービスに移行するのは容易

デメリット：1. サーバーの運用が入る2. 割高、S3の方がコストが抑えられる（多分、ある時点から大分S3が安くなる）3. 移行時に、やはり、工数が結構発生する

S3にした方が良い場合、、、1. WEBからの大量アクセスがくる場合、S3の方がコストが更に押さえられ、画像サイズの種類もそんなに必要がないので、実際楽なはず

2. 更なる高可用性が必要な場合3. CDNを使わない場合で、画像の更新がある場合



まだ、

以外と動いているので、

もうしばらく使って、

S3とのハイブリッド運用へ移行して、

もしかしたら、

全てS3へ移行することになるのかもしれないと

心の片隅で思う事がある日々を

しばらく送る事になりそう



お口に合いましたでしょうか？



http://snapdi.sh/dish/50de504b7e57054057fa8905




snapdish 画像配信について

Technology