2025年版 サーバーレス Web アプリケーションの作り方

主語がデカくてごめん
https://serverless.connpass.com/event/362044/ での発表内容です

Transcript

1. 2025年版 サーバーレス Web アプリケーションの作り⽅ ServerlessDays Tokyo 2025 株式会社サーバーワークス 渡辺隼⼈ 2025年9⽉20⽇
2. 渡辺 隼⼈ 株式会社サーバーワークス アプリケーションサービス本部 ディベロップメントサービス1課 趣味: ⾳楽を聴くこと、猫と遊ぶこと ⾃⼰紹介
3. 3 サーバーワークスについて サーバーワークスは、AWSの専業クラウドインテグレーター 「構築と移⾏、運⽤のプロフェッショナル」です 本社所在地 〒162-0824 東京都新宿区揚場町1-21 代表者 ⼤⽯ 良 設⽴ 2000年2⽉21⽇ 資本⾦ 3,255,903,491円 従業員数 524名(連結) ※2025年5⽉末⽇現在 事業内容 AWS専業のクラウドインテグレーター 営業所 ⼤阪・仙台・福岡 資格等 AWS Premier Tier Services Partner AWS Managed Service Provider Partner AWS Migration Services Competency Partner ISO /IEC 27001（JIS Q 27001） 主な株主 弊社役員、株式会社テラスカイ NTTドコモビジネス株式会社、 株式会社エヌ・ティ・ティ・データ 関連会社 株式会社G-gen（東京都新宿区） パーソル＆サーバーワークス株式会社（東京都千代⽥区） 富⼠フイルムクラウド株式会社（神奈川県横浜市） 株式会社サーバーワークス・キャピタル（東京都新宿区） 株式会社サーバーワークス・スマートオペレーションズ（新 潟県新潟市） 主な拠点 エンジニア 営業・バックオフィス 東京の他、⼤阪・仙台・福岡現在はリモートワークを 基本として⽇本全国からお客様をサポート
4. 1. お話しする内容 2. レンダリングとホスティング⼿法の選択肢 3. 実例紹介 4. まとめ ⽬次
5. お話しする内容
6. 6 お話しする内容 • 2025年のサーバーレス環境における Web アプリケーションのホス ティングとレンダリング⼿法を共有し、弊社の意思決定の観点を実例と ともに共有します • 私たちの組織は、AWS 上にお客様のワークロードをインフラストラク チャからアプリケーションまで⼀貫して構築しています。迅速な開発と デプロイを実現するためサーバーレスサービスを積極的に採⽤していま す
7. 7 お話しする内容 • 本発表内の Web アプリケーションとは、同⼀ドメインのフロントエン ドとバックエンド処理の集合体と定義します • AWS と JavaScript の宣⾔的 UI ライブラリの使⽤を前提に話します • 本発表では理解しやすさを優先し、レンダリング⼿法を⼀部のフレーム ワークとは異なる、または重複する形で分類しています
8. レンダリングとホスティング⼿法の 選択肢
9. 以下のレンダリング⼿法の分類でホスティング⼿法も併せてお話しします 1. SPA: Single Page Application 2. SSR: Server-Side Rendering 3. SSG: Static Site Generation 4. ISR: Incremental Static Regeneration ※ これ以降のスライド中の構成図は概要を掴んでいただくために単純化 してあります。 レンダリングとホスティング⼿法の選択肢
10. 10 1. SPA: Single Page Application Client AWS Cloud Amazon CloudFront Amazon S3 Amazon API Gateway AWS Lambda 要求 / 応答 Amazon DynamoDB レンダリング 動的データ取得
11. 11 1. SPA: Single Page Application の特徴 Client AWS Cloud Amazon CloudFront Amazon S3 Amazon API Gateway AWS Lambda 要求 / 応答 Amazon DynamoDB • ホスティングにコンピューティング不要 (SPA の成果物を置くだけ) • Web アプリケーションのレンダリングはブラウザで実施 • 初回アクセス時にレンダリングに必要なアセットをダウンロード • ページ遷移時のネットワーク通信が不要 • ただし、ページ上の動的なデータ取得のためはバックエンド API との 通信が必要 • 検索エンジン最適化や OGP 対応が難しい
12. 12 1. SPA: Single Page Application と組織 Client AWS Cloud Amazon CloudFront Amazon S3 Amazon API Gateway AWS Lambda 要求 / 応答 Amazon DynamoDB • SPA とバックエンド API で異なる技術選定が可能なためチームを分割 できる • 例) SPA: TypeScript, バックエンド API: Python • ⼀⽅で • バックエンド API の規約を OpenAPI 仕様などで担保する必要 がある • SPA とバックエンド API の互換性担保のために API のバージョ ニングまたは、デプロイサイクル調整等必要がある • 論理的には同⼀ドメインのコードが分散する
13. 13 2. SSR: Server-Side Rendering Client AWS Cloud AWS Lambda 要求 / 応答 Amazon DynamoDB Elastic Load Balancing Amazon ECS Amazon Aurora 常駐パターン イベント駆動パターン Amazon CloudFront レンダリング レンダリング 動的データ取得 動的データ取得
14. 14 2. SSR: Server-Side Rendering の特徴 Client AWS Cloud AWS Lambda 要求 / 応答 Amazon DynamoDB Elastic Load Balancing Amazon ECS Amazon Aurora 常駐パターン イベント駆動パターン Amazon CloudFront • ホスティングにコンピューティングが必要 • サーバーレスなアプローチだと以下の2つのパターンが考えられる • 常駐パターン (AWS Fargate) • イベント駆動パターン (AWS Lambda) • Web アプリケーションのレンダリングは基本的にサーバーで実施 • 動的なデータ取得もサーバーで実施
15. 15 2. SSR: Server-Side Rendering と組織 Client AWS Cloud AWS Lambda 要求 / 応答 Amazon DynamoDB Elastic Load Balancing Amazon ECS Amazon Aurora 常駐パターン イベント駆動パターン Amazon CloudFront • SPA のようにバックエンド API の実装分割が必須ではないため、同⼀ ドメインのコードの凝集度を⾼めることもできる • フルスタックフレームワークを⽤いることで実現可能 • 例) Next.js, React Router Framework mode • ⼀⽅で • チーム全体でスキルを統⼀する必要がある
16. 16 3. SSG: Static Site Generation Client AWS Cloud Amazon CloudFront Amazon S3 要求 / 応答
17. 17 3. SSG: Static Site Generation の特徴 Client AWS Cloud Amazon CloudFront Amazon S3 要求 / 応答 • ホスティングにコンピューティングは不要 (SSG の成果物を置くだけ) • Web アプリケーションはレンダリング済み • ビルド時に動的なデータ取得とレンダリングを実施 • 動的なデータに依存するページ更新には再ビルド・再デプロイが 必要 • ⽐較的静的な情報を扱うWeb アプリケーションに向いている
18. 18 4. ISR: Incremental Static Regeneration Client AWS Cloud 要求 / 応答 AWS Amplify
19. 19 4. ISR: Incremental Static Regeneration の特徴 Client AWS Cloud 要求 / 応答 AWS Amplify • SSG の扱いにくさである再ビルド機能をホスティングに組み込んだレ ンダリング⼿法 • Web アプリケーションはレンダリング済み • ビルド時に動的なデータ取得とレンダリングを実施 • 再ビルドをホスティング環境にて実施することでページを更新 • ホスティング環境の構築の難易度が⾼いため、以下の選択肢が現実的 • AWS Amplify • OpenNext AWS adapter (Next.js)
20. 実例紹介
21. 弊社の意思決定の観点から、各事例における良かった点と改善したい点を 共有させていただきます 1. 実例紹介 SPA 2. 実例紹介 SSR 3. 実例紹介 ISR 実例紹介
22. 実例紹介 SPA
23. 23 実例紹介 SPA Client AWS Cloud Amazon CloudFront Amazon S3 Amazon API Gateway AWS Lambda 要求 / 応答 Amazon DynamoDB • B2B の IoT 情報可視化 Web アプリケーション (2021年~) • 私たちの組織の状況 • Python を⽤いたサーバーレスシステムの実績あり • お客様要望対応のため初のフロントエンド取り組み • スキルセットに応じたチーム分けを実現するために SPA (Vue.js) と バックエンド API (Python, Serverless Framework) の組み合わ せを採⽤
24. 24 実例紹介 SPA Client AWS Cloud Amazon CloudFront Amazon S3 Amazon API Gateway AWS Lambda 要求 / 応答 Amazon DynamoDB • 良かった点 • 当時のスキルセットに応じたメンバー配置によるスムーズな開発 • OpenAPI 仕様に準拠したチーム間のコミュニケーション • 改善したい点 • 基本的に機能追加・修正には SPA, バックエンド API の両⽅の担 当の稼働が必要 • SPA, バックエンド API の両⽅を確認するにはコンテキストス イッチが求められる • リポジトリが SPA, バックエンド API で分散するため、Coding Agent への全てをコンテキストと渡すことが難しい
25. 実例紹介 SSR
26. 26 実例紹介 SSR Client AWS Cloud AWS Lambda 要求 / 応答 Amazon DynamoDB Elastic Load Balancing Amazon ECS Amazon Aurora 常駐パターン イベント駆動パターン Amazon CloudFront • B2B のモニタリング Web アプリケーション (2024年~) • 私たちの組織の状況 • AWS CDK, バックエンド TypeScript スキルセットの浸透 • Coding Agent の積極的な活⽤に向けたモノレポの取り組み • Coding Agent に必要な情報を⼀元化し、開発者のコンテキストス イッチを減らすため、モノレポ構成で AWS CDK と Next.js (SSR) を採⽤しました
27. 27 実例紹介 SSR Client AWS Cloud AWS Lambda 要求 / 応答 Amazon DynamoDB Elastic Load Balancing Amazon ECS Amazon Aurora 常駐パターン イベント駆動パターン Amazon CloudFront • 良かった点 • SSR により同⼀ドメインのコードの凝集度が⾼まったこと • コンテキストスイッチが減り開発者が Web アプリケーション全 体を把握できるようになったこと • 改善したい点 • Next.js ではレンダリング⼿法は SSR, SSG, ISR の混合であり、 その機能を⼗分活⽤できていないこと • 参考) Guides: Caching | Next.js
28. 実例紹介 ISR
29. 29 実例紹介 ISR Client AWS Cloud 要求 / 応答 AWS Amplify • 先ほどの B2B のモニタリング Web アプリケーション (2025年~) • 私たちの組織の状況 • Next.js の理解が進み SSR, SSG, ISR の混合レンダリングを活 ⽤できていないことを理解 • システムコンポーネントを AWS CDK のコンストラクト単位で分 割実施済み • Web アプリケーション責務のコンストラクトを Amazon ECS から cdk-nextjs-standalone コンストラクトに置き換えを決定 備考: AWS CDK コンストラクトとはコンストラクトは、1 つ以上の AWS CloudFormation リソースと その設定を表すアプリケーション内のコンポーネントです。
30. 30 実例紹介 ISR Client AWS Cloud 要求 / 応答 AWS Amplify • 良かった点 • Web アプリケーションの責務を AWS CDK のコンストラクトで 表現していたため、インフラストラクチャの差し替えが容易で あったこと • 常駐パターン (Amazon ECS) からイベント駆動パターン (AWS Lambda) に移⾏できたため、コストの最適化が⾒込めること • 備考 • 既に AWS CDK で構築済みであり、CDK コンストラクトの⽅が 導⼊が容易であったことから AWS Amplify は採⽤しませんでし た
31. 31 参考) ISR 構成図 出典: Architecture - OpenNext
32. まとめ
33. 33 まとめ 本発表でお伝えしたかった点は以下の3ステップです。 1. レンダリングとホスティング⼿法の選択肢を理解する 2. 現時点で最適な選択を組織とワークロードの⽬的や特性から考える 3. 変更可能なシステムアーキテクチャを取り⼊れ、継続的に進化させる
34. 34 まとめ 1. レンダリングとホスティング⼿法の選択肢を理解する • Web アプリケーションのレンダリングには、SPA, SSR, SSG, ISRと いった様々な⼿法があり、それぞれに対応するホスティング⼿法と異な る特徴が存在します
35. 35 まとめ 2. 現時点で最適な選択を組織とワークロードの⽬的や特性から考える • 組織の観点ではメンバーのスキルセットやチーム構成を考慮する必要が あります • ワークロードの観点では検索エンジン最適化や OGP 対応の必要性やト ラフィックパターン (常駐またはイベント駆動) などを考慮する必要が あります
36. 36 まとめ 3. 変更可能なシステムアーキテクチャを取り⼊れ、継続的に進化させる • 組織の習熟度やビジネス要件は常に変化するため、変更が容易なアーキ テクチャを実現することが⼤切と考えます • 実例で⽰した通り、私たちは AWS CDK の抽象化や構造化を活⽤し、 アーキテクチャが進化可能な状態であるように取り組んでいます
37. 37 所感 私の意⾒ • 最初から正解を出すのは難しいので変更可能なシステムアーキテクチャ であることが⼀番⼤切かなと思います • React Server Components など⽐較的新しいアーキテクチャが登 場し、フルスタックフレームワークはサーバーをより活⽤する⽅向に進 んでいると感じています • マルチクライアント対応 (Web SPA, mobile) などで意図してレンダ リングの責務を分割する必要がない限り初めは SSR を選ぶのが良いと 考えています