Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

F4ab9a845cd932f7aa97bdb634d74d77?s=47 koid
September 09, 2016
1.6k

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

F4ab9a845cd932f7aa97bdb634d74d77?s=128

koid

September 09, 2016
Tweet

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. 終わりに •  ご清聴ありがとうございました