Zenn
👌

AWS Cloud Quest Security 学習記録 Day6: Serverless Computing & AWS Lambda

に公開
AWS
Lambda
Serverless
AWS 認定試験
AWS Lambda
idea

はじめに

AWS Security Specialty取得を目指すAWS Cloud Quest学習の6日目として、次世代のアプリケーション開発アーキテクチャの基盤となるServerless ComputingとAWS Lambdaについて学習しました。サーバーレスアーキテクチャは、セキュリティ、運用性、コスト効率の観点から従来のサーバーベースアーキテクチャを大きく変革する重要な技術です。

本日学習した内容：

  • Serverless Computing概要と4つの主要メリット
  • AWS Serverless Platform の包括的なサービス群
  • AWS Lambda の詳細機能と動作原理
  • Lambda Invocation、Concurrency、Error Handling

Serverless Computing 概要

基本概念

Serverless Computing は、サーバーについて考えることなく、アプリケーションとサービスを構築・実行できるコンピューティングモデルです：

  • 重い作業をAWSが代行：サーバー管理、スケーリング、パッチ適用等
  • プロダクト構築に集中：インフラではなくビジネスロジックに注力
  • スケーラブルで信頼性の高い製品の構築を実現

Serverless の4つの主要メリット

1. No Server Management（サーバー管理不要）

  • サーバーのプロビジョニングや維持が不要
  • インフラストラクチャの運用から解放
  • AWSが自動的にサーバー運用を処理

2. Flexible Scaling（柔軟なスケーリング）

  • スケーリングやキャパシティプランニングの心配不要
  • AWSが使用量に応じて自動的にスケーリング
  • 需要の変動に即座に対応

3. Pay for Value（価値に対する支払い）

  • 使用した分のみ支払い
  • 使用していない時間の費用負担なし
  • コスト効率の大幅な改善

4. Highly Available and Secure（高可用性とセキュリティ）

  • 組み込まれた可用性と耐障害性
  • AWSマネージドサービスによるエンタープライズグレードのセキュリティ
  • 単一障害点の排除

AWS Serverless Platform

AWS は、サーバーレスアプリケーション構築を支援する包括的なマネージドサービス群を提供しています。

Compute（コンピューティング）

AWS Lambda

  • サーバーをプロビジョニング・管理することなくコードを実行
  • イベントドリブンな実行モデル
  • 複数のプログラミング言語をサポート

Lambda@Edge

  • AWS Edge LocationでLambda関数を実行
  • Amazon CloudFrontイベントに応答
  • グローバルな低レイテンシー処理を実現

AWS Fargate

  • コンテナ専用のサーバーレスコンピューティングエンジン
  • コンテナ実行に必要なインフラストラクチャをスケールし管理
  • Kubernetes や ECS での利用

Storage（ストレージ）

Amazon Simple Storage Service (S3)

  • セキュア、耐久性が高く、高度にスケーラブルなオブジェクトストレージ
  • サーバーレスアプリケーションの中心的なデータストア
  • イベントトリガーによるLambda関数の実行

Amazon Elastic File System (EFS)

  • シンプル、スケーラブル、エラスティックなファイルストレージ
  • 需要に応じてエラスティックにスケール
  • ファイルの追加・削除に合わせて自動的に拡大・縮小

Data Stores（データストア）

Amazon DynamoDB

  • 高速で柔軟なNoSQLデータベースサービス
  • 一桁ミリ秒の一貫したレイテンシーをあらゆるスケールで提供
  • 完全マネージドでサーバーレスアーキテクチャに最適

Amazon Aurora Serverless

  • Amazon AuroraのオンデマンドでAuto-Scalingな構成
  • MySQL と PostgreSQL互換
  • アプリケーションのニーズに基づいて自動的に起動・シャットダウン・容量調整

API Proxy

Amazon API Gateway

  • APIを作成、公開、維持、監視、セキュリティ保護するフルマネージドサービス
  • あらゆるスケールでのAPI管理
  • RESTful API とWebSocket APIの両方をサポート

Application Integration（アプリケーション統合）

Amazon Simple Notification Service (SNS)

  • フルマネージドのpublish-subscribeメッセージングサービス
  • ファンアウトメッセージングパターンの実装
  • 複数のサブスクライバーへの同時メッセージ配信

Amazon Simple Queue Service (SQS)

  • フルマネージドメッセージキューイングサービス
  • デカップリングされたアプリケーションコンポーネント間の通信
  • メッセージの確実な配信と処理

AWS AppSync

  • 柔軟なGraphQL APIの作成によりアプリケーション開発を簡素化
  • 複数のデータソースからのデータへの安全なアクセス、操作、結合
  • リアルタイムデータ同期とオフライン機能

