昨日Serverless Meetup Tokyo vol.2に参加しました。

Tune up AWS Lambda

Lambdaのパフォーマンスに関する話

知っておくべきこと

• 同時実行数　ある時点にfunctionsが実行される数
  • ストリーム別
    • 　シャードの数を大きくするとスケールしていく
    • 　Lambdaの実行数は、シャードの数とイコール

セーフティガードとして、Limit = 100

• • それ以外
    •   一秒あたりのイベント数＊実行時間

APIGatewayの時は秒間のリクエスト30s 30rps

同時実行数の制限緩和も可能だけど、実績がない場合は通らない。

実施にThrottleされているか確認

• ライフサイクルコめコンテナ　 Sandbox として動いている。dockerではない
  • 開始　コンテナ作成されて、コンテナ内にロード・展開(コールドスタート)
  • 終了
  • 再利用※時間が経っていない場合は、再利用される
    • 初期化処理は再利用されるのでパフォーマンス的なアドバンテージがある
    • 再利用されるとは保証するわけではない

• パフォーマンス関連
  • メモリ設定

コンピューティング全体の設定なので、CPU必要な場合はあげるといい

• • バッチサイズ

　一度に取得する最大のレコード数

シャード数増やすことで同時処理数も増えるので、どちらがいいかはワークロード次第

• Lambda functionを速くする方法
  • 定常的にリクエストする

ファンクションにたいしてPingするなり、ポーリングする処理を実装する

推奨の間隔は五分

• • コンピューティングリソースを増やす
  • 言語を変える

スピンアップの順番は、Java <  C# <  python < node.js

• • VPC使わない

ENIの生成、アタッチ処理は遅い

• • パッケージサイズを小さくする

Javaの場合、ProGuard等難読化ツールでパッケージを小さくできる

Lambdaの場合、使用するモジュールをコードに同封しないといけない。

• • グローバルスコープ
  • 同時実行性

インフラエンジニア”リング”レスアーキテクチャ

AzureFunctions 処理数1,200件/分 ピーク 3,700件/分捌いている。

AzureFunctionsは、bashでコードを書ける。Functions内で、perlも使えてしまう。

Serverless AWS構成でセキュアなSPAを目指す

Cloudfront + Amazon S3に一応Serverless

API Gateway + Lambdaになってしまうので、レイテンシ問題がある

Google Cloud FunctionsとかAzureFunctionsだとHTTP(S) Trigger機能があるので、レイテンシでどの程度違うかは別途検証してもようと。

STSのCredential有効期限(最大1H)とCognito Token(最大24H)なので、気をつける

Json Web Token https://blog.kazu69.net/2016/07/30/authenticate_with_json_web_token/

Data + No-Ops

データ処理、No-Opsでできる

プラットフォーム作らないくてもいい

より良いソフトウェアを作るのに力を費やすのがいい

Googleでは、Billionユーザの大きなデータを日々受け取っている

BigQuery の外にあるデータも分析できる

https://cloud.google.com/bigquery/external-data-sources

Bigqueryでは、構造化したデータしか扱えないので、複雑な処理はGoogle Dataflow