Vercelがビルド基盤DBをDynamoDBへ無停止移行

米Vercelは2026年8月12日、全ビルドの起点となる待機コンテナ群「ビルドウォームプール」の状態管理を、RedisからAWSのDynamoDBへ移行した経緯を技術ブログで公開しました。移行は2月に始まり4月に完了し、稼働を止めないまま本番トラフィック下でフラグ付きの5段階に分けて進められました。狙いは、失われると復旧できない課金用マッピングを永続ストアへ移すことでした。

ウォームプールは、待機中コンテナの状態と認証用トークン、そして実行中のビルドと課金対象デプロイを結ぶ対応表をRedisに保持していました。トークンや状態は失っても約10分で再構築できますが、課金の対応表はほかにどこにも記録がなく、失えばそのビルドは永久に請求できません。重要度の上がった状態を、一時キャッシュとして運用するストアに置き続けるリスクは無視できなくなっていました。

設計にあたってはRedisのデータ構造をそのまま持ち込まず、コードが実際に要求する8つのアクセスパターンを洗い出すところから始めています。コンテナIDをソートキーに据えて1レコードへ集約し、トークンはハッシュ化した属性として保存、ステータス集計には期限を考慮したインデックスを追加しました。テーブルを読んでも使える認証情報が手に入らない構造です。

切り替えはRedis単独、二重書き込み、シャドーリード、DynamoDB優先、DynamoDB単独の順に進み、各段階で一致率や書き込みエラー、遅延をダッシュボードで監視しました。3月には移行元のRedis基盤自体が停止しましたが、すでにDynamoDBを正としていたウォームプールとトークン処理は稼働を続けています。

最大の誤算は遅延でした。件数取得のP95が1.29ミリ秒から5.13ミリ秒に伸び、コンテナを作るたび状態を読む供給ループがN+1クエリとして顕在化し、1回の実行が最悪で数分に膨らんだのです。Redisの速さが設計上の前提を覆い隠していたわけです。

対処は遅延に追いつくことではなく、前提そのものを設計から外すことでした。バッチ化は測定値の倍率を定数として埋め込むため見送り、代わりに各ウォームプールの供給呼び出しを並行実行させ、単一の読み取りで直列化しない形へ作り替えています。振り返りに残された「P90で1ミリ秒から15ミリ秒への劣化でもウォームプール管理は落ちうる」という一文は、ストア移行が運ぶのはデータより前提だと示しています。