配信予約処理で盛大にやらかした件

　前回の記事でYouTube Live配信スケジュール作成を自動化してみました。

で、本日(これ書いてるときは日付またいでますが)5/1 9:00AMに初回の処理が流れたので結果を見てみます。
※[]で囲っているところはマスクしてる箇所です。

悪夢のタイムアウトとリトライ

　まずはCloudWatchのログを確認。

タイムアウトしてますね！しかもこれがAWSの標準リトライ仕様で3発起きています。
「返事がないから失敗したんだな」とAWSが良かれと思って再実行を繰り返した結果、Live配信スケジュールを見てみると……。

作成はされてますね、3回ジョブが走って！

予約配信155個！

原因の分析：なぜ落ちたのか？

　以前、テストで正常終了したときのログと見比べてみます。

正常時で105秒。デフォルトの2分（120秒）設定では、ネットワークのちょっとした遅延でアウトになるギリギリのラインだったんですね。メモリもMAX128MBに対して95MB使用と、かなりカツカツでした。

対策：Lambdaの設定を見直す

　このままでは毎月爆撃機が飛んでしまうので、設定を「鉄壁」モードに変更します。

とりあえずタイムアウト3分、メモリ512MB、リトライ0回で再設定してみましょう！

Lambdaコンソールの「設定」タブ＞「一般設定」から編集を開始します。

前述のとおりメモリを512MB、タイムアウトを3分にします。

一般設定の更新完了。これで「余裕」が生まれました。

次に、二次被害を防ぐための「再試行回数」の変更です。これをしておかないと、万が一失敗したときにまた連打されます。

「設定」タブ＞「非同期呼び出し」を選択します。

再試行回数を「0」に設定。失敗したときは、勝手に動かず止まっていただきましょう。

安全装置の設定完了です。

リベンジ：テスト実行

　修正した環境で、改めてテストを回してみます。

コードタブから「Test」を叩きます。

キャプション：ステータスコード200！今度はしっかり最後まで走りきりました。

最終的な完走ログがこちら。

実行時間は147秒。以前の120秒設定では絶対に到達できなかった領域です。 メモリ消費量は98MBと大きく変わりませんが、128MBでガベージコレクションが頻発して処理が停滞するよりは、512MBの広大な土地でゆったり動いてもらう方が安定感がありますね。

まとめ：自動化の先にある「運用の洗礼」と次なる一歩

　今回のトラブルシューティングを経て痛感したのは、「テスト環境の成功は、本番の安定を保証しない」というエンジニアリングの鉄則でした。128MBというリソース制限下での「120秒の壁」は、ネットワークの僅かな揺らぎで牙を剥き、結果として155個の重複予約という「API爆撃」を引き起こしました。

しかし、メモリを512MBへ増強し、再試行回数を0に設定するという「守り」を固めたことで、147秒という実行時間をかけて確実に完走させる安定性を手に入れることができました。

さて、これで配信枠の作成は安泰ですが、今回の件で「何が起きているか外から見える化すること」の重要性を再認識しました。次は、お仕事でも馴染みのある Datadog へCloudWatch Logsを転送する設定が必要になりそうです。

仕組みを一つ作るたびに、やりたいこと（やらねばならぬこと）が次々と溢れ出してくる……。これぞまさに、エンジニアの「終わりのない旅」ですね。

2026/5/4追記：

　ストリームキーの指定ができていない、自動開始/自動停止がオフになっているで配信枠は用意されてても配信が自動開始されませんでした！
ダメじゃん！