AWSのEC2周りを整理して、EC2 Auto Scalingを設定してみる。

はじめに

どーも、のぶこふです。
この記事はGFAMアドベントカレンダー2021の4日目の記事です。

4日目にして、すでに破綻しそうな感じがぷんぷんしてます。
Qiitaから、アドベントカレンダーのリマインドメールも届きました。ありがとうございます。
ということで、今日も元気に書いていきます。

今回は、みんなお馴染み。
「AWSと言ったらコレ！」
と言っても過言ではないEC2関連をまとめていきます。

今回のサービス一覧

Service名とか	概要
EC2 1	IaaSの代表格
EC2 Auto Scaling	リソースの増減するよ

前回の内容を鑑みて、内容を絞りました。
でも、EC2も奥が深く、本気でやろうとすると、これだけで１ヶ月は埋められると思います。
まずは、表面だけでも理解しよう、ということで、ライトに記述していきます。

EC2

• EC2：Amazon Elastic Compute Cloud
  • お馴染みのコンピューティングウェブサービスです
  • 逆に正式名称だと、「あれ、そんなサービスあったっけ？」と思いますね
    • コンピューティングウェブサービスって何よ？となると思いますが、いわゆるサーバです
• プロセッサ、ストレージ、ネットワーキング、オペレーティングシステム、購入モデルを選択出来ます
  • 具体例として・・・
    • OS：Windows、Linux系（Amazon Linux、RHEL、MacOS、Ubuntu…）
    • プロセッサ：インテル、AMD、Arm ベース

インスタンスタイプ

• 先の通り、EC2ではプロセッサの選択が行えます。その際、話に出てくるのが、インスタンスタイプです²

  • インスタンスタイプは[ファミリー][世代][追加機能].[サイズ]で構成されています

• ファミリー

  • メモリ・I/O・CPUクロック、価格・・・等、特徴に合わせたファミリーが提供されていて、処理するワークロードに合わせて、選択が可能です
  • 時たま、「最適なファミリーを選べ」みたいな話もあったりするので、ざっくりと覚えておくと良いと思います
    • どんどん増えていくので、その時々の最新を調べるのが吉

• 世代

  • 数字が大きい方が新しく、コスパが良いので、基本は最新世代（数字が最も大きいの）を選ぶのが推奨されています

• 追加機能

  • 内蔵ストレージ（インスタンスストア）を持っていたり、AMDのCPUだったり等

• サイズ

  • CPU、メモリ、EBS・NWの帯域幅によってサイズが分類されています
    • アプリが必要とするリソースに合わせて選択・変更します

ストレージ

• EC2にアタッチするストレージは2つに分類出来ます
• ※本記事では、紹介程度に留めておきます。ストレージ関連をまとめる時に本気出す
  • インスタンスストア³
  • EBS⁴

	InstanceStore	EBS
概要	インスタンス用のブロックレベルの一時ストレージ	EC2向けのスケーラブルなストレージ
種類	ブロックストレージ	ブロックストレージ
	揮発性（停止、休止、終了で消失）	永続性
	特定のインスタンスタイプでのみ使用可能	全タイプで使用可能
HDD/SSD	インスタンスタイプ（ファミリー）によって異なる	選択可能

EC2 Auto Scaling

• Auto Scalingと一口に言っても、実は分類されている^{5 6}
  • EC2のスケーリングをする「EC2 Auto Scaling」
  • EC2以外のAWSサービス（ECSやEMRなどのクラスタ、Auroraレプリカ等）のリソース管理する「Application Auto Scaling」⁷
  • 様々なリソースのスケーリングを管理する「AWS Auto Scaling」⁸
• Auto Scaling Groupと呼ばれるEC2インスタンスの集合体を作る
  • 最小/最大インスタンス数を定義すると、それより小さく/大きくなる事は無い
  • 希望するインスタンス数を定義すると、その台数になるように調整される

希望するインスタンス数？

• サイズ維持
  • 障害などで停止した際、差分を検知して追加してくれる
• 手動スケーリング
  • 希望する数を手動で変更し、台数を変更させる
• 自動スケーリング
  • 様々な条件に応じて、希望する数を動的に変更し、台数を変更させる

