Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【D2-8】WordPressのヘッドレス運用化 〜minimo roomのJamstack構...

【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/

MIXI ENGINEERS

March 19, 2024
Tweet

Video

More Decks by MIXI ENGINEERS

Other Decks in Technology

Transcript

  1. ©MIXI WordPressのヘッドレス運用化 鈴木 雅也 (Masaya Suzuki) Vantageスタジオminimo事業部 開発グループバックエンド開発チーム 樋口 鉄朗

    (Tetsuro Higuchi) Vantageスタジオminimo事業部 開発グループWebフロントエンド開発チーム 〜 minimo roomのJamstack構成移行プロジェクト 〜
  2. ©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
  3. ©MIXI • 樋口 鉄朗 (Tetsuro Higuchi) • 経歴 ◦ 2019年

    前職へ新卒入社 ▪ デジタルコンテンツの販売プラットフォームの事業部でフロントエンドエンジニア ▪ 途中から新規事業部へ、3ヶ月毎にプロジェクトが立ち消えするのを3度経験して転職 ◦ 2021年株式会社ミクシィ (現・株式会社MIXI) へJOIN ▪ minimo 3年目突入 フロントエンド開発グループにてフロントエンドエンジニア • 趣味 ◦ バイク、ロードバイク、一人旅、アニメ鑑賞、VRSNS、他 自己紹介 4
  4. ©MIXI • minimo roomはWordPressで構築されている • 2021年よりフロントエンド開発チームが創設 • 見た目の機能開発が多いminimo roomではフロントエンド開発チームだけで開発したい •

    開発チーム内で管理できる技術スタック内でなるべく運用したい • 既に数百記事が公開されている事から、SaaS等への移行はコストとリスクが高い • 外部からもライターさんを雇っている以上、エディタの変更は避けたい ◦ WordPressでの執筆に慣れているライターさんが多い ◦ WordPress以外のエディタにすると、ライターさん募集時にそれが障害となる可能性がある → WordPressは残しておきたい・・・! → 手法を検討 フロントエンドを分離 9
  5. ©MIXI バックエンド フロントエンド ヘッドレス化、フロントエンド分離後 11 リクエスト HTML等返却 データ取得 ブラウザ データベース

    フロントエンド-バックエンド間は APIでデータをやり取り 定期的にビルドされるので、記事は最新 Next.jsが事前にHTMLをビルドしておくので レスポンスが早くなる APIでデータのみを提供する CMSを ヘッドレスCMSと呼ぶ
  6. ©MIXI • メリット ◦ 技術領域の分担が比較的簡単に ◦ 見た目に関わる領域をWordPressから切り離せる ◦ 編集画面などの管理機能をWordPressに残せる ◦

    速度向上 • デメリット ◦ 管理するサーバー(Next.js)が増える ▪ S3等へ静的デプロイを行うのであればその限りではない ◦ 障害箇所の切り分け複雑度が増加 → WordPressをヘッドレスCMSとして運用し、Next.jsをフロントエンドとして利用する、フロントエンドを分離す る = Jamstack化 することに Jamstack化、ヘッドレス化、フロントエンド分離 12
  7. ©MIXI • 技術的課題とその解決策 ◦ WordPress REST APIとの戦い ◦ 強いCSSとの戦い ◦

    Next.jsのキャッシュ機構との戦い • フロントエンド分離のためのインフラ ◦ 概要 ◦ フロントエンド分離未対応ページへのルーティング ◦ まとめ 目次 13
  8. ©MIXI • Next.js • TypeScript • GraphQL • urql •

    Linaria • Vitest • Storybook • ESLint • Prettier など。 15 フロントエンドで最終的に導入されたライブラリ・フレームワーク等
  9. ©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
  10. ©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 カテゴリ • 名称 カテゴリ • 名称 タグ • 名称 タグ • 名称
  11. ©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件の記事と それに付随する情報全部取れる
  12. ©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を使うことに
  13. ©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 }
  14. ©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 } } }
  15. ©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 } } }
  16. ©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)
  17. ©MIXI • WordPressから返却される記事本文は、執筆したHTMLがそのままURIエンコードされたもの • 記事ページだけはWordPressテーマのCSSを使用する必要がある ◦ これはCSS設計やクラス命名などを負債として引き継ぐ必要があることを意味する • 採用しているWordPressテーマのCSS設計が非常に悪い ◦

    SMACSSやFLOCSSと言ったCSS命名規則は採用されていない ◦ HTMLタグが直接セレクタとして指定されている ◦ :not擬似クラスの極多用 ◦ !importantの極多用 ◦ 合計1万行を超える手実装+PHPによる文字列結合生成のCSS達 採用したWordPressテーマによる負債の影響 27
  18. ©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が付いているよ〜
  19. ©MIXI • 先述の通り、WordPressから直接CSSを取り寄せて全体にインポートするとあらゆる全てのページが汚 染される • あまりに強すぎるセレクタで、CSS in JSによるスコープドCSSも上書きされる • コンポーネントに区切っても、Next.jsのRouter

    Cache機能のせいで他のページにもCSSが漏洩 • これはglobal stylingを使っても、@importなどを使ってもそうなる • 1つ1つ潰していたらキリがない • Shadow DOMやiframe等を使うとSEO上よろしくない • せめてページ遷移する時にリロードし直してくれたら・・・・! スコープドCSSがWordPressにやられてしまう問題 29
  20. ©MIXI • 先述の通り、WordPressから直接CSSを取り寄せて全体にインポートするとあらゆる全てのページが汚 染される • あまりに強すぎるセレクタで、CSS in JSによるスコープドCSSも上書きされる • コンポーネントに区切っても、Next.jsのRouter

    Cache機能のせいで他のページにもCSSが漏洩 • これはglobal stylingを使っても、@importなどを使ってもそうなる • 1つ1つ潰していたらキリがない • Shadow DOMやiframe等を使うとSEO上よろしくない • せめてページ遷移する時にリロードし直してくれたら・・・・! スコープドCSSがWordPressにやられてしまう問題 30
  21. ©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
  22. ©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になったので、 知見蓄積の為に積極的に採用
  23. ©MIXI Next.jsのビルド方式 35 • Pages Routerでは ◦ 「getStaticProps」か「getServerSideProps」でSSGとSSRが区別されてた • Apps

    Routerでは ◦ 場合に応じてNext.jsがよしなにしてくれる ◦ SSG → Static Rendering(以後、SRと記載) ◦ SSR → Dynamic Rendering(以後、DRと記載)
  24. ©MIXI • 基本SRになる想定で実装しているのに・・・・ • レスポンスがWordPress時代より遅い • サーバー増強してもまだ遅い • 終いにはHTTP 504

    Gateway Timeout • どうやら途中に挟んでいるCDNにはキャッシュされていないようだ・・・ 36 リリース直後から問題が発生
  25. ©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にもクライアントにも絶対にキャッシュさせない設定
  26. ©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
  27. ©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ヘッダーの挙動
  28. ©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 今回の不具合の原因
  29. ©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
  30. ©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; };
  31. ©MIXI • ヘッドレスCMSでWPGraphQLは大変捗るので良い • GraphQL使うならぜひFragment Collocationの恩恵を受けよ • WordPressの有料テーマは完成度が玉石混交でリスクが高いので、カスタムテーマを使うか、完成度が ハンドリングできる方法(外部委託、OSS、etc…)の物を使おう •

    グループレイアウトを使うとSPA(Single Page Application)のメリットかつデメリットでもあるリロードが走ら ない問題に対処できる • Next.jsのキャッシュ機構は非常に複雑。よくドキュメントを読もう • Next.jsはヘッダーも勝手によしなに操作するので、意図した挙動か確認しよう 総まとめ 44
  32. ©MIXI 概要 • AWS上で構築されており、AWS CDKでコード管理されている • Next.jsやWordPressはECS (Elastic Container Service)

    を使って動かしている • 各ECSタスク内にはサーバー (Next.jsやWordPress) とnginxのコンテナが存在する 48
  33. ©MIXI 概要 • Next.js ECS Serviceへのルーティングの際はLORアルゴリズムを用いることで、各ECSタスクに負荷が 均等に分散されるようにしている • LOR (Least

    Outstanding Requests) アルゴリズム: 未処理のリクエスト数が最も少ないターゲット (ここではECSタスク) にリクエストを送信するアルゴリズム 52
  34. ©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にて質問を受け付けますので、是非お越しください!