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

Transcript

1. AWS Lambda
   ピーキーなアクセスに備える
   株式会社Gunosy
   ⼩出 幸典
   

   View Slide

2. ⾃⼰紹介
   •  名前
   –  ⼩出 幸典 （こいで ゆきのり）
   •  所属
   –  株式会社Gunosy
   •  プロビジョニング・デプロイフローの共通化とか
   •  過剰リソース警察、コスト削減おじさん
   •  好きなAWSサービス
   –  OpsWorks, Lambda, Trusted Advisor
   

   View Slide

3. 本⽇お話させていただく内容
   LambdaのThrottleを理解して上⼿にお付き合いしましょう
   

   View Slide

4. Lambdaの制限(Throttle)について
   •  Lambdaの同時実⾏数には上限がある
   –  同時実⾏数≒1秒あたりのリクエスト数×実⾏時間
   –  デフォルト同時実⾏数 100/region
   –  上限緩和申請は可能（ご利⽤は計画的に）
   –  https://docs.aws.amazon.com/lambda/latest/dg/limits.html
   •  同時実⾏数の上限を超えると…？
   –  制限がかかり、`exceeded limits` の例外が返される
   –  同期リクエストの場合、失敗扱いに
   –  失敗時にリトライしてくれないものもある
   

   View Slide

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ならクライアント側のリトライ処理
   •  ⼀定時間置いてリトライする
   

   View Slide

6. 本題
   そもそも制限を回避したい
   

   View Slide

7. 回避するためにどうするか
   1. そもそもリクエストさせない
   2. Lambda functionの実⾏時間を減らす
   

   View Slide

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
   

   View Slide

9. そもそもリクエストさせない
   •  認証の無いGETリクエストは積極的にキャッシュ
   –  キャッシュを有効に、Lambdaへのリクエストを減らす
   –  ※API Gatewayだけでもキャッシュ有効化が可能
   

   View Slide

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
    ← 同期 ⾮同期 →
    

    View Slide

11. Lambda functionの実⾏時間を減らす
    •  後続の処理を⾮同期にすることで実⾏時間を減らす
    –  とにかく実⾏時間を減らす、処理系を分ける、Pull型の実装へ
    •  同時に後ろにいるElasticsearchのメンテナビリティも確保
    –  SNS(SQS)に放り込んでピーク外に処理
    •  リトライについてもここで担保
    同時実⾏の数が増えてしまう 実⾏時間を減らしとにかく捌く
    

    View Slide

12. ローンチの前に
    •  失敗時(制限時)の処理を適切に
    –  それはリトライしてくれるものか否か？
    –  してくれない場合のエラー表⽰やリトライ処理を考える
    •  上限緩和申請しておく
    –  リクエスト数・実⾏時間の⾒積もり
    •  何よりもSA/TAMの皆様に相談する
    –  よりよいアーキテクチャ/戦略のアドバイスをもらう
    

    View Slide

13. 余談）もっとケアできる…？
    •  同時実⾏数が増えた場合に優先したいもの/優先しないもの
    –  （⼤半のものは⾃動的にリトライしてくれるが）
    –  API GatewayならThrottleの設定で制限をかけられる
    –  それ以外でいわゆる優先度付きキュー的なことはできない
    –  クリティカルなものはリージョンを分ける…等
    •  上限緩和申請でどうにもならないレベルのリクエスト
    –  （恐らくそれはLambdaじゃないほうが良い…?）
    –  何かラウンドロビン的な仕組みでLambdaの実⾏を複数のリージョ
    ンに分ける…等
    

    View Slide

14. まとめ
    アクセスの多い環境でLambdaを使う場合
    事前準備をしっかりとしましょう
    

    View Slide

15. 終わりに
    •  ご清聴ありがとうございました
    

    View Slide