LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@KRyota

AWS DVA対策メモ(AWS Lambda)

Last updated at Posted at 2025-01-15

ランタイムについて

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リソースに直接接続する場合。
コールドスタート/ウォームスタート 初回リクエスト時にランタイムや関数環境を初期化する時間（コールドスタート）。
その後のリクエストではキャッシュ済み環境を再利用（ウォームスタート）。		 コールドスタートの時間削減によるパフォーマンス最適化。
カスタムランタイム 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関数などにイベントを送信。 処理結果の追跡と次のステップの自動化。
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?