インフラ周りでお金をかけずに SSR したかった（AWS + Cloudflare）

SSR（Server Side Generation） というのをやってみたくて、Twitter のトレンドを時系列でチャート化するサイトを作った。
結局 SSR は必要なくて、SSG になっちゃったけど。

見た目はこんな感じ

実現したかったこと

最近のツイッターのトレンド推移を把握できるサイトを作りたい。
トレンド情報は一時間に一度 Twitter API を叩いて取得する。
-> トレンド情報をどこかに保持しておく必要がある

実現方法の遷移

構成

Backend + SSR

当初考えていたのは「Twitter API を叩いてレスポンスを保存しておくバックエンド」 + 「バックエンドを見にいく SSR サーバー」で、一時間毎の更新なら適当にフロント html のキャッシュ時間を長くしておけば良いかな、と言うもの。
予算の都合上バックエンドサーバーと SSR サーバーは同じ EC2 に置いた。
それぞれ Docker Image を作って ECR にプッシュしておいて、EC2 からプルして使う。
あとは Cloudfront のオリジンとして EC2 を使う形。

ここでドメイン周りが問題になった。
Cloudflare で管理してるドメイン（ahyaemon.com）のサブドメインを Route53 で管理したかったんだけど、Cloudflare の無料範囲内でそれができない？っぽかった（自分のやり方が悪かっただけかも知れない）。
Cloudflare 側で SSR できないかとも思ったけど、対応してるフロントエンドのフレームワークが Remix だけみたいなのをどこかで読んで、面倒いなと思ってしまった。

Backend + SSG

色々考えた結果、一時間に一回 SSG したほうが楽かなーという結論に至った。
で、一つの EC2 内にバックエンドサーバーと SSG サーバーを置き、cron で一時間毎に SSG してた。
next export して、その結果を S3 に置いた。

でも流石に t2micro の力ではそれを支えきれなかったみたいで、CPU クレジットを使い果たして瀕死になる事態が多発した。
実際は ssh で入ってなんやかんや試してる時に瀕死になってたんだけど、そういう試行錯誤が頻繁に中断されるのも微妙だからやり方を変える必要があった。

そこで、SSG は別の場所でやることにした。
定期実行だから ECS Fargate でやればいいかなと思ったんだけど、EC2 バックエンドサーバーとの通信が上手くいかず途方に暮れた。
あと ECS だと pull の時間がオーバーヘッドになるんじゃないかと言う不安。
あと Fargate は無料枠だと使えない。

結局、家で眠っていた MacBook Air に定期実行させるという最終手段に落ち着いた。
多分 Fargate を使うよりもマックつけっぱの電気代のほうが安いはず、、

あと何処かの時点で S3 ではなく Cloudflare R2 を使うようにした。
aws s3 コマンドで R2 にプッシュできたのは感心した。

フロント系は全て Cloudflare でなんとかなったので、 Route53 と CloudFront もやめた。
Route53 に微妙にお金が掛かってたから良かった。

最終的な構成とか技術スタック

SSG とバックエンドとインフラの Terraform を全部ひっくるめてモノレポにしたけど、個別でデプロイしたい時にめんどかったりするから分けるかも知れない。

フロントエンド

• React
• Next
  • ローカルマックから launchctl で定期的に SSG
    • SSG 結果は Cloudflare R2 にプッシュ
• TypeScript
• MUI
• Recharts
• ドメイン周りは Cloudflare

バックエンド

• Kotlin
• SpringBoot
  • @Scheduled を使って定期的に Twitter API を叩く
    • 取ってきたデータは DB じゃなくてメモリに置いておくと言う暴挙
  • @Controller でエンドポイントを用意
• EC2
  • docker build して、ECR プッシュして、EC2 にプルして起動するまでを github actions で実行

おわりに

家のマックの充電器の数がマックの数より少ないため、取り合いになる。