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?

新人プログラマ応援 - みんなで新人を育てよう！
@0h-n0

AWS Lambdaで学ぶサーバーレス設計パターン7選と実践的アンチパターン回避術

0
Last updated at Posted at 2026-04-04

AWS Lambdaで学ぶサーバーレス設計パターン7選と実践的アンチパターン回避術

この記事でわかること

  • サーバーレスアーキテクチャの主要7設計パターンとそれぞれの適用条件
  • イベント駆動・Fan-out・SagaなどのパターンをAWSサービスで実装する方法
  • コールドスタート対策やコスト最適化の具体的な手法と数値
  • 陥りやすい4つのアンチパターンとその回避方法
  • Step FunctionsのStandard/Express使い分けによるコスト最適化

対象読者

  • 想定読者: サーバーレスアーキテクチャの導入・設計を検討しているMLエンジニア・バックエンドエンジニア
  • 必要な前提知識:
    • AWSの基本的なサービス（S3、IAMなど）を使ったことがある
    • REST APIの基本的な概念を理解している
    • Pythonの基礎文法（Lambda関数のコード例で使用）

結論・成果

サーバーレスアーキテクチャの設計パターンを正しく選択・適用することで、インフラ管理コストの削減とスケーラビリティの向上を同時に実現できます。AWS公式の報告によると、Lambda SnapStartの導入でコールドスタート時間を最大90%削減でき、メモリの適切なサイジングにより月額コストを20〜30%削減した事例が報告されています（出典）。一方で、パターンの誤った適用（アンチパターン）は、かえってコスト増加やシステムの複雑化を招くため、各パターンの適用条件と制約を正確に理解することが重要です。

以下のフローチャートは、本記事で解説する7つの設計パターンの全体像と、それぞれの関係性を示しています。

サーバーレスの基本概念を理解する

サーバーレスとは「サーバーがない」という意味ではなく、インフラの管理をクラウドプロバイダーに完全に委任するアーキテクチャスタイルです。開発者はビジネスロジックに集中でき、サーバーのプロビジョニング、スケーリング、パッチ適用などをクラウド側が自動的に処理します。

サーバーレス市場は2026年時点でUSD 22.5Bの規模に達しており、2035年にはUSD 156.9Bに成長すると予測されています（出典）。

サーバーレスの基本的な特徴

MLエンジニアにとって身近な例で説明すると、サーバーレスは「推論APIをデプロイするとき、GPU/CPUインスタンスの管理を一切考えなくてよい」という状態に近いものです。ただし、Lambda関数には最大実行時間15分、メモリ最大10GB、デプロイパッケージサイズ250MB（解凍後）という制約があります。

特徴 説明 MLでの類推
従量課金 実行時間とリクエスト数に応じた課金 SageMaker Serverless Inferenceと同じ考え方
自動スケーリング リクエスト量に応じて自動で関数インスタンスが増減 オートスケーリンググループに近い
ステートレス 関数の実行環境間でデータを共有しない バッチ推論の各ワーカーが独立しているのと同じ
イベント駆動 外部イベント（HTTPリクエスト、S3アップロードなど）で起動 MLパイプラインのトリガーと同じ概念

注意: サーバーレスは万能ではありません。長時間実行タスク（15分超）、大量のメモリを必要とする処理（10GB超）、GPUが必要な推論処理にはECS/EKSやSageMakerの方が適しています。

7つの設計パターンを実装する

パターン1: APIゲートウェイパターン

最も基本的なパターンです。Amazon API GatewayをエントリーポイントとしてLambda関数を呼び出し、RESTful APIやGraphQL APIのバックエンドを構築します。

以下は、API GatewayとLambda関数でCRUD APIを構築する例です。

# handler.py - Lambda関数のハンドラー
# Python 3.12+ で動作確認
import json
import boto3
from datetime import datetime, timezone

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table("Items")


def handler(event, context):
    """API Gateway からのリクエストを処理するLambda関数"""
    http_method = event["httpMethod"]
    path = event.get("pathParameters") or {}

    if http_method == "GET" and "id" in path:
        return get_item(path["id"])
    elif http_method == "POST":
        return create_item(json.loads(event["body"]))
    else:
        return response(400, {"error": "Unsupported method"})


def get_item(item_id):
    result = table.get_item(Key={"id": item_id})
    if "Item" not in result:
        return response(404, {"error": "Item not found"})
    return response(200, result["Item"])


