DEV Community: やざしん

スモールスタートでサービスを作る時は、やはりHerokuが便利だね

やざしん — Thu, 12 Apr 2018 05:12:23 +0000

スモールスタートでサービスを作る時に今ならどのPaas使って構築するか考える

知人に聞かれたので整理も兼ねてここに残しておく

超かんたんなサービスの初期要件

機能要件)
- 会員登録ありのSNS
- メディア媒体あり
- ニッチセグメント版Rettyみたいなやつ
- 最近流行りのBlockchainとかそういうのは使わない
非機能要件)
- 拡張性があること(グロース時に、Paas変えなくてもスケールできること)
- ドキュメントが充実してること (jp/en問わず)
- あるていど技術的に枯れていること
- Paas業者が潰れなそうなところ (スタートアップ系のPaasは避ける)

結論

heroku (https://jp.heroku.com/home) 一択だなと
エンジニアがインフラ面をそこまで意識せずに使えるのは大きい。特にスモールスタート時は開発リソースも少ないので
運用コストが安い。初期の頃は無料プランで対応できる。(無駄にスペック高くしなければ)
運良くサービスがヒットし、グロースしたらエンジニア採用してAWSとかGCPに引っ越せばいいと思う

比較対象

ConohaなどのVPS
- 月額数千円〜は必ずかかる。インフラ知識が必要。サービス以外に思考リソースが取られる
Amazon Web Service (AWS) や Google Cloud Platform (GCP)
- 初期の頃は無料プランである程度つかえる。しかし、AWS/GCPの操作に関して、前提知識が結構必要
- セキュリティの設定をきちんとしないと、クラウド破産もありえる。下記は救われているが、救われないケースも有る
- 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。

余談

まぁ、dev.to (このサービス)もherokuで動いてるしねー。

The dev.to tech stack

劇的改善！管理人さんが何したかを推察してみる

やざしん — Thu, 29 Mar 2018 16:18:14 +0000

劇的改善！おつかれさまでした！！

Twitterで本人もツイートしていましたが、主に画像サイズを適切に処理したそうです

具体的な対応を推察してみる

たぶんjetpackとか入れたのかなと予想しつつ詳細をみてみます。
まぁ、当然これは確認しますよね
私がchromeでみたので、h2かつwebpで配信され、１画像あたり劇的にファイルサイズが減ってます
画像のリクエストをみてみると、
https://i[0-2].wp.com/ で画像が配信されてますね。その時に、画像のリサイズもはいってます。
わかりやすく、jetpackのphotonですね。 (言い切って間違ってたら恥ずかしいｗｗ)
photonは導入がらくなのですが、キャッシュが消せないのとか一部デメリットがあるので、それふまえて使う分には良いサービスですね。wordpressと蜜月で導入がとにかく楽です。

ここまできたら全面https/h2, AMP対応にしてほしい！とか欲張ってしまう (これはエンジニアのエゴ)

メリットとして、googleのSEOに強くなります。googleはhttpはどんどん非推奨としてランクおとしてますから。
- GoogleはHTTPSで保護されていないサイトを「安全でない」とChromeブラウザにハッキリと表示する方針
- ※2015年の記事です※HTTPS ページが優先的にインデックスに登録されるようになります
https&h2対応すると、UXが向上します。具体的には、h2対応ブラウザ(chromeとか)で見る時に、コンテンツが並列DLされて、表示速度が早くなります（体感でもわかるレベル。WEB屋ならw)
AMPもmobileで見るときのUXが劇的にあがります
- でも、AMPプラグインいれただけだと、デザインがクソダサいのでその調整コストが発生します。。

何はともあれ、劇的改善、おつかれさまでした！！

趣味のゲームでお世話になってるサイトが、レンサバから怒られてるツイートをみて改善案を考えてみた(3/24追記あり)

やざしん — Fri, 23 Mar 2018 03:52:54 +0000

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プラン
- https://www.xserver.ne.jp/functions/
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以下に縮小するのもできますが、レイアウト崩れたりするので..
ドキュメントはこちら

転送量を軸としたときの、サーバー代の目安について

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化は必須
- 公式サイト
- conohaでの使い方

所感

今回の件を通じて自分として学べたのは、クラウド系サービスは従量課金が主軸で、それを当然のようにつかってきたけど、それに慣れてない人が従量課金の世界に踏み込むと簡単にクラウド破産するリスクあるなーと。
大抵のサービスは、利用料金ベースで上限設定ができるので（AWSとか）、それをやるのはマストだなと。
レンサバは、"転送量"という軸では結構ゆるい。ただし回線細い(100Mbps)
- 100GB/日 (3TB/月)の範囲に収まるなら、
  - XSERVER X30プラン 4,000円程度 ※ ただしNW回線が100Mbpsなのでかなり詰まる(遅い)だろう
  - AWS 転送量だけで、50,000円ぐらい ※ 爆速。どんなに高負荷でも落ちない