Amazon EventBridge

  • サーバーレスイベントバスサービス
  • 多様なソースからのアプリケーションデータへの簡単なアクセス
  • AWSサービス、SaaSアプリケーション、カスタムアプリケーション間のイベント配信

Analytics（分析）

Amazon Kinesis

  • AWSでのストリーミングデータ処理プラットフォーム
  • リアルタイムデータの収集、処理、分析
  • 大量のストリーミングデータの効率的な処理

Amazon Athena

  • 標準SQLを使用してAmazon S3のデータを分析するインタラクティブクエリサービス
  • サーバーレスでインフラストラクチャ管理不要
  • ビッグデータの迅速な分析

Orchestration（オーケストレーション）

AWS Step Functions

  • 複数のAWSサービスをサーバーレスワークフローに調整
  • アプリケーションの迅速な構築と更新
  • 複雑なビジネスプロセスの視覚的な管理

Developer Tooling（開発者ツール）

AWS およびパートナーエコシステムが提供：

  • 継続的インテグレーション・デリバリー（CI/CD）ツール
  • テスト、デプロイメント、監視、診断ツール
  • SDK、フレームワーク、IDE プラグイン

サーバーレスプラットフォームの価値

AWS Serverless Platform を活用することで以下を実現：

  • 現代的なアプリケーションの構築
  • アジリティの向上：迅速な開発とデプロイメント
  • 総所有コストの削減：インフラ運用コストの大幅削減

AWS Lambda 詳細

基本概念と動作原理

AWS Lambda は、トリガーで設定できるサーバーレスコンピューティングサービスです：

  • トリガーに応答してコードを自動実行
  • すべての基盤となるコンピューティングリソースをAWSが管理
  • 高可用性でコードを実行・スケールするためのすべてをAWSが処理

Lambdaの動作プロセス

Step 1: コードのアップロード

2つの方法：

  • AWS Lambdaにコードをアップロード
  • Lambdaのコードエディターでコードを記述

作成されたコードはLambda関数と呼ばれます。

Step 2: トリガー設定

コードを以下のように設定：

  • 他のAWSサービスからのトリガー
  • HTTPエンドポイント
  • アプリ内活動
  • スケジュール実行

Step 3: 実行準備完了

AWS Lambdaの実行特性：

  • 呼び出された時のみコードを実行
  • 必要なコンピューティングリソースのみ使用

Step 4: 課金

使用した計算時間分のみ支払い

Lambda関数の呼び出し方法

直接呼び出し

  • Lambda Console
  • Lambda API
  • AWS SDK
  • AWS CLI
  • AWS Toolkits

AWSサービスからの呼び出し

Lambda関数を呼び出すサービス設定が可能

イベント処理

  • キューやストリームからの読み取り設定
  • EventBridge トリガーでのスケジュール実行

主要なトリガーサービス

Amazon Simple Storage Service (S3)

動作：

  • S3バケット内容の変化（オブジェクトの作成・削除・更新）でLambda関数を呼び出し
  • ファイル処理、データ変換、メタデータ抽出等に活用

Amazon Simple Notification Service (SNS)

動作：

  • SNS トピックにメッセージが発行され、Lambda関数がサブスクライブしていると呼び出し
  • メッセージ処理、通知配信、イベント処理等に活用

Amazon API Gateway

動作：

  • API Gateway でAPI作成
  • API が呼び出されるとAPI Gateway がLambda関数を呼び出し
  • サーバーレス REST API、GraphQL API の構築

Amazon DynamoDB

動作：

  • DynamoDBレコードが作成・変更されるとLambda関数をトリガー設定可能
  • データベースイベントの処理、レプリケーション、分析等に活用

Amazon Simple Queue Service (SQS)

動作：

  • SQS キューのメッセージ処理にLambda関数を使用
  • Lambda がキューをポーリングし、関数を同期的に呼び出し
  • バッチ処理、非同期タスク処理等に活用

Lambdaの3つの主要メリット

1. サーバー管理不要

  • サーバーのプロビジョニング・管理が不要
  • コードの記述とアップロードのみでAWSが自動実行
  • インフラ運用から完全に解放

2. 継続的スケーリング

  • 各トリガーに応答してアプリケーションを自動スケール
  • 並列処理でトリガーを個別に処理
  • ワークロードサイズに正確に対応したスケーリング

3. サブセカンドメータリング

精密な従量課金：

  • 使用した分のみ支払い
  • リクエスト数（コードがトリガーされた回数）に基づく課金
  • 実行時間（コード実行にかかった時間）に基づく課金
  • 1ミリ秒単位での課金
  • コードが実行されていない時は費用ゼロ

Lambda Invocation（呼び出し）

直接呼び出し方法

利用可能なツール

  • Lambda Console：ブラウザベースの管理インターフェース
  • Lambda API：プログラマティックアクセス
  • AWS SDK：各種プログラミング言語のSDK
  • AWS CLI：コマンドラインインターフェース
  • AWS Toolkits：IDE統合ツール

