Lambdaとは

☁️ `Lambda`とは

Lambdaは、Amazon Web Services（AWS）が提供するサーバーレスコンピューティングサービスです。これは、サーバーの管理やプロビジョニング（準備・設定）を行うことなく、コードを実行できるようにするものです。開発者はコードをアップロードするだけで、AWSがそのコードの実行に必要なインフラ（サーバー、OSなど）をすべて自動で管理してくれます。ユーザーは、コードが実行された時間と回数に対してのみ料金を支払う「従量課金制」となっています。

🎯 なぜLambdaが必要なのか

❌ 問題のある構成（従来のサーバー）

❌ 問題のある構成:

# 問題: EC2インスタンスを常時稼働
# 1. EC2インスタンスを起動（24時間稼働）
# 2. OSのセットアップ
# 3. アプリケーションのデプロイ
# 4. 監視とメンテナンス

# コスト計算:
# t3.mediumインスタンス: $0.0416/時間
# 24時間 × 30日 = 720時間/月
# コスト: $0.0416 × 720 = $29.95/月

# 問題点:
# 1. アイドル時間も課金される（リクエストがない時間も料金が発生）
# 2. サーバー管理が必要（OSの更新、セキュリティパッチなど）
# 3. スケーリングが手動（トラフィック増加に対応するため手動でスケール）
# 4. 運用コストが高い（監視、メンテナンス）

解決: Lambdaによるサーバーレス

# 解決: Lambda関数（イベント駆動）
import json

def lambda_handler(event, context):
    # リクエストが来た時だけ実行される
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

# コスト計算:
# リクエスト数: 100万回/月
# 実行時間: 100ms/リクエスト
# メモリ: 512MB
# コスト: 約$0.20/月（最初の100万リクエストは無料）

# メリット:
# 1. 実行時間のみ課金（アイドル時間は無料）
# 2. サーバー管理が不要（AWSが自動管理）
# 3. 自動スケーリング（トラフィックに応じて自動スケール）
# 4. 運用コストが低い（監視、メンテナンスが不要）

Lambdaの本質的な価値

1. コスト効率

# 従来のサーバー: 常時稼働
# コスト: $30/月（アイドル時間も含む）

# Lambda: イベント駆動
# コスト: $0.20/月（実行時間のみ）
# 節約: 約99%のコスト削減

# ただし、以下の場合は従来のサーバーの方が安い可能性がある:
# - 常時稼働が必要（24時間トラフィックがある）
# - 実行時間が長い（15分以上）
# - メモリ使用量が大きい（10GB以上）

2. 自動スケーリング

# Lambdaは自動的にスケールする
# 1リクエスト/秒 → 1000リクエスト/秒
# 自動的に1000個のLambda関数が並列実行される

# 従来のサーバーでは:
# 1. トラフィック増加を検知
# 2. 新しいインスタンスを起動（数分かかる）
# 3. ロードバランサーに追加
# 4. トラフィック減少後にインスタンスを終了

# Lambdaでは:
# 1. リクエストが来る
# 2. 自動的にLambda関数が実行される（数ミリ秒）
# 3. リクエスト処理が終わると自動的に終了

`Lambda`の主な特徴とメリット

Lambdaの採用は、開発チームに多くのメリットをもたらします。

サーバー管理が不要 💻
- サーバーのセットアップ、スケーリング、パッチ適用、メンテナンスといった面倒な作業から解放されます。開発者は、アプリケーションのロジックを実装することだけに集中できます。これにより、開発のスピードが上がり、運用コストも削減できます。
自動スケーリング 🚀
- Lambdaは、リクエストの増加に自動でスケールします。トラフィックが急増した場合でも、Lambdaが自動的に複数のインスタンスを起動してリクエストを処理するため、システムの可用性が維持されます。逆に、トラフィックが減少すれば、インスタンスも自動的に終了し、コストを最小限に抑えられます。
従量課金制 💰
- コードの実行時間とメモリ消費量に基づいて課金されるため、使った分だけ支払うことになります。アイドル状態のサーバーに料金を支払う必要がないため、コスト効率が非常に高いです。特に、トラフィックの変動が大きいアプリケーションや、バッチ処理のような断続的なタスクに適しています。

`Lambda`の活用例

Lambdaは、様々なユースケースで活用されています。

