【D2-8】WordPressのヘッドレス運用化 〜minimo roomのJamstack構成移行プロジェクト〜 | #MTDC2024 | MIXI TECH DESIGN CONFERENCE 2024

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
MIXI TECH DESIGN CONFERENCE 2024 - SESSION ARCHIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3/19(火) 17:20 〜 17:40｜D2-8

WordPressのヘッドレス運用化 〜minimo roomのJamstack構成移行プロジェクト〜

minimoの公式Webメディア「minimo room」ではWordPressを使用しています。
これをどのようにヘッドレスで運用できるようにしたかをフロントエンドとインフラの2つの側面からお話しします。

Vantageスタジオ minimo事業部 開発グループ バックエンド開発チーム
鈴木 雅也 / Masaya Suzuki

Vantageスタジオ minimo事業部 開発グループ Webフロントエンド開発チーム
樋口 鉄朗 / Tetsuro Higuchi

────────────────────────────
□セッション情報
https://techcon.mixi.co.jp/2024/d2-8.html
□イベントハッシュタグ
#MTDC2024
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◇◆◇ Information ◇◆◇
X（旧Twitter）
https://twitter.com/mixi_engineers
MIXI Developers Blog (medium)
https://mixi-developers.mixi.co.jp/
Slide (SpeakerDeck)
https://speakerdeck.com/mixi_engineers/
MIXI Design note
https://note.com/mixi_design/
採用情報
https://mixigroup-recruit.mixi.co.jp/
connpass
https://mixi.connpass.com/
HP
https://mixi.co.jp/

Transcript

