AWS DVA対策メモ(AWS Lambda)

# ランタイムについて

## AWS Lambdaのランタイムまとめ

AWS Lambdaのランタイムについて以下のポイントで解説します。

---

### **AWS Lambdaのランタイムとは？**
- Lambda関数のコードを実行する環境を提供するソフトウェア。
- 各ランタイムは特定のプログラミング言語とバージョンをサポートしています。
- ランタイムはAWSが提供するものと、カスタムランタイムの2種類があります。

---

### **AWS提供のランタイム**

| 言語                 | サポートされるバージョン                   | 備考                                                                                 |
|----------------------|------------------------------------------|--------------------------------------------------------------------------------------|
| **Node.js**          | 18.x, 16.x                             | JavaScript/TypeScriptの関数開発に最適。                                             |
| **Python**           | 3.9, 3.8, 3.7                          | データ処理や機械学習、スクリプトベースの関数に適しています。                        |
| **Ruby**             | 2.7                                    | サーバーレスアプリケーションに使用可能。                                             |
| **Java**             | 11, 8                                  | 高いパフォーマンスが必要なエンタープライズ向けのアプリケーションで使用されることが多い。 |
| **Go**               | 1.x                                    | 軽量で効率的な関数を構築可能。                                                      |
| **.NET**             | 6, 5, Core 3.1                         | C#によるアプリケーション開発に適しています。                                         |
| **PowerShell**       | 7.2                                    | 管理スクリプトや自動化タスクに最適。                                                |

---

### **カスタムランタイム**
- AWSが提供していない言語やフレームワークを使用したい場合に、自分でランタイムを定義可能。
- AWS Lambda Extensions APIを利用してカスタムランタイムを作成できます。
- **使用例**:
  - Rust、Kotlin、Elixirなど、公式にサポートされていない言語。
  - 特定のバージョンやカスタムフレームワークを必要とする場合。

---

### **ランタイムの選び方**
1. **使用する言語に基づいて選択**:
   - 既存のプロジェクトやチームのスキルに合った言語を優先。
2. **パフォーマンス要件**:
   - 高パフォーマンスが必要な場合はJavaやGo。
   - 軽量な処理やスクリプトにはPythonやNode.js。
3. **ライブラリやエコシステム**:
   - 利用可能なライブラリやフレームワークの充実度も考慮。


## AWS Lambdaの設定項目

以下は、AWS Lambdaの設定項目についての一覧とその説明です。

| 設定項目                  | 説明                                                                                       | 主な用途                                                 |
|---------------------------|-------------------------------------------------------------------------------------------|--------------------------------------------------------|
| **環境変数**              | 関数内で利用可能なキーと値のペアを設定。ランタイム環境に特定の値を渡すことが可能。          | 接続先URL、APIキー、設定値などの動的パラメータの管理。   |
| **タグ**                  | Lambda関数にメタデータを付与するためのキーと値のペアを設定。                               | リソース管理、課金分析、アクセス制御。                 |
| **基本設定**              | メモリサイズ（128MB〜10GB）、タイムアウト、関数名、説明などの基本情報を設定。               | パフォーマンス最適化やリソース管理。                   |
| **モニタリングツール**     | CloudWatch LogsやX-Rayを使用して、関数の実行状況やトレースデータを監視可能。               | パフォーマンスやエラーのトラブルシューティング。         |
| **VPC**                   | VPC内のリソース（例: RDS、ElastiCache）にアクセス可能にするためのネットワーク設定。          | セキュリティ強化、リソースのプライベート接続。          |
| **ファイルシステム**       | Amazon EFS（Elastic File System）をマウントして共有ファイルストレージを使用可能。            | 大規模データ処理やファイル共有が必要な場合。            |
| **同時実行数**            | 関数の同時実行可能なリクエスト数を設定。最大値を制限することで他のリソースを保護。           | コスト管理や他のリソースへの影響を最小化。              |
| **非同期呼び出し**        | 非同期に呼び出された関数のリトライポリシーや失敗したイベントの保存先（例: SQS、SNS）を設定。 | エラーハンドリングや非同期処理の信頼性向上。            |
| **データベースプロキシ**   | RDS Proxyを利用して、データベース接続を管理し効率化。                                     | 接続数の削減、スケーラビリティとセキュリティの向上。     |

