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

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

koid
September 09, 2016
2.1k

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

koid

September 09, 2016
Tweet

Transcript

  1. ⾃⼰紹介 •  名前 –  ⼩出 幸典 (こいで ゆきのり) •  所属

    –  株式会社Gunosy •  プロビジョニング・デプロイフローの共通化とか •  過剰リソース警察、コスト削減おじさん •  好きなAWSサービス –  OpsWorks, Lambda, Trusted Advisor
  2. Lambdaの制限(Throttle)について •  Lambdaの同時実⾏数には上限がある –  同時実⾏数≒1秒あたりのリクエスト数×実⾏時間 –  デフォルト同時実⾏数 100/region –  上限緩和申請は可能(ご利⽤は計画的に)

    –  https://docs.aws.amazon.com/lambda/latest/dg/limits.html •  同時実⾏数の上限を超えると…? –  制限がかかり、`exceeded limits` の例外が返される –  同期リクエストの場合、失敗扱いに –  失敗時にリトライしてくれないものもある
  3. 失敗時(制限時)にリトライしてくれないもの •  同期リクエスト、特に戻り値に意味のあるもの –  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ならクライアント側のリトライ処理 •  ⼀定時間置いてリトライする
  4. 例)ニュースパスの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 ← 同期 ⾮同期 →
  5. ローンチの前に •  失敗時(制限時)の処理を適切に –  それはリトライしてくれるものか否か? –  してくれない場合のエラー表⽰やリトライ処理を考える •  上限緩和申請しておく – 

    リクエスト数・実⾏時間の⾒積もり •  何よりもSA/TAMの皆様に相談する –  よりよいアーキテクチャ/戦略のアドバイスをもらう
  6. 余談)もっとケアできる…? •  同時実⾏数が増えた場合に優先したいもの/優先しないもの –  (⼤半のものは⾃動的にリトライしてくれるが) –  API GatewayならThrottleの設定で制限をかけられる –  それ以外でいわゆる優先度付きキュー的なことはできない

    –  クリティカルなものはリージョンを分ける…等 •  上限緩和申請でどうにもならないレベルのリクエスト –  (恐らくそれはLambdaじゃないほうが良い…?) –  何かラウンドロビン的な仕組みでLambdaの実⾏を複数のリージョ ンに分ける…等