1. ©MIXI WordPressのヘッドレス運用化 鈴木 雅也 (Masaya Suzuki) Vantageスタジオminimo事業部 開発グループバックエンド開発チーム 樋口 鉄朗 (Tetsuro Higuchi) Vantageスタジオminimo事業部 開発グループWebフロントエンド開発チーム 〜 minimo roomのJamstack構成移行プロジェクト 〜
2. ©MIXI 自己紹介 2
3. ©MIXI • 鈴木 雅也 (Masaya Suzuki) • 経歴 ◦ 2019年: 株式会社ミクシィ (現・株式会社MIXI) 新卒入社 ◦ 2019〜2021年5月: モンスターストライク等のデータ分析やデータ基盤の構築・運用を担当 ◦ 2021年6月〜: minimoでサーバーサイドの開発を中心にインフラの構築・運用も担当 • 著書 ◦ 数式をプログラムするってつまりこういうこと https://www.socym.co.jp/book/1206 ◦ データサイエンス100本ノック構造化データ加工編ガイドブック https://www.socym.co.jp/book/1356 自己紹介 3
4. ©MIXI • 樋口 鉄朗 (Tetsuro Higuchi) • 経歴 ◦ 2019年 前職へ新卒入社 ▪ デジタルコンテンツの販売プラットフォームの事業部でフロントエンドエンジニア ▪ 途中から新規事業部へ、3ヶ月毎にプロジェクトが立ち消えするのを3度経験して転職 ◦ 2021年株式会社ミクシィ (現・株式会社MIXI) へJOIN ▪ minimo 3年目突入 フロントエンド開発グループにてフロントエンドエンジニア • 趣味 ◦ バイク、ロードバイク、一人旅、アニメ鑑賞、VRSNS、他 自己紹介 4
5. ©MIXI minimoやminimo roomについて 5
6. ©MIXI • 2024年1月で10周年を迎えたサービス • 美容師やネイリスト、アイデザイナー等を予約・検索できる アプリ • サロンスタッフと直接やり取りができる minimoについて https://minimodel.jp/about 6
7. ©MIXI • minimoの公式Webメディア • 2022年5月リリース • 現役美容師や元ネイリスト、美容系インフルエンサーなど の経験を持つ個性豊かなメンバーが執筆 • トレンドの髪型からネイル紹介まで様々な最新の美容トレ ンドや美容知識についての記事を掲載 minimo roomについて https://minimodel.jp/room/ 7
8. ©MIXI Jamstack移行の経緯 8
9. ©MIXI • minimo roomはWordPressで構築されている • 2021年よりフロントエンド開発チームが創設 • 見た目の機能開発が多いminimo roomではフロントエンド開発チームだけで開発したい • 開発チーム内で管理できる技術スタック内でなるべく運用したい • 既に数百記事が公開されている事から、SaaS等への移行はコストとリスクが高い • 外部からもライターさんを雇っている以上、エディタの変更は避けたい ◦ WordPressでの執筆に慣れているライターさんが多い ◦ WordPress以外のエディタにすると、ライターさん募集時にそれが障害となる可能性がある → WordPressは残しておきたい・・・！ → 手法を検討 フロントエンドを分離 9
10. ©MIXI Jamstack 10 リクエスト HTML等返却 データ取得 クライアント データベース Jamstack ストレージ (AWS S3等) 事前にビルド・デプロイ
11. ©MIXI バックエンド フロントエンド ヘッドレス化、フロントエンド分離後 11 リクエスト HTML等返却 データ取得 ブラウザ データベース フロントエンド-バックエンド間は APIでデータをやり取り 定期的にビルドされるので、記事は最新 Next.jsが事前にHTMLをビルドしておくので レスポンスが早くなる APIでデータのみを提供する CMSを ヘッドレスCMSと呼ぶ
12. ©MIXI • メリット ◦ 技術領域の分担が比較的簡単に ◦ 見た目に関わる領域をWordPressから切り離せる ◦ 編集画面などの管理機能をWordPressに残せる ◦ 速度向上 • デメリット ◦ 管理するサーバー(Next.js)が増える ▪ S3等へ静的デプロイを行うのであればその限りではない ◦ 障害箇所の切り分け複雑度が増加 → WordPressをヘッドレスCMSとして運用し、Next.jsをフロントエンドとして利用する、フロントエンドを分離す る = Jamstack化 することに Jamstack化、ヘッドレス化、フロントエンド分離 12
13. ©MIXI • 技術的課題とその解決策 ◦ WordPress REST APIとの戦い ◦ 強いCSSとの戦い ◦ Next.jsのキャッシュ機構との戦い • フロントエンド分離のためのインフラ ◦ 概要 ◦ フロントエンド分離未対応ページへのルーティング ◦ まとめ 目次 13
14. ©MIXI 技術的課題とその解決策 14
15. ©MIXI • Next.js • TypeScript • GraphQL • urql • Linaria • Vitest • Storybook • ESLint • Prettier など。 15 フロントエンドで最終的に導入されたライブラリ・フレームワーク等
16. ©MIXI WordPress REST APIとの戦い 16
17. ©MIXI • WordPressからはREST APIでデータが取れる • ドキュメントがOpenAPI Specificationに則っていない ◦ クライアントの自動生成が出来ない ◦ WordPressのAPI Reference自体の検索性や使い勝手に難がある ◦ 一応、wp-typesというTypeScript向けの型ライブラリはある • WordPress REST APIの設計上、関連するデータ毎に単件取得APIを叩く必要がある ◦ APIから返却される記事データに付随するタグやカテゴリーはIDしか含まれない ◦ この仕様により、記事を表示するページを表示する為には下記APIを全部叩く必要がある ▪ 記事単件取得API ▪ タグ単件取得API ×記事に紐づくタグの件数分 ▪ カテゴリ単件取得API ×記事に紐づくカテゴリの件数分 ▪ 著者単件取得API ▪ 画像単件取得API ◦ 記事一覧取得APIも同様の設計 • WordPress REST APIと問題点 17
18. ©MIXI WordPress REST APIでデータを取得する場合のイメージ 18 1件の記事に付き4種×個数分・・・ 10件記事の情報取ろうと思ったら、最低でも約 50回もAPI叩く必要あるの！？？ 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称 記事 • タイトル • 投稿日時 • 抜粋文章 • 著者 • カテゴリ • タグ • アイキャッチ画像 著者 • 名前 • アバター画像 タグ • 名称 カテゴリ • 名称 添付画像 • 画像URL • ALT 添付画像 • 画像URL • ALT カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称
19. ©MIXI そこでGraphQL 19 • Facebook(現Meta)が中心に 開発を進めているAPI向けクエ リ言語 • 必要なデータをクエリ化して1 回で問い合わせ • 型システムがある query PostList($limit: 10) { posts(where: { last: $limit }) { nodes { title date description author { name attachedImage { src } } tags { nodes { name } categories { nodes { name } attachedImage { src } } } } 先程の図であれば、こんな感じのクエリになる これ1個で10件の記事と それに付随する情報全部取れる
20. ©MIXI そこでGraphQL 20 • WordPressは標準ではGraphQLに対応していない • WordPress REST APIと同じ内容をGraphQLで取得できるようにする OSSのWordPressプラグインに、「WPGraphQL」がある • https://github.com/wp-graphql/wp-graphql • スター数は約3600 • 主要なプラグインを組み合わせて使えるよう対応したWPGraphQL用プラ グインも多数存在 • WordPress管理画面上からGraphQL IDEが使える • 認証有無の設定なども詳しく設定できる • 若干の不具合はあった ◦ マルチバイト文字のファイル名を使ったテーマファイルがあると GraphQLスキーマが壊れる不具合 ▪ PR送って直した ◦ 記事本文のHTMLはGraphQLでデータ取ろうとするとエラーが発生 ▪ 記事本文の取得はWordPress REST APIを使うことに
21. ©MIXI GraphQLのFragmentを活用 21 • Fragmentの活用 ◦ コンポーネントのPropsのような利用箇所に対応するFragmentを定義 ▪ FragmentをQuery上で組み合わせれば、必要最低限の情報だけをリクエストできる ▪ Fragmentを書き換えれば自動的にQueryも書き換え ▪ Fragment Maskingで不要な情報が他のコンポーネントに漏洩しないようにできる query Hoge { posts { nodes { id title date excerpt } } } fragment FugaA on Post { id title excerpt } query Hoge { posts { nodes { id …FugaA …FugaB } } } fragment FugaB on Post { id title date }
22. ©MIXI コンポーネントで使いたいデータが増えても、fragment書き換えだけでOK 22 const { data } = await client.query(HogeDocument, {}); const posts = data.posts.node ?? []; const fugaA = getFragmentData(FugaAFragmentDoc, posts); console.log(posts); // [{ id: “xxx” }] console.log(fugaA); // [{ id: “xxx”, title “piyo”, excerpt: “hogefugapiyo”, status: “PUBLISH” }] fragment FugaA on Post { id title excerpt status } query Hoge { posts { nodes { id …FugaA } } }
23. ©MIXI Fragment Maskingを使った場合、関数を使ってfragmentを取得する必要がある 23 const { data } = await client.query(HogeDocument, {}); const posts = data.posts.node ?? []; const fugaA = getFragmentData(FugaAFragmentDoc, posts); console.log(posts); // [{ id: “xxx” }] console.log(fugaA); // [{ id: “xxx”, title “piyo”, excerpt: “hogefugapiyo” }] fragment FugaA on Post { id title excerpt } query Hoge { posts { nodes { id …FugaA } } }
24. ©MIXI Fragment Collocationの採用 24 fragment FugaA on Post { id title excerpt } query Hoge { posts { nodes { id …FugaA …FugaB } } } fragment FugaB on Post { id title date } • app ◦ post ▪ page.tsx ▪ query.gql • components ◦ FugaA ▪ index.tsx ▪ fragment.gql ◦ FugaB ▪ index.tsx ▪ fragment.gql fragmentファイルの位置を、 使用するファイルと同じ階層に設置 (=Collocate)
25. ©MIXI まとめ 25 • GraphQLはエンティティが複雑に絡み合うヘッドレスCMSにおいては非常に便利 • Fragment Collocationを活用することでコンポーネント分割時の運用開発も便利に
26. ©MIXI 強いCSSとの戦い 26
27. ©MIXI • WordPressから返却される記事本文は、執筆したHTMLがそのままURIエンコードされたもの • 記事ページだけはWordPressテーマのCSSを使用する必要がある ◦ これはCSS設計やクラス命名などを負債として引き継ぐ必要があることを意味する • 採用しているWordPressテーマのCSS設計が非常に悪い ◦ SMACSSやFLOCSSと言ったCSS命名規則は採用されていない ◦ HTMLタグが直接セレクタとして指定されている ◦ :not擬似クラスの極多用 ◦ !importantの極多用 ◦ 合計1万行を超える手実装+PHPによる文字列結合生成のCSS達 採用したWordPressテーマによる負債の影響 27
28. ©MIXI 採用したWordPressテーマのCSS例 28 .post h3.has-regular-font-size, .post h3:not([class^='is-style-heading-custom-']):not([class*='is-style-heading-custom-']):not(.css-no2):not(.rankh3):not(.post-card-title):not(#reply-title), .h3modoki, .step-title { font-size: 19px; line-height: 27px; } 「.post h3」なセレクタに対してnotセレクタが6個くっついてる .has-cyan-bluish-gray-color { color: var(--wp--preset--color--cyan-bluish-gray) !important; } .has-white-color { color: var(--wp--preset--color--white) !important; } .timeline > li .cardbox.kanren { background-color: transparent; margin-bottom: 10px; margin-top: 0 !important; } .custom-search-box-tpl-default .cs-text-input { padding-left: 25px !important; padding-right: 25px !important; padding-top: 10px !important; padding-bottom: 10px !important; } どこでもかんでもみんな〜!importantが付いているよ〜
29. ©MIXI • 先述の通り、WordPressから直接CSSを取り寄せて全体にインポートするとあらゆる全てのページが汚 染される • あまりに強すぎるセレクタで、CSS in JSによるスコープドCSSも上書きされる • コンポーネントに区切っても、Next.jsのRouter Cache機能のせいで他のページにもCSSが漏洩 • これはglobal stylingを使っても、@importなどを使ってもそうなる • 1つ1つ潰していたらキリがない • Shadow DOMやiframe等を使うとSEO上よろしくない • せめてページ遷移する時にリロードし直してくれたら・・・・！ スコープドCSSがWordPressにやられてしまう問題 29
30. ©MIXI • 先述の通り、WordPressから直接CSSを取り寄せて全体にインポートするとあらゆる全てのページが汚 染される • あまりに強すぎるセレクタで、CSS in JSによるスコープドCSSも上書きされる • コンポーネントに区切っても、Next.jsのRouter Cache機能のせいで他のページにもCSSが漏洩 • これはglobal stylingを使っても、@importなどを使ってもそうなる • 1つ1つ潰していたらキリがない • Shadow DOMやiframe等を使うとSEO上よろしくない • せめてページ遷移する時にリロードし直してくれたら・・・・！ スコープドCSSがWordPressにやられてしまう問題 30
31. ©MIXI • グループレイアウトを分けると、レイアウトを跨いだ場合ページ全体が再読み込みされる ◦ > Navigating across multiple root layouts will cause a full page load (as opposed to a client-side navigation). ◦ > (google翻訳)複数のルート レイアウト間を移動すると、(クライアント側のナビゲーションとは対照的 に) ページ全体が読み込まれます。 ◦ https://nextjs.org/docs/app/building-your-application/routing/route-groups • 本来は、ヘッダーやフッターが切り替わるなど、レイアウトがガッツリ変わるようなページを跨いだ場合に 便利な機能 • この機能を活用 グループレイアウトを分ける 31
32. ©MIXI • 記事を描画するページでのみWordPressテーマのCSSが読み込まれるように • 記事ページ内のCSSによるレイアウト崩れには、対WordPressテーマ用リセットCSSを何行か追加するこ とである程度駆逐に成功 • 残念ながら完全な形にするにはやはりCSSを丸ごと作り直すしかない・・・ 結果・まとめ 32 トップページ 記事ページ リンクホバーのアンダースコアが 残ってしまっている
33. ©MIXI Next.jsのキャッシュ機構との戦い 33
34. ©MIXI • 2022年10月25日リリースのNext.js 13.0より、Betaリリース ◦ https://nextjs.org/blog/next-13#new-app-directory-beta • 2023年05月04日リリースのNext.js 13.4より、Stable ◦ https://nextjs.org/blog/next-13-4#nextjs-app-router • 主な新機能 ◦ React Server Componentへの対応 ▪ サーバーサイドでコンポーネントを構築する事でクライアントでのjs実行量を最小限に抑える ◦ Layoutコンポーネント ▪ 従来の「_document.tsx」や「_app.tsx」でやっていたような機能を分離 ▪ ルート単位で共通化したコンポーネントを設置したり、metaタグの設定などを共有できる ◦ fetch ▪ Next.jsが拡張したfetchAPIが登場 ▪ fetchした内容のキャッシュをすることで、余分な重複リクエストを削減する ◦ OGP画像の動的ビルドサポート ◦ 他多数 Next.js App Router 34 開発開始後、間もなく Stableになったので、 知見蓄積の為に積極的に採用
35. ©MIXI Next.jsのビルド方式 35 • Pages Routerでは ◦ 「getStaticProps」か「getServerSideProps」でSSGとSSRが区別されてた • Apps Routerでは ◦ 場合に応じてNext.jsがよしなにしてくれる ◦ SSG → Static Rendering(以後、SRと記載) ◦ SSR → Dynamic Rendering(以後、DRと記載)
36. ©MIXI • 基本SRになる想定で実装しているのに・・・・ • レスポンスがWordPress時代より遅い • サーバー増強してもまだ遅い • 終いにはHTTP 504 Gateway Timeout • どうやら途中に挟んでいるCDNにはキャッシュされていないようだ・・・ 36 リリース直後から問題が発生
37. ©MIXI CDNとの組み合わせにおいてはCache-Controlヘッダーが重要になる 37 • CDNとしてAWS CloudFrontを採用 ◦ CloudFrontはキャッシュ時間はCache-ControlヘッダーやExpiresヘッダーを見て決める ◦ 無ければデフォルト設定値を適用 • Next.jsの出力したCache-Controlは「private, no-cache, no-store, max-age=0, must-revalidate」 ◦ これはCDNにもクライアントにも絶対にキャッシュさせない設定
38. ©MIXI 実はCache-ControlヘッダーもNext.jsが操っている 38 > You cannot set Cache-Control headers in next.config.js for pages or assets, as these headers will be overwritten in production to ensure that responses and static assets are cached effectively. > (Google翻訳)next.config.js でページまたはアセットの Cache-Control ヘッダーを設定することはでき ません。これらのヘッダーは、応答と静的アセットが効果的にキャッシュされるように本番環境で上書きさ れるためです。 え、説明これだけ？ https://nextjs.org/docs/app/api-reference/next-config-js/headers#cache-control
39. ©MIXI 少なくとも下記パターンがある 1. private, no-cache, no-store, max-age=0, must-revalidate 2. s-maxage=[n], stale-while-revalidate ※nは任意の整数 3. no-store, must-revalidate 4. public, max-age=31536000, immutable • どのパターンになるかは種々の設定やオプションの相互作用により最終的にNext.jsが決定する • dev mode中は必ず「1」のパターンで配信されるので、next serveするまでどのcache-controlになるか分 からない • Etagは吐くので、CDNを挟まなければ4以外のパターンなら検証してNextがビルドした最新のデータが表 示 39 Next.jsのCache-controlヘッダーの挙動
40. ©MIXI 少なくとも下記パターンがある 1. private, no-cache, no-store, max-age=0, must-revalidate 2. s-maxage=[n], stale-while-revalidate ※nは任意の整数 3. no-store, must-revalidate 4. public, max-age=31536000, immutable • 原因 ◦ 記事一覧系のページにて、クエリパラメータを使用してページングをしていた ◦ クエリパラメータを使うと、自動でDRに切り替わる ◦ DRに切り替わると、Cache-Controlヘッダーのパターンは「1」が出力される 一覧ページを見る度にビルドが走るし、CDNにキャッシュされないので、非常に重くなっていた 40 今回の不具合の原因
41. ©MIXI 具体例 41 export const revalidate = 1000; export const HogePage = ({ searchParams }) => { return <p>{searchParams.q}の検索結果<p> } export default HogePage; この仕様はカーソルベースのページングを行うリストページやクエリパラメータで検索ワードを指定するよう な検索ページでは一切キャッシュできない事を意味する 例： /commits/main/?after=hogefuga 例： /search?q=hoge
42. ©MIXI • 下記パターンは原則出来ない ◦ Next.jsは全部DRにして、CDNではキャッシュさせる ◦ クエリパラメータ使用ページを強制的にキャッシュ対象にする ◦ Next.jsのキャッシュ時間は10分にして、CDNは12時間にしてno-cacheで常に再検証 • ただし、どうしてもという場合は、middlewareで書き換えできる ◦ ただしキャッシュヘッダーとNext.js側の挙動の乖離による副作用でアクセス不能になる可能性も高く なるのでおすすめはしない • そのヘッダーがなぜ出力されているかを調べて、根本対処するべき 42 CDN挟む時どうしたらいいの？ export const middleware = (request: NextRequest) => { const response = NextResponse.next({ request: { headers: new Headers(request.headers), }, }); response.headers.set(CACHE_CONTROL_HEADER, ”no-cache, s-max-age=3600”); return response; };
43. ©MIXI • Next.jsのキャッシュ機構は非常に複雑。よくドキュメントを読もう • Next.jsのレールに乗っかろう。CDNとNext.jsのキャッシュ関係は、一蓮托生と捉えよ • Next.jsが出力したCache-Controlヘッダーが意図したものか、Pageリリース前に検査する • 意図していないのであれば、出力された理由を調べて根本対処しよう ◦ キャッシュでここまで疲弊するならシンプルな Remixで良かったなぁ・・・ ◦ RemixはSSRなので、それをCDNでキャッシュさせる方がシンプルで良かったかも・・・ まとめ 43
44. ©MIXI • ヘッドレスCMSでWPGraphQLは大変捗るので良い • GraphQL使うならぜひFragment Collocationの恩恵を受けよ • WordPressの有料テーマは完成度が玉石混交でリスクが高いので、カスタムテーマを使うか、完成度が ハンドリングできる方法(外部委託、OSS、etc…)の物を使おう • グループレイアウトを使うとSPA(Single Page Application)のメリットかつデメリットでもあるリロードが走ら ない問題に対処できる • Next.jsのキャッシュ機構は非常に複雑。よくドキュメントを読もう • Next.jsはヘッダーも勝手によしなに操作するので、意図した挙動か確認しよう 総まとめ 44
45. ©MIXI フロントエンド分離のためのインフラ 45
46. ©MIXI • 概要 • フロントエンド分離未対応ページへのルーティング • まとめ フロントエンド分離のためのインフラ: 目次 46
47. ©MIXI 概要 47
48. ©MIXI 概要 • AWS上で構築されており、AWS CDKでコード管理されている • Next.jsやWordPressはECS (Elastic Container Service) を使って動かしている • 各ECSタスク内にはサーバー (Next.jsやWordPress) とnginxのコンテナが存在する 48
49. ©MIXI 概要 • ECS Serviceの前段にCloudFrontとそちらへリクエストを飛ばすためのproxy ECS Serviceが あり、ページをキャッシュしている 49
50. ©MIXI 概要 • 管理画面用のWordPress ECS Serviceもあり、こちらはフロントエンド分離せずに運用している • 管理画面用のWordPressは複数立ち上げると管理画面にログインできなくなるため、 1台固定で運用 50
51. ©MIXI 概要 • リクエストはALBを使って以下のようにルーティングしている ◦ ページ: Next.js ECS Service ◦ GraphQL API: WordPress ECS Service 51
52. ©MIXI 概要 • Next.js ECS Serviceへのルーティングの際はLORアルゴリズムを用いることで、各ECSタスクに負荷が 均等に分散されるようにしている • LOR (Least Outstanding Requests) アルゴリズム: 未処理のリクエスト数が最も少ないターゲット (ここではECSタスク) にリクエストを送信するアルゴリズム 52
53. ©MIXI フロントエンド分離未対応ページへのルーティング 53
54. ©MIXI フロントエンド分離未対応ページへのルーティング • フロントエンド分離未対応のページは、Next.js ECS Service内にあるnginxから ECSのサービスディスカバリーを使ってWordPress ECS Serviceに飛ばし、 従来通りWordPress ECS Serviceでレンダリングしている • これにより、フロントエンド分離対応・未対応ページが混在した状態での運用を可能にしている 54
55. ©MIXI フロントエンド分離未対応ページへのルーティング • WordPress ECS Serviceをローリングアップデートした際に、WordPressコンテナが立ち上げ 途中にも関わらず、ECSタスクがサービスディスカバリーに登録されてしまう問題があった • これを防ぐため、WordPressのECSタスク内にあるnginxコンテナからWordPressコンテナへの 疎通を確認するコンテナヘルスチェックを設定している 55
56. ©MIXI フロントエンド分離未対応ページへのルーティング • また、サービスディスカバリーを使用するにあたり、ECSタスクに手を加えている (次スライド以降で説明) 56
57. ©MIXI フロントエンド分離未対応ページへのルーティング 57 • 以下の図は構成図からNext.jsとWordPressのECS Serviceのみを切り出した図である
58. ©MIXI フロントエンド分離未対応ページへのルーティング 58 • サービスディスカバリーを使ったNext.js ECS ServiceからWordPress ECS Serviceへの アクセスは以下の手順で行われる 1. Route53でWordPressのECSタスクの名前解決を行う 2. Route53から取得したIPアドレスにリクエストを投げる
59. ©MIXI フロントエンド分離未対応ページへのルーティング 59 • Route53から取得したIPアドレスはNext.jsのECSタスク内にあるnginxにキャッシュされる • キャッシュ期間はRoute53内のレコードのTTLに依存する
60. ©MIXI フロントエンド分離未対応ページへのルーティング 60 • WordPress ECS Service内でECSタスクのローリングアップデートが発生すると、 Route53に新ECSタスクのIPアドレスのレコードが登録される • Route53で名前解決を行った場合は新ECSタスクにリクエストを投げる
61. ©MIXI フロントエンド分離未対応ページへのルーティング 61 • しかし、Next.jsのECSタスク内にあるnginxにキャッシュが残っている場合、 旧ECSタスクにリクエストを投げてしまう
62. ©MIXI フロントエンド分離未対応ページへのルーティング 62 • この状態を避けるため、WordPressのECSタスク終了前にRoute53のレコードのTTLと 同じ秒数のsleepを入れ、Next.jsのECSタスク内にあるnginxにキャッシュが残っている間は 旧ECSタスクへアクセスできるようにした
63. ©MIXI • Next.jsやWordPressはECSを使って動かしている • ALBを使ってページのリクエストはNext.js ECS Service、GraphQL APIのリクエストはWordPress ECS Serviceに投げている • Next.js ECS Serviceへのルーティング時はLORアルゴリズムを使って各ECSタスクの負荷を 均等に分散している • フロントエンド分離未対応のページは、Next.js ECS ServiceからECSのサービスディスカバリーを使って WordPress ECS Serviceに飛ばし、従来通りWordPressでレンダリングしている • サービスディスカバリーを使うにあたり、WordPress ECS Serviceにおいて、 コンテナヘルスチェックを入れたり、ECSタスクの終了を遅らせたりしている フロントエンド分離のためのインフラ: まとめ 63 この後、ASK THE SPEAKERにて質問を受け付けますので、是非お越しください！
64. ©MIXI