def create_item(body):
    item = {
        "id": body["id"],
        "name": body["name"],
        "created_at": datetime.now(timezone.utc).isoformat(),
    }
    table.put_item(Item=item)
    return response(201, item)


def response(status_code, body):
    return {
        "statusCode": status_code,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps(body, default=str),
    }

なぜこの実装を選んだか:

  • DynamoDBはサーバーレスとの親和性が高く、接続プール管理が不要
  • boto3クライアントをモジュールレベルで初期化することで、ウォームスタート時に再利用される（Pythonの__init__でインスタンスを作るのと同じ考え方）

注意点:

API Gatewayにはペイロードサイズ上限（10MB）とタイムアウト（29秒）があります。大きなファイルのアップロードにはS3 Presigned URLを使用してください。また、API Gatewayには直接DynamoDBと統合する「サービス統合」機能もあり、Lambda関数を経由せずにシンプルなCRUD操作を実現できます。ビジネスロジックが不要な場合はこちらの方がコスト効率が高くなります。

パターン2: イベント駆動パターン

サーバーレスの真価を発揮するパターンです。S3へのファイルアップロード、DynamoDB Streams、CloudWatch Eventsなど、AWSサービスのイベントをトリガーとしてLambda関数を起動します。

# image_processor.py - S3イベント駆動の画像処理
# Python 3.12+ / Pillow 10.x で動作確認
import boto3
from PIL import Image
import io

s3 = boto3.client("s3")

# リサイズ対象のサイズ定義
THUMBNAIL_SIZES = {
    "small": (128, 128),
    "medium": (256, 256),
    "large": (512, 512),
}


def handler(event, context):
    """S3にアップロードされた画像を自動リサイズするLambda関数"""
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = record["s3"]["object"]["key"]

        # 処理済みファイルの再トリガーを防止
        if key.startswith("thumbnails/"):
            return

        # 元画像を取得
        obj = s3.get_object(Bucket=bucket, Key=key)
        image = Image.open(io.BytesIO(obj["Body"].read()))

        # 各サイズでリサイズして保存
        for size_name, dimensions in THUMBNAIL_SIZES.items():
            resized = image.copy()
            resized.thumbnail(dimensions)

            buffer = io.BytesIO()
            resized.save(buffer, format="JPEG", quality=85)
            buffer.seek(0)

            output_key = f"thumbnails/{size_name}/{key}"
            s3.put_object(
                Bucket=bucket,
                Key=output_key,
                Body=buffer,
                ContentType="image/jpeg",
            )

    return {"statusCode": 200, "body": "Thumbnails created"}

ハマりポイント: S3イベントで処理結果を同じバケットに保存する場合、処理済みファイルが再度イベントをトリガーして無限ループになることがあります。上記コードではthumbnails/プレフィックスチェックで防いでいますが、別バケットに出力するか、S3イベントのプレフィックスフィルタで対処するのがより安全です。

パターン3: Fan-outパターン

1つのイベントを複数のコンシューマーに同時配信するパターンです。SNS（Simple Notification Service）とSQS（Simple Queue Service）を組み合わせることで、信頼性の高いメッセージ配信を実現します。

# order_publisher.py - 注文イベントをSNSにパブリッシュ
# Python 3.12+ で動作確認
import json
import boto3

sns = boto3.client("sns")
ORDER_TOPIC_ARN = "arn:aws:sns:ap-northeast-1:123456789012:order-events"


def handler(event, context):
    """注文処理後にFan-outでイベントを配信"""
    order = json.loads(event["body"])

    # SNSトピックにメッセージをパブリッシュ
    # 全てのサブスクライバー（SQSキュー）に同時配信される
    sns.publish(
        TopicArn=ORDER_TOPIC_ARN,
        Message=json.dumps({
            "order_id": order["order_id"],
            "customer_id": order["customer_id"],
            "items": order["items"],
            "total": order["total"],
        }),
        MessageAttributes={
            "event_type": {
                "DataType": "String",
                "StringValue": "ORDER_PLACED",
            },
            "priority": {
                "DataType": "String",
                "StringValue": "high" if order["total"] > 10000 else "normal",
            },
        },
    )

    return {"statusCode": 202, "body": json.dumps({"status": "accepted"})}

