回答編集履歴
1
add
answer
CHANGED
|
@@ -15,4 +15,54 @@
|
|
|
15
15
|
色々面倒になるのでオススメしません。
|
|
16
16
|
|
|
17
17
|
■FYI
|
|
18
|
-
[デプロイ自動化（CodeDeploy + CodePipeline + CodeCommit）](http://xp-cloud.jp/blog/2018/01/19/2727/)
|
|
18
|
+
[デプロイ自動化（CodeDeploy + CodePipeline + CodeCommit）](http://xp-cloud.jp/blog/2018/01/19/2727/)
|
|
19
|
+
|
|
20
|
+
----
|
|
21
|
+
# 追記
|
|
22
|
+
|
|
23
|
+
少し整理しますと
|
|
24
|
+
|
|
25
|
+
既にAutoScalingグループがある場合に単純にサーバ台数を追加するのであれば、
|
|
26
|
+
個数を増やせば良いだけです。
|
|
27
|
+
そうではなく、新規のAutoScalingグループを作成したいということであってますよね？
|
|
28
|
+
|
|
29
|
+
`AWS CodeDeploy`は、スケール機能を持っていません。デプロイからAMI作成して配置する仕組みです。
|
|
30
|
+
つまりWEBアプリケーションを利用可能な状態にする`デプロイ`です。
|
|
31
|
+
|
|
32
|
+
`AWS AutoScaling`は、CPU使用率が90%とかになった時に、インスタンス数を自動的に増減する仕組みです。
|
|
33
|
+
つまりシステムの規模を柔軟に変更する`スケール`です。
|
|
34
|
+
|
|
35
|
+
ソースコードをビルドしてデプロイしてAutoScaleにAMIを配置して
|
|
36
|
+
AutoScalingの機能でスケールさせるのは、`スケール`ではなく`デプロイ`になります。
|
|
37
|
+
|
|
38
|
+
ゴールデンAMIを使った場合も、CodeDeployを使った場合も
|
|
39
|
+
AutoScaling自体が`起動AMI`から起動するため、
|
|
40
|
+
その前段であるデプロイ（AMIの配置）までは同一の工順を辿ります。
|
|
41
|
+
|
|
42
|
+
* ゴールデンAMI作成用のEC2インスタンス内でビルド
|
|
43
|
+
→アプリ配置
|
|
44
|
+
→ゴールデンAMIを作成
|
|
45
|
+
→AutoSacalingのAMIを変更
|
|
46
|
+
→AutoScalingに配置
|
|
47
|
+
→AutoScalingでスケールされる
|
|
48
|
+
|
|
49
|
+
* CodeDeployでAMIを作成
|
|
50
|
+
（ビルド→アプリ配置→ゴールデンAMIを作成→AutoSacalingのAMIを変更をCodeDeployが実行）
|
|
51
|
+
→AutoScalingに配置
|
|
52
|
+
→AutoScalingでスケールされる
|
|
53
|
+
|
|
54
|
+
その後、AutoScalingの機能によりAutoSaclingグループのEC2がスケーリングされます。
|
|
55
|
+
|
|
56
|
+
デプロイ時間は、デプロイ工程が違うために時間差は出るかもしれませんが、
|
|
57
|
+
スケール時間は、AWS AutoScaling が行うので全く一緒です。
|
|
58
|
+
|
|
59
|
+
例えばGitから落としてきたソースをビルドしてAMIを配置しAutoScalingまで行うことを
|
|
60
|
+
`スケール`（総デプロイ時間）と称されているのであれば
|
|
61
|
+
|
|
62
|
+
`スケール速度`（デプロイ時間）は、環境や作成方法によりデプロイ時間が増減しますので
|
|
63
|
+
実際に自分で作って測ったほうが早いと思います。
|
|
64
|
+
|
|
65
|
+
また、AutoScalingのデプロイは、基本的には「blue green deploy」が一般的です。
|
|
66
|
+
|
|
67
|
+
前段のビルド工程は、メンテナンス前にやっておくべきことですので、
|
|
68
|
+
速度や時間を気にすることではないように感じます。
|