Monolith First Serverless Development

© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Monolithic Lambda
Monolith First - Serverless Development
Kensuke Shimokawa
Snr. Serverless Specialist
Amazon Web Services Japan

View Slide

About me…
Kensuke Shimokawa
https://speakerdeck.com/_kensh
https://qiita.com/_kensh

View Slide

Agenda
• AWS Lambda について
• AWS Lambda はイベントドリブン
• AWS Lambda はコンテナサービスなのか︖
• AWS Lambda の実⾏モデル
• AWS Lambda におけるマイクロサービス
• AWS Lambda とデザイン
• AWS Lambda を Monolithic に運⽤する

View Slide

AWS Lambda について

View Slide

歴史の始まりはイベントドリブンだった
• Amazon S3 → AWS Lambda から始まった / Nov. 13, 2014
• 実は Amazon API Gateway → AWS Lambda は後発 / Jul. 9, 2015
• そして Amazon SQS → AWS Lambda へと進化 / Jun. 28, 2018

View Slide

🎂
🎂

View Slide

AWS Lambda はイベントドリブン

View Slide

Lambda Invoke のよくある誤解
Invoke API
Client Service
API payload
Lambda Service
def lambda_handler(event, context):
# do something
return { … }
handler
event object
event
注) この図は間違い

View Slide

Lambda Invoke
Invoke API
Client Service
API payload
Lambda Service
実⾏環境
Runtime API
Lambda Function Instance
API payload
def lambda_handler(event, context):
# do something
return { … }
handler
event object
event

View Slide

なぜイベントドリブンとの相性がよいのか
• ひとつのことをうまくやるのが得意
• あれ、これマイクロサービスっぽい︖
• “⼀つのこと” の意味を拡張
• WEB のバックエンドをうまくやる
• 既存のフレームワークとの相性問題
• ColdStart の問題
• Performance の課題

View Slide

Decision tree
Can be
event driven?
Can be
event driven?
Can be
event driven?
Object Storage Queue Stream
File system
アーキテクチャをイベントドリブンにできるか︖
YES YES YES
NO NO NO

View Slide

Use CDN, Server push, cache, rate limit, etc.
Microservices
Microservices
Microservices
DB
DB
DB
Queue
REST
REST
Stream
Browser
Mobile REST
REST
Amazon
API Gateway
Cache
css, js, html, image
Static Contents
CDN
Cache
WAF
WAF
Object Storage
WebSocket Server push

View Slide

Decision tree
アーキテクチャを⾮同期にできるか︖
Can be
asynchronous?
Can be
asynchronous?
Can be
asynchronous?
asynchronous asynchronous asynchronous
synchronous
YES YES YES
NO NO NO

View Slide

AWS Lambda は
コンテナサービスなのか︖

View Slide

どこまでコンテナっぽく使えるのか
• Artifact はコンテナ形式でパッケージングされている
• docker run しているわけではない
• レジストリは Amazon Elastic Container Registry (ECR) だけ
• サイドカーは使えるが制限も多い / Lambda Extension
Main Side
Log Saving
App
実⾏環境
Log Store Service
https://aws.amazon.com/jp/builders-flash/202202/new-lambda-container-development-7/

View Slide

Lambda execution environment
Firecracker MicroVM
MicroVM Kernel
Lambda Sandbox
Execution Environment
KVM on Bare Metal EC2
FunctionB
Code
FunctionB
/tmp
Extension
Code
FunctionB
Runtime
Extension
Runtime
FunctionB
vCPU
FunctionB
Memory
Firecracker MicroVM
MicroVM Kernel
Lambda Sandbox
Execution Environment
FunctionA
Code
FunctionA
/tmp
Extension
Code
FunctionA
Runtime
Extension
Runtime
FunctionA
vCPU
FunctionA
Memory
Shared resources
within execution
environment
Unshared resources
within execution
environment
https://docs.aws.amazon.com/lambda/latest/
operatorguide/execution-environment.html
Managed by AWS Lambda Service
FunctionA
Network
FunctionB
Network

