GO Tech Talk #31 タクシーアプリ『GO』におけるNext.jsの活用

by GO Inc. dev

Embed

Start on current slide

Slide 1

Slide 1 text

GO Tech Talk #31 タクシーアプリ『GO』における Next.jsの活用 2025/10/22 (Wed)

Slide 2

Slide 2 text

Slide 3

Slide 3 text

GOがNext.jsで作る Webプロダクトサービス紹介 2025/10/22 (Wed) Webプロダクト開発部 / Takaaki Ito GO株式会社

Slide 4

Slide 4 text

© GO Inc. 4 自己紹介 GO株式会社 Webプロダクト1グループ GM / 伊藤貴章 SI/受託開発企業に入社しチームリーダーや新人研修講師を経験後、金融サービス事業会社にて基盤刷新や新規サービス開発等に幅広く携わる 2022年9月にGOへバックエンドエンジニアとして入社 2024年6月にWebプロダクト開発部を立ち上げる趣味・GO 軽音部でSax吹いてます🎷 ・GOジョブキックボクシング部はじめました🥊

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© GO Inc. Confidential 8 GOブランドの集客力とドライバー専門キャリアアドバイザーによるマッチング力を活かし、タクシーに加えて物流・バスのドライバー人材紹介も拡大するなど、ドライバーに特化した人材採用プラットフォームを提供『GO』アプリだけでなく、主にtoC向けサービス開発でNext.jsを採用ドライバーに特化した人材採用プラットフォーム『 GOジョブ』開発において、 SEOとパフォーマンスを重視して Next.js採用しています 8 求人の検索・閲覧・応募メッセージプロフィールの登録自己PRをAI生成 https://gojob.go.goinc.jp

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© GO Inc. 従来のReactアプリケーションにはいろいろな課題が ● コードが冗長になる ○ ステートや副作用のコード、nullのハンドリング ● パフォーマンスの悪化 ○ クライアントバンドルサイズが増える ● XSSを受けた場合などに生じるセキュリティリスク ○ データフェッチ処理やトークンをJavaScriptから参照可能な領域に配置する必要がある 23 Next.js App Routerの採用とサーバーサイドを中心とした設計

Slide 24

Slide 24 text

© GO Inc. 基本的コンセプトサーバーファースト設計 - 処理の大部分はサーバーサイドでクライアントは最小限に具体的にはバックエンドサーバーからのデータ取得や更新、認可やアクセスコントロール等はすべてサーバーで行うクライアントは、どうしてもステートやライフサイクルに伴う処理が必要な場合のみ・必要な範囲に絞って使う 24 Next.js App Routerの採用とサーバーサイドを中心とした設計

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© GO Inc. このようにサーバーサイドに処理を寄せることで ● コードの可読性が上がる ○ 煩わしいステートとライフサイクルの管理がなくなる ● パフォーマンス向上 ○ クライアント側のバンドルサイズを下げることができる ● セキュリティリスクの低減 ○ データの取得や送信、認証情報をサーバーサイドに隠蔽できる ○ Middlewareによる認可・アクセスコントロールの一元管理ができる 31 Next.js App Routerの採用とサーバーサイドを中心とした設計

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© GO Inc. GOでは、全社共通で作り込まれた内製のk8s環境あり、インフラリソースを共通化しています。内製のk8s環境には、デプロイパイプラインから分析・監視の仕組みも入っているため、クラウドが分散するより、一元管理されている方が、トータルで工数が小さくなると判断し、 Next.jsも内製のk8s環境でセルフホストする選択をしています。ただし、Next.jsをセルフホストするには少しコツが必要になってくるので、やっていることをご紹介 44 セルフホストする上での注意点

Slide 45

Slide 45 text

