1つのバケットに所有者が2人いると、最後にapplyした側が勝つ
S3のlifecycleルールを1つ追加したらterraform applyが失敗した。原因は、同じバケットのlifecycle設定を2つのリソースがそれぞれ所有する構造。S3のlifecycleはルール単位ではなくドキュメント単位なので、最後の勝者が相手のルールを静かに消す。
- #インフラ
- #Terraform
- #S3
- #AWS
- #障害対応
小さなアプリを自分の手で作りながらぶつかった技術・道具・試行錯誤の記録。
S3のlifecycleルールを1つ追加したらterraform applyが失敗した。原因は、同じバケットのlifecycle設定を2つのリソースがそれぞれ所有する構造。S3のlifecycleはルール単位ではなくドキュメント単位なので、最後の勝者が相手のルールを静かに消す。
キューにジョブを入れるコードが初日から毎回失敗していた。エラーは握りつぶされ、テストはモックのおかげで緑のまま。コロン一文字が3つの機能を静かに殺した話。
証明書ピンニングをreport-onlyで有効にした途端、SentryにSPKIミスマッチが74件たまった。MITM攻撃に見えたし、AIは「GoogleはHTTPSを傍受しない」としてストア審査の可能性をきっぱり退けた。本番APIのログから取り出した実際のIPが、その推定を覆した。
1日のうちにCRITICALの通知が4つたまった。504、Prisma P2028、管理画面の500、そして「DATABASEサービスダウン」。RDSの指標をまず開いたら、21時間ずっとCPU最大19.7%で無事だった。遅かったのはDBではなく、大西洋を25回渡る往復であり、「ダウン」の通知はヘルスチェックが自分で作り出したものだった。
エージェントのセッションを並列に立ち上げれば生産性が倍になると思っていた。実際にはブランチの乗っ取り、他人のブランチに載ったコミット、reflogで拾い上げた孤児コミット、同じ機能の二重実装まで、一週間のうちに実際の事故が立て続けに起きた。一つのチェックアウトを共有する並列エージェントが生む事故の類型学と、それを経て立てたルール。
AIコーディングエージェントはテストを回していないのに「テスト通過」と報告する。嘘ではなく構造の問題だ。報告を検査に変えるオープンソースのゲートprove-itを作りながら学んだこと - そして自作の5行フックが静かに失敗する4つの形。
同じモデルに自分のコードをレビューさせると、自分の出した結論をまた承認する。ほぼすべてのコードをAIと一緒に書く1人開発者が、一つのAIの仕事を別のAIに「反論してみろ」とぶつけるクロスチェックのループを常設パイプラインに固めた話。セルフレビューが見逃したバグを3ラウンド連続で捕まえた実例とプロンプト設計。
stagingで毎日鳴っていたGoogle Playの404アラート。発生源を止めれば静かになるが、それと失敗モードを直すことは別の問題だった。404は再試行しても意味のない恒久的なエラーなのに、5xxと一緒くたにされて再試行されていたという話。
AIコーディングエージェントは、仕事を終えていなくても終わったと言う。テストを走らせずに通ったと言い、再現もせずに直したと言う。ほぼすべてのコードをAIと一緒に書く1人開発者が、完了を言葉ではなく証拠でしか認めないようにした検証ゲートの話。
デプロイのたびにSentryにPrismaのP2028エラーが落ちていた。終了順序を直そうと踏み込んだら、NestJSのenableShutdownHooksとgraceful shutdownライブラリの両方がSIGTERMを掴んでいて、終了フックが毎回二重に実行されていたことが分かった話。
AWSの請求書が2か月連続で予算を超えた。削れるリソースを探したが、本当のレバーは「どれだけ使うか」ではなく「どう買うか」だった。SpotとGravitonがなぜ安いのか、そして無駄に見えて実は切ってはいけないコスト(RDS Proxy)まで - 請求書の数字ひとつひとつに宿る「理由」についての話。
CMSなしでマークダウンファイルだけで動くブログをNext.js 16 App Routerで作った過程。フォルダ構成、MDX設定、SEOまで実際のコードの流れでまとめました。
複数のアプリとWebを1つのリポジトリで管理するTurborepoモノレポの構成法。共通設定の共有、キャッシュでビルドを節約、アプリごとのデプロイまで実践目線でまとめました。
自宅のミニPC 1台で複数のWebサービスを安全に公開する方法。ポート開放なしでCloudflare TunnelでHTTPSをつなぎ、Docker Composeで運用します。