2012-06-02
h300 にかかった CDN 利用料と、それを半分に抑えてくれた JPEGmini
少し前に書いたエントリーでは、h300 にどっと押し寄せたアクセスを捌くために、画像ファイルを別サーバに移したり、最終的には AWS の CDN である「Amazon CloudFront」を導入したことなどを、その判断基準も含めてまとめました。
それに対して、1番よく訊かれたのが
で、ぶっちゃけ、結局サーバ代(CDN 利用料含む)にどれだけかかったの?
という質問でした。
ぶっちゃけたところを、書きます。また CDN 利用料を抑えるために JPEGmini という Web サービスが非常に役に立ったので、併せて紹介します。
h300 にかかった CDN 利用料と、それを半分に抑えてくれた JPEGmini
1. h300 にかかったサーバ代は、ぶっちゃけ 3万円/月
結論から書くと、2012年4月分のサーバ代は、およそ下記のとおりとなりました。
レンタルサーバ(メモリ1GB)x 2台 | 2000円 |
CDN 利用料 | 28,944円 |
合計 | 30,944円 |
レンタルサーバ代の 2,000円はいいとして、気になる CDN 利用料の計算は次のとおり。
30KB(サムネイル画像1枚あたりのファイルサイズ)
x 20(1ページあたりのサムネイル数)
x 100,000(1日あたりの PV)
x 30(日)
= 1,800,000,000 KB
= 1,800 GB(1か月の転送量)
1,800 x $0.201/GB x 80円/$
= 28,944円(1か月の料金)
Amazon CloudFlont は転送量に比例して、課金されます。1GB につき 0.201 ドルかかります。計算しやすいように 1ドル = 80円 で計算しています。
PV はもちろんのこと、1ページあたりのサムネイル数や、画像1枚あたりのファイルサイズも、後述するとおりいろいろと変動がありましたが、ここでは計算の仕方とだいたいの目安が分かれば良いだろうということで、計算しやすい値を入れています。
ということが伝わってくれたら幸いです。なお、ついでというか、僕はなんとなく複雑に感じて使いませんでしたが、AWS では計算用のツールも用意されています。
2. CDN 利用料を半分に抑えてくれた JPEGmini
それと、もうひとつお伝えしたかったのが「JPEGmini」という Web サービス。
結構有名なサービスなのでご存知の方も多いとは思いますが、簡単に説明すると、ユーザがアップロードした JPEG ファイルを、見た目の品質はそのままに、ファイルサイズを圧縮してくれるというサービスです。
ファイルサイズが圧縮されて何が嬉しいかというと
1. CDN 費が抑えられる(AWS CloudFront では転送量に応じて課金)
2. 転送速度が上がり、サイトの表示速度が上がる
実際に使ってみて、デモに載っているように 5分の1とかまではいきませんでしたが、下記の例のようにおよそ半分近くまで圧縮できました。転送量に応じて課金される CDN では、ファイルサイズが半分になるということは、利用料が半分になるということを意味します。
h300 リリース当初は JPEGmini で圧縮していなくて、CDN 費を見積もったら 6万くらいいきそうでしたが、JPEGmini のおかげでずいぶん安く抑えることができました(それでも個人にとっては大きな出費ですケド)
Before | After | |
---|---|---|
画像ファイル1 | 82 KB | 45 KB |
画像ファイル2 | 57 KB | 33 KB |
画像ファイル3 | 53 KB | 29 KB |
画像ファイル4 | 45 KB | 29 KB |
画像ファイル5 | 37 KB | 25 KB |
3. JPEGmini 使用前後で、画像の転送速度を比較
ファイルサイズが圧縮されれば、画像の転送にかかる時間も短くて済みます。今回とりあえずひとつの画像のみ比較してみましたが、結果は下記のとおりとなりました。
Before | After | |
---|---|---|
ファイルサイズ | 76.4 KB | 41.2 KB |
受信にかかった時間 | 178 ms | 16 ms |
(before)
(after)
h300 で扱っているサムネイル画像はそんなに大きなものではないので、150 ms ほどの差しか出ませんでしたが、画像が大きければもっと顕著な差が出ると思います。
4. JPEGmini の仕組み
ん?てか、JPEG って既に圧縮されてるんじゃなかったっけ?
という疑問をお持ちの方は、下記のブログ記事が参考になると思います。僕の知る限りでは、JPEGmini の仕組みは公表されていませんが、小飼弾さんが推測してくれています。
ただし、僕はいまいち理解できませんでした...
5. CDN を利用すべきか否かの判断基準
というわけで、JPEGmini サイコーだよね、つくってくれた人ありがとー、で終わろうとも思ったのですが、最近たまに「やっぱり Amaozon CloudFront などの CDN を使ったほうが良いですかねー?」と相談されることがあるので、触れておきます。
僕は次の基準で判断するようにしています
(1) CDN を使った方がサイトのレスポンスが速くなるのか?
(2) CDN を使った方がレスポンスが速くなるとして、それは、CDN 利用料に見合うだけのものか?
(1) について、意外かもしれませんが、CDN を使ったからといって、諸条件により、レスポンスが速くなるとは限りません。例えば下記は、h300 の、あまりアクセスがない時間帯の、画像の受信にかかった時間です。
レンタルサーバ | CDN | |
---|---|---|
受信にかかった時間 | 16 ms | 28 ms |
(レンタルサーバ)
(CDN)
CDN のほうが時間がかかっています。ファイルサイズが小さかったり、アクセスが少ないサイトでは、レンタルサーバとあまり変わりないか、むしろレンタルサーバのほうが速かったりします。
一方で、転送するファイルのサイズが大きかったり(大きな画像、音声、動画)、アクセスが多いケースでは、有意な差が出るようです。
いずれにせよ、自分のサイトが遅くなったかもと感じたら、一度は実際に CDN を試してみるとよいかもしれません。そして、1ページあたりのファイルサイズと PV を式に当てはめて試算をしてみる。
出された見積金額と、効果とを天秤にかけてみれば、その CDN を利用すべきか否かの答えは自ずと出ると思います。
6. レンタルサーバと CDN のハイブリッドという選択肢
ちなみに、h300 では、CDN を常時利用しているわけではありません。リリース時は、メモリ1GB のレンタルサーバを利用していましたが、画像サーバを、もう少しスペックが高いレンタルサーバ(VPS)に移行させたら、結構サクサク表示できるようになったので、通常はそちらを利用しています。
ただ、本ブログがはてブのホッテントリに載ったり、どこかのサイトで紹介されたりしてアクセスが集中すると、ときおり表示がもっさりすることがあるので、そういった場合は、画像配信を CDN に切り替えています。
...というわけで、h300 の CDN と JPEGmini の紹介でした。よろしければ参考にしてください。ではでは。
▽ h300 - 人妻動画サイトを Rails3 と jQuery スキルアップのためにつくってみました(R18)
(※閲覧は18歳になってから)
おまけ 1 - 無料 CDN「Cloud Flare」という選択肢
社内の詳しい人に教えていただいて、(別の人が)本ブログのコメントにも書いてくださったのですが、いまは「Cloud Flare」(クラウドフレア)という、無料で利用できる CDN があるようです。有料プランも用意されていて月額20ドル。
それはありがたい!と思い、すぐに試したかったのですが、利用規約をよくよく読んでみると、エロサイト禁止でした。orz
というわけで h300 では利用できませんでしたが、エロでないサイトを運営されていらっしゃる方は、試してみる価値があると思います。WordPress のブログとかでも使われているようです。
おまけ 2 - JPEGmini の Mac アプリケーション
JPEGmini は、当初、画像をアップロードして圧縮してもらう Web サービスでしたが、圧縮処理をローカルでできるように Mac アプリがでました(有料)
JPEGmini の Web サービス版は、一度にアップロードできるファイル数は 1000 となっているし、圧縮処理も結構待たされるので、大量の画像を圧縮する人は Mac アプリ版のほうが向いているかもしれません。
- 173 http://b.hatena.ne.jp/
- 50 http://www-ig-opensocial.googleusercontent.com/gadgets/ifr?exp_rpc_js=1&exp_track_js=1&url=http://choichoi.sakura.ne.jp/hatena_bookmark.xml&container=ig&view=default&lang=ja&country=US&sanitize=0&v=93f3141f56619caf&parent=http://www.google.com&lib
- 32 http://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CG0QFjAA&url=http://d.hatena.ne.jp/inouetakuya/20100530/1275186244&ei=aBXKT7C-I-HGmQXA_LXqDg&usg=AFQjCNHdTwpTXJgyiconUr7po4z6EKlAeg&sig2=1bwvKsYot3jA0QLAtxdTYw
- 31 http://b.hatena.ne.jp/hotentry/it
- 22 http://t.co/fH0OoFMM
- 19 http://b.hatena.ne.jp/entrylist
- 19 http://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=4&ved=0CHQQFjAD&url=http://d.hatena.ne.jp/inouetakuya/20100520/1274310646&ei=vxXKT9DMK-mfmQWb8tmMDw&usg=AFQjCNGHe_C95aELir_-rWEN8jy71m6OyQ&sig2=Cip6scjWM11j_r5brZmzEg
- 18 http://b.hatena.ne.jp/hotentry
- 18 http://reader.livedoor.com/reader/
- 15 http://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CIgBEBYwAQ&url=http://d.hatena.ne.jp/inouetakuya/20110726/1311640787&ei=XRTKT4bjGI7ImQWY8bn7Dg&usg=AFQjCNGnpC7j_GEn20kX3ROtaBD742RRWg&sig2=drI_tOhukXu-PIxhPQaCaw
- 2012-05-27 hiratake55 の開発メモ 4/74 5%
- 2012-05-27 ネットワークエンジニアがインフラエンジニアへなるため軌跡 3/59 5%