1日1%成長する ~AWS Lambda3~

AWSの学習メモ

AWS Lambda3

コールドスタート
    1. 関数コードのダウンロード
    2. 新しいコンテナ開始
    3. runtimeの起動
ウォームスタート
    1. 関数コードの実行


コールドスタートの一部をX-Rayで確かめられる
    initialization部分がランタイム初期化時間
        -> ここがコールドスタートにあたる
        -> 2回目からなくなる（ウォームスタートした場合）
    invocation部分が関数コード実行

    VPCにアクセスできる形にするとX−Ray上で分類されない部分で時間がかかる
    initializationの前に時間がかかる。
        -> ウォームスタート時はもう作成済なので関数コード実行になる

コールスタートを早くするには？
    - コンピューティングリソースを増やす
        - メモリしか設定できない（メモリサイズでCPUも決まる）
            - メモリを上げることで早く終るケースもあるので上げてしまうのも有り
            - 一番減らし引き上げていき処理時間が変わらないところまで引き上げるなど
        - 
    - ランタイムを変える（JVMとか遅いから）
        - 一度温まるとコンパイル言語のほうが早い
    - パッケージサイズを小さくする
        - サイズが大きくなるとコールドスタート時のコードダウンロード時間がかかる
        - 依存関係を減らす、不要なモジュールは含めない
        - コード最適化ツールを使って（難読化ツール）で減らす
    - VPCは必要でない限り使用しない
        - どうしてもVPC内リソースにアクセスする必要がある場合
        - RDSとか
        - Amazon Elasticsesarch ServiceはIAMでアクセス制御できるのでパブリックもあり
        - VPCアクセスを有効すると10~30秒かかる

関数コード
    - コードの最適化 => 各言語のベストプラクティスや最適化手法
    - Fatでモノリシックな関数にならないようにする
        - 1つの関数はなるべく単機能
        - 関数内でのオーケストレーションは禁物
    - ハンドラとコアロジックは分離させる
        - ビジネスロジックは単体できる
コンテナ再利用
    - グローバルスコープを活用
        - ウォームスタート時に有効になっているため
        - def handler以下は毎回実行させる

必要なものだけ読み込む
     response = s3_client.get_object(...)
     response = s3_client.select_object_content(
        expression="SELECT SUBSTR(obj._1, 1, 8), obj._2 FROM s3object as obj"
     )
     - まるまるとるのと絞って取り込むのとでは費用が異なる

コード内ではオーケストレーションしない
    - Fatでモノリシックな関数はつくらない
    - タイムアウトを起こしやす
        -> Step Functionsを利用する