はじめに
株式会社TeraDoxの@tdx_yoshikawaです。Vercelはフロントエンド開発において、「git pushするだけでデプロイ完了」という開発者体験の良さで多くの支持を集めています。本記事では、コードがpushされてから実際にユーザーに配信されるまでのプロセス・仕組みを詳しく解説します。
Vercelのデプロイパイプライン全体像
Vercelのデプロイは、複数のAWSサービスを巧みに組み合わせた分散システムで実現されています。
上図は、公式ドキュメントから引用したもので、git pushから本番環境への反映までの一連の流れを示しています。主要なコンポーネントとして、以下が連携して動作します。
- GitHub: ソースコードのホスティングとWebhook送信
- Amazon S3: ソースコードとビルド成果物の保管
- AWS Lambda: 検証処理とサーバーレス関数の実行
- Amazon SQS: ビルドジョブのキューイング
- AWS Fargate: ビルドコンテナの実行環境
- Vercel Edge Network: グローバルなコンテンツ配信
これらのサービスが密接に連携することで、開発者は複雑なインフラを意識することなく、シンプルなデプロイ体験を享受できます。以下、各ステップの詳細を説明します。
コードがデプロイされるまでの工程
1. デプロイのトリガー
GitHubへのpushやPRのマージが発生すると、Webhookを通じてVercelに通知が送られます。VercelのGit統合は、コミットを自動的に検知し、新しいデプロイを開始するように設定されています。
2. ソースコードの一時保管
プロジェクトファイルは最初にAmazon S3にアップロードされます。このフェーズにより、以下のメリットが得られると推測されます。
- ビルド環境からの高速アクセスが可能
- 複数のビルドワーカーが同じソースにアクセス可能
- ビルド失敗時のリトライが容易
3. デプロイ前検証プロセス
AWS Lambdaがデプロイ前に以下の項目を確認します。
- Vercelの認証チェック：ユーザーを認証し、リクエストの信頼性とデプロイ作成権限を確認することで、不正アクセスや整合性の喪失から保護します。
-
設定ファイルの解析：
vercel.jsonファイルに記述されたプロジェクト構成が有効でVercelプラットフォーム要件に合致しているかを検証します。具体的には、rewritesやheadersなどのルーティング設定の妥当性、cleanUrls: trueによる静的HTMLファイルのサフィックス削除（config.jsonの"overrides"プロパティ経由）、およびEdge Middlewareのルーティングルールなどがチェックされます。 - リソース制限の確認：プロジェクトの料金プラン（Hobby、Pro、Enterpriseなど）に基づいて、ビルドの同時実行数が十分に利用可能であるか、およびビルドコンテナに割り当てられるメモリ、ディスクスペース、CPUといったリソースが確保されているかを確認します。これには、最大45分のビルドタイムアウトや、各ビルドキャッシュが最大1GBであることなども含まれます。
4. ビルドのスケジューリング
Amazon Simple Queue Service（SQS）を使用して、ビルドがスケジューリングされます。具体的には、以下が実行されます。
- 並列処理の制御：Hobbyチームは1つ、Proチームは最大12、Enterpriseチームはカスタム量のビルドスロットを購入し、同時ビルド数を管理できます。
- 新しいコミットが行われた場合、Vercelは同じブランチの古いキューに入っているビルドをスキップし、最新のコミットのみを優先して実行します。
5. ビルドとプロビジョニング
AWS Fargate on EC2で構成されるビルドコンテナにより、ビルドとプロビジョニングが実行されます。Vercelのビルドシステムは、プロジェクトごとに安全で隔離された仮想環境を作成し、需要に応じて自動的にスケーリングします。これにより、各コンテナは独立した環境で動作し、セキュリティと再現性を保証します。Vercelの課金プランによっては、並列でビルドできるコンテナの数が制限されます。
ビルド完了後、Vercelは成果物を分析し、最適な実行環境にプロビジョニングします。具体的な配置先は以下のとおりです。
- サーバーレス関数（APIルートやSSRページ用） → AWS Lambda
- Edge Functions（ミドルウェアやEdge Runtime関数用）→ VercelのEdge Network（AWS Global Networkを基盤とする）
- 静的ファイル（HTML、CSS、JS、画像等） → 静的ストレージ（Amazon S3）にアップロードされVercel CDNを介して提供されます
- 最適化された画像 → リクエストに応じて画像をオンザフライで最適化し、エッジでキャッシュするVercel専用の画像最適化サービスに転送されます。
6. リアルタイムステータス更新
ビルドコンテナは、デプロイのステータスを追跡するAPIエンドポイントに継続的にpingを送信します。このエンドポイントを使用して、VercelはGitHubやVercelのダッシュボード上に、デプロイの進捗をリアルタイムに表示します。
7. デプロイ完了
ビルドが成功すると以下の処理が実行されます。
- プレビューURLの生成（PRの場合）
- プロダクションURLへの反映（mainブランチの場合）
- GitHubへのステータス通知
まとめ
本記事では、Vercelのデプロイ基盤がどのように動作しているかを詳しく解説しました。AWSの複数のマネージドサービスが緊密に連携し、高速かつ安定したデプロイを実現していることが分かりました。特にビルド成果物を適切な実行環境へ自動配置するプロビジョニング機能は、Vercelのコア技術であると考えています。
ちなみに、調査中にインドのエンジニアによるVercelクローンの開発動画も発見しました。今回理解したアーキテクチャを参考に、自分でも簡易版を実装してみたくなりました。実際に手を動かすことで、Vercelの設計の巧みさをより深く理解できそうです。
I built Vercel in 2 Hours (System Design, AWS, Docker, Redis, S3)
用語集
- オンザフライ：リクエスト時にリアルタイムで処理を実行すること
- CDN：Content Delivery Network。世界中に配置されたサーバーから最も近い場所からコンテンツを配信する仕組み
- サーバーレス関数：サーバー管理不要で実行できる関数。リクエスト時のみ起動し、使用分だけ課金されるパターンが多い。
- プロビジョニング：リソースを適切な実行環境に配置・設定すること
参考文献
振袖探しに特化したポータルサイト「My振袖」や電子契約システム「契約大臣」をはじめ、数多くのWebサービスの開発・運営を行っております。当社の採用情報や社風にご興味をお持ちの方は、Wantedly(wantedly.com/companies/company_6763410)をご覧ください。
Discussion