なぜSNS + SQSの組み合わせか:

  • SNS単体だと配信失敗時にメッセージが消失するリスクがある
  • SQSをバッファとして挟むことで最大14日間メッセージを保持でき、処理失敗時のリトライが可能
  • 各コンシューマーが独立した速度で処理できる（MLの推論パイプラインで前処理と推論の速度差を吸収するバッファと同じ発想）

制約条件: SNSの標準トピックではメッセージの順序保証がありません。順序が重要な場合はSNS FIFOトピック + SQS FIFOキューを使用しますが、スループットが毎秒300メッセージ（バッチ処理時3,000メッセージ）に制限されます。

パターン4: Sagaパターン（分散トランザクション）

複数のサービスにまたがるトランザクションを管理するパターンです。各ステップに補償アクション（ロールバック処理）を定義し、途中で失敗した場合に一貫性を保ちます。AWS Step Functionsが理想的なオーケストレーション基盤です（出典）。

以下はStep Functionsの状態マシン定義（ASL: Amazon States Language）の例です。

{
  "Comment": "注文処理Sagaパターン",
  "StartAt": "ReserveInventory",
  "States": {
    "ReserveInventory": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:reserve-inventory",
      "ResultPath": "$.inventory",
      "Catch": [{
        "ErrorEquals": ["States.ALL"],
        "Next": "OrderFailed",
        "ResultPath": "$.error"
      }],
      "Next": "ProcessPayment"
    },
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:process-payment",
      "ResultPath": "$.payment",
      "Catch": [{
        "ErrorEquals": ["States.ALL"],
        "Next": "CancelInventory",
        "ResultPath": "$.error"
      }],
      "Next": "ArrangeShipping"
    },
    "ArrangeShipping": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:arrange-shipping",
      "ResultPath": "$.shipping",
      "Catch": [{
        "ErrorEquals": ["States.ALL"],
        "Next": "RefundPayment",
        "ResultPath": "$.error"
      }],
      "Next": "OrderCompleted"
    },
    "CancelInventory": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:cancel-inventory",
      "Next": "OrderFailed"
    },
    "RefundPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:refund-payment",
      "Next": "CancelInventory"
    },
    "OrderCompleted": {
      "Type": "Succeed"
    },
    "OrderFailed": {
      "Type": "Fail",
      "Cause": "Order processing failed",
      "Error": "SagaRollbackCompleted"
    }
  }
}

よくある間違い: Sagaパターンでは各ステップの補償アクションを冪等（何度実行しても同じ結果になる）に設計する必要があります。Step Functionsのリトライ機能により補償アクション自体が複数回実行される可能性があるためです。たとえば「在庫を-1する」ではなく「予約ID: XXXの在庫予約をキャンセルする」という設計にします。

Step Functions Standard vs Express の使い分け:

特性 Standard Express
最大実行時間 1年 5分
実行モデル exactly-once at-least-once
最大スループット 2,000実行/秒 100,000遷移/秒
料金モデル 状態遷移ごとに課金 実行時間+回数で課金
適用場面 決済処理、注文ワークフロー IoTデータ処理、ストリーミング

Sagaパターンのような正確性が求められるワークフローにはStandard Workflowsを選択します。Express Workflowsはat-least-once実行モデルのため、各ステップが冪等であることが前提です。

パターン5: CQRSパターン（コマンドクエリ責務分離）

書き込み操作（Command）と読み取り操作（Query）を分離するパターンです。サーバーレスでは、書き込み用と読み取り用で異なるLambda関数とデータストアを使い分けます。

# write_handler.py - 書き込み側（Command）
# Python 3.12+ で動作確認
import json
import boto3
from datetime import datetime, timezone

dynamodb = boto3.resource("dynamodb")
eventbridge = boto3.client("events")

# 書き込み用テーブル（正規化されたデータ）
write_table = dynamodb.Table("Orders")


def handler(event, context):
    """注文データを書き込み、変更イベントを発行"""
    order = json.loads(event["body"])
    order["updated_at"] = datetime.now(timezone.utc).isoformat()

    # 書き込みテーブルに保存
    write_table.put_item(Item=order)

    # EventBridgeに変更イベントを発行
    # → 読み取り用ビューを非同期更新するLambdaがトリガーされる
    eventbridge.put_events(
        Entries=[{
            "Source": "orders.service",
            "DetailType": "OrderCreated",
            "Detail": json.dumps(order, default=str),
            "EventBusName": "default",
        }]
    )

    return {"statusCode": 201, "body": json.dumps(order, default=str)}

