メモ > サーバ > サービス: AWS > Auto Scaling
Auto Scaling
■オートスケーリングの作成
EC2 → AUTO SCALING → 起動設定 → Auto Scaling グループの作成 → 起動設定の作成
1. AMI の選択
Amazon Linux AMI を選択。
2. インスタンスタイプの選択
t2.micro を選択。
3. 詳細設定
名前: Sample
高度な設定 ユーザーデータ: （起動時に実行したい処理を指定できる。）
高度な設定 IPアドレスタイプ: （「パブリック IP アドレスを各インスタンスに割り当てます。」にするといい？）
4. ストレージの追加
特に変更せず。
5. セキュリティグループの設定
必要に応じて、あらかじめ設定しておいたセキュリティグループを選択。
6. 確認
内容を確認して、問題なければ「起動設定の作成」。
ダイアログが表示されるので、キーペアを作成or選択して「起動設定の作成」。
1. Auto Scaling グループの詳細設定
グループ名: Sample Group
グループサイズ: 1
ネットワーク: （VPCを選択 or 作成。）
サブネット: （サブネットを選択or作成。マルチAZにしたい場合は複数AZを選択する？）
高度な詳細 ロードバランシング: （ELBを使う場合、チェックを入れてロードバランサーを選択する。）
2. スケーリングポリシーの設定
少し試す程度なら「このグループを初期のサイズに維持する」でいいが、この設定だとアクセス数が増えてもインスタンス数は増えない。
実際はここでスケーリングの設定を行う。
3. 通知の設定
少し試す程度なら設定不要だが、実際はここで通知の設定を行う？
4. タグを設定
必要に応じて設定する。
5. 確認
内容を確認して、問題なければ「Auto Scaling グループの作成」。
EC2 → AUTO SCALING → Auto Scaling グループ
でグループの状態を確認できる。
EC2 → インスタンス
などでも、インスタンスが起動されていることを確認できる。
■オートスケーリングの編集
ユーザーデータなどを編集したい場合、「起動設定」から設定をコピーして新たに起動設定を作成する。
その後「Auto Scaling グループ」からグループを編集し、使用する起動設定を切り替える。
起動設定を切り替えたからといって、以前の起動設定で作成されたインスタンスが削除されたりはしないみたい。
新しい起動設定を適用させたい場合、以前作成されたインスタンスを終了させれば自動的に新しいインスタンスが作成される。
ユーザーデータを直接編集したり…はできないみたい。
■オートスケーリングの解除
「Auto Scaling グループ」でグループを削除、さらに「起動設定」で設定を削除。
関連するインスタンスも自動で削除されるみたい。
ロードバランサーなど他のサービスも使っている場合、それらも削除する。
今からでも遅くない、AWS Auto Scaling入門
http://toach.click/hello-aws-auto-scaling/
スケールアウトを自動化する
http://www.atmarkit.co.jp/ait/articles/1407/15/news007.html
【AWS】AutoScalingを使う際の注意点についてまとめてみました
http://dev.classmethod.jp/cloud/aws/autoscaling_considerations-for-system-configuration/
【AWS】Auto Scalingまとめ
http://qiita.com/iron-breaker/items/2b55da35429da7b19e49
1台のサーバですら Auto Scaling でケチる
http://blog.hde.co.jp/entry/2015/02/12/175214
■ユーザーデータについて
例えば以下のように記述しておくと、EC2起動時に /root/test.txt が作成される。
#!/bin/bash
touch /root/test.txt
作成されたファイルは以下のとおり。root権限で実行されている。
# ll /root/
total 0
-rw-r--r-- 1 root root 0 Sep 5 05:16 test.txt
例えば以下のように記述しておくと、EC2起動時に /test.txt が作成される。
（rootのホームディレクトリでは無いので注意。）
#!/bin/bash
touch test.txt
例えば以下のようにシェルスクリプトを作成しておき、
# vi /root/startup.sh
ユーザーデータで以下のように記述しておくと、EC2起動時に /root/startup.sh が実行される。
（シェルスクリプト内でパスを省略すると、やはり / 直下が基準となるので注意。）
#!/bin/bash
touch /root/test.txt
# chmod 700 /root/startup.sh
# /root/startup.sh
#!/bin/bash
/root/startup.sh
/root/startup.sh の内容を作りこむことで、
EC2起動時に yum update や git pull などを行うことができる。
■要調査メモ
台数が多いと基本的に固定IPを割り振らない？数十代台数百台になると、固定IPの割り振りは非現実的。
台数が多いと一台一台を監視していてもあまり意味がない？トータルで監視する定番の方法はある？
ユーザーデータの作りこみが必要。
Zabbixへの自動登録、デプロイ。
ログの退避も必要。起動時ではなくインスタンス終了時の処理を作る？
CloudWatchLogで転送し続けていればいい？
Zabbix監視対象からの自動除外も必要。
サーバ名はデフォルト名のままの方がいい？
インスタンスの異常検知 → 新規インスタンスの起動 → ロードバランサーへの割り当て
という過程があるため、デフォルトの検知設定（オートスケーリング・ロードバランサーとも300秒）だとタイムラグが大きすぎるかも。
CloudWatchとの組み合わせで、適切な検知設定を作成する必要がありそう。
インスタンスの数やEIPの数など、初期状態では制限があるので必要に応じて緩和申請が必要。
RDSやElastiCacheのインスタンス数は増えない？はじめから高機能なインスタンスにしておく必要がある？
RDSのリードレプリカは手動で作成して、アプリケーション側も手動対応が必要？
接続先のサービスにIP制限がある場合、オートスケーリングでないNATサーバを立てる必要がある？
リポジトリの内容が更新された時点で、全サーバにおいて自動でデプロイを実行する必要がある？
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（前編）。JAWS DAYS 2014
http://www.publickey1.jp/blog/14/110jaws_day_2014_1.html
クックパッドでは完全自動デプロイでは無いみたい？
マージしたらCIは走るが、その後改めてデプロイを行う？
CLIで稼働中のインスタンス一覧を表示して、そこに現在のバージョンを表示して、ポチポチと手動でデプロイするとか？
クックパッドにおけるサーバ監視と運用の工夫
http://techlife.cookpad.com/entry/2015/04/28/100000
AutoScalingも怖くない、Zabbix自動登録
http://blog.serverworks.co.jp/tech/2014/05/29/zabbix-auto-registration/
オートスケールするインスタンスをzabbix監視対象として自動登録(削除)する
http://qiita.com/kaojiri/items/c8d2061829b96b84d850
PHP 5分でわかる! Zabbix API の使い方（ホスト一覧の取得）
https://blog.apar.jp/zabbix/3055/
以下は後から見つけたので未検証だが、詳細にかかれているので良さそう。
AWS Elastic Beanstalkで環境構築自動化
http://qiita.com/supertaihei02/items/b2373890b7e739ded318
以下も後から見つけて未検証だが、実際の運用フローも紹介されているので参考にできそう
AWS再入門2018 Amazon EC2 Auto Scaling編 ｜ Developers.IO
https://dev.classmethod.jp/cloud/aws/2018-aws-re-entering-autoscaling/