ウェブアプリケーションのバックエンド
- API Gatewayと連携させることで、サーバーレスなREST APIを構築できます。クライアントからのHTTPリクエストをLambda関数が処理し、データベース（DynamoDBなど）にアクセスしてデータを操作するといった、バックエンドロジックの実装に利用されます。
データ処理 📊
- S3バケットに新しい画像がアップロードされたら自動的にLambda関数がトリガーされ、その画像をリサイズしたり、透かしを入れたりする処理を実行するといった用途で使われます。また、ストリーミングデータ（Kinesisなど）のリアルタイム処理にも利用できます。
Cronジョブの代替 ⏰
- スケジュールされたイベント（例えば、毎日午前1時にデータベースのバックアップを取る）を自動で実行するタスクにもLambdaは最適です。

`Lambda`とコンテナ、`EC2`との違い

Lambdaは、インフラの管理をAWSに完全に任せるという点で、コンテナやEC2とは根本的に異なります。

特徴	`AWS Lambda`	`AWS EC2`	`Docker`（`Fargate`/`ECS`）
サーバー管理	不要	必須	ほぼ不要（`Fargate`）
スケーリング	自動（イベント駆動）	手動/オートスケーリング	自動（設定に基づく）
課金モデル	従量課金（実行時間）	インスタンスの稼働時間	コンテナの稼働時間とリソース
実行環境	一時的、実行ごとに起動	長時間実行	長時間実行
最適な用途	短時間・断続的なタスク	長時間実行、常時稼働	マイクロサービス、複雑なアプリケーション

Lambda vs EC2 vs Fargate: 実践的な選択判断

判断フローチャート:

1. 実行時間は？
   ├─ < 15分 → Lambdaを検討
   └─ > 15分 → EC2/Fargateを検討

2. 実行頻度は？
   ├─ 断続的（1日数回） → Lambdaを推奨
   ├─ 中程度（1時間数回） → Lambda/Fargateを検討
   └─ 常時稼働 → EC2/Fargateを推奨

3. コールドスタートは許容できるか？
   ├─ 許容できる（数秒の遅延OK） → Lambda
   └─ 許容できない（即座に応答が必要） → EC2/Fargate

4. メモリ要件は？
   ├─ < 10GB → Lambdaを検討
   └─ > 10GB → EC2/Fargateを推奨

実践的な選択例:

# Lambdaが適している場合:
# 1. APIエンドポイント（短時間実行、断続的）
@app.route('/api/users')
def get_users():
    # Lambda関数として実行
    return jsonify(users)

# 2. イベント処理（S3アップロード時の画像リサイズ）
def resize_image(event, context):
    # S3に画像がアップロードされたら自動実行
    # 実行時間: 数秒
    # 実行頻度: 断続的
    pass

# 3. スケジュール実行（Cronジョブ）
# CloudWatch Eventsで毎日1時に実行
def daily_backup(event, context):
    # データベースのバックアップ
    # 実行時間: 数分
    # 実行頻度: 1日1回
    pass

# EC2/Fargateが適している場合:
# 1. Webアプリケーション（常時稼働が必要）
# 2. 長時間実行されるバッチ処理（数時間）
# 3. WebSocket接続（長時間接続が必要）
# 4. 大きなメモリ要件（10GB以上）

Lambdaの実践的なユースケース

ユースケース1: API Gatewayとの統合

# Lambda関数: REST APIエンドポイント
import json

def lambda_handler(event, context):
    # API Gatewayからのイベントを処理
    method = event['httpMethod']
    path = event['path']

    if method == 'GET' and path == '/users':
        # ユーザー一覧を取得
        users = get_users_from_db()
        return {
            'statusCode': 200,
            'body': json.dumps(users)
        }

    return {
        'statusCode': 404,
        'body': json.dumps({'error': 'Not found'})
    }

ユースケース2: S3イベントトリガー

# Lambda関数: S3アップロード時の画像処理
import boto3
from PIL import Image

s3 = boto3.client('s3')

def lambda_handler(event, context):
    # S3に画像がアップロードされたら実行
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # 画像をダウンロード
    image = s3.get_object(Bucket=bucket, Key=key)

    # 画像をリサイズ
    img = Image.open(image['Body'])
    img.thumbnail((800, 600))

    # リサイズした画像をアップロード
    s3.put_object(
        Bucket=bucket,
        Key=f'resized/{key}',
        Body=img.tobytes()
    )

    return {'statusCode': 200}

まとめ

Lambdaは、サーバーレスアーキテクチャの基盤となる重要なサービスです。適切に使用することで、コストと運用負荷を大幅に削減できます。

シニアエンジニアとして考慮すべき点:

コールドスタート: 初回実行時の遅延を考慮した設計
タイムアウト: 15分の制限を考慮した設計
メモリ制限: 10GBの制限を考慮した設計
コスト最適化: 実行時間とメモリ使用量の最適化
エラーハンドリング: リトライとデッドレターキュー（DLQ）の設定