# read_handler.py - 読み取り側（Query）
# Python 3.12+ で動作確認
import json
import boto3

dynamodb = boto3.resource("dynamodb")

# 読み取り用テーブル（非正規化・クエリ最適化済み）
read_table = dynamodb.Table("OrdersReadModel")


def handler(event, context):
    """読み取り最適化されたビューからデータを取得"""
    customer_id = event["pathParameters"]["customer_id"]

    # GSI（Global Secondary Index）で高速クエリ
    result = read_table.query(
        IndexName="customer-index",
        KeyConditionExpression="customer_id = :cid",
        ExpressionAttributeValues={":cid": customer_id},
    )

    return {
        "statusCode": 200,
        "body": json.dumps(result["Items"], default=str),
    }

なぜCQRSを選ぶか:

  • 読み取りと書き込みのスケーリング要件が異なる場合に有効（MLの学習と推論のリソース分離と同じ発想）
  • 読み取り側は非正規化データを使うことでJOIN不要で高速に
  • EventBridgeを介した非同期同期により、書き込み側のレイテンシに影響を与えない

制約条件: CQRSでは読み取りビューの更新に遅延（Eventual Consistency）が発生します。書き込み直後に最新データを読み取る必要がある場合は、このパターンは適していません。

パターン6: Strangler Figパターン（段階的移行）

モノリシックなアプリケーションをサーバーレスへ段階的に移行するためのパターンです。API Gatewayをプロキシとして使い、リクエストを既存システムと新しいLambda関数に振り分けます（出典）。

トレードオフ: Strangler Figパターンは移行リスクを最小化しますが、移行期間中は2つのシステムを並行運用するため、運用コストが一時的に増加します。移行の粒度（APIエンドポイント単位 vs 機能単位）を事前に決定し、移行順序のロードマップを作成することが重要です。

パターン7: BFF（Backend for Frontend）パターン

フロントエンドの種類（Web、モバイル、IoT）ごとに専用のバックエンドLambda関数を用意するパターンです。各フロントエンドが必要とするデータ形式やAPIレスポンスをカスタマイズできます。

# bff_mobile.py - モバイル向けBFF
# Python 3.12+ で動作確認
import json
import boto3

lambda_client = boto3.client("lambda")


def handler(event, context):
    """モバイルアプリ向けに最適化されたレスポンスを返す"""
    user_id = event["pathParameters"]["user_id"]

    # 下流サービスからデータ取得
    # 注意: 直接Lambda呼び出しは同期チェーンのアンチパターンになりうる
    # 本来はDynamoDB等から直接取得する方が望ましい
    user_data = invoke_service("user-service", {"user_id": user_id})
    orders = invoke_service("order-service", {"user_id": user_id, "limit": 5})

    # モバイル向けに必要最小限のフィールドのみ返す
    # → 通信量を削減し、モバイルのバッテリー消費を抑える
    return {
        "statusCode": 200,
        "body": json.dumps({
            "user": {
                "name": user_data["name"],
                "avatar_url": user_data["avatar_url"],
            },
            "recent_orders": [
                {"id": o["id"], "status": o["status"], "total": o["total"]}
                for o in orders["items"]
            ],
        }),
    }


def invoke_service(function_name, payload):
    result = lambda_client.invoke(
        FunctionName=function_name,
        Payload=json.dumps(payload),
    )
    return json.loads(result["Payload"].read())

注意: 上記コードでは説明のためにLambda間の直接呼び出しを使用していますが、これは後述するアンチパターン（同期チェーン）に該当します。実運用ではAppSyncやDynamoDBから直接データを取得するか、API Gateway経由でアクセスしてください。

アンチパターンを回避する

設計パターンと同様に重要なのが、避けるべきアンチパターンの理解です。AWSの公式ブログでも繰り返し警告されている4つの代表的なアンチパターンを解説します（出典）。

アンチパターン1: 同期チェーン（Lambda呼びLambda）

Lambda関数が別のLambda関数を同期的に呼び出すパターンです。呼び出し元は応答を待つ間も課金が発生し、エラー時のリトライも複雑になります。

