作って終わりじゃないサーバーレス 〜9年運用する大規模EC物流API基盤の設計・運用のリアル〜

2026/09/19 に ServerlessDays Tokyo 2026 で発表した登壇資料です。
https://tokyo.serverlessdays.io/
株式会社ZOZO
ブランドソリューション開発本部
ZOZOMO部 FBZブロック
杉田 尚弥
#serverlessjp

Transcript

1. 作って終わりじゃない サーバーレス 〜9年運用する大規模EC物流API基盤の設計・運用のリアル〜 株式会社ZOZO ブランドソリューション開発本部 ZOZOMO部 FBZブロック 杉田 尚弥 Copyright © ZOZO, Inc. 1
2. 株式会社ZOZO ブランドソリューション開発本部 ZOZOMO部 FBZブロック 杉田 尚弥 Fulfillment by ZOZOが提供するAPIシステムを開発・運用 社内の開発者向けAI活用推進を担う専門チームも兼務 🛠：AWS / DevOps / Python / Go 🏠：福岡 👍：サウナ / 旅行 / 映画鑑賞 / 辛麺 © ZOZO, Inc. 2
3. https://zozo.jp/ • ファッションEC • 1,700以上のショップ、11,000以上のブランドの取り扱い • 常時138万点以上の商品アイテム数と毎日平均3,100点以上の新着 商品を掲載（2026年6月末時点） • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、シューズ専門ゾーン 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など © ZOZO, Inc. 3
4. https://fbz.zozo.com/ • ZOZOTOWN出店企業の自社ECのフルフィルメント支援サービス • 自社EC運営のための撮影・採寸・梱包・配送などの各種フルフィルメント業務 を、ZOZOの物流拠点「ZOZOBASE」が受託 • 設備投資・人件費・在庫保管料などの負担なしで、自社ECの運営が可能 • 各販売チャネル（自社EC・店舗・ZOZOTOWN）の在庫連携が可能。 これにより、商品欠品による販売機会の損失を最小化 © ZOZO, Inc. 4
5. FBZ APIのサービス概要 入荷 ZOZO TOWN 自社カート システム 商品在庫データ連携 5 FBZ API データ連携 ZOZOBASE (物流拠点) 出荷 ZOZOTOWNと自社ECの在庫を一元化 © ZOZO, Inc. 5
6. FBZ APIのサービス概要 © ZOZO, Inc. 6
7. 今日話すこと キーワードは PART 1 「変化への追従」 プロダクトを取り巻く環境の4種類の変化 フレームワーク・プラグイン・ランタイム・肥大化 PART 2 追従を支えた3つの仕組み E2Eテスト・デプロイの追跡性・可観測性 まとめ © ZOZO, Inc. 7
8. PART 1 プロダクトを取り巻く環境の4種類の変化 フレームワーク / プラグイン / ランタイム / 肥大化 © ZOZO, Inc. 8
9. 変化① まずは、土台のフレームワークから 9年間の相棒 Serverless Framework — 選定・追従・有償化の実録 © ZOZO, Inc. 9
10. 変化① まずは、土台のフレームワークから 【前提】Serverless Framework とは YAMLの設定ファイルひとつで、サーバーレスアプリケーションの構成をまとめて管理できるOSS ① 書く ② 1コマンドでデプロイ serverless.yml functions: createCart: handler: cart.create events: ③ AWS に構築される $ serverless deploy API Gateway ✓ コードを自動でパッケージング → ✓CloudFormation に変換 → - http: path: /carts method: post シンプルなYAMLで定義 Lambda DynamoDB など ✓ API Gateway の配線も自動 ✓ 環境（dev / stg / prd）の 定義したリソース一式が スタックとして一括管理される 切替も簡単 足りない機能はコミュニティが公開している プラグイン で補完できる © ZOZO, Inc. 10
11. 変化① まずは、土台のフレームワークから フレームワークのアップデートに追従 公式メジャーリリース 対象：Serverless Framework FBZの追従 2023年11月 v4有償化を発表 2016年10月 2020年9月 v1.0 リリース 2024年6月 v2.0 リリース v3.0 リリース 2018 2020 2022 v4.0 リリース（有償） 2024 2026 2017年7月 2023年 2026年 v1から開発開始 v3.27へ移行 （v2はスキップ） v4で運用中 2018年 v1.27 ここから5年更新が止まる © ZOZO, Inc. 2022年1月 2024年12月 ライセンス契約のうえ v4へ一括移行 11
12. 変化① まずは、土台のフレームワークから 2つの話を深掘り 公式メジャーリリース 対象：Serverless Framework FBZの追従 2023年11月 v4有償化を発表 2016年10月 2020年9月 v1.0 リリース 話その1 なぜ選んだのか 2018 2024年6月 v2.0 リリース v3.0 リリース 2020 2022 v4.0有償化でも移行したのか リリース（有償） 話その2 2024 2017年7月 2023年 v1から開発開 始 v3.27へ移行 （v2はスキップ） 2018年 v1.27 ここから5年更新が止ま る © ZOZO, Inc. 2022年1月 2026 2024年12月 ライセンス契約のうえ v4へ一括移行 12
13. 話その1 ・ 2017年 なぜ Serverless Framework を選んだのか 当時の選択肢は今と全く違う — 何を比較し、何を決め手にしたか © ZOZO, Inc. 13
14. 変化① まずは、土台のフレームワークから 話その1 なぜ Serverless Framework を選んだのか 2017年当時の選択肢 検証した Serverless Framework プラグインをはじめとしたエコシステムが最も充実 AWS SAM AWS純正のサーバーレス特化IaC CloudFormation AWS純正の汎用IaC。Lambda 以外も含む全リソースを記述できる 3ツール AWS Chalice 検証対象外 Zappa Apex AWS製・Python特化。 Flask風の小規模REST API向けで、多様なイベント駆動構成には不向き 既存の Flask / Django（WSGI）を Lambda に載せ替える用途で、 新規API基盤の前提と合わない 複数Lambdaや関連リソースをプロジェクトとしてまとめて管理できる まだ存在しない：AWS CDK（2019年GA）／ Pulumi（2018年〜）／ SST（2021年〜） © ZOZO, Inc. 14
15. 変化① まずは、土台のフレームワークから 話その1 なぜ Serverless Framework を選んだのか 実際に検証した3ツール AWS純正2ツールと比較したうえで、Serverless Framework を採用 記述量 CloudFormation AWS SAM Serverless Framework × 配線もパッケージングもすべて ◦ CloudFormation 拡張で ◦ 関数・イベント・リソースを短い 自前で記述。 サーバーレス関連の定義が簡潔 YAML で定義 ◦ AWS純正で実績十分 × 登場直後で未成熟 ◦ 利用事例が豊富 成熟度 ・SAM本体のGAは2018年4月 ・CLIのGAは2020年7月 GitHubスター 11,000超（2016年） → 25,000超（2018年） × プラグインのような拡張手段が ◦ プラグインをはじめエコシステム ない が最も充実 必要な権限 ◦ CloudFormationの権限のみ ◦ CloudFormation 準拠 △ admin相当の権限が必要 結論 見送り 見送り 採用 拡張性 △ 汎用ゆえに不足はすべて手作り ※ https://serverless.com/blog/releasing-serverless-framework-v1-and-fundraising ※ https://serverless.com/blog/serverless-framework-wins-best-microservices-api-awards © ZOZO, Inc. 15
16. 話その2 ・ 2024年 有償化された v4 に、それでも移行したのか ライセンス費と移行工数の天秤 — 既存と新規で答えを分けた © ZOZO, Inc. 16
17. 変化① まずは、土台のフレームワークから 話その2 有償化された v4 に、それでも移行したのか v4有償化 — 他ツールへ移行か、ライセンス契約して継続利用か 移行工数とライセンス費を天秤にかけ、「契約して継続利用」を選んだ 何が起きたか： 一定規模以上の組織による商用利用は有償サブスクリプション化と発表 選択肢A：他ツールへ移行 やること 40以上のスタック・Lambda 500本超のIaC定義を CDK等で書き直し 選択肢B：ライセンス契約して継続利用 コード資産はそのまま活かすのでバージョンアップのみ ・ツール利用に伴う費用はゼロ ・年間数百万規模のライセンス費 ・数ヶ月の移行工数＋全APIの再検証 ・移行工数はほぼゼロ リスク 段階移行に伴うデグレの検知が難しい ベンダーの価格・プラン改定に影響される 判断 見送り 採用 コスト © ZOZO, Inc. 17
18. 変化② フレームワークの次は、プラグイン 本体に追従しても終わらない — 依存するプラグインも変化する © ZOZO, Inc. 18
19. 変化② フレームワークの次は、プラグイン 【前提】プラグインの仕組み serverless.yml に1行足すだけで、デプロイ処理の途中に処理を差し込める拡張機構 service: fbz-api $ serverless deploy provider: ビルド name: aws ↓ runtime: python3.13 パッケージング ↓ plugins: - serverless-plugin-split-stacks - serverless-prune-plugin - my-original-plugin ← 設定の検証やコードの前処理 # 自作も可 デプロイ ← Lambda Extentionを付与（datadog） ← スタックをネスト分割（split-stacks） ← IAMポリシーを加工して上限を回避 ↓ 後処理 ← 古いバージョンの掃除prune 各工程の前後に用意されたフックに処理を登録でき、本体に手を入れずに振る舞いを拡張できる © ZOZO, Inc. 19
20. 変化② フレームワークの次は、プラグイン プラグインは便利だが、使いすぎは注意 9年で導入した12種のうち、現在も使い続けているのは半分だけ 9年で導入 6種 現役で稼働中 12 ・導入したあとも継続してアップデートに追従する必要がある 種 プラグインを導入するだけで、 ・開発が止まったプラグインはフォークしたうえで利用 → やりたいことを素早く実現できる 一方で、本体バージョンへの継続的な追 従と、開発が止まるリスクを抱え込む そのプラグイン、本当に必要ですか？ 6種 役目を終えて削除 — 捨てる判断も保守のうち ・本体の標準機能として統合された ・未使用化・別手段への移行・リスク見直し ・プラグインの更新が止まるリスク ・プラグイン同士の依存によって想定外の挙動が起きるリスク © ZOZO, Inc. 20
21. 変化③ ランタイムにも寿命はある ツールを追いかけても終わらない — コードが動く足場そのものが古びていく © ZOZO, Inc. 21
22. 変化③ ランタイムにも寿命はある ランタイムのEOL Lambda はランタイムの EOL 後、段階的に作成・更新ができなくなる ※ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html © ZOZO, Inc. 22
23. 変化③ ランタイムにも寿命はある 二度のEOL対応 プラグイン経由で生成されるLambda（Node.js など）が依存するランタイムも EOL 対象 1回目 2022年 2回目 2025年 © ZOZO, Inc. Python 3.6 → 3.9 どう進めたか ・Lambda 500本超に対する初のランタイム移行 ・計画書を作成したうえで慎重にリリース ・APIの挙動を確認する自動テストが無く、壊れていない ・依存ライブラリの互換性を確認 ことを証明する手段が手動検証しかなかった ・APIの手動検証を都度実施 Python 3.9 → 3.13 どう進めたか 1回目の移行完了から3ヶ月後に導入した、 E2Eテスト(自動)が最初からある状態で着手 ・自動実行されるE2Eテストを判断基準に、 スピード感をもって検証 ・互換性の洗い出しやコード修正 23
24. 変化③ ランタイムにも寿命はある 年表で見るランタイム更新の歴史 対象：Lambda（Python ランタイム） Lambda サポート終了 FBZの対応 2022年7月 2025年12月 Python 3.6 サポート終了 Python 3.9 サポート終了 2023年12月 Python 3.7 サポート終了 2018 2020 2022 2024 2026 2017年7月 2022年5月 2025年 Python 3.6 で開発開始 3.6→3.9 完了 3.9→3.13 完了 数ヶ月かけて対応 (手動検証) 1回目の半分以下の期間で完了 2022年8月 E2E テスト導入 以後の追従判断の基準に © ZOZO, Inc. 24
25. 変化③ ランタイムにも寿命はある 継続的なキャッチアップは自動化すると安心 AWS Health Eventの通知をSlackに連携して検知している © ZOZO, Inc. 25
26. 変化④ 変わるのは、外側だけではない フレームワーク・プラグイン・ランタイムに追従する間に、 自分たちのプロダクトも肥大化していく © ZOZO, Inc. 26
27. 変化④ 変わるのは、外側だけではない 構成が肥大化する ツールだけでなく、自分たちのプロダクト自体も変化する — 成長の先でぶつかった2つの課題 課題① リソース上限 課題② デプロイ時間 何が起きたか どう対処したか 機能追加のたびにリソースが増え、 ・処理やドメイン単位でスタック分割 CloudFormationの500リソース上限に到達 ・それでも大きいスタックは nested stack に分割 何が起きたか どう対処したか ・1回のデプロイに1時間以上かかる ・ビルドの並列化 ・動作確認や障害時の切り戻し時間がかかる ・デプロイオプションの見直し デプロイ時間は、障害からの復旧速度でもある 遅いデプロイは、遅い切り戻し — 信頼性の問題になる © ZOZO, Inc. 27
28. 変化④ 変わるのは、外側だけではない デプロイ 74分 → 24分 原因は「単一ビルド内での直列実行」 — 並列化とオプション見直しで約70%短縮 → 1時間14分 24分 直列デプロイ 約70%短縮 ビルドの並列化 変更セットを経由しない パッケージ処理の削減 CodeBuild のバッチビルド（ビルドグラ direct deployments を有効化し、 時間のかかっていたdevDependencies フ）でタスクの依存関係を定義し、依存の CloudFormation の変更セット作成を の除外処理をスキップしてパッケージ作成 ないスタックを並列更新 省略して直接反映 を短縮 ※ https://techblog.zozo.com/entry/fbz-cicd-strategy © ZOZO, Inc. 28
29. PART 2 追従を支えた3つの仕組み 外から確かめる E2Eテスト / 中身を見る 可観測性とデプロイの追跡性 © ZOZO, Inc. 29
30. 仕組み① 「変更を加えた後も壊れていない」 をどう確かめるか 4つの変化すべてに共通する問い — その答えが、判断基準としてのE2Eテスト © ZOZO, Inc. 30
31. 仕組み① 「変更を加えた後も壊れていない」をどう確かめるか E2Eテスト なぜ E2E テストが、変化への追従の「判断基準」になるのか 1. 実装に依存しない 2. デプロイ後の環境で動かす 3. 全通過をひとつの判断基準に 中身を入れ替えてもテストは書き直さな 設定・ビルド・プラグインの挙動まで 変化の種類を問わずルールは同じ い 含めて実際に動くかを確かめる STEP 1 変更を加えてデプロイ STEP 2 E2E テストを実行 構成管理ツールやランタイム更新、 プラグインの入れ替えなど → デプロイ後の環境に、外から API を叩く 「中身がどう変わったか気にしない」 「変化の種類は問わない」 回帰テストは、追従の「判断基準」になる © ZOZO, Inc. 全通過 → 進める → 1件でも失敗 → 原因を調査 変化のたびに確認方法を考え直さなくていい 31
32. 仕組み① 「変更を加えた後も壊れていない」をどう確かめるか Karate で書く E2E テスト API テストに特化した OSS フレームワーク — リクエストと期待するレスポンスを、そのまま書く 実装に依存しない Feature: 在庫確保 API HTTP で外から叩き、レスポンスだけを見る Background: * url baseUrl JSON を型・パターンで検証 動的に変わる値もチェックできる Scenario: 在庫を確保できる Given path '/v1/stocks/reserve' And request { itemCode: ' #(itemCode) ', quantity: 2 } 環境は設定で切り替え When method post baseUrl や itemCode を環境ごとの変数にして、 Then status 200 同じシナリオを検証と本番で回す And match response == { reservationId: ' #uuid ', status: 'RESERVED', シナリオをつなげてフローを検証 前のレスポンスを次のリクエストに渡し、 quantity: 2, expiresAt: ' #string ' } * def reservationId = response.reservationId カート作成 → 注文 → 注文参照の流れで確かめる ※ https://github.com/karatelabs/karate © ZOZO, Inc. 32
33. 仕組み② 「動いているものの中身」 をどう見るか E2E は外からレスポンスを確かめる 内部で何が動いているかを見るのが、可観測性とデプロイの追跡性 © ZOZO, Inc. 33
34. 仕組み② 「動いているものの中身」をどう見るか 可観測性とデプロイの追跡性（Datadog） 可観測性 — 全関数を一括計装 デプロイの追跡性 — 上げた結果をバージョン別に見る serverlss.yml に1行 plugins: serverless-plugin-datadog ↓ デプロイ時に、アプリコードには手を入れず Lambda 500本超に Datadog Extension を適用 ↓ トレース メトリクス ログ バージョンの切り替わりがそのまま見える 追従後の挙動確認も性能改善も、まずここを見る 外から確かめ、中身を見る — この2つで追従が完結する ※ https://docs.datadoghq.com/ja/tracing/services/deployment_tracking/ © ZOZO, Inc. 34
35. 今までの内容を整理 どの仕組みが、どの変化に効いたか 変化① フレームワーク 変化② プラグイン 変化③ ランタイム 変化④ 肥大化 © ZOZO, Inc. ① E2Eテスト — 外から確かめる ② 可観測性・デプロイの追跡性 — 中身を見る 影響範囲が大きくても機能影響が無いことを把握 どのスタックまで届いたかを version タグで確認 入れ替え・フォーク・削除による既存機能への影響を検知 可観測性自体をプラグインで一括導入 2025年の 3.9→3.13 はスピードと安全を両立 パフォーマンスやエラー率を比較 — 並列デプロイで反映タイミングが分かれても追跡できる 35
36. 変化は止められない 追従できる仕組みは作れる © ZOZO, Inc. 36