検証のために、AWSのデプロイツールをいろいろ試しています。
今回、CodePipelineによる以下のような一連のデプロイフローを試していました。

CodeCommit -> CodeBuild -> CodeDeploy

が、いかんせんデプロイまでにかなり時間がかかります。
前回はCodeDeployの速度改善をしましたが、リリースコンテンツを増やしたところ、CodeCommitの部分でもかなり時間がかかることがわかりました。

CodeCommitが遅い

デプロイフローの一連の流れを検証している際は、リリースコンテンツを1MBぐらいにしていたので気が付きませんでしたが、リリースコンテンツを増やすとかなり時間がかかってしまうことがわかりました。

デプロイしてみる

今まで1MBぐらいだったリリースコンテンツを、2GBぐらいにしてCodeCommitにコミットしました。
今回ビルドする要件はなかったので、CodeBuildは外しました。
なお、今回リリースする対象サーバーは1台とします。

CodePipelineの結果

リリースコンテンツが1MBのときは、CodeCommitにコミットをしてから、デプロイが完了するまでの時間は、約3分でした。

リリースコンテンツを2GBに増やしたところ、CodeCommitにコミットをしてから、デプロイが完了するまでの時間は、なんと約12分半でした。

容量が増えるので、ある程度時間が増えるのは当然わかっていましたが、想定よりかなり時間がかかってしまうことがわかりました。

CodeCommit部分

今回の一連の流れでは、まずCodeCommitのコンテンツが固められ、S3に配置されることになります。ここでかかった時間は約8分半です。
ここは、単純にCodePipeline側が裏でやっているだけなので、おそらく小手先による時間短縮はできないのではないかと思っております。
一気に2GBのコンテンツを追加コミットしたからなのかな〜？と思い、その後1ファイルだけコミットしてみましたが、時間は変わりませんでした。毎回リポジトリのコンテンツ全てに対して処理がされるようです。
リリースの度にこれだとしんどい…。1ファイルアップしただけなのにこれとは…

CodeDeploy部分

CodeDeployのログを見てみると、DownloadBundle と Installで、それぞれ1分程時間がかかっていることがわかります。まあここはこんなもんですかね。

感想

やはりどうやってもCodePipelineによるデプロイ方式だと、それなりに時間がかかってしまうようです。
CodePipelineによるデプロイ方式は、AutoScalingに対応していたり、ローリングデプロイができたりと、かなりオシャレだと思っていたのですが、頻繁にコンテンツのリリースがあったり、静的サイトや、ビルド要件がないPHPのサイトであれば、Gitpull方式や、rsync(s3sync)方式のデプロイのほうがよいかも…と感じるようになってきました。