# bad_example.py - アンチパターン: 同期チェーン
def handler(event, context):
    # Lambda A → Lambda B → Lambda C と同期呼び出し
    # Lambda Aは B と C の実行完了まで待機（課金され続ける）
    result_b = lambda_client.invoke(FunctionName="function-b", Payload=payload)
    result_c = lambda_client.invoke(FunctionName="function-c", Payload=result_b)
    return result_c  # 合計コスト: A + B + C の実行時間

解決策: SQSキューで非同期化するか、Step Functionsでオーケストレーションする

# good_example.py - 改善: SQSで非同期化
import boto3
import json

sqs = boto3.client("sqs")
QUEUE_URL = "https://sqs.ap-northeast-1.amazonaws.com/123456789012/process-queue"


def handler(event, context):
    """処理結果をSQSに送信し、次のLambdaは非同期で処理"""
    result = process_data(event)

    sqs.send_message(
        QueueUrl=QUEUE_URL,
        MessageBody=json.dumps(result),
    )

    # すぐにレスポンスを返す（次の処理はSQSトリガーで別のLambdaが担当）
    return {"statusCode": 202, "body": json.dumps({"status": "accepted"})}

アンチパターン2: Lambda Monolith（モノリスLambda）

1つのLambda関数に複数のAPIエンドポイントや機能を詰め込むパターンです（出典）。

# bad_example.py - アンチパターン: 全APIを1関数に集約
def handler(event, context):
    path = event["path"]
    if path == "/users":
        return handle_users(event)
    elif path == "/orders":
        return handle_orders(event)
    elif path == "/payments":
        return handle_payments(event)
    elif path == "/notifications":
        return handle_notifications(event)
    # ... 数十のエンドポイントが続く

問題点:

  • デプロイパッケージが肥大化しコールドスタートが長くなる
  • 1エンドポイントの変更で全エンドポイントが再デプロイされる
  • IAM権限が過剰になる（全機能分の権限を1関数に付与）

解決策: 機能単位でLambda関数を分割し、API Gatewayのリソースごとに異なるLambda関数をマッピングする。ただし、**過度な分割（マイクロ関数化）**も別のアンチパターンです。ドメインの境界に沿った適切な粒度を見極めてください。

アンチパターン3: プロキシ関数

ビジネスロジックを持たず、リクエストをそのまま別のサービスに転送するだけのLambda関数です。

# bad_example.py - アンチパターン: 単なるプロキシ
def handler(event, context):
    # DynamoDBからデータを取得して返すだけ
    # → Lambda関数を挟む意味がない
    result = table.get_item(Key={"id": event["pathParameters"]["id"]})
    return {"statusCode": 200, "body": json.dumps(result["Item"])}

解決策: API Gatewayの「サービス統合」機能でLambdaを介さずにDynamoDBに直接アクセスする。コスト削減とレイテンシの改善が同時に得られます。

アンチパターン4: 過度な分割（ナノサービス）

ビジネスロジックの1ステップを1 Lambda関数に分割しすぎるパターンです。

問題点:

  • 関数間の依存関係が複雑化し、テストが困難になる
  • ドメインの凝集性が失われ、ビジネスロジックが分散する
  • デプロイ・監視の対象が爆発的に増える

解決策: Single Responsibility Principle（単一責任の原則）を関数レベルではなくサービスレベルで適用する。関連する操作（例: ユーザーのCRUD操作）は1つのLambda関数にまとめ、異なるドメイン（例: ユーザー管理と決済）は別の関数に分割します。

コールドスタートとコスト最適化を実践する

サーバーレスの運用において最も議論される2つのトピック、コールドスタート対策とコスト最適化の具体的な手法を解説します。

コールドスタート対策

コールドスタートとは、Lambda関数の実行環境が新規に作成される際に発生する初期化遅延のことです。2025年の計測データによると、Python 3.12ランタイムで約300〜500ms、Java 21ランタイムで800〜1500msのコールドスタートが報告されています（出典）。

対策の選択肢:

対策 効果 コスト 適用場面
SnapStart コールドスタート最大90%削減 無料 Java 11+, Python 3.12+, .NET 8
Provisioned Concurrency コールドスタート完全排除 $15〜30/月（512MB×10環境） 低レイテンシ要求のAPI
軽量ランタイム採用 50〜100msのコールドスタート 無料（開発コスト増） Rust, Go
依存関係の最小化 30〜50%の起動時間削減 無料 全ランタイム共通

注意: 2025年8月にAWSはINIT phase billingを変更し、一部のワークロードではコールドスタートのコストが100万呼び出しあたり$0.80から$17.80に増加しました（出典）。SnapStartやProvisioned Concurrencyの採用をより積極的に検討する理由が増えています。

