少人数チームで実現する、大規模AWSサーバーレス基盤における"揺らがない"信頼性運用

2026/8/4 Fusic Tech Live vol.32 〜AWS Ambassador・TopEngineer・Jr.Champion大集結〜
https://fusic.connpass.com/event/397671/

Transcript

1. 少人数チームで実現する、大規模AWSサーバーレス基盤に おける"揺らがない"信頼性運用 Fusic Tech Live vol.32 〜AWS Ambassador・TopEngineer・Jr.Champion大集結〜 2026.08.04 Mai Miyazaki @maimyyym ©Fusic Co., Ltd. 0
2. Introduction Click!! 宮 崎 真 衣 MA I M IYA ZA KI HN: mai (@maimyyym ) 株式会社Fusic 事業本部 クラウドエンジニアリング部門 チームリーダー / エンジニア ◉ I am - 元百貨店スタッフ （Beauty Counselor） 2023年10月 Fusic入社 2026 Japan AWS Top Engineers ◉ Skill - AWS / Python / TypeScript / PHP(Laravel) Interested in: Security, Identity & Compliance ◉ Comment - 最近の関心ごと: DevOps, SRE, … ©Fusic Co., Ltd. 1
3. 1. 前提: 少ないパワーで大きなシステム運用を回す 2. 基盤: IaCでちゃんと自動化する仕組み 3. 基盤: Gitの基本機能の利用とスクリプトによる自動化 4. 総括: 考えていること、これからのこと ©Fusic Co., Ltd. 2
4. 今日話すこと 大規模なAWSサーバーレスAPIシステムを約一年運用してみて、 効果があったと感じていることを紹介します。 ※ AWSの高度な技術やTipsの紹介ではありません。 ©Fusic Co., Ltd. 3
5. 1 前提: 少ないパワーで大きなシステム運用を回す ©Fusic Co., Ltd. 4
6. 前提: 少ないパワーで大きなシステム運用を回す 「少ないパワーで大きなシステム運用を回す」とは？ ©Fusic Co., Ltd. 5
7. 「少ないパワーで大きなシステム運用を回す」とは？ 運用している”大規模サーバーレスAPI”について 重要度が高い 基本的に落ちてはならない リクエスト数の多さ 月間数億リクエスト / 分間10,000req前後 速度とエラー率の要件 P90で100〜500ms以下 / エラー率0.01%未満 多数のリソース Lambdaが約40個 ※あえて曖昧な表現にしています。 / その他、サーバーレスサービスを網羅的に利用 そして、もちろん常に開発は続いていく。 ©Fusic Co., Ltd. 6
8. 「少ないパワーで大きなシステム運用を回す」とは？ アプリもインフラもすべて含めて = 開発(Dev)・運用(Ops)を2〜3人の少人数体制で対応。 実現したいこと 安定運用 スムーズな変更 (機能追加・修正) ©Fusic Co., Ltd. 7
9. 運用しているシステムについて プライベートネットワーク プライベートAPI Gatewayの利用 - リソースポリシー設定 - カスタムドメイン設定 クロスアカウント接続 Lambdaの制御 - APIGWステージとLambdaエイリアスの接続 - ProvisionedConcurrencyによる スパイク対策・速度維持 - AssumeRoleによる最小権限の実現 RAMを用いたAPIGWドメイン共有 ・・・など、要件に応じた細かな設定が多々 ©Fusic Co., Ltd. 8
10. 実現していること - 信頼性 パフォーマンスの維持 限りなく0に近いエラー率 ロールバック対応は1度のみ バグ発覚後、原因調査から ロールバックまで3時間程度 ©Fusic Co., Ltd. 9
11. 実現していること - 開発の高速化・属人化の排除 週1以上のリリースを実現 プロジェクトにjoin して 1ヶ月以内 にはリリース作業が可能 ©Fusic Co., Ltd. 10
12. 2 基盤: IaCでちゃんと自動化する仕組み ©Fusic Co., Ltd. 11
13. IaCで"ちゃんと自動化"とは？ IaCの機能を活かしながら、複雑な環境も徹底してスタック管理下に置く ※ これが意外とむずかしい・・・ ©Fusic Co., Ltd. 12
14. 改めて、IaC（Infrastructure as Code）とは？ Infrastructure as Code (IaC) とは、手動のプロセスや設定の代わりにコードを使用してコン ピューティングインフラストラクチャをプロビジョニングおよびサポートできることをいいます。 出典: https://aws.amazon.com/jp/what-is/iac/ ©Fusic Co., Ltd. 13
15. 改めて、IaC（Infrastructure as Code）とは？ Infrastructure as Code (IaC) とは、手動のプロセスや設定の代わりにコードを使用してコン ピューティングインフラストラクチャをプロビジョニングおよびサポートできることをいいます。 出典: https://aws.amazon.com/jp/what-is/iac/ コードで定義して終わりじゃない インフラストラクチャとコードで”運用”できること ©Fusic Co., Ltd. 14
16. TerraformとAWS SAMの使い分け TerraformとAWS SAMを併用し、以下のように使い分けています。 Terraform ネットワークリソース サーバーレスリソース以外全般（カスタムドメインも含む） AWS SAM サーバーレスリソース(Lambda, API Gateway, DynamoDB…) ©Fusic Co., Ltd. 15
17. TerraformとAWS SAMの使い分け 複数のIaCツールを併用して使い分けるメリットは？ ©Fusic Co., Ltd. 16
18. TerraformとAWS SAMの使い分け 複数のIaCツールを併用して使い分けるメリットは？ 依存関係が複雑にならない 同一テンプレート内で参照するより、 arnのハードコードが良いこともある AWS SAMの役割から飛び出さないので 複雑化を避けられる AWS SAMの記法でできないことを CloudFormation記法で定義しない ©Fusic Co., Ltd. 17
19. AWS SAMの役割範囲 AWS SAM ＝ AWS CloudFormation の拡張機能 サーバーレスアプリケーションのプロビジョンを担う アプリケーションコードの変更は SAM 経由で更新 ©Fusic Co., Ltd. 18
20. 大規模APIのSAMの実態 Q: 大規模サーバーレスAPIのYAMLファイルは何行になるでしょうか？ ©Fusic Co., Ltd. 19
21. 大規模APIのSAMの実態 YAMLテンプレート 約3000行 ©Fusic Co., Ltd. 20
22. 大規模APIのSAMの実態 YAMLテンプレート 約3000行 主な原因【複数のステージ】 全ステージのリソースプロビジョンを管理・自動化したい → 各種リソースの設定値を全て定義するため ① 各種ログ、デプロイメント設定 ② DefinitionBodyで統合リクエストを定義 × Lambdaの数 ③ AWS::Lambda::Permission リソース ＝ 各ステージごとのAPIGWがLambdaを実行するための権限定義 その他 ・API Gatewayリソースポリシー ・API Gatewayキャッシュ設定 ・開発・ステージング・本番環境×マルチリー ジョン分のenv変数定義 ・・・など ※ あくまで一例です。行数も正確には言えませんが、概ねこのぐらいです。 ※ 訳あってCDKの選択はできず、ここまでやってきました。 ©Fusic Co., Ltd. 21
23. 大規模APIのSAMの実態 1つのAPI Gatewayに十数個のLambda ＝ 依存関係がある → 1スタック / 1テンプレート 管理が良い ◎ テンプレートの膨大化を防ぐために、別でリソース操作を行うスクリプトを書いてGitHub Actions上で実行 する構成にしていた時期もありました。 → AWS CLIでのリソース操作はスタック管理下に入らないため、余計に複雑化。 ◎ テンプレート行数が多いこと自体のデメリットはそんなにない。 Lambda関数ごとに同じ定義を記述することは、プログラミングコードでは「同じことを繰り返し書かない」と されるが、IaCに関してはその限りではない。 「徹底した自動化」ができて、「管理の複雑さ」がなくなれば、OK！ ※ 本システムにおいて導き出した考えです。構成により最適解は異なります。 ©Fusic Co., Ltd. 22
24. 3 基盤: Gitの基本機能の利用とスクリプトによる自動化 ©Fusic Co., Ltd. 23
25. 実現していること 「リリース作業」を 安全で速い 誰でも一人で実施 ロールバック ©Fusic Co., Ltd. 24
26. 本システムにおける"リリース"とは ©Fusic Co., Ltd. 25
27. 本システムにおける"リリース"とは 特定の機能追加・変更をステージング・本番環境に反映すること 1 2 変更されたコードを Lambdaの新バージョンとしてデプロイ エイリアス: hoge デプロイされたLambdaのバージョンに、 API Gatewayの特定ステージと紐づく エイリアスを貼る ステージ: hoge ©Fusic Co., Ltd. 26
28. GitHubの機能を利用したリリースの一連の流れ 01 いつでも反映可能なPRはmainにマージ 02 リリース実施OKが出た時点で、mainの最新地点コミットにタグを打つ（git tag） タグからリリースを作成 03 ローカル端末でタグにcheckout／そのタグから release_1.0.1 のような名前でリリース 専用ブランチを作成 04 リリース専用ブランチからステージング環境・本番環境デプロイ用ブランチにPR作成 → マージすると自動デプロイが起動 ※デプロイはGitHub Actionsで自動化（AWS SAMのコマンドを実行） ©Fusic Co., Ltd. 27
29. GitHubの機能を利用したリリース メリット リリースごとの変更内容を管理しやすい → ロールバックが簡単 ロールバック時の作業 前のバージョンのタグでリリース専用ブランチを作成し、 デプロイ用ブランチ宛にPR作成 → 反映 ©Fusic Co., Ltd. 28
30. GitHubの機能を利用したリリースの一連の流れ 01 いつでも反映可能なPRはmainにマージ 02 リリース実施OKが出た時点で、mainの最新地点コミットにタグを打つ（git tag） タグからリリースを作成 03 ローカル端末でタグにcheckout／そのタグから release_1.0.1 のような名前でリリース 専用ブランチを作成 04 リリース専用ブランチからステージング環境・本番環境デプロイ用ブランチにPR作成 → マージすると自動デプロイが起動 ※デプロイはGitHub Actionsで自動化（AWS SAMのコマンドを実行） ©Fusic Co., Ltd. 29
31. GitHubの機能を利用したリリースの一連の流れ 01 いつでも反映可能なPRはmainにマージ 02 リリース実施OKが出た時点で、mainの最新地点コミットにタグを打つ（git tag） タグからリリースを作成 03 ローカル端末でタグにcheckout／そのタグから release_1.0.1 のような名前でリリース 専用ブランチを作成 04 ここの作業を自動化 リリース専用ブランチからステージング環境・本番環境デプロイ用ブランチにPR作成 → マージすると自動デプロイが起動 ※デプロイはGitHub Actionsで自動化（AWS SAMのコマンドを実行） ©Fusic Co., Ltd. 30
32. スクリプトによるリリース準備の自動化 タグ作成〜リリースPR作成までを1ステップで ./create_release.sh <バージョン名> を実行するだけ。 1 2 3 4 mainにswitch gitタグ作成 GitHub Release作成 各環境(STG・PRD)への リリースPR作成 ※ ④のリリースPRには、③で作成したリリースノートのリンクを記載 ©Fusic Co., Ltd. 31
33. 実現していること 「リリース作業」を 安全で速い 誰でも一人で実施 ロールバック ©Fusic Co., Ltd. 32
34. 実現していること 「リリース作業」を 安全で速い 誰でも一人で実施 ロールバック 週1〜2以上のリリースを実現（開発が多い時期） パッチ適用もスムーズに（フロー化しているため） ©Fusic Co., Ltd. 33
35. 4 総括: 考えていること、これからのこと ©Fusic Co., Ltd. 34
36. 運用環境を整えた根底にあるもの 人間の“気をつける”や“覚える”に頼らない、徹底した自動化 運用において手動操作がほとんどない。GitHub Actionsの範囲外の作業はスクリプトで自動化。 データ移行やデータの存在確認など、同じCLI操作が続いたり、複雑な操作を行ったり・・・ 少しでも面倒さを感じたらすぐに自動化を考える AIで効率化するのではなく、AIで効率化を加速する ©Fusic Co., Ltd. 35
37. 運用環境を整えた根底にあるもの まだまだやれることはある！ AWS SAMの差分確認（diff check） PR上でのterraform planの自動化 E2Eテストの自動化 テストカバレッジの測定 ©Fusic Co., Ltd. 36
38. 運用環境を整えた根底にあるもの 今日話した“AWSの魅力を活かし切るための技術基盤”は AWSに関する高度な知識だけではなく、汎用的ともいえる技術の組み合わせでした。 細かいTipsの積み重ね、管理手法の徹底、シンプルで楽であること・・・ 終わりなき改善を日々楽しんでいます！ ©Fusic Co., Ltd. 37
39. カジュアル面談もお気軽に！ Let’s Talk! OSEKKAI × TECHNOLOGY ココロと技術で、ぴったりも、びっくりも。 Thank You ご清聴いただきありがとうございました ©Fusic Co., Ltd. 38