他のAWSサービス経由の呼び出し

サービス固有の特徴：

  • 各サービスで異なる呼び出し方法
  • イベント構造の違い
  • 設定方法の違い

Poll-Based Invocation（ポーリングベース呼び出し）

対象サービス

  • Amazon Simple Queue Service (SQS)
  • Amazon DynamoDB
  • Amazon Kinesis

Event Source Mapping

定義：

  • Lambda 内のリソース
  • アイテムを読み取り、バッチでLambda関数に送信
  • ストリームやキューからのアイテム処理に使用

動作プロセス：

AWS Lambda → サービスをポーリング → データ読み取り → イベント作成 → 関数呼び出し

同期 vs 非同期呼び出し

同期呼び出し（Synchronous Invocation）

特徴：

  • リクエスト・応答モデル
  • Lambda が関数を実行し、応答を待機
  • 関数実行終了時にレスポンス返却
  • **関数コードからの応答 + 追加データ（ログ、実行時間等）**を含む

主要な呼び出し元サービス：

  • Amazon API Gateway：RESTful API呼び出し
  • AWS CLI：コマンドライン実行
  • AWS SDK：プログラム内での直接呼び出し
  • AWS Lambda Console：テスト実行

応答例：

{
    "StatusCode": 200,
    "Payload": "関数の実行結果",
    "ExecutedVersion": "$LATEST",
    "LogResult": "実行ログの内容"
}

非同期呼び出し（Asynchronous Invocation）

特徴：

  • fire-and-forget モデル
  • Lambda が関数を実行するためにイベントをキューに配置
  • 関数の実行結果を待機しない
  • 即座に確認応答を返却

主要な呼び出し元サービス：

  • Amazon S3：バケットイベント（オブジェクト作成・削除）
  • Amazon SNS：トピックへのメッセージ発行
  • Amazon CloudWatch Events：スケジュールイベント
  • AWS CodeCommit：リポジトリイベント

応答例：

{
    "StatusCode": 202,
    "Payload": ""
}

使い分けの指針

同期呼び出しを選択する場合：

  • 即座に結果が必要（API応答等）
  • 関数の実行結果に基づく処理が必要
  • エラーハンドリングを呼び出し元で実装

非同期呼び出しを選択する場合：

  • バックグラウンド処理（ファイル処理、メール送信等）
  • 関数の実行時間が長い場合
  • 高いスループットが必要な場合

Lambda Concurrency（並行実行）

並行実行の基本概念

Concurrency Limitの仕組み

AWSアカウントレベルでの制御：

  • デフォルト制限：リージョンあたり1,000並行実行
  • すべてのLambda関数での共有制限
  • 制限緩和：AWS Supportを通じて上限増加が可能

Concurrency の計算方法

並行実行数 = 実行頻度 × 実行時間

例：
- 毎秒100回実行される関数
- 平均実行時間：0.5秒
- 必要な並行実行数：100 × 0.5 = 50

Reserved Concurrency（予約済み並行実行）

目的と動作

特定の関数への並行実行数保証：

  • 重要な関数に対する並行実行数の予約
  • 他の関数による消費を防止
  • パフォーマンスの予測可能性向上

設定例

総制限：1,000並行実行
├── 関数A（Reserved）：300並行実行
├── 関数B（Reserved）：200並行実行  
└── その他の関数：500並行実行（共有）

利用シナリオ

  • ミッションクリティカルな関数
  • SLAが定義されている関数
  • 予測可能な負荷パターンの関数

Provisioned Concurrency（プロビジョニング済み並行実行）

Cold Start問題の解決

課題：

  • Lambda関数の初回実行時の遅延（コールドスタート）
  • 実行環境の初期化時間

Provisioned Concurrencyの効果：

  • 事前に実行環境を準備
  • 初期化済みの関数インスタンスを維持
  • ほぼゼロのレイテンシーで関数実行開始

設定と課金

設定方法：

  • 関数バージョン単位での設定
  • 必要な並行実行数を指定

課金モデル：

  • プロビジョニング済み並行実行数に対する時間課金
  • 実際の実行時間に対する従量課金
  • リクエスト数に対する従量課金

使用ケース

  • レイテンシーに敏感なアプリケーション
  • APIのレスポンス時間が重要
  • 定期的なトラフィックパターン

Lambda Error Handling（エラーハンドリング）

同期呼び出しでのエラーハンドリング

クライアント側でのエラー処理

エラー応答の形式：

{
    "errorMessage": "エラーの詳細メッセージ",
    "errorType": "Exception",
    "stackTrace": [
        "詳細なスタックトレース"
    ]
}

処理フロー：

