はじめに
個人で「AI模試ノート」というAWS認定試験をはじめとするベンダー資格の模試学習アプリをAWS Amplify Gen2(バックエンドはCDK)を使用して構築しています。
ブランチへpushするたびにCI/CDが走るため重宝しているのですが、微小な変更でもデプロイ完了まで平均約8分かかるのがややネックに感じていました。
そんななか、CDKベースで爆速デプロイできると噂のcdkd(CDK Direct) を思い出し、「乗り換えられるのでは？」と思った矢先に、みのるんさん(@minorun365)の以下ツイートが目に留まり、自分のアプリもcdkdに乗り換えてみることにしました。
デプロイツールもAmplifyを卒業して、AWS Hero後藤さん作成のCDK Direct (cdkd) を使っており、毎回10分以上かかっていたデプロイ時間が1分半に爆速化しました！
本記事では、cdkdの概要とAmplify Gen2への適用可否を整理したうえで、自作アプリと同種の構成を使って、CDK、CDK Expressモード等と速度を比較していきます。
cdkdは開発/テストワークフロー専用での利用を推奨しております。
本番環境での使用を想定されていないためご注意ください。
この記事でわかること
- cdkdの概要と、通常のCDK deploy・CDK Expressモードとの違い
- Amplify Gen2で構成していたアプリを、素のCDKだけでどう再現したか
- 自作アプリ相当の構成で計測した「CDK通常 → CDK Express → cdkd」のデプロイ速度比較
- 実際に使ってみて踏んだ制約・注意点
ターゲット
- Amplify Gen2やCDKでバックエンドを組んでいて、デプロイの遅さに悩んでいる方
- cdkd(CDK Direct)というOSSに興味がある方
- 前回のExpressモード記事を読んで、「もっと速くする方法はないの?」と思った方
先に結論
| # | 手段 | コマンド | デプロイ時間 | 通常CDK比 |
|---|---|---|---|---|
| 0 | Amplify Gen2 CI/CD(実測・参考値) | Amplify Console | 平均 約8分3秒(範囲 7分23秒〜9分2秒) | ― |
| 1 | 素のCDK(通常) | cdk deploy |
259.32秒(Total: 332.54秒) | 基準 |
| 2 | CDK Expressモード | cdk deploy --express |
213.64秒(Total: 295.32秒) | 約1.2倍 |
| 3 | cdkd | cdkd deploy |
実測待ち | 実測待ち |
| 4 | cdkd(待機スキップ) | cdkd deploy --no-wait |
実測待ち | 実測待ち |
- 0行目は同一構成での比較ではない(フロントエンドビルド込み・CloudFormation経由の
ampx pipeline-deploy)ため、あくまで「体感の基準値」として参考に載せる。1〜4は、Amplify Gen2で構成していたアプリと同種のリソースをAmplifyを介さない素のCDKで再現した検証専用スタックでの実測(詳細は2章参照)
1. cdkdとは
cdkdは、AWS DevTools Heroとして活躍されているgotoさん(@365_step_tech)が開発したOSSです。公式リポジトリの説明を引用します。
Drop-in CDK CLI for existing CDK apps — up to 15x faster deploys via direct AWS SDK calls instead of CloudFormation
ひとことで言うと、既存のCDKコードはそのままに、CloudFormationのチェンジセット計算・安定化待機を丸ごと飛ばして、代わりに専用の「SDK Provider」またはCloud Control APIで直接リソースを作る代替CLIのようです。作者のgotoさんによるZenn記事(既存の AWS CDK コードのまま、最大 15 倍速くデプロイできる『cdkd』を作った)によると、開発の動機は「cdk deploy --hotswapは速いがCloudFormationとの間にドリフトが生まれてしまう」という課題感だったとのことです。
仕組み
処理の流れは3段階です。
- Synthesis: CDKアプリをサブプロセス実行してCloud Assembly(CloudFormationテンプレート相当)を生成
- Asset Build & Publish: LambdaのZipやコンテナイメージをS3/ECRへアップロード
- cdkd Engine: 独自のデプロイエンジンが、依存関係グラフ(DAG)を解析して依存のないリソースを並列に、主要リソースは専用のSDK Providerで、それ以外はCloud Control APIでプロビジョニングする
CloudFormationのスタックという概念自体を使わず、状態はS3(ETagによる楽観的ロック)で管理しています。
作者公表のベンチマーク
Zenn記事に掲載されているベンチマークです(執筆時点で追試はしていません、あくまで作者公表値)。
| スタック構成 | CloudFormation通常 | Expressモード | cdkd | cdkd --no-wait
|
|---|---|---|---|---|
| VPC+Lambda+SQS+CloudFront | 562秒 | 366秒 | 197秒 | 40秒 |
| SQS(単純) | 83秒 | 22秒 | 9秒 | 9秒 |
非同期リソース(CloudFront等)を含むスタックほど効果が大きく、Expressモード比でも約2倍、非同期リソース込みでは最大9倍速いとのことです。
cdkdに"express"モードはあるか
今回の検証を始める前に「cdkdにもExpressモード的なものがあるのでは」と思って探しましたが、cdkd自体に"express"という名前のオプションは見当たりませんでした。CloudFormationを経由しない設計そのものが速さの源泉になっているため、Expressモードのような「安定化待機を省略するモード切り替え」という概念が不要、というのが正確なところのようです。近い役割を持つのは--no-waitフラグで、こちらはRDSやCloudFrontなど非同期リソースの安定化待ちそのものをスキップします。
本番非対応という制約
READMEに明記されている、見過ごせない制約です。
This project is in early development and is NOT suitable for production use. Features are incomplete, APIs may change without notice, and there may be bugs that could affect your AWS infrastructure. Use at your own risk in development/testing environments only.
開発・テスト用途限定のツールで、本番デプロイは推奨されていません。また、CloudFormationのブートストラップロール(cdk-hnb659fds-deploy-role-*)では権限が不足するため、直接SDKを呼び出すための専用IAMロールが必要になる点も、通常のCDK運用との違いです。
2. 検証方法・検証環境
自作アプリの構成
自作アプリ「AI模試ノート」の構成を簡単に紹介します。
- フロントエンド: Next.js(App Router)。Amplify Hostingでビルド・配信
- バックエンド: Amplify Gen2(
amplify/backend.ts)- 認証: Cognito(メールログイン、招待制のクローズドベータ、管理者グループ)
- データ: DynamoDB単一テーブル(Amplify Data(GraphQL)は使わず、CDKで直接定義)
- 通知: Lambda + EventBridge(定期実行で学習リマインダーをWeb Push)
- CI/CD:
develop/mainブランチへのpushで、Amplify Consoleがampx pipeline-deployを実行
検証方針
Amplify自体に「ワンコマンドで素のCDKへ完全移管する」機能は無いため、今回は検証用にAmplify Gen2で構成していたアプリと同種のリソースを、Amplifyを介さない素のCDKだけで再現しました。バックエンド(Cognito/DynamoDB/Lambda+EventBridge)に加えて、Amplify Hostingが担っているフロントエンド配信も自前で用意する必要があるため、Next.js(App Router)をCDKでホスティングする標準的な構成(S3 + CloudFront + Lambda)もcdklabs/cdk-nextjsで追加しています。このスタックに対して「通常CDK」「CDK Express」「cdkd」の3つのデプロイ手段を比較します。
検証スタックの構成
バックエンド相当
- Cognito UserPool(メールログイン、自己サインアップ無効) + UserPoolClient + IdentityPool + 管理者グループ
- DynamoDB テーブル(PK/SK、
PAY_PER_REQUEST、TableEncryption.DEFAULT) - Lambda(
NodejsFunction) + LogGroup + EventBridge Rule(定期実行) - IAMポリシー(テーブルアクセス権限、Cognito管理API権限など)
フロントエンドホスティング相当(Amplify Hostingが担っている部分)
-
cdklabs/cdk-nextjsの
NextjsGlobalFunctionsで、Next.js(App Router)をS3 + CloudFront + Lambdaで配信する構成を追加 - SSR部分はAWS Lambda Web Adapterを使ってホストする形です。Next.jsの
standaloneビルド成果物(node server.jsで起動できる、普通のHTTPサーバー)をそのままコンテナイメージに詰め、Lambda Web AdapterがLambdaの呼び出しイベントをHTTPリクエストに変換してこのサーバープロセスに渡します。Next.js側のコードをLambda用に書き換える必要はありません - コンテナイメージとはいってもECS/Fargateのように常時起動しているわけではなく、あくまでLambda関数のパッケージング形式(Package type: Image)としてコンテナを使っているだけです。デプロイ時にDockerでこのイメージをビルドする必要があるため、Dockerが実行環境に必須になります(cdk-nextjsのPrerequisitesに明記)
- Next.jsアプリ本体は静的ページ1つ・動的SSRページ1つ・ヘルスチェックのみの最小構成(ページ数はデプロイ時間にほぼ影響しないため)
検証環境
| 項目 | 内容 |
|---|---|
| aws-cdk(CLI) | v2.1138.0 |
| aws-cdk-lib | v2.266.0 |
| cdkd | v0.284.42 |
| Node.js | v24.15.0 |
| リージョン | ap-northeast-1(東京) |
検証の流れ
- 素のCDKで
cdk deploy(通常モード) - 一旦
cdk destroyで削除し、cdk deploy --express - 一旦削除し、cdkdを導入して
cdkd deploy - 一旦削除し、
cdkd deploy --no-wait
各手段のデプロイ完了までの時間(timeコマンドのreal)を記録しました。
3. 通常のCDKでデプロイ(Before)
cdk deploy --require-approval never
✅ CdkdBenchmarkStack
✨ Deployment time: 259.32s
Outputs:
CdkdBenchmarkStack.NextjsUrl = https://dxxxxxxxxxxxxx.cloudfront.net
Stack ARN:
arn:aws:cloudformation:ap-northeast-1:xxxxxxxxxxxx:stack/CdkdBenchmarkStack/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
✨ Total time: 332.54s
Deployment time(CloudFormationのデプロイそのものにかかった時間)は259.32秒(約4分19秒)、synthやDockerでのコンテナイメージビルド・Asset publishまで含めたTotal timeは**332.54秒(約5分33秒)**でした。前回記事はDeployment timeで数値を揃えていたので、以降の比較もこちらを基準にします。CloudFrontディストリビューションの作成が入っている分、前回のExpressモード記事のS3+CloudFrontパターン(210.34秒)と近い水準です。
4. CDK Expressモードでデプロイ
CDK Expressモードの仕組み自体は前回の記事で詳しく検証済みなので、ここでは自作アプリ相当の構成での結果だけ載せます。
cdk deploy --express --require-approval never
実測待ち: real 分秒
5. cdkdでデプロイ
npm i -g @go-to-k/cdkd
cdkd bootstrap # アカウント初回のみ
cdkd deploy --yes
実測待ち: real 分秒
6. cdkd(待機スキップ)でデプロイ
--no-waitを付けて、非同期リソースの安定化待ちも省略した場合です。
cdkd deploy --yes --no-wait
実測待ち: real 分秒
注意点(ハマりどころ)
- 本番非対応: READMEに明記されている通り、cdkdは開発/テスト専用。今回の検証も本番のAmplify環境とは完全に分離した検証専用スタックで行った
-
専用IAMロールが必要な場合がある:
cdk-hnb659fds-deploy-role-*では権限不足になりうる。CI利用時は--role-arn(またはCDKD_ROLE_ARN環境変数)での専用ロール指定が公式に推奨されている -
Dockerが必須: フロントエンドホスティング(
cdk-nextjs)のLambda関数はコンテナイメージとしてビルドするため、Docker(またはDocker互換のコンテナエンジン)が無いとデプロイに失敗する
動作確認
| 検証項目 | 期待する挙動 | 結果 |
|---|---|---|
cdkd deployが成功する |
通常のCDK deployと同じ最終状態になる | 実測待ち |
| CDK Express比でも速い | 作者公表値では約2倍 | 実測待ち |
--no-waitでさらに速くなる |
非同期リソースの安定化待ちがなくなる | 実測待ち |
まとめ
自作のAmplify Gen2アプリと同種の構成で、CDK通常デプロイ・CDK Expressモード・cdkdの3段階を比較しました。
一方で、cdkd自体は本番非対応と明記された実験的なツールなので、「AI模試ノートを今すぐcdkdに完全移行する」という当初のアイデアは、現時点では現実的ではないという結論になりました。とはいえ、開発中のイテレーション速度という観点では魅力的な選択肢なので、今後もcdkdの開発動向は追いかけていきたいと思います。
参考