AWS Lambda実践ガイド：コスト削減とパフォーマンス最適化の全技術

TL;DR

• AWS Lambdaで従来のEC2比90%のコスト削減を実現
• コールドスタートは適切な設定で100ms以下に抑制可能
• メモリ設定の最適化でコストパフォーマンスが大幅に向上
• Provisioned Concurrencyで予測可能なレスポンスタイムを実現

はじめに：なぜ今Lambdaなのか

「サーバー管理から解放されたい」

エンジニアなら誰もが一度は思ったことがあるはずです。深夜のサーバーダウン対応、パッチ適用のための休日出勤、突発的なトラフィック増加への対応。これらすべてから解放される方法があります。それがAWS Lambdaです。

私たちのチームでは、2023年にEC2ベースのAPIサーバーをLambdaに移行しました。結果として、月額15万円だったインフラコストが1.5万円に削減。運用工数もほぼゼロになりました。

本記事では、その移行で得た知見と、Lambdaを本番環境で使いこなすためのテクニックを包み隠さずお伝えします。

AWS Lambdaの仕組みを理解する

実行モデル

Lambdaは「イベント駆動型」の実行モデルを採用しています。リクエストが来たときだけ関数が起動し、処理が終わると停止する。この仕組みにより、待機時間の課金がなくなります。

リクエスト → Lambda起動 → 処理実行 → レスポンス → Lambda停止
              ↑                              ↓
              └──── 次のリクエストで再起動 ←────┘

課金モデル

Lambdaの課金は2つの要素で決まります：

1. リクエスト数: 100万リクエストあたり$0.20
2. 実行時間: GB-秒あたり$0.0000166667

例えば、128MBメモリで平均200ms実行、月間100万リクエストの場合：

リクエスト料金: 100万 × $0.20/100万 = $0.20
実行時間料金: 100万 × 0.2秒 × 0.125GB × $0.0000166667 = $0.42
合計: $0.62/月（約90円）

同等のEC2（t3.micro）は月額約$8.50。実に13倍以上のコスト差があります。

Lambda関数の実装ベストプラクティス

基本構造

効率的なLambda関数の基本構造を示します：

// 初期化処理はハンドラー外で行う（コールドスタート時のみ実行）
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB.DocumentClient();

// DB接続などの重い処理も外に出す
let dbConnection = null;

const initializeConnection = async () => {
  if (!dbConnection) {
    dbConnection = await createDatabaseConnection();
  }
  return dbConnection;
};

exports.handler = async (event, context) => {
  // コンテキストの再利用を有効化
  context.callbackWaitsForEmptyEventLoop = false;

  try {
    // 接続の再利用
    const db = await initializeConnection();

    // ビジネスロジック
    const result = await processRequest(event, db);

    return {
      statusCode: 200,
      headers: {
        'Content-Type': 'application/json',
        'Access-Control-Allow-Origin': '*'
      },
      body: JSON.stringify(result)
    };
  } catch (error) {
    console.error('Error:', error);
    return {
      statusCode: 500,
      body: JSON.stringify({ error: 'Internal Server Error' })
    };
  }
};

エラーハンドリングの設計

本番環境では、適切なエラーハンドリングが不可欠です：

class LambdaError extends Error {
  constructor(message, statusCode, errorCode) {
    super(message);
    this.statusCode = statusCode;
    this.errorCode = errorCode;
  }
}

const errorHandler = (error) => {
  // 既知のエラー
  if (error instanceof LambdaError) {
    return {
      statusCode: error.statusCode,
      body: JSON.stringify({
        error: error.message,
        code: error.errorCode
      })
    };
  }

  // 未知のエラー（詳細はログに出力、クライアントには汎用メッセージ）
  console.error('Unexpected error:', error);
  return {
    statusCode: 500,
    body: JSON.stringify({
      error: 'Internal Server Error',
      code: 'INTERNAL_ERROR'
    })
  };
};