# Lambdaの主な機能

| 機能                        | 説明                                                                                     | 主な用途                                              |
|-----------------------------|-----------------------------------------------------------------------------------------|-----------------------------------------------------|
| **VPCアクセス**             | Lambda関数をAmazon VPC内に配置し、プライベートリソース（例: RDS、ElastiCache）にアクセス可能。 | セキュリティを高め、VPCリソースに直接接続する場合。    |
| **コールドスタート/ウォームスタート** | 初回リクエスト時にランタイムや関数環境を初期化する時間（コールドスタート）。<br>その後のリクエストではキャッシュ済み環境を再利用（ウォームスタート）。 | コールドスタートの時間削減によるパフォーマンス最適化。 |
| **カスタムランタイム**       | AWSが公式にサポートしていない言語やフレームワークを使用可能。独自のランタイムを構築し、Lambdaで実行。 | Rust、Kotlinなどの非公式言語を使用する場合。         |
| **Layers**                  | 複数のLambda関数間で共有可能なライブラリや依存関係をパッケージ化して再利用。               | 共通ライブラリ（例: NumPy、Pandas）やカスタムコードの共有。 |
| **Extensions**              | Lambda関数の実行環境を拡張し、ログ収集、モニタリング、セキュリティツールを統合。            | サードパーティツールとの統合（例: Datadog、Splunk）。 |
| **デプロイパッケージ**       | Lambda関数のコードをZIPファイルまたはコンテナイメージとしてアップロード可能。               | コードの管理や特定のランタイム要件への適応。          |
| **バージョニングとエイリアス** | Lambda関数のバージョンを固定し、ステージ（例: 開発、テスト、本番）に応じたエイリアスを使用可能。 | 安全なデプロイとロールバック、環境ごとのバージョン管理。 |

 **VPCアクセス**:
  - セキュアな環境でプライベートリソースにアクセス可能。
  - VPC内のリソース（例: RDS、ElastiCache）と安全に通信できます。

- **コールドスタートの最適化**:
  - 必要最小限の依存関係を設定し、適切なランタイムを選ぶことでコールドスタートの影響を減らします。
  - 特にユーザー体験を重視するアプリケーションで重要です。

- **カスタムランタイムとLayers**:
  - 独自の言語（例: Rust、Kotlin）を利用したLambda関数を実行可能。
  - 共通ライブラリ（例: NumPy、Pandas）を再利用することで効率的に開発できます。

- **Extensions**:
  - ログ収集やモニタリングツール（例: Datadog、Splunk）を容易に統合。
  - 運用管理を効率化し、トラブルシューティングを迅速化します。

- **デプロイパッケージ**:
  - ZIPファイルまたはコンテナイメージを利用して、柔軟にLambda関数をデプロイ可能。
  - 特定のランタイム要件や依存関係を持つアプリケーションにも対応。

- **バージョニングとエイリアス**:
  - Lambda関数のバージョンを固定して運用可能。
  - ステージ（例: 開発、テスト、本番）ごとにエイリアスを設定し、安定したデプロイやロールバックをサポート。

# 
## AWS Lambdaのイベントとイベントソース

AWS Lambdaは、さまざまなイベントソースをトリガーとして関数を実行します。イベントソースは「ポーリングベース」と「イベントドリブン」の2種類に分類されます。

---

### **1. ポーリングベースのイベントソース**
- Lambdaが指定したソースをポーリングし、データが発生すると関数を呼び出します。
- 主なイベントソース:
  - **Amazon SQS**:
    - メッセージキューからメッセージを取得して処理。
  - **Amazon DynamoDB Streams**:
    - DynamoDBのテーブルで発生したデータ変更イベントを取得。
  - **Amazon Kinesis Data Streams**:
    - ストリームデータ（例: IoTデータ、ログデータ）を処理。

#### **特徴**
- データのリアルタイム処理が可能。
- ポーリング間隔や並列処理の設定が可能。
- キューやストリーム内のデータを順次処理。

#### **使用例**
- SQSからのジョブ実行キュー。
- DynamoDBテーブル変更のログ記録。
- KinesisストリームでIoTデータのリアルタイム分析。