View Slide

AWS Lambda の実⾏モデル

View Slide

AWS Lambda を使う上で考えたいこと
• なぜ、ルーティングを持ちたくないのか
• なぜ、マルチスレッドを持ちたくないのか
• なぜ、プロセスを複数起動させたくないのか

View Slide

API Gateway Routing
Endpoint
/api/
GET
POST
/books/
/{id}
GET
PUT
Lambda function
Lambda function
Lambda function
Lambda function
$ curl https://domain/api/books/12
API Gateway
Routing

View Slide

Lambda Worker Routing
Application Load
Balancer
Front End
Front End
Worker Manager
Worker Manager
Worker
Worker
Invoke
Routing
Reserve Sandbox
Routing
Amazon API Gateway
AWS Lambda

View Slide

Lambda Handler
dispatch event def handler(event, context):
id = getId(event)
book = get_item(id)
return book
handler

View Slide

• 多重ルーティングを緩和できるか︖ => モノリシックデザインへ

View Slide

API Gateway Routing / 再掲
Endpoint
/api/
GET
POST
/books/
/{id}
GET
PUT
Lambda function
Lambda function
Lambda function
Lambda function
API Gateway
Routing
Routing
+ Web Framework

View Slide

API Gateway でどのようにルーティングするのか
• ANY + Proxy
• 認証やWAFなどは統合されて coupling に
• method resource 単位の細かい統合制御はやり難い
• method 単位の throttle など API Gateway ならではの機能は使い難い

View Slide

API Gateway Routing / Monolithic
Endpoint
/{proxy+}
ANY Lambda function
API Gateway
Routing
Monolithic
Routing

View Slide