コールドスタート対策の決定版

コールドスタートはLambdaの最大の課題です。しかし、適切な対策で実用上問題ないレベルまで抑制できます。

コールドスタートが発生する条件

1. 関数が初めて呼び出されたとき
2. 一定時間（約15分）アイドル状態が続いた後
3. 同時実行数が増加し、新しいインスタンスが必要になったとき
4. コードをデプロイした直後

対策1: パッケージサイズの最小化

# 開発依存関係を除外
npm prune --production

# 不要ファイルを除外（.lambdaignore）
node_modules/**/*.md
node_modules/**/*.ts
node_modules/**/test/**

効果: パッケージサイズを50MB→15MBに削減し、コールドスタートが800ms→300msに改善。

対策2: Provisioned Concurrency

予測可能なトラフィックがある場合、Provisioned Concurrencyが有効です：

# serverless.yml
functions:
  api:
    handler: handler.main
    provisionedConcurrency: 5  # 常に5インスタンスをウォーム状態に

コスト: 約$0.015/時間/インスタンス。24時間で$0.36、月額で約$11/インスタンス。

対策3: ウォームアップ戦略

定期的にLambdaを呼び出してウォーム状態を維持：

// warmup.js - CloudWatch Eventsで5分ごとに実行
exports.handler = async (event) => {
  const lambda = new AWS.Lambda();

  const functions = [
    'production-api-users',
    'production-api-orders',
    'production-api-products'
  ];

  await Promise.all(functions.map(name =>
    lambda.invoke({
      FunctionName: name,
      InvocationType: 'Event',  // 非同期呼び出し
      Payload: JSON.stringify({ warmup: true })
    }).promise()
  ));
};

関数側でウォームアップリクエストを処理：

exports.handler = async (event) => {
  // ウォームアップリクエストは即座に返す
  if (event.warmup) {
    console.log('Warmup request');
    return { statusCode: 200, body: 'Warmed up' };
  }

  // 通常の処理
  // ...
};

メモリ設定の最適化

Lambdaのメモリ設定は、パフォーマンスとコストに直結します。

CPU割り当ての仕組み

メモリに比例してCPU能力が割り当てられます：

最適なメモリサイズの見つけ方

AWS Lambda Power Tuningを使用：

# SAR（Serverless Application Repository）からデプロイ
aws serverlessrepo create-cloud-formation-change-set \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --stack-name lambda-power-tuning

実行結果の例：

{
  "power": 512,
  "cost": 0.0000042,
  "duration": 215,
  "stateMachine": {
    "executionCost": 0.00045,
    "lambdaCost": 0.0042,
    "visualization": "https://lambda-power-tuning.show/..."
  }
}

私たちのケースでは、256MB→512MBに増やすことで：

• 実行時間: 450ms → 180ms（60%短縮）
• コスト: $0.0000047 → $0.0000030（36%削減）

メモリを増やすと実行時間が短縮され、結果的にコストも下がるケースが多いです。

実践的なユースケースと実装

ユースケース1: REST API

API Gatewayと組み合わせた典型的な実装：

// api/users.js
const { DynamoDB } = require('@aws-sdk/client-dynamodb');
const { DynamoDBDocument } = require('@aws-sdk/lib-dynamodb');

const client = new DynamoDB({});
const docClient = DynamoDBDocument.from(client);

exports.handler = async (event) => {
  const { httpMethod, pathParameters, body } = event;

  switch (httpMethod) {
    case 'GET':
      if (pathParameters?.id) {
        return await getUser(pathParameters.id);
      }
      return await listUsers();

    case 'POST':
      return await createUser(JSON.parse(body));

    case 'PUT':
      return await updateUser(pathParameters.id, JSON.parse(body));

    case 'DELETE':
      return await deleteUser(pathParameters.id);

    default:
      return { statusCode: 405, body: 'Method Not Allowed' };
  }
};

async function getUser(id) {
  const result = await docClient.get({
    TableName: process.env.USERS_TABLE,
    Key: { id }
  });

  if (!result.Item) {
    return { statusCode: 404, body: JSON.stringify({ error: 'User not found' }) };
  }

  return { statusCode: 200, body: JSON.stringify(result.Item) };
}

ユースケース2: 画像処理パイプライン

S3トリガーを使った自動画像処理：

const sharp = require('sharp');
const { S3Client, GetObjectCommand, PutObjectCommand } = require('@aws-sdk/client-s3');

const s3 = new S3Client({});

exports.handler = async (event) => {
  for (const record of event.Records) {
    const bucket = record.s3.bucket.name;
    const key = decodeURIComponent(record.s3.object.key);

    // オリジナル画像を取得
    const { Body } = await s3.send(new GetObjectCommand({ Bucket: bucket, Key: key }));
    const imageBuffer = await streamToBuffer(Body);

    // 各サイズでリサイズ
    const sizes = [
      { name: 'thumbnail', width: 150, height: 150 },
      { name: 'medium', width: 800, height: 600 },
      { name: 'large', width: 1920, height: 1080 }
    ];

    await Promise.all(sizes.map(async (size) => {
      const resized = await sharp(imageBuffer)
        .resize(size.width, size.height, { fit: 'inside' })
        .webp({ quality: 80 })
        .toBuffer();

      const newKey = key.replace('uploads/', `processed/${size.name}/`).replace(/\.[^.]+$/, '.webp');

      await s3.send(new PutObjectCommand({
        Bucket: bucket,
        Key: newKey,
        Body: resized,
        ContentType: 'image/webp'
      }));
    }));
  }

  return { statusCode: 200, body: 'Processing complete' };
};

ユースケース3: スケジュールバッチ処理

CloudWatch Eventsを使った定期実行：

// 毎日深夜に実行されるレポート生成
exports.handler = async (event) => {
  const yesterday = new Date();
  yesterday.setDate(yesterday.getDate() - 1);

  // 前日のデータを集計
  const metrics = await aggregateMetrics(yesterday);

  // レポートを生成
  const report = generateReport(metrics);

  // S3に保存
  await saveToS3(report, `reports/${formatDate(yesterday)}.json`);

  // Slackに通知
  await notifySlack({
    channel: '#daily-reports',
    text: `📊 Daily report generated: ${metrics.totalOrders} orders, $${metrics.revenue} revenue`
  });

  return { success: true };
};

VPC接続とセキュリティ

VPC Lambda の設定

RDSやElastiCacheにアクセスする場合、VPC内でLambdaを実行する必要があります：

# serverless.yml
provider:
  vpc:
    securityGroupIds:
      - sg-xxxxxxxxx
    subnetIds:
      - subnet-xxxxxxxx
      - subnet-yyyyyyyy  # 複数AZに配置

functions:
  api:
    handler: handler.main
    vpc:
      securityGroupIds:
        - ${self:provider.vpc.securityGroupIds}
      subnetIds:
        - ${self:provider.vpc.subnetIds}

VPC Lambdaのコールドスタート対策

VPC Lambdaはコールドスタートが長くなる傾向がありましたが、2019年の改善で大幅に短縮されました。それでも以下の対策が有効です：

1. Provisioned Concurrencyの利用（前述）
2. RDS Proxyの使用: 接続管理を効率化

const { Signer } = require('@aws-sdk/rds-signer');
const mysql = require('mysql2/promise');

const signer = new Signer({
  hostname: process.env.RDS_PROXY_ENDPOINT,
  port: 3306,
  username: process.env.DB_USER
});

let connection;

async function getConnection() {
  if (!connection) {
    const token = await signer.getAuthToken();
    connection = await mysql.createConnection({
      host: process.env.RDS_PROXY_ENDPOINT,
      user: process.env.DB_USER,
      password: token,
      database: process.env.DB_NAME,
      ssl: { rejectUnauthorized: true }
    });
  }
  return connection;
}

モニタリングとデバッグ

CloudWatch Logsの活用

構造化ログでデバッグ効率を上げる：

const log = (level, message, data = {}) => {
  console.log(JSON.stringify({
    level,
    message,
    timestamp: new Date().toISOString(),
    requestId: global.requestId,
    ...data
  }));
};

exports.handler = async (event, context) => {
  global.requestId = context.awsRequestId;

  log('INFO', 'Request received', {
    path: event.path,
    method: event.httpMethod
  });

  try {
    const result = await processRequest(event);
    log('INFO', 'Request completed', {
      statusCode: 200,
      duration: Date.now() - startTime
    });
    return result;
  } catch (error) {
    log('ERROR', 'Request failed', {
      error: error.message,
      stack: error.stack
    });
    throw error;
  }
};

CloudWatch Insights でのクエリ例

-- エラー率の確認
fields @timestamp, @message
| filter level = 'ERROR'
| stats count() as errors by bin(1h)

-- 遅いリクエストの特定
fields @timestamp, duration, path
| filter duration > 1000
| sort duration desc
| limit 20

-- コールドスタートの検出
fields @timestamp, @duration, @billedDuration
| filter @initDuration > 0
| stats count() as coldStarts, avg(@initDuration) as avgInitTime by bin(1h)

X-Ray によるトレーシング

const AWSXRay = require('aws-xray-sdk-core');
const AWS = AWSXRay.captureAWS(require('aws-sdk'));

exports.handler = async (event) => {
  const segment = AWSXRay.getSegment();

  // カスタムサブセグメント
  const subsegment = segment.addNewSubsegment('ProcessOrder');
  try {
    const result = await processOrder(event);
    subsegment.close();
    return result;
  } catch (error) {
    subsegment.addError(error);
    subsegment.close();
    throw error;
  }
};

コスト最適化の実践戦略

1. 適切なタイムアウト設定

デフォルトの3秒は短すぎることが多いですが、無制限に長くすると障害時のコストが膨らみます：

functions:
  api:
    timeout: 10  # APIは10秒
  batch:
    timeout: 900  # バッチは15分（最大）

2. 不要な実行の削減

条件チェックを最初に行い、不要な処理を避ける：

exports.handler = async (event) => {
  // 早期リターンで不要な処理を避ける
  if (!event.body) {
    return { statusCode: 400, body: 'Bad Request' };
  }

  const data = JSON.parse(event.body);
  if (!data.userId) {
    return { statusCode: 400, body: 'userId is required' };
  }

  // ここからが本処理（課金される時間を最小化）
  // ...
};

3. Graviton2（ARM）の活用

ARM アーキテクチャで20%のコスト削減：

provider:
  architecture: arm64  # x86_64 から変更

注意: 一部のネイティブモジュールは対応が必要です。

まとめ：Lambda導入の判断基準

AWS Lambdaが適しているケース：

• イベント駆動型処理: Webhook、ファイル処理、通知
• 可変トラフィック: アクセス数が大きく変動するAPI
• バッチ処理: 定期的なデータ処理、レポート生成
• マイクロサービス: 小さく独立した機能の実装

Lambdaが適さないケース：

• 長時間実行: 15分を超える処理
• ステートフルな処理: WebSocket接続の維持
• 高頻度・定常負荷: 常にリクエストがある場合（EC2の方が安い）
• 特殊なランタイム: サポートされていない言語やバージョン

サーバーレスは銀の弾丸ではありません。しかし、適切なユースケースで使えば、運用コストと管理工数を劇的に削減できます。まずは小さなプロジェクトで試してみてください。

リソース

• AWS Lambda 公式ドキュメント
• Serverless Framework
• AWS SAM（Serverless Application Model）
• Lambda Power Tuning

---

Lambdaの導入でお困りの方は、お気軽にご相談ください。