こちらの記事は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 に直結します。
-
Errors/Invocations：エラー率（Errors ÷ Invocations）(AWS ドキュメント) -
Duration（p95/p99）：平均値ではなくパーセンタイルを見る (AWS ドキュメント) -
Throttles：同時実行数不足。ユーザー影響に直結しやすい (AWS ドキュメント) -
ConcurrentExecutions：上限（Quota）や Reserved Concurrency に迫っているか (AWS ドキュメント) -
AsyncEventAge/IteratorAge：非同期/ストリーム処理の「遅延」の正体 (AWS ドキュメント) -
DeadLetterErrors/DestinationDeliveryFailures：非同期処理の最終的な「死」 (AWS ドキュメント)
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. 恒久対応
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 なきアラートはただの騒音。必ずセットで作る。