© GO Inc. ● Next.jsのキャッシュやkvストアが使えない ○ キャッシュデータはデフォルトで.next配下に配置されるがコンテナ環境では書き込めない ■ EFSを使ってvolumeマウントしても良いが、競合等のリスクがあるため、Redisに保存しに行くように ○ kvストアも用意されていないので、キャッシュ用に用意したRedisにnamespaceを分けて保存 ● Version Skew（画面放置されたまま裏でリリースがかかったときに、Server Actionsでのエラー）が発生する ○ Vercelだと、Skew Protection（古いリクエストは古いサーバーに、新しいリクエストは新しいサーバーにポストする仕組み）があるが、セルフホストだとないので、破壊的変更がないように ● デプロイパイプラインやCDN等も自前で用意する必要がある 45 セルフホストする上での注意点

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

GOにおける Self Hosting Next.js Application 浜地亮輔

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© GO Inc. 51 Kenos（Kubernetes基盤） ▪ Kenosとは ▪ GOにおけるアプリケーションをホスティングしている Kubernetesを中心とした社内プラットフォーム ▪ 100人以上の開発者によって100以上のマイクロサービスが稼働している ▪ Kenosのしきたりを守る必要がある（自由度は若干低いかも） ▪ Kenosを利用するメリット ▪ 構築コストが低い（手順の確立化、自動生成 ▪ 非機能要件がほぼ満たされた状態でリリースできる ▪ 運用や調査が非常に楽（サービス間で構成差がほぼないため

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© GO Inc. 53 マネージドサービスを使わなかった理由 ▪ 過去のAWS Amplify運用時の知見 ▪ セキュリティ要件が合わない ▪ トラブルシューティングが難しい ▪ 技術スタックを標準化するための時間の欠如 ▪ VercelやAWS AmplifyなどマネージドSSRのサービスの検証・比較に多くの時間をかけられなかった ▪ Kenosなら大部分の非機能要件を満たした状態でリリース可能 => Kenos上にNext.jsアプリをSSRとして稼働させる

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

© GO Inc. 56 Kenosで実現できること：簡単な環境構築 1. 専用ボイラープレートからリポジトリを生成 2. インフラリソース準備（Amazon CloudFront、Amazon Elasticacheなど） 3. GitHubの特定ブランチにPushしてデプロイ以上！ ↑ ヘルスチェックAPIやデプロイワークフロー、　Kenosの設定周りを自動生成 ↑ BOTがTerraformコードやk8s yamlを自動生成するのでapplyするだけ ↑ ボイラープレート生成物だけでも最悪動く

Slide 57

Slide 57 text

Slide 58

Slide 58 text

© GO Inc. 58 Kenosで実現できること：オブザーバビリティ基盤 ▪ Grafanaをベースとした監視環境によって、サービス構築時に半自動で監視が設定される ▪ App Routerの1APIとしてメトリクス出力エンドポイントを実装 ▪ Prometheusを利用してNode.jsのメトリクスも取得 ▪ サービスメッシュによりサービス間通信の状況も可視化 ▪ （まだできていないけど、将来的にはTracingも実現予定 ↑気になる人はTechブログを Node.js関連のメトリクスもパネル化

Slide 59

Slide 59 text

© GO Inc. 59 まとめと感想 ▪ GOのKubernetes基盤「Kenos」上にNext.jsのアプリケーションをセルフホスティングする仕組みを整えた ▪ Amazon CloudFront等を利用することで効率的なリクエストキャッシュを実現 ▪ Kenosが提供する「ボイラープレートによる高速な環境構築」「動的環境」「オブザーバビリティ基盤」機能を実現 ▪ マネージドサービスで始める場合よりも当然大変だが、デメリットばかりではない ▪ （既に基盤がある場合は）マネージドサービスでは実現しづらい非機能要件部分の対応がほぼ不要になる ▪ マネージドサービスが隠蔽してくれるところを自前で実現する必要があるため、Next.jsを更に理解できる環境になる → Next.jsを更に一歩踏み込んで使ってみたい人にオススメ

Slide 60

Slide 60 text