Amebaチョイス 立ち上げの裏側 ~依存システムとの闘い~

自己紹介 2 AmebaLIFE事業本部 五十嵐 大地（Daichi Igarashi） X: @mr_ynu_2014_no4 / GitHub: Dai7Igarashi ● 20新卒 フロントエンジニア@Ameba ● Ameba Pick → ブログ → Amebaチョイス 立ち上げ → Owl出向中 ● SEO関連の開発を多数経験 ● 目標はフルスタック

アジェンダ 3 ● Amebaチョイスを取り巻く技術 ● しんどかったこと・乗り越えた方法 ● 成果と振り返り ● 締め

Amebaチョイスを取り巻く技術 4

サービス紹介 5 2024年5月15日リリースした、商品比較メディア。 「Amebaチョイス」を検索してみてね！

開発経緯 6 去年 Ameba x CyberOwl によるライフスタイル管轄が誕生。 CyberOwlのノウハウ・システムを利用し、Ameba発のSEOメディア立ち上げへ。

記事配信の大まかな流れ 7 商品モジュール （SSR）

記事配信の大まかな流れ 8 記事本文エリア （SSR）

記事配信の大まかな流れ 9 ページ全体 （SSR）

記事配信の大まかな流れ 10 なんか複雑すぎん🤔？

microCMSでやる場合の比較 11 vs

microCMSでやる場合の比較 12 vs OwlのCMSについては 詳しく触れません（ご容赦🙏）

しんどかったこと・乗り越えた方法 13

制約と願望 14 ● DB参照モジュールは ○ SSRしてCMSに返す ○ 個々でhydration用scriptを実行 ● CMSはSSR結果を記事配信サーバに返す ● Amebaで標準化されつつある構成が良い†1 ● DB更新系＆SEO対策のためSSR必須 ● App Router使いたい（使ってみたい） ● ウィジェットサーバは分離したい <直感 †1. Muddy Web #4 「Amebaブログの会員画面システム刷新の道程」を真似たい

しんどかったこと1. 記事用CMSのレスポンスがHTMLのため、UI作りが難しい 15 記事本文はHTML（文字列）で返されるので、Reactコンポーネント作りが無理。 CMS側でclassを自由につけられるので、それでひたすら頑張る... これについては工夫の余地がなかったので諦め😇

しんどかったこと1. 記事用CMSのレスポンスがHTMLのため、UI作りが難しい 16 CMSが返すDOM構造で対応不可なUIは、createPortalでDOMに差し込む（荒技）

しんどかったこと2. ウィジェットhydration用scriptがNative ESM + libモードでビルド必須 17 これだけならViteが良さそうだが、Viteでのサーバビルドは不都合が多い。 ● express動かすのにvite-plugin-nodeなどが必要。 ○ CJSでのサーバ実行自体に必要そうだが、ロックインがヤダ（制御が難しい）。 ● importするライブラリによってはESM→CJSがうまくいかずエラーになる。 ○ vite-plugin-esmoduleとか色々試したが、やはり制御が難しいのでヤダ。

しんどかったこと2. ウィジェットhydration用scriptがNative ESM + libモードでビルド必須 18 そこで、クライアントはvite・サーバはtsup（esbuild）でビルドを分けた。

しんどかったこと3. viteとtsupに分けたらcss modulesの同期取れない懸念出てきた 19 CSS Modulesは、仕様は決まっているが実装は各々。 ビルドツールが異なると、SSR↔hydration間のclass名が不一致の懸念あり†1。 そこで、viteビルドのhash値をtsup側でSSR結果に埋め込むようにした。 †1. hydration後の結果を強制的に正にする方法は、出来ない場合があるのでやらない vite tsup

しんどかったこと4. デプロイ方法を良く考えないと修正リリース時に障害が起きる 20 ウィジェットのhydrationエントリファイルは choice-widget.js のみ。 これは事前にCMSに登録するもので、バージョニングするには工夫が必要。 バージョニングしない状態で、Amebaプラットフォームに沿って ● クライアント用assetを先にS3に保存 ● ローリングアップデートによるサーバデプロイ を行うと、修正リリース時のみhydrationエラーの可能性が出てくる。

しんどかったこと4. デプロイ方法を良く考えないと修正リリース時に障害が起きる 21 この問題に対しては ● デプロイ戦略の変更は変更コスト・金銭コストを鑑みて一旦やらない ● バージョニングはメンテナンス性を鑑みて一旦やらない ことにし、代わりに ● 後方互換性を持たせた段階リリース ● リリースに関するドキュメントの整備 で暫定対応。

しんどかったこと5. App RouterではCache-Controlを使ったCDN制御が難しい 22 キャッシュの責務はCDNに一任し、アプリケーションのキャッシュは切りたい。 force-dynamic等を指定すると、 ● アプリケーションのキャッシュはOFFになる ● が、Cache-ControlがApp Router側で制御される（private等が付与される） www.ameba.jpのFastlyはAmebaチョイス以外も管理しており、 Cache-Controlを見てキャッシュ判定をしているので、そこは汚したくない。 ※ Cache-Control的にはキャッシュしないのにCDN側でキャッシュさせるのはそもそも不自然

しんどかったこと5. App RouterではCache-Controlを使ったCDN制御が難しい 23 そこでApp Router用にカスタムCache-Controlヘッダを作成。 Fastly側でCache-Controlを上書き。 Fastly(vcl)

成果と振り返り 24

成果 25 ● Owlのシステムを使った（Owl以外での）開発実績を作った ● Amebaのプラットフォーム上で開発出来た ● Amebaで標準化されている構成のため、新規参入コストを低く出来た ● ロックインを極力避け、制御や移管が容易な状態に出来た

振り返り 26 ● ビルドが複雑化したので、ウィジェットサーバを分離しておいて助かった ● ビルド・hydration・キャッシュの深い部分を学べた💪 ● App Router導入のメリットを検証出来ていないのが心残り😢 ● リリース障害等、テストで未然に障害を防げる仕組みがあると良い

締め 27

28 とても勉強になる開発でした。 本日はご清聴ありがとうございました！