1. Lambda関数でエラー発生
2. エラー情報を呼び出し元に返却
3. 呼び出し元でエラーハンドリング実装
4. 必要に応じてリトライ処理

非同期呼び出しでのエラーハンドリング

自動リトライ機能

Lambdaの組み込みリトライ：

  • 関数エラー時に自動的に再実行
  • デフォルト：最大2回のリトライ
  • 指数バックオフでリトライ間隔を増加

リトライプロセス：

初回実行 → エラー → 1回目リトライ → エラー → 2回目リトライ → エラー → DLQ送信

Dead Letter Queue (DLQ)

目的：

  • リトライ上限に達した失敗イベントの保存
  • 後続の分析や手動処理のためのデータ保持

設定可能なサービス：

  • Amazon SQS：キューベースのDLQ
  • Amazon SNS：トピックベースのDLQ

DLQ設定例：

{
    "DeadLetterConfig": {
        "TargetArn": "arn:aws:sqs:region:account:dlq-queue"
    }
}

エラー種別と対応策

Function Error（関数エラー）

原因：

  • 関数コード内の例外
  • タイムアウト（最大実行時間超過）
  • メモリ制限超過

対応策：

  • 適切な例外処理の実装
  • タイムアウト値の調整
  • メモリ割り当ての最適化

Service Error（サービスエラー）

原因：

  • Lambda サービス側の問題
  • リソース制限（並行実行数上限等）

対応策：

  • Concurrency制限の見直し
  • リトライロジックの実装
  • AWS Service Health Dashboardの確認

ベストプラクティス

エラーハンドリング設計

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    try:
        # メイン処理
        result = process_business_logic(event)
        
        return {
            'statusCode': 200,
            'body': json.dumps(result)
        }
        
    except ValueError as ve:
        # 予期されるビジネスエラー
        logger.error(f"Validation error: {str(ve)}")
        return {
            'statusCode': 400,
            'body': json.dumps({'error': 'Invalid input'})
        }
        
    except Exception as e:
        # 予期しないエラー
        logger.error(f"Unexpected error: {str(e)}")
        return {
            'statusCode': 500,
            'body': json.dumps({'error': 'Internal server error'})
        }

監視とアラート

  • CloudWatch Logsでのエラーログ監視
  • CloudWatch Metricsでのエラー率監視
  • CloudWatch Alarmsでの自動アラート設定

Lambda のセキュリティベストプラクティス

1. IAM Role と権限管理

最小権限の原則

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::specific-bucket/*"
        }
    ]
}

リソースベースポリシー

Lambda関数の実行権限制御：

  • 特定のサービスからの呼び出しのみ許可
  • クロスアカウントアクセスの制御

2. ネットワークセキュリティ

VPC設定

プライベートリソースアクセス時：

  • Lambda関数をVPC内で実行
  • 適切なサブネット配置
  • セキュリティグループでのトラフィック制御

外部アクセスの制御

  • NAT Gateway経由でのインターネットアクセス
  • VPC Endpointでの AWS サービスアクセス

3. 環境変数と機密情報管理

AWS Systems Manager Parameter Store

import boto3

def get_secure_parameter(parameter_name):
    ssm = boto3.client('ssm')
    response = ssm.get_parameter(
        Name=parameter_name,
        WithDecryption=True
    )
    return response['Parameter']['Value']

AWS Secrets Manager

データベース認証情報等の管理：

  • 自動ローテーション
  • 暗号化された保存
  • 細かいアクセス制御

4. 監査とコンプライアンス

CloudTrail統合

  • Lambda関数の作成・更新・削除の記録
  • 実行ログと設定変更の関連付け

X-Ray トレーシング

  • 関数実行の詳細な分析
  • パフォーマンス問題の特定
  • エラーの根本原因分析

まとめ

学習した主要ポイント

  1. Serverless Computingは、サーバー管理不要で柔軟なスケーリング、従量課金、高可用性を実現
  2. AWS Serverless Platformは、コンピューティングからストレージ、データベース、API、統合まで包括的なサービス群を提供
  3. AWS Lambdaは、イベントドリブンなサーバーレスコンピューティングの中核サービス
  4. 同期・非同期呼び出し、並行実行制御、エラーハンドリングにより、多様なアプリケーション要件に対応
  5. 適切なセキュリティ設計により、エンタープライズグレードのサーバーレスアプリケーションを構築

AWS Security Specialty取得に向けて

AWS Lambdaとサーバーレスアーキテクチャは、以下の観点から重要です：

  • 責任共有モデル：AWSが管理する範囲の拡大とセキュリティ責任の明確化
  • IAM統合：細かい権限制御とリソースベースポリシー
  • ネットワークセキュリティ：VPC統合とプライベートリソースアクセス
  • データ保護：環境変数暗号化と機密情報管理
  • 監査証跡：CloudTrailとX-Rayによる包括的な監視

Discussion