1日1%成長する ~Aws Lambda Part2~

AWSの学習メモ

Aws Lambda Part2

エイリアスを利用したトラフィックの移行

    routing-configを利用して2つのバージョン間でのリクエストトラフィックが
    転送される割合(%)を決められる。

    1. 2%のみ新しいバージョンへ
    2. 残り98%は元のバージョンへ
    3. 新しいバージョンが成熟
    4. エイリアスを更新し、全てのトラフィックを新しいバージョンへ
    ※カナリアデプロイみたいな感じ

Lambda Layers
    様々なLambda functionで共通利用するコンポーネントを個別に持つのではなく、
    Lambda Layerとして定義し参照することができるようにする

    /optの下に指定した順番に展開される
        - 特定のモジュールのバージョンを上書きされる
        - 同じパスや同名ファイルを使うときは注意

    Layerは1つの関数で5個まで

    /optの下に各言語の依存を解決する固有パスがある
        - Python : python, python/lib/python3.7/site-packages
        - Nodejs : nodejs/node_modules, nodejs/node8/node_modules(NODE_PATH)

デッドレターキュー（DLQ）
    非同期実行時に2回のリトライにも関わらず処理が正常に終了しなかったときにそのイベントを指定された
    Amazon SQS or SNSのトピックへと送信
        - イベントを失うことなく後続の処理で扱うことできるため、より信頼性が高いシステムが開発可能
        - 関数単位で設定可能で全ての非同期で呼び出し可能
        - 振り分け先
            - SQS：SendMessage
            - SNS：Publish

        - 内容
            - ペイロードには元のイベントのペイロードがそのまま格納される
                - ペイロード：パケットに含まれるヘッダやトレーラーなど付加情報を覗いたデータ本体のこと
            - メッセージ属性
                - RequestID：一意のリクエストID
                - ErrorCode：3桁のHTTPエラーコード
                - ErrorMessage：エラーメッセージ（1KB）
Custom Runtimes
    あらたのリリースされたRuntime APIで可能になった

    - Liunxで互換のランタイムを持ち込むことで、任意の言語でLambda関数を記述可能
    - 
    - Runtime bootstrap
        - ファンクションに"bootstrap"と呼ばれる実行ファイルを含める必要がある
        - デプロイパッケージに含めてLayerとして登録
        - Runtime HTTP APIと実行するファンクションとのブリッジとして振る舞う
        - bootstrapがないとエラーになる
        - bootstrap作成
            - Initialization Tasks
                - 請求時間とタイムアウト対象
                - 関数変数読み取り
                    - _HANDLER
                    - ファンクションで設定されたロケーション、通常ファイル名.メソッド
                    - LAMBDA_TASK_ROOT
                        - ファンクションのコードを含むディレクトリ
                    - AWS_LAMBDA_RUNTIME_API
                        - Runtime APIのホスト名とポート
                - 関数の初期化
                    - ハンドラファイルを読み込み、グローバルスコープを処理
                    - SDKクライアントやDB接続などの静的リソースを作成して複数の呼び出しに再利用
                - エラーハンドリング
                    - エラー発生時は初期化エラーAPIをコール
            - Processing Tasks
                - ループイベントを待ち受ける形
                - イベント取得
                - トレーシングヘッダの伝播
                    - APIレスポンスに含まれるLambdaーRuntime-Trace−IDヘッダからX-Ray
                    　のトレーシングヘッダを取得
                    - _X_AMZN_TRACE_IDに値をセット
                - コンテキストオブジェクトを作成
                - 関数のハンドラ呼び出し
                - レスポンスのハンドリング
                - エラーハンドリング
                - クリーンアップ

    使い所は？
        - Lambdaがサポートしている言語の最新がない
        - Lambdaがサポートを打ち切った言語のバージョンを使い続けたい
        - Lambdaでサポートされていない言語
        ※ランタイム起因のトラブルはサポート対象にならない

モニタリング
    CloudWatch
        - invocations：Lambda実行回数で課金対象
        - duration：実行時間msec（コールドスタートは含まれない）
        - errors：エラー回数
        - throttles：同時実行数を超過した回数（緩和申請の目安）
        - 
    X-Ray

    Lambdaが保証しているのは呼び出されたときに「最低1回実行」のみ
    つまり、複数回呼び出される可能性がある。
        - アプリケーション側で冪等性を確保、検知できるようにする
        - s3やdynamodb使うとか

ストリームベースでの監視/運用ポイント
    - IteratorAgetのAvgが大きくなっている場合は処理遅れが想定される
        - Lambda実行環境のスペックにより実行時間の短縮を考える
        - Kinesis Streamsのshardを分割
    - Error metricsが上がった場合は処理がロックされている可能性がある
        - Lambdaプログラム改善
        - Kinesis streamsの読み込みをlatest/timestampベースで再設定
    - Streamの場合、Errorを挙げないように設計/テストをすることが重要

LambdaのSQS起動の注意
    メッセージ到達時の挙動
        5つのパラレルロングポーリング接続を使用してSQSキューのポーリングを開始、
        メッセージ数 > 処理量の傾向が続き、最終的に処理が追いつかない場合、
        同時実行数の上限までスケール

    Lambda関数単位に同時実行数を制限しない場合、アカウントの上限までスケールする可能性がある。
        - 他のLambda関数の起動を妨げる可能性がある
        - 大規模に使用する際には対象のLambda関数に対して同時実行数の設定を検討する

X−Rayデーモン
    - Lambda関数をトレースする場合、X-Rayデーモンが自動的に実行される。
        - X-Rayデーモンによって最大16MB or 関数のメモリ割りて3%
        - Lambdaは関数のメモリ制限を超えないようにX-rayデーモンを終了しようとする
            - Lambda関数に128MB割当。X-Rayデーモンに16MBが割り当てられる。
            - 128 - 16 = 112MBを超えるようだとデーモンを終了する