---

### **2. イベントドリブンのイベントソース**
- AWSサービスがイベントを発生させると、自動的にLambda関数がトリガーされます。
- 主なイベントソース:
  - **Amazon S3**:
    - バケット内のオブジェクト作成や削除イベント。
  - **Amazon SNS**:
    - トピックへのメッセージ送信イベント。
  - **Amazon EventBridge**:
    - スケジュールやAWSサービス間のイベント。

#### **特徴**
- イベントが発生するたびにリアルタイムでLambda関数が起動。
- 明示的なポーリング設定は不要。
- 即時応答が必要な処理に最適。

#### **使用例**
- S3バケットにアップロードされた画像の処理。
- SNS経由でシステム全体に通知を送信。
- EventBridgeを利用したスケジュールベースのバッチ処理。

---

### **ポーリングベースとイベントドリブンの比較表**

| 分類                   | 特徴                                              | 主なイベントソース                                   | 使用例                                     |
|------------------------|--------------------------------------------------|----------------------------------------------------|------------------------------------------|
| **ポーリングベース**   | データソースをポーリングしてトリガーを取得。          | SQS, DynamoDB Streams, Kinesis Data Streams       | メッセージキュー、データ変更監視、リアルタイム処理 |
| **イベントドリブン**   | イベントが発生したタイミングで自動的にLambdaを実行。  | S3, SNS, EventBridge                              | バケット監視、通知処理、スケジュール実行     |

---

### **選び方のポイント**
- **ポーリングベース**:
  - データが大量に発生し、継続的に処理が必要な場合に適しています。
  - リアルタイム性が重要なストリームデータ処理。

- **イベントドリブン**:
  - イベントごとに明確なトリガーが存在する場合に適しています。
  - 即時レスポンスが求められる画像処理や通知処理。

---

AWS Lambdaのイベントソースを選ぶ際は、用途やアプリケーションの要件に基づいてポーリングベースまたはイベントドリブンを選択してください！

# 同期呼び出しと非同期呼び出し

## AWS Lambdaの同期呼び出しと非同期呼び出し

AWS Lambdaは、用途に応じて「同期呼び出し」と「非同期呼び出し」の2つの呼び出し方法をサポートしています。それぞれの特徴と選び方を以下にまとめます。

---

### **1. 同期呼び出し**

#### **特徴**
- 呼び出し元がLambda関数の処理結果を待つ。
- Lambda関数が正常に完了すると結果が呼び出し元に返され、エラー時にはエラー情報が即座に返される。

#### **利用例**
- API GatewayやApplication Load Balancer経由でのHTTPリクエスト。
- データ処理の結果を即座に取得したい場合。

#### **主なトリガー**
- **API Gateway**: HTTPリクエストに応答。
- **Application Load Balancer**: Webアプリケーションのバックエンド。
- **AWS SDK**: Lambda関数を同期的に呼び出す。

#### **メリット**
- 処理結果を即座に取得可能。
- 応答時間が重要なアプリケーションに最適。

#### **デメリット**
- 呼び出し元が処理完了を待つため、応答遅延の可能性がある。

---

### **2. 非同期呼び出し**

#### **特徴**
- 呼び出し元がLambda関数の処理完了を待たない。
- イベントはLambdaサービスにキューイングされ、Lambda関数がバックグラウンドで処理。

#### **利用例**
- メール送信やログ記録など、即時応答が不要なタスク。
- SNSやS3などからのイベント処理。

#### **主なトリガー**
- **Amazon S3**: バケットにオブジェクトがアップロードされたとき。
- **Amazon SNS**: トピックへのメッセージ発行。
- **EventBridge**: スケジュールイベントやAWSサービス間の連携。

#### **メリット**
- 呼び出し元の負担を軽減し、処理を非同期で効率化。
- リトライ機能により信頼性を向上。

#### **デメリット**
- 処理結果が即座に返されない。
- リトライ設定やDLQ（デッドレタキュー）の管理が必要。

---

### **同期呼び出しと非同期呼び出しの比較表**

