こちらの記事はAWS Lambda 実践入門 Advent Calendar 2025 23日目の記事になります。

構築、デプロイ、セキュリティ、性能最適化……と進んできましたが、「作ったものは、いつか必ず壊れます」。
Day23 では、本番稼働後に我々が枕を高くして寝るための「運用設計（監視と復旧）」について、SRE の原則を Lambda に適用する形で解説します。

1. まず結論：運用設計のゴール

やみくもにアラートメールを飛ばすのは運用ではありません。運用設計には明確なゴール（三位一体）があります。

SLO（Service Level Objective）
- サービスの「合格ライン（品質）」を数値で宣言する。
- 例：「99.9% 成功する」「3秒以内に終わる」
アラート
- SLO から逸脱した（または逸脱の予兆がある）時だけ、適切な温度感で通知する。
- 「CPU が跳ねたけどユーザー影響はない」なら、深夜に叩き起こしてはいけない。
Runbook（手順書）
- 通知を受けた人が、寝起きでも迷わず復旧できる手順書を用意する。
- **「アラートと Runbook は 1:1 で対になる」**のが鉄則です。

CloudWatch の Application Signals は、アカウントで有効化し（必要な計測設定が揃っている前提で）、メトリクスとトレースを収集してアプリケーションの状態を俯瞰できる仕組みです。SLO（可用性・レイテンシ）もここに載せて運用できます。(AWS ドキュメント)

2. SLO 設計：Lambda を“サービス”として定義する

Lambda は用途によって「何が健全か」の定義が全く異なります。初心者が迷わないための定義パターンを紹介します。

2-1. 対象別の切り方

パターン	監視すべき重要指標（SLI）	備考
API 系	可用性（Availability）レイテンシ（Latency p95/p99）	ユーザーが待っている時間が全て。同期呼び出し。
非同期系	処理遅延（Age / Queue Depth）＋失敗検知（DLQ / `DestinationDeliveryFailures`）	「いつか終わればいい」が「いつまでも終わらない」はNG。
バッチ系	完了時刻ジョブ成功率	指定時刻までに終わったかどうかが最重要。

2-2. SLO の設定例（テンプレート）

最初から「100%」を目指してはいけません。**「現状の実力値 → 改善目標」**の順で設定します。

API 可用性 SLO：月次 99.9%（ローリング 30 日）
API レイテンシ SLO：p95 < 500ms を 99% 達成
非同期遅延 SLO：キュー滞留（Age）< 5 分を 99% 達成
失敗 SLO（非同期）：DLQ 送付 0、または DestinationDeliveryFailures=0

3. アラート設計：ノイズを減らし、判断を増やす

3-1. 通知の原則

アラートには「緊急度」というタグ付けが必要です。

Page（即時対応・電話/PagerDuty）
- 定義：ユーザー影響が現在進行形で出ている。SLO のエラーバジェットが急速に燃えている。
- アクション：叩き起こされてでも、今すぐ止血する。
Ticket（翌営業日対応・Slack/Jira）
- 定義：ユーザー影響はないが、予兆がある（スロットル微増、コスト異常、DLQ チラつき）。
- アクション：原因を調査し、恒久対応する。

3-2. Lambda で“まず押さえるべき”代表メトリクス

CloudWatch Metrics で最低限監視すべき項目です。これらは後述の Runbook に直結します。

4. Runbook 実践：アラートに“必ず”手順書を紐づける

「アラートが鳴った、さてどうしよう」とログを漁り始めるのは敗北です。
アラートの Description には 「この Runbook を見る」という URL が貼ってある状態にしてください。

以下に、現場でそのまま使える「3大トラブル対応 Runbook」を公開します。これまでの連載（Day14, Day19, Day20, Day21）の集大成です。

Runbook 1：Timeout（実行時間超過）対応

API の 504 エラーや、非同期処理の詰まりを引き起こす代表的な要因です。

A. まず確認する（3分トリアージ）

直近デプロイの有無（Day14：Deploy Marker）
- 直近 60 分以内にコードや環境変数が変わっていれば、即ロールバック（Day13）。
メトリクス相関（Day19：性能）
- Duration と同時に MaxMemoryUsed が張り付いていないか？（メモリ不足 → CPU不足）
- Throttles が出ていないか？

B. 暫定復旧（安全な順）

ロールバック：原因調査より先に、前のバージョンに戻してサービスを復旧させる。
メモリを上げる：Lambda はメモリ＝CPU パワーです。1024MB → 2048MB に上げるだけで改善するケースも多いです（まず試す価値が高い）。
タイムアウト値の延長：これは「延命措置」です。根本解決にはならないため、チケットを切って後日 Timeout ログの直前を調査します。

C. 恒久対応

重い処理（PDF 生成など）の並列化・非同期化（Day20：最適化）。
VPC 内リソース（DB 等）への接続遅延解消（Day21：VPC）。

Runbook 2：DLQ 増加（非同期・キュー系の失敗）対応

非同期処理（SQS/SNS/EventBridge）が失敗し、Dead Letter Queue（DLQ）にメッセージが溜まっている状態です。

A. まず確認する（3分トリアージ）

DLQ の中身を見る
- これが全てです。1 件メッセージを取得し、body を確認します。
失敗の分類
- 恒久エラー：バグ、スキーマ不整合、データ欠損 → 再試行しても無駄。
- 一時エラー：DB タイムアウト、API スロットリング → 時間を置けば成功する。

B. 暫定復旧

被害拡大防止：上流（イベント流入）を止められるなら止める。
隔離：DLQ のメッセージを「調査用キュー」や S3 に退避させ、メイン処理への影響を切り離す。
再処理（Redrive）
- 一時エラーなら、AWS コンソールの「DLQ Redrive」機能などでソースキューへ戻す。
- 恒久エラーなら、修正パッチを当ててから戻すか、データを修正して投入する。

C. 恒久対応

「腐ったメッセージ」を捨てるか隔離するロジックの実装。
冪等性（Idempotency）の担保（Day3：イベント駆動）。

Runbook 3：VPC 内疎通不良（タイムアウト/接続エラー）対応

「何も変えていないのに急に繋がらなくなった」というケースの代表格です。

A. まず確認する（3分トリアージ）

接続先はどこか？
- インターネット（NAT Gateway は生きているか？）
- AWS サービス（VPC Endpoint はあるか？）
- 社内リソース（Direct Connect / VPN は正常か？）
変更管理（Day14）
- セキュリティグループ、ルートテーブル、ネットワーク ACL の変更履歴を確認。

B. 暫定復旧

ロールバック：ネットワーク設定を含む IaC の変更があれば戻す。
VPC 外への退避：もし VPC が必須でない処理（S3 操作だけなど）なら、一時的に VPC 設定を外して復旧させる（Day21：VPC（NAT-less / Endpoint））。

C. 恒久対応

接続先台帳の作成（どの関数がどこに繋ぐか）。
VPC Endpoint の漏れがないか棚卸し（Day21）。

5. 全体像の整理

運用はサイクルです。一度決めたら終わりではなく、障害が起きるたびに Runbook を太らせ、SLO を見直します。

まとめ

SLO で「守るべきライン」を決める。
アラートは「アクションが必要な時」だけ鳴らす。
Runbook なきアラートはただの騒音。必ずセットで作る。