コスト最適化の具体的手法

Lambda関数の料金は $0.20/100万リクエスト + $0.0000166667/GB秒 で計算されます（出典）。

メモリサイジングの逆説: Lambdaではメモリ割り当てを増やすとCPUパワーも比例して増加します。そのため、コンピュート集約的な処理ではメモリを増やした方が総コストが下がる場合があります。

# cost_optimizer.py - メモリ設定ごとのコスト比較スクリプト
# Python 3.12+ で動作確認
# 実際のベンチマークデータに基づいて最適なメモリ設定を見つける

def calculate_lambda_cost(memory_mb, duration_ms, invocations):
    """Lambda関数のコストを計算"""
    gb_seconds = (memory_mb / 1024) * (duration_ms / 1000)
    compute_cost = gb_seconds * 0.0000166667 * invocations
    request_cost = invocations * 0.0000002  # $0.20 per 1M
    return compute_cost + request_cost


# メモリを増やすと実行時間が短縮される例
configs = [
    {"memory_mb": 128, "duration_ms": 3000, "label": "128MB / 3000ms"},
    {"memory_mb": 256, "duration_ms": 1500, "label": "256MB / 1500ms"},
    {"memory_mb": 512, "duration_ms": 800, "label": "512MB / 800ms"},
    {"memory_mb": 1024, "duration_ms": 450, "label": "1024MB / 450ms"},
]

monthly_invocations = 1_000_000

for config in configs:
    cost = calculate_lambda_cost(
        config["memory_mb"],
        config["duration_ms"],
        monthly_invocations,
    )
    print(f"{config['label']}: ${cost:.2f}/月")
    # 出力例:
    # 128MB / 3000ms: $6.45/月
    # 256MB / 1500ms: $6.45/月
    # 512MB / 800ms:  $6.87/月
    # 1024MB / 450ms: $7.70/月
    # → この例ではメモリを増やしてもコスト差は小さいが、
    #   レイテンシは3000ms → 450msに大幅改善

コスト最適化のチェックリスト:

  1. AWS Lambda Power Tuningツールでメモリ設定を最適化する
  2. Provisioned Concurrencyは本当に必要なAPIにのみ適用する
  3. 安定したワークロードにはCompute Savings Plansで最大17%割引を適用する
  4. コスト配分タグ（Cost Center, Environment, Team）をCI/CDで強制する

よくある問題と解決方法

問題 原因 解決方法
Lambda関数が15分でタイムアウト 処理時間が長すぎる Step Functionsで分割するか、ECS/Fargateに移行
DynamoDB ProvisionedThroughputExceeded 書き込みキャパシティ不足 オンデマンドモードに変更、またはSQSでバッファリング
S3イベントの無限ループ 処理結果を同じバケット・プレフィックスに保存 出力先バケットを分離、またはプレフィックスフィルタ設定
API Gateway 29秒タイムアウト Lambda処理が遅い 非同期パターンに変更（202 Accepted + ポーリング）
コールドスタートでレイテンシ急増 関数の未使用時間が長い SnapStart有効化、またはProvisioned Concurrency設定
Lambda同時実行数の上限到達 デフォルト1,000の制限 AWS Supportに上限緩和を申請、またはSQSでスロットリング

まとめと次のステップ

まとめ:

  • サーバーレス設計パターンは大きく4カテゴリ（リクエスト処理、イベント駆動、ワークフロー、移行・統合）に分類される
  • イベント駆動パターンとFan-outパターンがサーバーレスの基本であり、同期チェーンを避けて非同期処理を優先する
  • SagaパターンはStep Functions Standardワークフローで実装し、各ステップの冪等性を保証する
  • コールドスタートはSnapStart（無料）で最大90%削減でき、メモリの適切なサイジングで20〜30%のコスト削減が可能
  • アンチパターン（同期チェーン、Lambda Monolith、プロキシ関数、過度な分割）の回避がシステムの健全性に直結する

次にやるべきこと:

  • AWS Serverless Patterns Collectionで自分のユースケースに合ったパターンを探す
  • AWS Lambda Power Tuningでメモリ設定を最適化する
  • 小規模なAPIから始めてAPIゲートウェイパターンを実装し、段階的にイベント駆動パターンに移行する

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

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?