#えむけーろぐ

間違った事を書いていたらやさしく教えてください

『Web配信の技術』を読んだ

出版されてすぐ買ったものの、積読本になっていた『Web配信の技術』を読んだのでメモ。

この表紙を見て「キャッシュ周り、特にCDNの本かな」という期待をして購入した。もちろんCDNへの言及も多いものの、特に前半はCDN以前にWeb配信という領域でHTTPの仕様を理解しつつ当たり前のこと当たり前にやりましょう、という話が多く書いてあった印象。例えばgzip圧縮ちゃんとしましょう、とか不必要にデカいアセットを配信するのはやめましょう、とか。各種HTTPヘッダ(VaryとかAccept-Encodingとか、もちろんCache-Controlとか)の役割などについてもRFCを参照しながら解説されていた。no-cacheは「キャッシュをするな」という意味ではないですよー、とかそういうところも。リバースプロキシやCDNをうまく使う話は後半に寄っていた気がする。

本の中でも書かれていたが、「Web配信」というとどうしてもYouTubeやSpotifyなどのように大きなファイルの配信を必要とするWebサイトや、ソシャゲやメディアなどtoC寄りのサービスのほうを想像してしまいがち。またこの手のサイトは時間帯によってアクセス数の大小が激しかったり、バズると跳ねがちなので配信頑張らなきゃいけないのは自明。でも実際はそれだけではなくて、toBのWebサービスも立派なWeb配信である。今どき画像を使わないWebサービスなんてそうそう無いし、そもそもHTMLを吐き出すのだって裏側のDBや外部サービスにアクセスして何かしらの処理をして生成するんだからコストは掛かる。そのため、この本で書いてあるようなWeb配信をちゃんとやるプラクティスは役に立つ。

今どきはアクセスがそんなに多くないtoBのサービスでもEC2やS3をそのままインターネットに露出させずCloudFrontを挟んでいると思うが、それはなぜなのか。オリジンが太平洋を跨いだUSにあるHerokuでも、直アクセスするよりCDNを挟んだほうが日本からの遅延が少ないのだが、それはなぜなのか。本書を読めば、これらの疑問にそれなりの根拠を持って答えられるようになると思う。

あと僕みたいなRails中心でやってきたWebエンジニアは、HTTPのキャッシュまわりの意識が低い傾向にある気がしていて、静的コンテンツはとりあえずキャッシュさせるものの、動的コンテンツは一切キャッシュしない*1ケースが多いと思う。何も考えずにRailsでコードを書くと多分そうなる。本書では「動的コンテンツをキャッシュさせる意義と方法」や、「動的コンテンツ中心のWebサイトでCDNを通す意義」についても触れられていて、その辺をちゃんとやっていこうという気持ちにもなる。

最後の方の章では、CDNの役割が単なるキャッシュサーバではないということにも触れられていた。CDNの本質は世界中のネットワーク品質が良く、ユーザに近いところにエッジサーバがあることであり、キャッシュはCDNが得意ないくつかのことのひとつに過ぎない。キャリア的にtoBのサービスを作ることが多くCDN無くてもいいんじゃないと言われがちかもしれない自分にとって、この視点を獲得できたのは大きい。

 

積ん読だったこの本を再度手にとった動機はPodcastの音声配信まわりの改善*2だが、本業の仕事の方でも十分役立てられそうな内容が多くてよかった。

*1:Railsのコントローラーから返すレスポンスは基本 Cache-Control: max-age=0, private, must-revalidate なはず

*2:趣味でやっている「ゆるふわPodcast」の音声配信はすべて自作している。参考: Podcast配信システムを自作したら捗った話 - SpeakerDeck