Web Framework Routing / Monolithic
dispatch event
from mangum import Mangum
app = FastAPI()
handler = Mangum(app)
handler
@app.get(‘/api/books')
def books():
return [book1, boo2, boo3, … bookN]
@app.post(‘/api/books')
def books(book):
put_item(book)
@app.put("/api/books/{id}")
def books(book):
put_item(book)
@app.get("/api/books/{id}")
def get_book(id):
book = get_item(id)
return book
Routing

View Slide


View Slide

ルーティングとスレッドそしてプロセス
Handler 内での、
• ルーティングなし、スレッドなし
• Pure Lambda
• ルーティングあり、スレッドなし
• AWS Chalice
• ルーティングあり、スレッドあり
• Spring Boot / Ruby on Rails / Laravel on Lambda

View Slide

スケールのポイント
Amazon DynamoDB
マルチスレッドでスケールさせる
ためには、スケールアップが必要
となる / マルチプロセスも同様
AWS Lambda
Amazon API Gateway

View Slide


View Slide

Lambda Lifecycle のポイント / Env Freeze
Runtime
INIT
Function
INIT
Function
INVOKE
Lambda Execution Environment
Function
INVOKE
Function
INVOKE
Runtime
SHUTDOWN
INIT INVOKE INVOKE INVOKE SHUTDOWN
Freeze Freeze Freeze
time

View Slide

Lambda Lifecycle のポイント / Frozen
Runtime
INIT
Function
INIT
Function
INVOKE
Lambda Execution Environment
Function
INVOKE
Function
INVOKE
Runtime
SHUTDOWN
time
frozen frozen
sub process A sub process B
※ マルチスレッドや Node.js での Event Queue も同様

View Slide

スケールのポイント / 再掲
Amazon DynamoDB
Amazon API Gateway
AWS Lambda マルチスレッドでスケールさせる
ためには、スケールアップが必要
となる / マルチプロセスも同様
Lambda 関数実装としてのマルチプロセス、
マルチスレッドのコントロール
サーバーレスサービスでのスケール
コントロール
KISS principle
>

View Slide

AWS Lambda におけるマイクロサービス

View Slide

サービスの⼤きさ
⼊荷する
⽀払い
Monolith
出荷する
ポイント
獲得
在庫数の
取得

View Slide

⼊荷する
在庫ドメイン
出荷する
在庫数の
取得
ポイント
獲得
⽀払い
Modular Monolith
決済ドメイン
Interface

View Slide

⼊荷する
在庫ドメイン
出荷する
在庫数の
取得
ポイント
獲得
⽀払い
決済ドメイン
Microservices
API

View Slide

なぜ⼈はマイクロサービスで作れと⾔ってきたか
• 最⼩権限の原則
• Cold Start
• Function model の原則 / Event Driven Lambda
• Web Framework は Lambda 世界の住⺠じゃない︖
• Lambdaのスケーリングを意識して作られていない

View Slide

マイクロサービスとして作った時の弊害
• 細かくたくさんのパイプライン
• 関数爆発 / Lambda 関数が 1000 個ということも
• 誰が、どの関数を管理、運営しているかの統制
• Lambda Layer の使い⽅における課題
• package managerで管理したい︖
• IDE でクラス参照できない
• リファクタの容易性を維持したい
• モノリポの管理複雑性
• リポ push 通知 / webhook の path route が煩雑化

View Slide

マイクロサービス Lambda の勘違い 1/2
• Lambda は分割しており、DB も分かれているがリリースサイクルを
同期しないといけない
• 共通のLayerに⽀配され、共通が更新されると全部に配布しないといけない
• IAM Role を使い回している
• Lambda からLambda を呼んでいる
• polyglot になっていない

View Slide

マイクロサービス Lambda の勘違い 2/2
• マイクロサービス = 1 Lambda 関数だと思っている
• 極度に Monolith を嫌う、極度に Microservices 思考
• API backed Lambda と Messaging service backed Lambda を同じ感
覚で作ろうとしている
• messaging backed は microserviceであるかはともかく、does one thing/few
things
• 全部を Microservices にしようとしている
• トランザクション境界を跨いでを分離してしまう
• リポジトリ数が発散する

View Slide

Lambda の⼤きさ
⼊荷する
在庫ドメイン
出荷する
在庫数の
取得
ポイント
獲得
⽀払い
決済ドメイン
Functional Unit
Microservices の単位よりも
さらに粒度が細かい

View Slide

Lambda の⼤きさ
⼊荷する
在庫ドメイン
出荷する
在庫数の
取得
ポイント
獲得
⽀払い
決済ドメイン
AWS CloudFormation Stack
Functional Unit

View Slide

Lambda の⼤きさ
⼊荷する
在庫ドメイン
出荷する
在庫数の
取得
ポイント
獲得
⽀払い
決済ドメイン
High Cohesion / ⾼凝集
AWS CloudFormation Stack

View Slide

Lambda の⼤きさ
Monolith
Modular Monolith
Microservices
Functional Unit
High Cohesion
FAT
THIN
Container の尺度
Lambda の尺度
Microservices
(Nanoservices)
Lambda
Monlithic
Lambda

View Slide

アーキテクチャで⾒ると / ギフトサービス
admin
reminder
gift
order
AWS Cloud
Admin API
fetch
Notify Bus Notify Flow
render
select
templates
templates
attachments
rendered
prepare
send
notifications
SMS
SaaS
Mail
SaaS
Monolith
Change
stream
ETL
data integration
Template
Insight
transform
Change
stream
ETL
data integration
Send
Insight
transform
Data
SaaS
transform
ETL Search

View Slide

ドメインで分けると
admin
reminder
gift
order
AWS Cloud
Admin API
fetch
render
select
templates
templates
attachments
rendered
prepare
send
notifications
SMS
SaaS
Mail
SaaS
Monolith
Change
stream
ETL
data integration
Template
Insight
transform
Change
stream
ETL
data integration
Send
Insight
transform
Data
SaaS
transform
ETL Search
Notification Domain Analytics Domain

View Slide

マイクロサービスはコンテキスト境界で分割
admin
reminder
gift
order
AWS Cloud
Admin API
fetch
render
select
templates
templates
attachments
rendered
prepare
send
notifications
SMS
SaaS
Mail
SaaS
Monolith
Change
stream
ETL
data integration
Template
Insight
transform
Change
stream
ETL
data integration
Send
Insight
transform
Data
SaaS
transform
ETL Search
マイクロサービス

View Slide

スタックで分けると
admin
reminder
gift
order
AWS Cloud
Admin API
fetch
render
select
templates
templates
attachments
rendered
prepare
send
notifications
SMS
SaaS
Mail
SaaS
Monolith
Change
stream
ETL
data integration
Template
Insight
transform
Change
stream
ETL
data integration
Send
Insight
transform
Data
SaaS
transform
ETL Search
Admin Template Analytics
Notification
Store
Notification Analytics

View Slide

現状は、Functional Unit
admin
reminder
gift
order
AWS Cloud
Admin API
fetch
render
select
templates
templates
attachments
rendered
prepare
send
notifications
Monolith

View Slide

Cohesion (凝集度)で結合すると
admin
reminder
gift
order
AWS Cloud
Admin API
Admin function
templates
templates
attachments
rendered
prepare
send
notifications
Monolith

View Slide

Microservices (Domain)で結合すると
admin
reminder
gift
order
AWS Cloud
Admin API
Notify function
templates
templates
attachments
rendered
notifications
Monolith
Monlithic
Lambda

View Slide

AWS Lambda とデザイン

View Slide

モノリスとマイクロサービスは排他ではない
• 結局はアーキテクチャパターン
• パターンを利⽤するのであって、⽀配されるのではない
• e.g. “我が社のプロダクトはすべてマイクロサービスにします︕”
• 両⽅共存して使う / これは Lambda に限らず
• テスタブルでリファクタブルなら、アーキテクチャは推移する
• 進化し続けるのがよい

View Slide

サービスの適切な⼤きさって︖
• モノリスとマイクロサービスの２択は極端
• その中間の適切な位置を探る
• 探りはじめの⽅向性のマインドセットがモノリスファースト
• デザインは KPI ではない、ビジネスが進化するに⼗分であれば良い
• 逆にマイクロサービスであってもビジネスが進化しなかったり、その妨げに
なっていることを観測できる KPI が必要
• そもそも進化が必要ない領域をなぜマイクロサービスにするのか︖
• 常に⾃問⾃答する

View Slide

モジュラーモノリスという道
• 単にモノリス回帰するわけではなくモジュラーにはしておく

View Slide

アーキテクチャの進化
Time
1
7
初期開発では
モノリシックを許容
1
Modular
Monolith
⼩さな
Monolith
3
Modular
Monolith
3
新たな
⼩さな
Monolith
凝集度で
分割
凝集度で分割しつつ
⼩さなモノリスは許容
5
凝集度の⾼いモジュール
適切な分離

View Slide

どのラインで分離するか︖
• マイクロサービスファーストだとマイクロサービスで分離する
（マインドセット）
• モノリスファーストだと、複数のモノリスと、モノリス内部のモジュール
で分離（できる）
• ビジネスの初期段階では、ドメイン境界が曖昧
• モノリスからマイクロサービス移⾏は、全体移⾏であるわけない、
部分的に⼩さなポーションをマイクロサービスにする
• Big-Bang 的な移⾏にしない
• 価値を⽣む箇所でAgilityが必要な部分
• モノリスは消えない、消す必要もない

View Slide

統治できない分割は、分割統治ではない
• コンポーネントが増える
• 全体のスローダウンを招いてないか
• 分割したもののオーナーシップをチームにまかせる
• 全体統制のままであればそれは組織的にはモノリシックのまま / 分散モノリス
在庫ドメイン
在庫数の
取得
⽀払い
決済ドメイン
Endpoint
Endpoint
デプロイ時の同時性制約 / 相互依存

View Slide

AWS Lambda を Monolithic に運⽤する

View Slide

Lambda Layer の使い⽅に注意
• Lambda Layer は枯れた⾮機能要件のためにつかう (better)
• Extension (サイドカー) の導⼊には良い
• on goingで進化、開発している部分には適さない
• 特に⾮スクリプト⾔語
• package managerに管理を委譲するか、あえて共通化しない
機能要件
⾮機能要件
成熟
途上
Lambda
Layer
Package
Manager
スクリプト⾔語

View Slide

Lambda に対する設定の注⼊
• Lambda は、設定変更を⼆つの層で考える
• １層⽬ – Lambda 関数⾃体の設定変更
• e.g メモリ、/tmp 領域、サービスインテグレーション、、、etc.
• Cold Start する
• ２層⽬ – Lambda 関数の上にのるアプリケーションビジネスロジックの変更
• e.g. feature flag、debug mode 、、、etc.
• Lambda関数のデプロイを伴うと、Cold Start するが、、、
Lambda Configuration
Application Configuration
1層⽬
2層⽬

View Slide

AWS AppConfig によるロジックと設定の分離
デプロイ戦略
AWS AppConfig AWS Lambda
新
設
定
初期化時に取得し
TTL付きキャッシュ
しておく
Pull
Pull
初期化時に取得し
TTL付きキャッシュ
しておく
Parameter Storeなど
Parameter Storeなど
ここでの設定とはLambda サービスの設定ではなく、アプリケーション内のロジックにおける設定のこと
例. フィーチャーフラグ on/off

View Slide

設定の注⼊における Lambda デザイン
• Lambda における設定の変更
• モノリシック Lambda における設定の注⼊
• Cold Start を併発せずに、設定を注⼊
https://docs.aws.amazon.com/ja_jp/a
ppconfig/latest/userguide/appconfig-
integration-lambda-extensions.html
AWS Lambda
Lambda
function
AppConfig
Extension
Configuration
Cache
AWS SDK
AWS AppConfig

View Slide

Lambda Web Adapter
• HTTP request のためのエントリーポイント Proxy
https://speakerdeck.com/_kensh/web-frameworks-on-lambda

View Slide

Monolithic Lambda の ColdStart
• リクエスト – レスポンスで利⽤されないモジュールを抱えることに
• 初回⽴ち上がりは Latency がのるが、、、
• ⽴ち上がると Does many things︕

View Slide

Snap Start
• Cold Start 抑制のためのメモリキャプチャとレジューム
Invoke API warm start ?
Is snapshot
available?
Create a snapshot
Resume
the snapshot
Invoke handler
Complete
Invocation
No No
Yes

View Slide

Multi-lang Snap Start が欲しい
• Snap Start は 2023.06 時点で、Java11,17 (Corretto) のみが対応
• 次にどのランタイムの対応を期待していますか︖
• ぜひ皆様の声を AWS に届けてください。

View Slide

Multi-lang Snap Start が登場した後の期待感
• Lambda 関数は single thread / single process モデルであるため与え
られたリソース (CPU/メモリ) が単⼀リクエストのために専有
• これにより、プログラミング実装の考慮点を削減することを期待
• Lambda 特有の実⾏モデルに対応した Web Framework OSS が登場
することを期待したい
• それは Lambda専⽤の Framework ではなく、Function as a Service (FaaS) を
プラットフォームとする汎⽤Frameworkとなっても良い

View Slide

Key takeaway

View Slide

Key takeaway
• AWS Lambda の実⾏モデルを理解することで本当にモノリスに⾏く
べきかどうかを判断する
• モノリス⾃体は単なるデザインの選択肢 / 悪ではない
• Lambda ⽂脈でのモノリスとコンテナ⽂脈のモノリスはサイズ感が異なる
• 開発初期にはモノリスが許容されることは多い / モノリスファースト
• モノリスから、アーキテクチャ進化できるようにしておく
• Snap Start の Multi-lang 対応へのリクエストを是⾮︕

View Slide

Thank you!
Kensuke Shimokawa
https://speakerdeck.com/_kensh
https://qiita.com/_kensh

View Slide

Please complete
the session survey

View Slide

Monolith First Serverless Development

Monolith First Serverless Development

kensh

More Decks by kensh

Other Decks in Technology

Featured

Transcript