「Heroku Meetup #19 Heroku Trust!」でLTさせてもらってきました！

せっかくなので、LTのスライドを一部修正して掲載しておきます。

Heroku Meetupはずっと行きたかったけど今まで都合がつかず、初参加できてよかったです。

ピザごちそうさまでした🍕

LT内容

というわけで発表したスライドはこちら。

3行で要約

補足とか言い訳とか

ちょうど発表の数日前に、似た内容の話がはてぶでバズってました。

またさらに前に話題になったdev.toもHeroku/Railsであの爆速を実現してて、その速さのコアな部分はFastlyによるCDN配信だったと理解しています。

今回発表した内容も考え方はほぼ同じなんですが、Fastlyとかを使うんじゃなくてGCS使ってるところが違う点です。

またメリット/デメリットの比較に関して、今回は配信速度の追求よりも、大量のアクセスをちゃんとさばくというところに重点を置いているため、その点もご了承ください。

個人的にはdev.toの爆速っぷりに驚いた一人なので、今後Fastly（もしくは類似サービス）を使うのはもっと主流になっていくんじゃないかと思っています。

ただ現時点でまだCDNでの動的コンテンツキャッシュをよく把握できておらず、自分の力量を考えると本番で試すのは怖いなーという感じです。

あと金額的にもFastlyは多少高いのかなーと思っていて、個人のWebサービスなんかで使うにはまだハードルが高いという印象です。

※そもそもFastly使ったことないので、違うよっていうご意見あればぜひ教えてほしいです。

その点GCS方式は、ベストプラクティスではないかもしれないけど、わたし程度のエンジニアレベルで3年運用してて、お安くてトラブルもなく、今のところ超快適です。

なので少なくとも現時点で、お手軽に試す分にはおすすめできるんじゃないかなーという話でした。

ちなみに、LTのあと懇親会で色んな方に話しかけてもらったのですが、ちゃんとした開発会社さんからS3で似た仕組みを運用してるよ、という話を聞きました。

4年前に試行錯誤してこのやり方にたどり着いたのですが、まぁ間違ってなかったんだなーと思えてうれしい限りです。

まとめというか、余談

せっかくLTまでしたんですが、THE TOURNAMENTは現在、Rails/HerokuからFirebase/Riot.jsに絶賛リニューアル中です。

しかしFirebaseにインフラが変わっても、このGCS方式の仕組み自体は続けています。

いままでHTML出力は、Herokuのschedulerアドオンでバッチ処理していたのですが、CloudFunctionでFirestoreの更新をトリガーに動かすように変えたくらいですね。CloudFunction超便利。

安定稼働してきたらFirebase版のやり方もまとめてみたいと思います。

余談の余談

Herokuからの移行を決めたのには色々理由があるのですが、Herokuがだめだからというわけではなく、作ってるサービスとの相性が大きいです。

トーナメントだとデータ構造がほぼjsonで、フロントでうにょうにょ動かすのがメインになることを考えたときに、Heroku/Railsである必然性がなくてですね。。（気付くのが遅い）

個人的にいまでもHerokuは大好きです。

現状Herokuの無料プランでずっと動かせるのは1アプリだけなので、トーナメントの枠が空いたら、4年ぶりにHerokuで新しいアプリを動かせるのが楽しみだったりします。

おしまい。

（2018年4月1日追記）

Firebaseへのお引っ越しが完了したので記事にまとめました。

さようなら、Heroku。また会う日まで。。