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
AWS Lambda - ピーキーなアクセスに備える / Gunosy Beer Bash #8
Search
koid
September 09, 2016
0
2k
AWS Lambda - ピーキーなアクセスに備える / Gunosy Beer Bash #8
koid
September 09, 2016
Tweet
Share
More Decks by koid
See All by koid
新しい技術の導入時に大切にしていること / IVS CTO Night 2018 LT
koid
2
7k
GunosyでのKinesis Analytics利用について / AWS Solution Days 2017 -AWS DB Day-
koid
0
230
GunosyでのKinesis Analytics利用について / BigData JAWS 6 Kinesis Analytics
koid
1
900
re:Inventに行ってきました - 気になった新サービス / AWS re:Invent2016 Participants LT
koid
0
2k
AWS Lambdaで複数アカウント間でアレコレする / Gunosy Beer Bash #7
koid
1
2k
サーバにログインしない・させないサービス運用 / AWS Summit 2015 Devcon
koid
6
9k
GunosyのMicroServicesとOpsWorks / よくわかる AWS OpsWorks
koid
18
5.9k
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Speed Design
sergeychernyshev
24
570
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
How to Think Like a Performance Engineer
csswizardry
19
1.1k
Facilitating Awesome Meetings
lara
49
6k
How GitHub (no longer) Works
holman
311
140k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Statistics for Hackers
jakevdp
796
220k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
A Philosophy of Restraint
colly
203
16k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Transcript
AWS Lambda ピーキーなアクセスに備える 株式会社Gunosy ⼩出 幸典
⾃⼰紹介 • 名前 – ⼩出 幸典 (こいで ゆきのり) • 所属
– 株式会社Gunosy • プロビジョニング・デプロイフローの共通化とか • 過剰リソース警察、コスト削減おじさん • 好きなAWSサービス – OpsWorks, Lambda, Trusted Advisor
本⽇お話させていただく内容 LambdaのThrottleを理解して上⼿にお付き合いしましょう
Lambdaの制限(Throttle)について • Lambdaの同時実⾏数には上限がある – 同時実⾏数≒1秒あたりのリクエスト数×実⾏時間 – デフォルト同時実⾏数 100/region – 上限緩和申請は可能(ご利⽤は計画的に)
– https://docs.aws.amazon.com/lambda/latest/dg/limits.html • 同時実⾏数の上限を超えると…? – 制限がかかり、`exceeded limits` の例外が返される – 同期リクエストの場合、失敗扱いに – 失敗時にリトライしてくれないものもある
失敗時(制限時)にリトライしてくれないもの • 同期リクエスト、特に戻り値に意味のあるもの – API Gateway, Cognito Sync (と、Amazon Echo)
– http://www.slideshare.net/keisuke69/aws-lambda-amazon-api- gateway-deep-dive/22 • クライアント側で適切にエラー処理を実装する必要がある – API Gatewayならエラーメッセージ・画⾯の表⽰ • CloudFrontを前に挟んでステータスコード⾒てsorry返すとか – Cognito Syncならクライアント側のリトライ処理 • ⼀定時間置いてリトライする
本題 そもそも制限を回避したい
回避するためにどうするか 1. そもそもリクエストさせない 2. Lambda functionの実⾏時間を減らす
例)ニュースパスの記事シェアページの例 • CloudFront(API Gateway+S3)で配信 – Python(+テンプレートエンジンjinja2)でhtmlレスポンス – 静的コンテンツ(画像、css)の配信はS3から – 400系/500系のレスポンスはCloudFrontで設定
※開発的な事情で今は普通にEC2上で動いています AWS Lambda Amazon S3 Amazon CloudFront Amazon API Gateway Amazon S3 client mobile client
そもそもリクエストさせない • 認証の無いGETリクエストは積極的にキャッシュ – キャッシュを有効に、Lambdaへのリクエストを減らす – ※API Gatewayだけでもキャッシュ有効化が可能
例)ニュースパスのCognito Syncの例 • Cognito Syncで同期されたデータを検索⽤ESに保存 – CognitoSync -> Lambda ->
(Queue) -> ElasticSearch – あえてSNS(SQS)を挟み、後続の処理を⾮同期化している Amazon Cognito Amazon SNS Amazon SQS AWS Lambda Amazon Elasticsearch Service EC2 instance mobile client ← 同期 ⾮同期 →
Lambda functionの実⾏時間を減らす • 後続の処理を⾮同期にすることで実⾏時間を減らす – とにかく実⾏時間を減らす、処理系を分ける、Pull型の実装へ • 同時に後ろにいるElasticsearchのメンテナビリティも確保 – SNS(SQS)に放り込んでピーク外に処理
• リトライについてもここで担保 同時実⾏の数が増えてしまう 実⾏時間を減らしとにかく捌く
ローンチの前に • 失敗時(制限時)の処理を適切に – それはリトライしてくれるものか否か? – してくれない場合のエラー表⽰やリトライ処理を考える • 上限緩和申請しておく –
リクエスト数・実⾏時間の⾒積もり • 何よりもSA/TAMの皆様に相談する – よりよいアーキテクチャ/戦略のアドバイスをもらう
余談)もっとケアできる…? • 同時実⾏数が増えた場合に優先したいもの/優先しないもの – (⼤半のものは⾃動的にリトライしてくれるが) – API GatewayならThrottleの設定で制限をかけられる – それ以外でいわゆる優先度付きキュー的なことはできない
– クリティカルなものはリージョンを分ける…等 • 上限緩和申請でどうにもならないレベルのリクエスト – (恐らくそれはLambdaじゃないほうが良い…?) – 何かラウンドロビン的な仕組みでLambdaの実⾏を複数のリージョ ンに分ける…等
まとめ アクセスの多い環境でLambdaを使う場合 事前準備をしっかりとしましょう
終わりに • ご清聴ありがとうございました