AWS Lambda - ピーキーなアクセスに備える / Gunosy Beer Bash #8

Transcript

1. AWS Lambda ピーキーなアクセスに備える 株式会社Gunosy ⼩出 幸典
2. ⾃⼰紹介 •  名前 –  ⼩出 幸典 （こいで ゆきのり） •  所属 –  株式会社Gunosy •  プロビジョニング・デプロイフローの共通化とか •  過剰リソース警察、コスト削減おじさん •  好きなAWSサービス –  OpsWorks, Lambda, Trusted Advisor
3. 本⽇お話させていただく内容 LambdaのThrottleを理解して上⼿にお付き合いしましょう
4. Lambdaの制限(Throttle)について •  Lambdaの同時実⾏数には上限がある –  同時実⾏数≒1秒あたりのリクエスト数×実⾏時間 –  デフォルト同時実⾏数 100/region –  上限緩和申請は可能（ご利⽤は計画的に） –  https://docs.aws.amazon.com/lambda/latest/dg/limits.html •  同時実⾏数の上限を超えると…？ –  制限がかかり、`exceeded limits` の例外が返される –  同期リクエストの場合、失敗扱いに –  失敗時にリトライしてくれないものもある
5. 失敗時(制限時)にリトライしてくれないもの •  同期リクエスト、特に戻り値に意味のあるもの –  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ならクライアント側のリトライ処理 •  ⼀定時間置いてリトライする
6. 本題 そもそも制限を回避したい
7. 回避するためにどうするか 1. そもそもリクエストさせない 2. Lambda functionの実⾏時間を減らす
8. 例）ニュースパスの記事シェアページの例 •  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
9. そもそもリクエストさせない •  認証の無いGETリクエストは積極的にキャッシュ –  キャッシュを有効に、Lambdaへのリクエストを減らす –  ※API Gatewayだけでもキャッシュ有効化が可能
10. 例）ニュースパスの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 ← 同期 ⾮同期 →
11. Lambda functionの実⾏時間を減らす •  後続の処理を⾮同期にすることで実⾏時間を減らす –  とにかく実⾏時間を減らす、処理系を分ける、Pull型の実装へ •  同時に後ろにいるElasticsearchのメンテナビリティも確保 –  SNS(SQS)に放り込んでピーク外に処理 •  リトライについてもここで担保 同時実⾏の数が増えてしまう 実⾏時間を減らしとにかく捌く
12. ローンチの前に •  失敗時(制限時)の処理を適切に –  それはリトライしてくれるものか否か？ –  してくれない場合のエラー表⽰やリトライ処理を考える •  上限緩和申請しておく –  リクエスト数・実⾏時間の⾒積もり •  何よりもSA/TAMの皆様に相談する –  よりよいアーキテクチャ/戦略のアドバイスをもらう
13. 余談）もっとケアできる…？ •  同時実⾏数が増えた場合に優先したいもの/優先しないもの –  （⼤半のものは⾃動的にリトライしてくれるが） –  API GatewayならThrottleの設定で制限をかけられる –  それ以外でいわゆる優先度付きキュー的なことはできない –  クリティカルなものはリージョンを分ける…等 •  上限緩和申請でどうにもならないレベルのリクエスト –  （恐らくそれはLambdaじゃないほうが良い…?） –  何かラウンドロビン的な仕組みでLambdaの実⾏を複数のリージョ ンに分ける…等
14. まとめ アクセスの多い環境でLambdaを使う場合 事前準備をしっかりとしましょう
15. 終わりに •  ご清聴ありがとうございました