2018/03/24追記概要
- 下の方にあります
- 初手の画像サイズ変更について
- 転送量を軸としたときの、サーバー代の目安について
はじめに
趣味のゲームでお世話になってるサイトが、転送量(20TB/month)を叩き出し、レンサバから怒られてるツイートをみて
改善案を考えてみた
該当のツイートはこちら
TL;DR;
- 原因
- 1ファイルあたり画像がでかい
- キャッシュコントロールができてない (no-cache沢山ついてる)
- CDNつかってないので負荷が全部WEBサーバに集中。アクセス集中時に500で落ちてる
- 対応の初手
- nginxの設定かえて、画像はCDN経由&CDNで画像サイズの最適化もする
- 根本対応
- 案1) XSERVERから、conohaとかさくらに引っ越し&wordpress(ノーマル)をwordpress(kusanagi)に変えて高速化
- 案2) WPの記事をS3など経由して静的コンテンツとして配信するモデルに変更
- 移行コスト＆作業量を考えると、案2のほうが楽だろう
- cloudfront + S3の配信モデルにして、https対応+h2対応を同時に行う
- cdnはfastlyでも良いが維持コストがトレードオフ (個人利用ではfastly高い...)
- 効果
- 初手の対応するだけで
- XSERVERの転送量は大幅に減らせる(1/100。つまり200GB/月も狙えるかも)
- 例の悟飯(幼年期)の画像でいうと → 3.6MB が 36KB相当にできる
- 頻出する120KB程度の画像も30~40KBに削減できる
- 初手の対応するだけで
- 試算(記事TOP4位までの数字なので、全体量とは異なる)
現状整理
- PV: 2000万PV/月
- 転送量: 20TB/月。520GB以上/日のスコアもあり
- 情報源：https://twitter.com/suuzidedokkan/status/976830275484254208
ページの特徴
- キャラのカード画像をそれなりに使っているので、ページあたりの容量は増えがち
- 各ページにコメント機能があり、コメント量も多い
-
2月のPVランキング をみると
- 3位の記事が1TB越えてますね。体感として、全部画像が無駄に大きい
- 特に4位の悟飯の画像は1枚で3.6MBもある 笑
- TOPページの状況 (Ad画像は含まず)
対策のコンセプト
- 移行コストをなるべく掛けない (費用も、作業量も)
- キャッシュコントロールを見直し、CDN活用する
- ついでにサイト自体の高速化も含めてやる(https対応, h2の対応 etc)
サーバ構成を分かる範囲で調べる
- XSERVER X20プラン
- wordpress自動インストールサービスを使って構築してる(だろう)
- nginx + wordpress (php7 + mysql 5系)
- 前述の調査をふまえて、基本的に転送量だけがネック
- ただ、たまに高負荷で500エラーだしてるのでWP自体の高速化も必要
- だいたいアプリがメンテに入ると、このサイトも500出し始める
具体的な対応
対応の初手(緊急度が高いと思うので、対応スピード優先)
- nginxの設定かえて、画像はCDN経由&CDNで画像サイズの最適化もする
- CDNはcloudinaryを使う
- URLパラメータを使って、動的に画像変換できる
- デバイスごとに最適な配信調整ができる(jpeg, webpとか)
- 導入コスト(作業量)が少ない
- 兎にも角にも、cloudinaryでアカウントつくる
- 下記URLから登録してもらえると、双方に転送量とかのボーナスが付きます
- https://cloudinary.com/invites/lpov9zyyucivvxsnalc5/phh26dlxmmplxsgcx7of
- nginxの設定はこんな感じ。suuzidedokkanってところは、cloudinaryでそのアカウント取得してた場合の仮値
$> vim /etc/nginx/conf.d/suuzidedokkan.conf
location ~* \.(jpg|jpeg|gif|png|ico|svg)$ {
access_log off;
expires 10d;
# use cdn
rewrite ^(.*)$ https://res.cloudinary.com/suuzidedokkan/image/fetch/c_limit,f_auto,fl_progressive,q_auto/http://xn--n9jvd7d3d0ad5cwnpcu694dohxad89g.com$request_uri? last;
}
- 試算(記事TOP4位までの数字なので、全体量とは異なる)
根本対応
- 案1) XSERVERから、conohaとかさくらに引っ越し&wordpress(ノーマル)をwordpress(kusanagi)に変えて高速化
- DB-Dumpとか含めて、それなりに手間がかかる。
- 案2) WPの記事をS3など経由して静的コンテンツとして配信するモデルに変更
- 移行コスト＆作業量を考えると、案2のほうが楽だろう
- cloudfront + S3の配信モデルにして、https対応+h2対応を同時に行う
- cdnはfastlyでも良いが維持コストがトレードオフ (個人利用ではfastly高い...)
- ここのやり方は気が向いたら更新します
あとは数字でドッカン管理人さんからDMでもきたら個別にやり方教えます。 (@yazashin までどうぞ)
★ 2018/03/24 追記
初手の画像サイズ変更について
- 上記に書いた設定だと、画像の自動最適化は行っていますが、そもそもでかすぎる画像の縦横サイズ変更まで入れてません。なので劇的な効果はでないとおもいます。
- パラメータ調整すれば、一律、横幅 400px以下に縮小するのもできますが、レイアウト崩れたりするので..
- ドキュメントはこちら
最新の状況
- とりあえず下記ツイートから、CDNへの転送については導入出来た模様
- おつかれさまでした！ これで転送量ベースで、画像の可視化ができました
現状は、多少画像の最適化はされた状態ですが、ほぼCDN化前と同じ転送量になってるとおもいます
-
手順としては、このレポートページから下記の様に、転送量の多い画像から対策を順番にしていきます
- 私の管理してる本番データなので、要所要所ぼかしてます
- 私の管理してる本番データなので、要所要所ぼかしてます
wordpressにアップロードした画像を１個づつ編集していくか、アップロードフォルダの画像まるっとDLして、一括でサイズ変更かけるか。やり方は色々です
転送量を軸としたときの、サーバー代の目安について
- XSERVERだと、下記の転送量上限がある https://thepracticaldev.s3.amazonaws.com/i/asnh590e4vi3as1qqd85.png
- X20プランだと90GBで、管理人さんが怒られたメール本文と一致。X30にしても焼け石に水感あり。
- 今回のケースは、マシンスペック（Wordpress動かすサーバ)は、4core/メモリ8GB/Disk 100GB(これはどんだけ使ってるかわからないので適当)程度あれば良いだろう
- とにかくネックは転送量。
- 地道に画像サイズ減らす＆CDN幾つかつかって、無料枠の範囲で切り替えていく(手動だけども)が金額的にはいいのかも。
追記まとめ
- 月20万ぐらいサーバー費にかけれるぜ！ってのなら、AWS化が個人的におすすめ。（必要なら手伝っちゃうレベル)
- XSERVERからConoha VPSに引っ越せば、金額面でも転送量面でも幸せになれそう
- Conoha おすすめ。私も商用で使ってます。
- 引っ越すなら、Wordpressはkusanagi化は必須
所感
- 今回の件を通じて自分として学べたのは、クラウド系サービスは従量課金が主軸で、それを当然のようにつかってきたけど、それに慣れてない人が従量課金の世界に踏み込むと簡単にクラウド破産するリスクあるなーと。
- 大抵のサービスは、利用料金ベースで上限設定ができるので（AWSとか）、それをやるのはマストだなと。
- レンサバは、"転送量"という軸では結構ゆるい。ただし回線細い(100Mbps)
- 100GB/日 (3TB/月)の範囲に収まるなら、
- XSERVER X30プラン 4,000円程度 ※ ただしNW回線が100Mbpsなのでかなり詰まる(遅い)だろう
- AWS 転送量だけで、50,000円ぐらい ※ 爆速。どんなに高負荷でも落ちない
- 100GB/日 (3TB/月)の範囲に収まるなら、
Top comments (0)