| 呼び出し方法           | 特徴                                                                 | 主な用途                                     | トリガー例                                  |
|------------------------|---------------------------------------------------------------------|--------------------------------------------|--------------------------------------------|
| **同期呼び出し**       | 呼び出し元がLambdaの処理完了を待つ。                                   | 即時レスポンスが必要な場合。                  | API Gateway, Application Load Balancer, AWS SDK |
| **非同期呼び出し**     | 呼び出し元がLambdaの処理を待たずにイベントを送信。                      | バックグラウンドタスクや即時応答不要な処理。   | S3, SNS, EventBridge                        |

---

### **選び方のポイント**

1. **即時応答が必要な場合**:
   - 同期呼び出しが適しています。
   - 例: HTTPリクエストやAPI応答。

2. **バックグラウンドでの処理が適切な場合**:
   - 非同期呼び出しが適しています。
   - 例: メール通知、バッチ処理、ファイル処理。

---


## AWS Lambdaのエラーハンドリングと通知、リトライ処理

AWS Lambdaのエラーハンドリング、通知、リトライ処理についての詳細を以下にまとめます。

---

### **1. エラーハンドリング**

#### **Lambda関数でのエラー**
- Lambda関数の実行中にエラーが発生した場合の動作：
  - **同期呼び出し**: 呼び出し元（例: API Gateway）にエラーが即座に返されます。
  - **非同期呼び出し**: イベントはリトライされ、失敗した場合はデッドレタキュー（DLQ）やエラー送信先に送信されます。

#### **エラータイプ**
1. **ハンドラで発生する例外**:
   - 例: `raise Exception("Error message")`
2. **タイムアウトエラー**:
   - Lambda関数が設定されたタイムアウト（最大15分）を超える場合。
3. **外部サービスのエラー**:
   - 例: データベースやAPI接続失敗。

---

### **2. 通知**

#### **CloudWatchアラーム**
- Lambda関数のエラー率を監視。
- メトリクス「Errors」や「Throttles」に基づいてアラームを設定可能。
- SNSを使って通知を送信。

#### **SNS通知**
- 非同期呼び出しの失敗イベントやDLQの内容を通知。
- 設定例:
  - DLQとしてSQSを使用し、失敗イベントをSNS経由で通知。

---

### **3. リトライ処理**

#### **同期呼び出しのリトライ**
- 呼び出し元がリトライ制御を実施。
- 例: AWS SDKでリトライロジックを設定。

#### **非同期呼び出しのリトライ**
- 非同期呼び出しでは、Lambdaサービスが最大2回リトライ。
- リトライ間隔は最大1分。
- 設定可能な項目:
  - 最大リトライ回数。
  - リトライ間隔。

---

### **4. デッドレタキュー（DLQ）**

#### **用途**
- 非同期呼び出しで処理に失敗したイベントを保持。
- 再処理やデバッグのために使用。

#### **設定例**
- DLQとしてSQSまたはSNSを指定。
- 失敗イベントを保存し、後で解析や再処理を実施。

---

### **5. エラー送信先**

#### **用途**
- 処理成功/失敗に基づいてイベントを別のサービスに送信。

#### **送信先の例**
- SQSキュー。
- SNSトピック。
- 別のLambda関数。

---

### **ポイントまとめ**

| 項目                   | 説明                                                                                       | 主な用途                                   |
|------------------------|-------------------------------------------------------------------------------------------|------------------------------------------|
| **エラーハンドリング**   | Lambda関数内で発生したエラーを管理。タイムアウトや例外処理を含む。                             | 信頼性向上、障害の特定。                   |
| **通知**               | SNSやCloudWatchアラームを活用して、異常検知やエラーを通知。                                   | 異常監視、トラブルシューティング。          |
| **リトライ処理**        | 非同期呼び出しは最大2回リトライされる。設定による制御が可能。                                | 信頼性向上と処理の再実行。                 |
| **デッドレタキュー (DLQ)**| 失敗イベントをSQSまたはSNSに送信し、再処理やデバッグに活用。                                 | 失敗イベントの管理と再処理。               |
| **エラー送信先**        | 処理結果（成功/失敗）に基づいてSQS、SNS、Lambda関数などにイベントを送信。                     | 処理結果の追跡と次のステップの自動化。       |