実はHerokuで充分なのでは問題

Herokuはwebアプリをインターネット上にデプロイする場所として広く使われている。web業界の人は誰もが一度は触った事があると思う。

何が便利なのかというと、デプロイ作業が極めて簡単なことだ。コマンド一発でサーバーが用意され、これまたコマンド一発でデプロイが出来る。一般に、webアプリは依存するライブラリが多種多様あり、それらを漏れなくインストールしないとデプロイ出来ないのだが、代表的なwebアプリケーションの作り方に添って作っている限り、後は構成を検知してよしなにやってくれるのだ。noteのリリース時の検証にも大活躍してくれた。

別にHerokuの回し者ではないのだが、一旦これを経験すると、VPSを借りてLinuxのセットアップをしてミドルウェアいれて....といった一般的な構築作業が気の遠くなる工程に思えてくる。

しかし、HerokuはUSとヨーロッパにサーバーがあり、日本からの通信に時間がかかるという問題があった。「光遅すぎ問題」というやつで、数十数百ミリ秒の遅延も体感速度では結構ストレスになってしまう。速度はUXに大きく関わるため、特にtoCのサービスでは本番環境で採用するのは厳しかった。

しかし、最近はすべてのリクエストをCDNサービス経由でキャッシュするケースが増えてきたため状況が変わってきた。CDNは全世界にキャッシュサーバーを配置し、アクセスされた場所に一番近いサーバーが応答してコンテンツを返す。これにより、「光遅すぎ問題」が解決され、高速に通信ができる。

いままでは静的コンテンツ（画像やcssなど）しか現実的にはキャッシュできなかったが、動的コンテンツ、つまり "/konpyu" のようなアクセスするたびにレスポンスが変わるページもCDNにキャッシュ可能になってきた。

そうなると、Herokuのサーバーが地球上のどこにあるのかは大きな問題ではなくなる。CDN用語で、キャッシュの基となる提供元をオリジンというのだが、Herokuはオリジンとして機能すれば充分ということになる。

実際、爆速だと話題になった dev.to も動的コンテンツのキャッシュにCDNサービスのFastlyを採用し、オリジンはHerokuを使っている。Herokuでも充分に爆速になっているわけである。

もちろん、キャッシュを効かせようのない更新系のリクエストは受け付ける必要があるため、Herokuサーバーをどのくらい用意（=課金）しておく必要があるかはサービス特性による（これまた、コマンド一発で簡単にサーバの増減ができるのでラクではある）。

というわけで、サービスの規模や特性によっては、HerokuとCDNで充分に対応できる時代になっているのでないかと思っている。

余談: dev.to は少ない人数で回しているためか、Herokuはもちろんのことあらゆるコンポーネントを徹底的にSaaSで代替し省力化している。以下のstackリストがなかなかおもしろかった。

https://dev.to/ben/the-devto-tech-stack