スケール動作時に「インスタンスの分散」を重要視する

• 複数のAZにまたがってグループを作成している時、各AZ間で均一にインスタンスを配置しようとする
  • インスタンス数が最も少ないAZに新規起動する

設定方法

• 概要が掴めたところで、早速、使ってみたいと思います。
  • かくいう私も、初めて設定するので、ドキドキしながら設定してみます。
  • AMIの設定については、独自AMIを使うでも良いですし、各自の状況に合わせて変更してください。

起動設定を作成する

1. EC2コンソールを開く

2. リージョンを確認する（指定したリージョンに紐づく）

3. Auto Scaling ＞ 起動設定 を選択し、「起動設定の作成」を選択する
   

4. 情報を入力して、「起動設定の作成」を選択します

項目名	設定値
名前	my-launh-conf
AMI	ami-0218d08a1f9dac831(Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type )
インスタンスタイプ	t2.micro
追加設定	デフォルトのまま
ストレージ	デフォルトのまま
セキュリティグループ	デフォルトのまま（新規作成、全IPからのSSH許可）
キーペア	既存のキーペアの選択

AutoScalingグループを作成する

1. EC2コンソールを開く

2. リージョンを確認する

3. Auto Scaling ＞ Auto Scaling Group を選択し、「Auto Scaling グループの作成」を選択する
   

4. 情報を入力して、「AutoScalingグループを作成する」を選択する

   1. 複数ページに分かれているので、途中は「次へ」を選択する

項目名	設定値
名前	my-auto-group
起動設定	my-launh-conf（先程作成した起動設定を選択）
ネットワーク（AZとサブネット）	デフォルトで用意されているap-northeast-1a〜1dを選択
ロードバランシング	デフォルトのまま（ロードバランサがありません）
ヘルスチェック	デフォルトのまま
その他の設定	デフォルトのまま
グループサイズ（希望する容量）	2
グループサイズ（最小キャパシティ）	1
グループサイズ（最大キャパシティ）	3
スケーリングポリシー	デフォルトのまま（なし）
インスタンスのスケールイン保護	デフォルトのまま
通知を追加	なし
タグを追加	Key:Name, Value:AutoScaling, 新しいインスタンスにタグ付けをする:チェック

挙動確認

1. しばらくしてから、インスタンス一覧にアクセスすると、インスタンスが起動しているのがわかります。
   

2. 試しに、インスタンスを削除してみます。
   希望容量を「２」と設定しているので・・・？
   

3. しばらくすると、新しくインスタンスが起動していますね！
   ちゃんと、希望通りの数となりました。
   

あれ？じゃあ、どうやってインスタンスを終了させたら良いの？

• スケーリングポリシーが設定してあるのであれば、「有効化/無効化」を変更することができます⁹
  • ※今回は設定していないです
• ポリシーを設定していない場合は、Auto Scaling Groupを削除する必要があるみたいです
  • Auto Scaling Groupを削除すると、紐付いていたEC2インスタンスも削除されます
  • 「ゴミを残しておかない」という観点からも、起動設定も削除しても良さそうです

おわりに

• ようやく「やってみた」感を出せるようになってきました。
  • ドキュメントをまとめるだけではなかなか理解し難いところもあるので、実際にサービスを触ってみて、理解して行こうと思います。
  • 今回のアドベントカレンダーの裏テーマは「知らないサービスを触ってみる」なので！

「AutoScalingも触ったこと無いのかー（ぶぶっ」と、思われても仕方なし。
愚直に、一つずつでも、触ってみるしかないぞー。そんな精神で、やっていこうと思います。

今回はここまでです。
ありがとうございました。

1. EC2 BlackBelt ↩

2. インスタンスタイプ 公式ドキュメント ↩

3. インスタンスストア 公式ドキュメント ↩

4. EBS 公式ドキュメント ↩

5. AutoScaling BlackBelt ↩

6. EC2 AutoScaling 公式ドキュメント ↩

7. Application Auto Scaling 公式ドキュメント ↩

8. AWS Auto Scaling 公式ドキュメント ↩

9. スケーリングポリシーの有効化と無効化 公式ドキュメント ↩