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
7.1k
GunosyでのKinesis Analytics利用について / AWS Solution Days 2017 -AWS DB Day-
koid
0
240
GunosyでのKinesis Analytics利用について / BigData JAWS 6 Kinesis Analytics
koid
1
910
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
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Building an army of robots
kneath
302
43k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Producing Creativity
orderedlist
PRO
341
39k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
Writing Fast Ruby
sferik
627
61k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
What's new in Ruby 2.0
geeforr
343
31k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
RailsConf 2023
tenderlove
29
900
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
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を使う場合 事前準備をしっかりとしましょう
終わりに • ご清聴ありがとうございました