【Web技術】高速配信の戦略

0.前提を押さえる

転送量を抑えることを意識すること

AWSをはじめとするクラウドサービスでは転送量ベースの課金を採用しているものが多い。無計画に配信していると馬鹿にならない金額になる。

1.クライアント側の対策

標準仕様の誤解から不用意な設定を行なっていないかチェックする。

正しいHTTPヘッダの設定を行い、ローカルキャッシュをうまく使ってリクエスト数そのものを減らせないか検討すること。HTTPヘッダの仕様や設定方法などについては以下の記事で解説しています。

【Web】HTTP、ブラウザのキャッシュ機能について

キャッシュが有効に使われているかチェックをするには開発者ツールで、「memory cache」もしくは「disk cache」と表示されているか確認すれば良いです。

コンテンツのサイズを小さくする。

非常に有効な戦略。原則Web/APPサーバーで圧縮を行います。（ちなみに、AWSのS3は特に圧縮については何もしてくれないです。）

ただ、コンテンツを小さくする処理をリクエストのたびに行うとWebサーバーなどのオリジンの負荷は増大してしまいます。スケールアップやスケールアウトなどで対策をとるということもできますが、コストが増えてしまいます。

ただ、キャッシュサーバー（Proxy/CDN）が小さくしたコンテンツをキャッシュすることでオリジンの負荷を軽減でき、さらには低コストにできる。

メディア系

配信コンテンツとして大きいのはこちら。サイトとコンテンツはリッチになりつつあるのでメディアも増大しています。

画像

例えば、小さく表示するためのサムネイルなのに明らかに大きな画像が設定されているなど。

目安としては、通常のサイトであれば300KBを超える画像、画像主体のサイトなら1MBを超えてくるものがあれば改善対象としてチェックするべきです。

大きい画像であれば、適切なリサイズや画質を少し下げたりします。(JPEGならquality)

圧縮に関しては画像フォーマットの多くはすでに何らかの圧縮がかかっているため画像は圧縮に含めない方が良いです。

また、実装時の考慮点としては、一覧ページと詳細ページで表示画像サイズを変えることも重要です。（一覧は一気に画像を表示するので、画像サイズを小さくすると良い。）

→たまに、同一の画像をCSSを使ってサイズだけ変えているというケースがありますがこれは配信においてはアンチパターンになります。一覧と詳細で別サイズでそれぞれ用意しておくのが良いです。一見すると、2枚の画像をそれぞれ持つのはディスク容量が圧迫しそうですが、トラフィック面ではメリットが大きいです。最近はサムネを一気に作れるサービスも出てきています。（AkamaiのImage &Video Managerなど）

最近流行りのwebPやjpeg、pngなど画像形式の使い分けについては詳しくは以下にまとめております。

【Web技術】配信のための画像の知識

動画

HLSやCDNなど自前配信はコストがかかりすぎるので避けるべきです。（動画技術者などを集める必要がある。）普通にYoutubeを使って埋め込みにする方がかなりコストが安くなりますし簡単です。

ただ、動画でのコンテンツ制作ではなく、配信自体をビジネスとしたい場合は話は別ですが。

テキスト系

テキスト系であればボディを圧縮する対策が使えます。gzipもしくはbrotliなど。minify済みのJSとかでも1/3程度に圧縮されたりできます。（gzipであればほとんどのブラウザが対応しています。）

有効になっているかは、Chrome開発者ツールの「Content-Encoding」がgzipになっているか見ればすぐにわかります。

また、テキスト系でも圧縮するとしても圧縮自体のサイズが小さいものはあまり効果がないので圧縮対象から外しましょう。(nginxでいえばgzip_min_lengthなどで指定可能です。）

CSS

CSSスプライトはHTTP1.1時代は有効な戦術だったが、HTTP2時代はmultiplexingが効くのでそこまで必要じゃなくなった。

ちなみに、CSSスプライトとは複数の画像リソースを一つにまとめてしまって処理時間を高速化する手法です。

JavaScript

近年のJavaScriptのファイルサイズはどんどんファイルサイズが肥大化してきている。jQuery3.3.1であれば、minify化しても86KB(する前であれば270KBもある)。

2.Proxy、CDN導入を検討

「1」の対策はユーザー側の負荷低減のために必要ですが、ユーザー数が増えてきた場合はサーバー側に負荷がかかることになるのでサーバー側の負荷低減のためのキャッシュによる対策も重要になります。

Appサーバー自体にキャッシュをするという方法もあるかもしれませんが、CDNやProxyなどのキャッシュに特化したサーバー(Varnishやnginxなど)に比べて効率的ではないです。

なお、CDNはリクエスト数による課金が増えることがあるので注意です。

ESIを使う。

サイトを部分的にキャッシュすることができます。最近はJSONを使ってAPI経由でやり取りすことも増えましたが、それもESIで合成が可能です。

3.インメモリデータベースを使う。

memocachedや、ElasticCacheなどですね。

4.サーバー増強

単純にProxyの台数を2台に増やせば帯域の数を倍にすることが可能です。

Proxyを複数台に分けるデメリット

Proxyの帯域性能について

1Gbpsあれば問題になることは少ないです。実際はそれより遥かに少ない100Mbpsを使っていることが少なくないです。その場合仮に10台並べて1Gbpsの帯域を使えるようにしたとしてもクライアントの通信速度は最高100Mbps以上にはならないです。そこまでするならCDNを使う検討をした方が良いです。

キャッシュストレージを共有していない。

Proxy間でキャッシュストレージは共有していないです。なので別のproxyに問い合わせたときにキャッシュがなければオリジンへ問い合わせるので負荷が行ってしまうことになります。

対策

Proxyを並列ではなく多段にしてキャッシュ情報を集約するようにします。システム全体としてもキャッシュストレージの容量を増やすことが可能です。（二段目で重複して持たせるようにできるため）

また、多段にすると耐障害性も高まります。(Proxyが障害でダウンした際も他のProxyで拾える）

1段

管理するProxyの台数は減らせますが、設定が複雑になりやすいというデメリットがあります。また、パフォーマンスを出すために気をつけるポイントも多いです。

2段

基本はこれで十分なケースが多いです。

3段

海外などにいくような大規模な配信をする場合以外は検討しないです。というかこのような構成は自社でやることはほとんどないです。CDNもこの構成になっているので活用します。