AWS関連メモ

作成日時：2024-08-01以前
更新日時：2024-08-01

Lambda

• Multi-AZ
• ZipはS3、コンテナはECRに格納される
• 同時実行回数0で実質非活性状態。消さなくてもいい
• SAM使えば便利
• 一時ファイルは512MBまで
• 15分でタイムアウト
• .NET使用可能(C#, PowerShell出来そう)
• 定義済み環境変数とユーザー定義環境変数がある
• イベント引数は自由に設定できる

同時実行数

• 同一アカウント同一リージョンでの同時実行制限(1000)
• 超えた場合
  • 非同期型は最長6時間の間、再実施
  • 同期型は即死
• 同時実行数は制限できる
  • 総合計が1000を超えないように、このAPIは10までとか。

起動時

• 前回実行時のデータが残りうる
  • 頻繁に呼び出された場合、環境を使いまわす
  • ファイル保存系とか注意
• 使いまわされた場合、グローバルメソッドは動かない
  • Lambdaが動かすのはエントリポイントのみ
  • 例えるならstaticイニシャライザが動かずに処理実行

起動法

• プッシュ
  • 同期
  • 非同期
    • 呼び出し元へは即時レスポンス
    • キューに格納され随時実行
    • 指定回数失敗したらDLQに格納される
      • SQSとかSNSとかで通知するが良い
    • エラーにより複数回起動される可能性があり
      • 冪等性の担保
    • いつ実行されるか不明なので、実行時にS3などからリソース消えてたりとかありうる。
• ストリーム
  • DynamoDB
  • Kinesis
  • MQ
  • SQS

ホットスタートとコールドスタート

• ホットは早く、コールドは遅い
• プロビジョニング
  • コールドを避けるためあらかじめ建ててくれる
  • 待ち時間は課金対象
  • ただし、プロビ数は同時実行のカウント対象外

過重エイリアス

複数バージョンを指定の割合で割り振りできる。

RDS Proxy

コネクションプーリングしてくれる。

イベントループ

「S3配置をトリガーとして、格納されたファイルを加工してS3に置く」というLambdaだと無限ループが発生する。
バケット分けたりするかルールを細かく決める。

レイヤー

• 共通ライブラリの登録
• レイヤーにおいておけば、依存するLambdaを1個ずつ更新することはない。

API Gateway

• 2種類ある
  • REST API
    • 高い
    • 高機能
    • WAF使える
  • HTTP API
    • 安い
• Lambda Proxy統合
  • あり：Gateway 1 <=> 1 Lambda
  • なし：Gateway 1 <=> * Lambda
  • ありにして、1Lambdaでルーティングして処理すればいい
  • なしならAPI1個に1パスの定義か

CloudFront

• CORS回避
  • CloudFrontを経由すれば、後ろに何がいてもドメインは同一なため。

CloudFront
-> /s3/xxx
-> /api/xxx

S3

• ライフサイクルポリシー
• 署名URLアップロード
  • content-type弄ってXSSとかできるらしい
  • edgeでチェックとかすればいいか
• Intelligent-Tiering
  • アクセスパターンに応じて、自動的に適切なストレージクラスに格納してくれる。

SES

• デフォルトで制限があるらしいので、制限解除すること
• メールアドレスの検証
• バウンスの確認
  • Gmailのルールに引っかかりかねない
• DMARC/DKIM/SPF
  • Gmailの5000/d

ECS

• Auto Scalling
• スティッキーセッション

RDS

WAF

• URLパスのadminが弾かれる可能性

LB

• メンテナンスページの返却

dynamodb

• グローバルセカンダリインデックスはユニークでなくともよい。
• 操作時のイベントをRDSに飛ばすことができる

SAM

• CloudFormationを拡張したっぽいやつ。Serverless特化。
• スタック再構築とかあるので、既存のスタックを消したくなければ回避オプション指定。
• SARからテンプレを取得できる

ドリフト

SAMで構築した後にコンソールから変更することで発生する不整合状態。
チェックツールがあるらしい。

サーバーレスにおける金を掛けないデータ集計

サーバーレスでDynamoDBとか使うと集計が面倒くさい。
下記の方法はどうか。

• LambdaやAthenaでS3内部のデータを集計する
• CloudWatch(S3)のログをもとに集計
  • ログをJSON形式にする+集計情報を吐いておく
  • 失敗したりしてもログを消さない限り、再計算できる。
  • イベントソーシング的

ランニングコストはかからない⇒営業に有利か。

ログ

ECSとかだとタスク定義で、標準出力の内容を収集できたりする。