クラスメソッドの最新開発ノウハウを学ぶ勉強会サーバーサイド編

肥後橋のクラスメソッドさんの勉強会にいってきました。
お菓子と飲み物が準備されているのが嬉しいですね。

セッション

西田将幸さん

構成
- CloudFront + ALB + Fargate + Aurora
- フロント : Next.js
- コンテンツ : microCMS
- CI/CD : Github Actions
モダン化？
- フロントは TypeScript しか考えられられない
- バックエンドと両方使える TypeScript 採用
- React を CX 事業部ではメインで使っている
SEO 要件
- SEO が重要なので SSR が必要だった
- bot でクローリングできないケースと高速化のために SSR を採用
Next.js
- React で SSR するならデファクト
- 反面 SPA のように S3 + CloudFront でほっとけない
Fargate
- もともとあった VPC 内の RDS を参照するため
- Lambda より安定するから ECS 採用
- Node.js 実行基盤
NestJS
- バックエンドは NestJS で内部 Route53 をたてて Fargate で実行
- ルーティングに Internal ALB は使ってない
- Next.js の API Routes を BFF として使用
バックエンドエンジニアが多い
- バックエンドエンジニアもフロントエンドにコミットできるようにした
- Turborepo を使ったモノレポ構成
- CI/CD はパスもチェック
- Zod を利用

SPA で済むならそれでもよかったけど、SEO が重要なので SSR にしたとのこと。
SSR にすると動かす基盤が必要で、そのときに Fargate 使うならプラットフォームは気になくていいけど、Node.js のアップデート対応が気になるなー。

濱田孝治（ハマコー）さん

vCPU に対する物理コアの違い
- x86 は 2vCPU 1物理コア
- arm は 1vCPU 1物理コア
- 要するに同じインスタンスサイズで arm は2倍の物理コア利用なので安い
インタプリタ（Node.jsやPython）やJavaなら設定変更だけで使える
マルチアーキテクチャコンテナイメージ作れば解決

マルチアーキテクチャは buildx 入れるのがめんどくさいので一旦諦め。
マルチアーキテクチャにせずに Arm でビルドして Fargate使ったけど、意外と誰も Graviton は本番利用してないのね。

P33 の Lambda のランタイム一覧で、Go に赤枠ついてないけど、Go も Arm 対応してないですね。
Image 作って動かすことならできます。

新澤忠士さん

ログの要件
- 問題検知、調査
- 法令遵守
- データ活用
CloudWatch Logs
- Subscription Fileter で Firehose から S3 へ配置
  - Lambda で Text からバイナリ変換
ログの量が多くなると
- NAT Gateway ではなく VPC Endpoint を通したほうが安い
Fargate で Fluentbit を動かして Firehose でバッファリングさせて S3 に吐く
- CloudWatch を通さずに節約
- Lambda の場合、標準で CloudWatch に出力させるので IAM で止めてしまう

Log はとりあえず設定して、料金が上位にきてしまうというあるあるなケースに陥ることが多いです。
よほど費用がやばくない限り、コストをかけて改善するかは迷うところ。

参加している人が少なめではありましたが、関西では顔なじみな人が多かったですね。
今回は、ハマコーさんと懇親会でたくさん喋れたのがよかったです。
たぶん、re:Invent 以来でした。