AutoScaling時のアプリのデプロイ方式について

Question

たとえばWebアプリのAPサーバをAutoScalingしようとした際、
新規で起動したサーバへのアプリのデプロイ方式はどんなものが推奨されるか、
あるいはそれぞれのやり方でメリット・デメリットあるようであれば比較を教えてください。

（例）
最新アプリをデプロイ済のゴールデンAMIを作成し、それを元にAutoScalingする
メリット：スケール速度が速い
デメリット：アプリ更新時にAMIの作成し直しが必要となる

Answer 1

AWS Auto Scaling を使う場合は、AMIを指定する必要があります。
EC2インスタンスがしきい値を超えた場合、指定したAMIからEC2インスタンスを作成し起動します。
そして不要になったらEC2を棄却する動きをするため、Auto Scaling環境下では、ログが途切れたりします。

そのため基本的には、以下のような連携方法にしないといけません。

デプロイツールをトリガーにして、EC2インスタンスにアプリをDeployし、
そのEC2インスタンスをAMIにして、AutoScalingさせる方法です。

これを自動的に行なってくれるAWSサービスが、** AWS CodeDeploy **です。
CodeDeployは、EC2インスタンスはもちろんAutoScalingにも対応しているで、
今はCodeDeployを使ってデプロイする方法が一般的ですね。

メリデメ云々というよりかは、AutoScaling配下でCodeDeployを使わない場合は、
色々面倒になるのでオススメしません。

■FYI
デプロイ自動化（CodeDeploy + CodePipeline + CodeCommit）

---

追記

少し整理しますと

既にAutoScalingグループがある場合に単純にサーバ台数を追加するのであれば、
個数を増やせば良いだけです。
そうではなく、新規のAutoScalingグループを作成したいということであってますよね？

AWS CodeDeployは、スケール機能を持っていません。デプロイからAMI作成して配置する仕組みです。
つまりWEBアプリケーションを利用可能な状態にするデプロイです。

AWS AutoScalingは、CPU使用率が90%とかになった時に、インスタンス数を自動的に増減する仕組みです。
つまりシステムの規模を柔軟に変更するスケールです。

ソースコードをビルドしてデプロイしてAutoScaleにAMIを配置して
AutoScalingの機能でスケールさせるのは、スケールではなくデプロイになります。

ゴールデンAMIを使った場合も、CodeDeployを使った場合も
AutoScaling自体が起動AMIから起動するため、
その前段であるデプロイ（AMIの配置）までは同一の工順を辿ります。

• ゴールデンAMI作成用のEC2インスタンス内でビルド

　→アプリ配置
→ゴールデンAMIを作成
→AutoSacalingのAMIを変更
→AutoScalingに配置
→AutoScalingでスケールされる

• CodeDeployでAMIを作成

　（ビルド→アプリ配置→ゴールデンAMIを作成→AutoSacalingのAMIを変更をCodeDeployが実行）
→AutoScalingに配置
→AutoScalingでスケールされる

その後、AutoScalingの機能によりAutoSaclingグループのEC2がスケーリングされます。

デプロイ時間は、デプロイ工程が違うために時間差は出るかもしれませんが、
スケール時間は、AWS AutoScaling が行うので全く一緒です。

例えばGitから落としてきたソースをビルドしてAMIを配置しAutoScalingまで行うことを
スケール（総デプロイ時間）と称されているのであれば

スケール速度（デプロイ時間）は、環境や作成方法によりデプロイ時間が増減しますので
実際に自分で作って測ったほうが早いと思います。

また、AutoScalingのデプロイは、基本的には「blue green deploy」が一般的です。

前段のビルド工程は、メンテナンス前にやっておくべきことですので、
速度や時間を気にすることではないように感じます。

Comments

[aoiro27]

CodeDeployを使うデプロイ方式だと、
デプロイ済みののゴールデンAMIを使う場合と比べて、
スケール速度が落ちるというデメリットはありませんか？

[lazhuward]

長くなったので、上に追記しました。
意図が違っていたのであれば、ここに書いてもらえますか。