どうもPナッツです！
5日目、2つ目の記事です。
本記事はAuto Scalingについてまとめた記事です。
ELBと組み合わせることで何が便利になるのかというところまで書いていくので、まだELBの記事を見ていない方は先に読んでいただけると理解しやすいと思います！
Auto Scalingとは
状況に応じてEC2インスタンスを自動で増減してくれるサービスです。
アクセスが増えたらインスタンスを増やし、アクセスが減ったらインスタンスを減らしてくれます。
名前の通り、自動でスケーリングしてくれるサービスというわけですね。
何が便利なの？
業務アプリケーションを例に考えてみます。
業務で使うアプリなので、当然ながら業務時間中はアクセスが増えます。
逆に業務時間外になるとアクセスは減ります。
もしAuto Scalingを使わなかった場合、
- 朝になったらインスタンスを増やす
- 夜になったらインスタンスを減らす
みたいな作業を自分でやらなければいけません。
しかも4日目の記事でまとめた通り、EC2は起動している時間に応じて料金が発生します。
そのため、
「アクセスは少ないのにインスタンスを大量に起動したまま放置していた」
なんてことになると、その分だけ余計なコストがかかってしまいます。
こうした面倒な作業や無駄なコストを解決してくれるのがAuto Scalingです。
アクセスが増えたら自動でインスタンスを追加し、アクセスが減ったら不要なインスタンスを減らしてくれます。
忘れっぽい僕にはありがたいサービスですね（笑）
ELBと組み合わせることで何ができる？
Auto ScalingはELBと組み合わせて使われることが多いそうです。
それぞれ便利なサービスだということは分かりましたが、組み合わせると何が嬉しいのでしょうか。
ELBのおさらいですが、ELBはリクエストを複数のインスタンスへ振り分けたり、異常なインスタンスを切り離したりしてくれるサービスでした。
一方でAuto Scalingは、インスタンスの増減を自動化してくれるサービスです。
インスタンスは物理サーバではなく仮想サーバなので、必要に応じて増やしたり減らしたりしやすいのが強みです。
実際にELBとAuto Scalingを組み合わせると、次のようなイメージになります。
例えば、
- アクセスが少ない時はEC2を2台
- アクセスが増えたらEC2を5台
というようにAuto Scalingが自動で調整します。
そして増えたEC2に対して、ELBがリクエストをうまく振り分けてくれるわけです。
つまり、
Auto Scalingが「サーバーを増やす担当」
ELBが「リクエストを振り分ける担当」
として連携しているんですね。
この自動で動く感じ、個人的にかなり好きです。
僕みたいに、
「アクセス増えたからサーバー増やさなきゃ！」
「アクセス減ったから今度は減らさなきゃ！」
みたいなことを手動でやりたくない人にとっては天国みたいな仕組みだなと思いました。
Auto Scalingの特徴
Auto Scalingには次のような特徴があります。
- スケーリングタイプ
- 3つの要素
- アプリケーションデプロイの自動化
それぞれ簡単にまとめます。
スケーリングタイプ
そもそもスケーリングには大きく分けて2種類あります。
- 水平スケーリング
- 垂直スケーリング
水平スケーリング
インスタンスの台数を増減させる方法です。
例えば、
EC2を2台から5台へ増やす
といったイメージです。
Auto Scalingはこちらの方式になります。
垂直スケーリング
インスタンスそのものの性能を上げる方法です。
例えば、
t3.micro → t3.large
のようにインスタンスタイプを変更します。
ただし、変更時には停止が必要になる場合もあります。
そのため、柔軟に増減できる水平スケーリングの方が扱いやすそうだなと感じました。
3つの要素
Auto Scalingを実現するためには主に次の3つを設定します。
- 起動テンプレート（何を起動するか）
- Auto Scalingグループ（どこで起動するか）
- Auto Scalingポリシー（いつ増減するか）
起動テンプレート（何を）
起動するEC2の設定を定義します。
AMIやインスタンスタイプなどを事前に決めておくことで、同じ構成のEC2を自動で起動できます。
Auto Scalingグループ（どこで）
起動テンプレートや配置するAZ、最小・最大インスタンス数などを設定します。
ELBと連携する場合もここで設定します。
Auto Scalingポリシー（いつ）
どのタイミングで増減するかを決める設定です。
主な種類として、
- 動的スケーリング
- 予測スケーリング
- スケジュールスケーリング
があります。
アプリケーションデプロイの自動化
Auto Scalingでは新しいEC2を自動で起動できます。
ただ、起動しただけでは実際には使えません。
例えば、
- Webサーバーをインストールする
- アプリケーションを配置する
- 設定ファイルを反映する
といった作業も必要になります。
テキストでは、
- ステートレス
- ブートストラップ
- ユーザーデータ
- メタデータ
といった単語が出てきました。
正直なところ、この辺りはまだ完全には理解しきれていません（笑）
ただ今の理解としては、
「Auto Scalingで新しくEC2が増えても、すぐに戦力として動けるよう準備しておく仕組み」
という認識です。
実際に触る機会があれば、改めてまとめてみたいと思います。
最後に
ELBとの組み合わせによって、
- EC2の増減
- リクエストの振り分け
を自動化できるのはかなりありがたいですね。
AWSのメリットとして、
「インフラ管理ではなく本来の業務に集中できる」
という話をよく聞きます。
今回学んだAuto Scalingは、まさにその考え方を体現したサービスだなと思いました。
できるところは自動化して、自分は本来やるべき仕事に集中する。
AWSらしい考え方ですね。
また、CloudWatchという監視サービスと組み合わせることも多いようです。
まだテキストで詳しく出てきていないので、学習したら改めて記事にまとめようと思います。
それでは！
まとめ問題
問題1
Auto Scalingの主な役割として正しいものはどれでしょうか？
A. リクエストを複数のEC2へ振り分ける
B. EC2インスタンスを自動で増減させる
C. データを暗号化して保存する
D. データベースを自動で作成する
問題2
Auto Scalingと組み合わせて利用されることが多いサービスはどれでしょうか？
A. Amazon S3
B. Amazon RDS
C. Elastic Load Balancing（ELB）
D. Amazon Route 53
問題3
Auto Scalingが採用しているスケーリング方式はどれでしょうか？
A. 水平スケーリング
B. 垂直スケーリング
C. ハイブリッドスケーリング
D. 手動スケーリング
問題4
Auto Scalingを構成する要素として正しい組み合わせはどれでしょうか？
A. EC2・S3・RDS
B. IAM・VPC・CloudTrail
C. 起動テンプレート・Auto Scalingグループ・Auto Scalingポリシー
D. CloudWatch・Route 53・CloudFront
問題5
Auto ScalingとELBを組み合わせるメリットとして最も適切なものはどれでしょうか？
A. データを自動でバックアップできる
B. アクセス増加時にEC2を増やし、ELBが負荷を分散できる
C. EC2のOSを自動で更新できる
D. IAMユーザーを自動で作成できる
答えはコチラ
問題1：B
問題2：C
問題3：A
問題4：C
問題5：B
コメント