はじめに
AWSハンズオンfor Beginnersシリーズとして提供されている「Amazon EC2 Auto Scaling スケーリング基礎編」を実施した際のメモです。
ビジネスの拡大に伴いリソースのスケーリングが必要です。例えば、オンプレでスケーリングする場合、マシンの物理的な入れ替えなどが発生し、即時対応が難しく、手作業であるため、誤りも発生する可能性があります。また、急な需要増加に対応できず機会損失にもつながります。
Auto Scalingを使用することでこれらを解決するとともに、可用性の維持とコスト最適化につなぐことができます。
本ハンズオンでは、2種類のスケーリング方法の実践およびインスタンスに異常があった際の自動置き換えを体験します。
アジェンダ
- 本ハンズオンの概要
- スケーリングにまつわる課題とAmazon EC2 Auto Scalingについて
- ハンズオンの事前準備
- スケジュールスケーリング（１）~起動テンプレートの作成~
- スケジュールスケーリング（２）~Auto Scalingグループの作成、スケジュールの設定~
- ターゲット追跡スケーリング（１）~ターゲット追跡スケーリングの設定~
- ターゲット追跡スケーリング（２）~負荷をかけてスケールアウトを確認~
- ターゲット追跡スケーリング（３）~負荷をとめてスケールインを確認~
- 異常なインスタンスの置き換え
- 本シリーズのまとめ、リソースの削除
メモ
スケーリングの種類
Auto Scalingにはスケジュールに基づいたスケーリング（スケジュールスケーリング）と需要に基づいた動的スケーリングの2種類があります。
スケジュールスケーリング
スケジュールスケーリングは文字通り、スケジュールに基づいてスケーリングを行います。
例えば、指定した日時にインスタンスを4つ起動する、などです。
スケーリングする時間とインスタンスの数を設定するため、このスケーリングを使用する前提として「いつ」「どのぐらい」リソースが使用されているかを把握しておく必要があります。
動的スケーリング
動的スケーリングはインスタンスのCPU使用量などを基準にスケーリングを行う方法です。
例えば、インスタンスのCPU使用量が80%を超えたら1つインスタンスを追加する、などです。
動的スケーリングの場合、予測できない需要に対応できますが、スケーリングには時間を要します。
そのため、スパイクアクセスに注意する必要があります。また、前提として需要増加により「なに」に負荷がかかるか（何をスケーリングの基準とするか）を把握しておく必要があります。
Auto Scalingのコンポーネント
Auto Scalingには2つのコンポーネントがあります。
1つ目は起動テンプレートです。起動テンプレートとは、Auto Scalingによって起動するEC2インスタンスの情報をまとめたファイルです。AMI、インスタンスタイプ、ネットワーク設定などの情報をファイルに記載します。
2つ目はAuto Scalingグループです。Auto Scalingグループとは、スケーリングの設定をまとめたコンポーネントです。どの起動テンプレートを使用するかとか、維持するインスタンス数、スケールアウト時の最大インスタンス数、スケールイン時の最小インスタンス数、スケーリングのトリガーなどを設定します。
動的スケーリング設定
動的スケーリングを設定するには、まず、スケーリングポリシーを作成する必要があります。
スケーリングポリシーには、ターゲット追跡スケーリング、ステップスケーリング、シンプルなスケーリングの3種類があります。
ターゲット追跡スケーリングとは、設定したターゲット値を維持するようにスケールアウト、スケールインを行う機能です。
例えば、CPU使用量が60%を維持するようインスタンス数の増減を自動化してくれます。ターゲット追跡スケーリングを設定すると、CloudWatchアラームが作成されます。ターゲット値によりスケールインするアラームとスケールアウトするアラームの2つが作成されます。
インスタンスへの負荷テスト
EC2インスタンスにSSHログインし、stressコマンドを実行して、CPU、メモリ、ディスクなどに負荷をかけることができます。
設計時の注意点
スケーリングにより、インスタンスが増減するため、インスタンスに依存したステートフルなアプリだとスケーリング時にインスタンスが持つ情報が失われる可能性があります（もしくは、スケールアウトしたことで情報がないインスタンスにアクセスしてしまう）。
このようなことを防ぐため、ステートレスな設計を目指しましょう。
例えばセッション情報はサーバで持つのではなく、DynamoDBやElastiCacheなど外に持たせるなど。
異常インスタンスの置き換え
Auto Scalingには、EC2のステータスチェックやELBのヘルスチェックの結果によって異常とみなされたインスタンスを置き換える機能があります。
本ハンズオンでは、Auto Scalingグループ内のインスタンスを停止させてみて、その後新しいインスタンスが立ち上がるかを確認しました。
ハンズオンの感想
コスト最適化、可用性向上のためほぼ全てのサービスで必要な機能であると感じます。
動的スケーリングの場合、何をどのぐらいの基準でスケールするかは、過去に同じような構成でサービスを作っていればそれを参考にできます。
そうでない場合、一旦決めにし、メトリクスを監視、傾向を掴んだ上で再設定する必要があると感じます。
なお、インスタンスの数を増やしたくないなど（インスタンスにインストールするライセンスの問題）の顧客の要望が過去ありました。その場合はAutoScalingの水平スケーリングではなく、垂直スケーリングを考慮しなければなりません。