Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大規模サーバーレスプロジェクトのリアルな零れ話
Search
maimyyym
May 10, 2025
Technology
3
380
大規模サーバーレスプロジェクトのリアルな零れ話
2025/05/10
Serverless Meetup Fukuoka #5
https://serverless.connpass.com/event/348712/
maimyyym
May 10, 2025
Tweet
Share
More Decks by maimyyym
See All by maimyyym
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
10
5.1k
Amazon Inspector コードセキュリティで手軽に実現するシフトレフト
maimyyym
0
340
組織とセキュリティ文化と、自分の一歩
maimyyym
3
1.5k
ABWG2024採択者が語るエンジニアとしての自分自身の見つけ方〜発信して、つながって、世界を広げていく〜
maimyyym
1
500
re:Invent2024で広がった AWS Verified Accessの可能性を探る
maimyyym
1
230
“自分”を大切に、フラットに。キャリアチェンジしてからの一年 三ヶ月で見えたもの。
maimyyym
0
460
IAM JSON ポリシーと仲良くなろう
maimyyym
3
170
2年目エンジニアが過ごしたre:Invent、私にできる明日からのEverything starts with security
maimyyym
0
160
"とにかくやってみる"で始めるAWS Security Hub
maimyyym
2
500
Other Decks in Technology
See All in Technology
ローカルLLMとLINE Botの組み合わせ その2(EVO-X2でgpt-oss-120bを利用) / LINE DC Generative AI Meetup #7
you
PRO
0
140
ソースを読むプロセスの例
sat
PRO
15
9.8k
CREが作る自己解決サイクルSlackワークフローに組み込んだAIによる社内ヘルプデスク改革 #cre_meetup
bengo4com
0
290
webpack依存からの脱却!快適フロントエンド開発をViteで実現する #vuefes
bengo4com
2
2.4k
事業開発におけるDify活用事例
kentarofujii
5
1.3k
旅で応援する✈️ NEWTが目指すコミュニティ支援とあたらしい旅行 / New Travel: Supporting by NEWT on Your Journey
mii3king
0
140
Introduction to Sansan Meishi Maker Development Engineer
sansan33
PRO
0
310
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
3k
Biz職でもDifyでできる! 「触らないAIワークフロー」を実現する方法
igarashikana
3
2.1k
Copilot Studio ハンズオン - 生成オーケストレーションモード
tomoyasasakimskk
0
200
Data Hubグループ 紹介資料
sansan33
PRO
0
2.2k
[2025年10月版] Databricks Data + AI Boot Camp
databricksjapan
1
240
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.8k
Done Done
chrislema
185
16k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
How to Think Like a Performance Engineer
csswizardry
27
2.1k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.5k
Designing for Performance
lara
610
69k
Side Projects
sachag
455
43k
Statistics for Hackers
jakevdp
799
220k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Transcript
2025.05.10 @maimyyym Mai Miyazaki 大規模サーバーレスプロジェクトの リアルな零れ話 Serverless Meetup Fukuoka #5
2 Introduction 宮 崎 真 衣 HN: mai (@maimyyym )
株式会社Fusic (2023.10〜) 事業本部 技術創造部門 / エンジニア MAI MIYAZAKI ◉ I am ◉ Skill ◉ Commenh m IDDM(1型糖尿病) 3歳発 元百貨店スタッフ(Beauty Counselor AWS Community Builder(Security) 2025- m AWS / Python / PHP(Laravel) 最近野球観戦にハマりました⚾️ Click!!
3 今日のおはなし 大規模サーバーレスプロジェクトを経験して ちょっとした気づきと学び
4 最近のお仕事 サーバーレスプロジェクトの PM兼デベロッパーといったロールで動いています こんな感じの構成(イメージ) 比較的簡単な、よくあるサーバーレス構成
5 最近のお仕事 サーバーレスプロジェクトの PM兼デベロッパーといったロールで動いています こんな感じの構成(イメージ) 比較的簡単な、よくあるサーバーレス構成 ・・・と思っていた
6 最近のお仕事 サーバーレスプロジェクトの PM兼デベロッパーといったロールで動いています こんな感じの構成(イメージ) 比較的簡単な、よくあるサーバーレス構成 いっぱいある しかもクロスアカウント! あらゆるイベントタイプを網羅
7 大変だったこと 多くのイベントタイ7 B API Gatewa% B Kinesis Data Stream
B DynamoDB Stream B S3→SNS→SQ B S3→EventBridge→SNS→SQS Lambdaの数が30以上 複数アカウント・リージョンに展開
8 大変だったこと 多くのイベントタイ7 B API Gatewa% B Kinesis Data Stream
B DynamoDB Stream B S3→SNS→SQ B S3→EventBridge→SNS→SQS Lambdaの数が30以上 複数アカウント・リージョンに展開 規模が大きい
9 大変だったこと 大変だったこと
10 大変だったこと 変数上書きで実行コンテナの使い回しを実感 デプロイしないと分からない「実際のイベント構造」 メンタルモデルの共有の難しさ
11 大変だったこと 変数上書きで実行コンテナの使い回しを実感 デプロイしないと分からない「実際のイベント構造」 メンタルモデルの共有の難しさ
12 実行コンテナの使い回しを実感 AWS Lambdaでは、関数を実行するコンテナは 「使い捨て」ではなく「使い回し」 def main(event, context): def main(event,
context): def main(event, context): def main(event, context): def main(event, context): def main(event, context): ×
13 実行コンテナの使い回しを実感 こんなコードを書いていました (Python) 一回目の実行結果 二回連続でリクエストを送ると・・・? (一回目と同じ結果のはず!) response = {“result”:
[]} def main(event, context): result = { “hoge”: “fuga” } response.append(result) return response response = { “result”: [{“hoge”: “fuga”}] }
14 実行コンテナの使い回しを実感 こんなコードを書いていました (Python) 一回目の実行結果 二回目の実行結果 response = {“result”: []}
def main(event, context): result = { “hoge”: “fuga” } response.append(result) return response response = { “result”: [{“hoge”: “fuga”}] } response = { “result”: [ {“hoge”: “fuga”}, {“hoge”: “fuga”}, ] }
15 実行コンテナの使い回しを実感 こんなコードを書いていました (Python) 一回目の実行結果 二回目の実行結果 response = {“result”: []}
def main(event, context): result = { “hoge”: “fuga” } response.append(result) return response response = { “result”: [{“hoge”: “fuga”}] } response = { “result”: [ {“hoge”: “fuga”}, ] } {“hoge”: “fuga”}, 増えた!
16 実行コンテナの使い回しを実感 こんなコードを書いていました (Python) 一回目の実行結果 最初の一回だけ 二回目の実行結果 response = {“result”:
[]} def main(event, context): result = { “hoge”: “fuga” } response.append(result) return response response = { “result”: [{“hoge”: “fuga”}] } response = { “result”: [ {“hoge”: “fuga”}, ] } {“hoge”: “fuga”}, 増えた! 実行コンテナが使い回され、 関数 = main()だけが実行される。 main()の外での初期化は行われない…!
17 実行コンテナの使い回しを実感 Lambdaの「実行コンテナ」の概念とPythonの言語仕様を APIの振る舞いを通して実感した(知ってはいたけど…!)
18 大変だったこと 変数上書きで実行コンテナの使い回しを実感 デプロイするまで分からない「実際のイベント構造」 メンタルモデルの共有の難しさ
19 大変だったこと 変数上書きで実行コンテナの使い回しを実感 デプロイするまで分からない「実際のイベント構造」 メンタルモデルの共有の難しさ
20 デプロイするまで分からない「実際のイベント構造」 イベントとなる、さまざまなAWSサービス Amazon API Gateway Amazon Kinesis Data Streams
Amazon DynamoDB Streams Amazon SQS Amazon S3 Amazon EventBridge Amazon SNS
21 デプロイするまで分からない「実際のイベント構造」 Lambda関数が受け取るイベントのJSON構造 Amazon API Gateway { "headers": { "X-Forwarded-Host":
"example.com", "X-Forwarded-Proto": "https" }, "resource": "/v1/users/{user_id}.json", "requestContext": { "resourcePath": "/v1/users/{user_id}.json", "path": "/v1/users/12345.json", "protocol": "HTTP/1.1", "requestTimeEpoch": 1728054000000 }, "pathParameters": { "user_id": "12345.json" } }
22 デプロイするまで分からない「実際のイベント構造」 Lambda関数が受け取るイベントのJSON構造 { "kinesis": { "partitionKey": "partitionKey-03", "kinesisSchemaVersion": "1.0",
"data": base64.b64encode( "sequenceNumber": "xxxxxxxxxxxxxxx "approximateArrivalTimestamp": 1428537600, }, "eventSource": "aws:kinesis", "eventID": "shardId-000000000000:xxxxxxxx", "invokeIdentityArn": "arn:aws:iam::EXAMPLE", "eventVersion": "1.0", "eventName": "aws:kinesis:record", "eventSourceARN": "arn:aws:kinesis:EXAMPLE", "awsRegion": "us-east-1", } Amazon Kinesis Data Streams
23 デプロイするまで分からない「実際のイベント構造」 Lambda関数が受け取るイベントのJSON構造 { "Message": "{ "Records": [ { "eventName":
"ObjectCreated:Put", "s3": { "bucket": { "name": "hoge-xxxxxxxx-bucket" }, "object": { "key": "hoge/example.html" } } } ] }" } Amazon SQS Amazon SNS Amazon S3
24 デプロイするまで分からない「実際のイベント構造」 Lambda関数が受け取るイベントのJSON構造 { "Message": "{ "detail-type": "Object Created", "detail":
{ "bucket": { "name": "hoge-xxxxxxxx-bucket" }, "object": { "key": "hoge/example.html" } }, "is_initial_data_import": true }" } Amazon SQS Amazon SNS Amazon EventBridge Amazon S3
25 デプロイするまで分からない「実際のイベント構造」 単体テストでイベントを定義しても、それが合っているかは 実際にデプロイ・起動させて初めて分かる。 実際のイベント構造に合わせて単体テストを書いていた。
26 デプロイするまで分からない「実際のイベント構造」 単体テストでイベントを定義しても、それが合っているかは 実際にデプロイ・起動させて初めて分かる。 実際のイベント構造に合わせて単体テストを書いていた。 【実際にあった、ハマりポイント】 SQSのrawメッセージ配信が有効・無効の設定によって 微妙に構造が違った。気付きづらい…!
27 デプロイするまで分からない「実際のイベント構造」 ドキュメント見るしかない
28 デプロイするまで分からない「実際のイベント構造」 ドキュメント見るしかない 各AWSサービスの仕様を知る + ドキュメントを読み慣れる いい機会でした。
29 大変だったこと 変数上書きで実行コンテナの使い回しを実感 デプロイするまで分からない「実際のイベント構造」 メンタルモデルの共有の難しさ
30 大変だったこと 変数上書きで実行コンテナの使い回しを実感 デプロイするまで分からない「実際のイベント構造」 メンタルモデルの共有の難しさ
31 メンタルモデルの共有の難しさ 「メンタルモデル」とは? > 頭の中にある「ああなったらこうなる」といった「行動のイメージ」を 表現したものである。 (Wikipediaより) 【メンタルモデルが形成できている状況とは?】 プロジェクト内でタスクを受け取ったり、仕様を共有されたり、 デバッグしたりする時に、前提知識・全体像が脳内にしっかり構築
されており、スムーズに理解できる状況のこと
32 メンタルモデルの共有の難しさ 「メンタルモデル」とは? > 頭の中にある「ああなったらこうなる」といった「行動のイメージ」を 表現したものである。 (Wikipediaより) 【メンタルモデルが形成できている状況とは?】 プロジェクト内でタスクを受け取ったり、仕様を共有されたり、 デバッグしたりする時に、前提知識・全体像が脳内にしっかり構築
されており、スムーズに理解できる状況のこと PMの立場として、新規メンバーにメンタルモデルを形成してもらい 共通認識をつくることを目指した
33 メンタルモデルの共有の難しさ Webフレームワークにおける「メンタルモデル」の共有 サーバーレスPJの話をする前に・・・ プロジェクトA プロジェクトB 同じ設計思想 ・・・ FusicではLaravelやRuby on
Railsが主に使用されるフレームワーク プロジェクトが異なっても、たいてい似たような設計思想で構築する プロジェクト固有の知識・仕様こそあるが、設計思想の点では 共通の「メンタルモデル」をみんな持っている laravel-app/ ├── app/ ├── bootstrap/ ├── config/ ├── database/ ├── public/ ├── resources/ ├── routes/ ├── storage/ ├── tests/ laravel-app/ ├── app/ ├── bootstrap/ ├── config/ ├── database/ ├── public/ ├── resources/ ├── routes/ ├── storage/ ├── tests/
34 メンタルモデルの共有の難しさ 大規模サーバーレスPJにおける「メンタルモデル」の共有 イベント駆動で があるからこそ、 プロジェクト固有の「メンタルモデル」0から形成する必要がある 自由度・柔軟性 フレームワークを使用しない プロジェクト独自の構成 複雑で多様なイベント
(どこから何を受け取ってどう処理する?)
35 メンタルモデルの共有の難しさ 大規模サーバーレスPJにおける「メンタルモデル」の共有 イベント駆動で があるからこそ、 プロジェクト固有の「メンタルモデル」0から形成する必要がある むずかしい! 自由度・柔軟性 フレームワークを使用しない プロジェクト独自の構成
複雑で多様なイベント (どこから何を受け取ってどう処理する?)
36 メンタルモデルの共有の難しさ 大規模サーバーレスPJにおける「メンタルモデル」の共有 イベント駆動で があるからこそ、 プロジェクト固有の「メンタルモデル」0から形成する必要がある むずかしい! 自由度・柔軟性 フレームワークを使用しない プロジェクト独自の構成
複雑で多様なイベント (どこから何を受け取ってどう処理する?) 正解はないからこそ手探り
37 メンタルモデルの共有の難しさ 大規模サーバーレスPJにおける「メンタルモデル」の共有 イベント駆動で があるからこそ、 プロジェクト固有の「メンタルモデル」0から形成する必要がある むずかしい! 自由度・柔軟性 フレームワークを使用しない プロジェクト独自の構成
複雑で多様なイベント (どこから何を受け取ってどう処理する?) 正解はないからこそ手探り 【やったこと】 仕様や構成を可視化する PRのレビューを通して理解してもらう 「分かりやすく言い換え」をあえてしない
38 大規模サーバーレスプロジェクトのリアルな零れ話 まとめ Lambdaの実行コンテナの概念を「実感」した Point 01 さまざまなイベントを扱ってAWSサービスへの理解が深まった Point 02 自由度・柔軟性が高いからこそ「メンタルモデル」の形成が0からになる
Point 03 AWSサービス、Web基礎、PMとして・・・学べることが多くて、お得! Point 04
39 Thank You ご清聴いただきありがとうございました We are Hiring! https://recruit.fusic.co.jp/ カジュアル面談もお気軽に! Let's
Talk!