【AWS-SAA勉強記】第1回_EC2/EC2 Auto Scaling編

この記事は作者本人がAWS-SAAの学習を通じて、曖昧や覚えづらい部分をサービス単位でまとめたものです。
特に、概要だけではイメージがわきづらいので、できるだけユースケースを活用して理解しやすいようにしています。
教材はSHOEISHAの[AWS教科書 AWS認定ソリューションアーキテクトアソシエイト テキスト＆問題集](https://www.amazon.co.jp/AWS%E6%95%99%E7%A7%91%E6%9B%B8-AWS%E8%AA%8D%E5%AE%9A%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%82%A4%E3%83%88-%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%EF%BC%86%E5%95%8F%E9%A1%8C%E9%9B%86-%E7%85%A4%E7%94%B0-%E5%BC%98%E6%B3%95/dp/4798183261/ref=sr_1_5?crid=3FF4OG65DFJ67&dib=eyJ2IjoiMSJ9.T249byXp1rsbDxkYXfxXb6fI4BUDNVOMSaquZL-1mVpPGu6oOTJAj19zZAYJR86Jon6ca0-q7sg_Ial5s1cea15f4gmNEJG8LyNQfNCbzfRWbdc3QShULjB2kryq34xDUkL-inBJMmFaiNYCb3lq0OcIRowzNObcgxFyIO96gEzEfcAYd2dxcSG6AHyl5e2DAQpdDy0xOEQZb_sRAX47vahzwyOMS8huPEScwArE3A0.zBHSxW-BjHBATnQ5vd4s6NikPxikuDNRnvEEGpF7d6A&dib_tag=se&keywords=aws+%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88+%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%82%A4%E3%83%88&qid=1724027719&s=books&sprefix=AWS%2Cstripbooks%2C195&sr=1-5)を参考にしています。

## EC2/EC2 AUto Scalingに関する曖昧な部分
EC2／EC2 Auto ScalingはAWSの初歩中の初歩であり、サービスの基本的な概要は割愛します。詳細の中で曖昧になりがちな部分は以下の通りです。（あくまでも私個人が曖昧であると感じた部分です）
* キーペア
* プレイスメントグループ
* Auto Scalingポリシー

本記事では、これらの内容やユースケースについて解説していきます。

## キーペア

### 概要
AWSにおけるキーペアとは、**公開鍵暗号方式を利用したセキュリティ認証のためのツール**です。具体的には、**公開鍵と秘密鍵のペアで構成されており、主にEC2インスタンスへのアクセスに使用**されます。

### 役割
|  名称  |  役割  |
| ---- | ---- |
|  公開鍵  |  EC2インスタンスに保存され、誰でも見ることができます。  |
| 秘密鍵 | あなたのローカルマシンに保存され、厳重に管理されます。この秘密鍵を使って、インスタンスへのSSH接続を行います。 |

`秘密鍵の管理: 秘密鍵は一度しかダウンロードできないため、紛失しないように注意が必要です。`
`セキュリティ: 秘密鍵を他人に渡さないようにし、適切に保護することが重要です。`

### ユースケース
キーペアは、**EC2インスタンスにSSHで安全にアクセスするために使用**されます。
例えば、ウェブサーバーをセットアップする際に、キーペアを使ってリモートからサーバーにログインし、必要なソフトウェアをインストールしたり、設定を行ったりします。

# プレイスメントグループ
### 概要とユースケース
AWSのプレイスメントグループは、**EC2インスタンスの配置を最適化**するための機能です。
これにより、**パフォーマンスの向上や耐障害性の強化**が図れます。
プレイスメントグループには以下の3種類があります。
|  グループ  |  特徴  |  ユースケース  |
| ---- | ---- | ---- |
| クラスタープレイスメントグループ | **同一のAZ内でインスタンスを密集**させ、**低レイテンシーと高スループット**を実現します。 | **高速なネットワーク通信が必要なアプリケーションや、分散コンピューティングのワークロード**に適しています。 |
| パーティションプレイスメントグループ | **インスタンスを複数のパーティションに分け、それぞれが異なるラックに配置**されます。これにより、**ハードウェア障害の影響を最小限に抑えます**。 | **大規模なデータ処理や、耐障害性が求められるアプリケーション**に適しています。 |
| スプレッドプレイスメントグループ | **各インスタンスを異なるラックに配置し、同時障害のリスクを減らします**。1つのAZ内で最大7つのインスタンスを配置できます。 | **少数の重要なインスタンスを分散**させる必要がある場合に適しています。 |

プレイスメントグループを利用することで、特定のワークロードに対して最適な配置戦略を選択でき、システムのパフォーマンスや信頼性を向上させることができるという訳です。
- クラスターは「集まり」という意味なので、EC2が密集していて早いんだなあ。
- パーティションは「仕切り」という意味なので、EC2が仕切られていて耐障害性が高いんだなあ。
- スプレッドは「広がり」という意味なので、EC2が分散させられていて耐障害性が高いんだなあ。

スプレッドパーティショングループとパーティションプレイスメントグループの違いが分かりづらいですね。

**大規模→パーティションプレイスメントグループ**
**小規模→スプレッドプレイスメントグループ**
と覚えましょう。

## Auto Scalingポリシー
### 概要
Auto Scalingポリシーは、EC2インスタンスの数を自動的に調整するための設定です。これにより、アプリケーションの需要に応じてリソースを増減させることができます。主なAuto Scalingポリシーには以下の種類があります。
- 動的スケーリングポリシー
    - ターゲット追跡スケーリングポリシー
    - ステップスケーリングポリシー
    - シンプルスケーリングポリシー
- スケジュールドスケーリングポリシー
- 予測スケーリングポリシー

スケジュールドスケーリングポリシーは、特定の日時に基づいてスケーリングを行うものです。
予測スケーリングポリシーは、CloudWatchからの履歴データを利用し、機械学習によるキャパシティの予測を行うものです。
この２つは文字の通りで理解し易いため、詳細は割愛します。

### 各動的スケーリングポリシーの特徴
まずは、各スケーリングポリシーの特徴を説明します。
|  名称  |  特徴  |
| ---- | ---- |
|  ターゲット追跡スケーリングポリシー  | 特定のメトリクス（例：CPU使用率）をターゲット値に維持するようにスケーリングします。**ステップスケーリング等と比較して、細かな設定を行う必要がないため、管理を容易**に行うことができます。 |
| ステップスケーリングポリシー | メトリクスの値に応じて段階的にスケーリングします。**CloudWatchアラームの設定に対して、上限値と下限値を設定することにより、多段階でかつ柔軟な制御**を行うことができます。 |
| シンプルスケーリングポリシー | 基本的にステップスケーリングと同様の設定を行うが、**一段階のアクション**のみの設定となります。多くの場合は、**将来的な拡張を考慮すると、シンプルスケーリングよりステップスケーリングの使用が勧められています。** |

### 各動的スケーリングポリシーのユースケース
#### ターゲット追跡スケーリングポリシー
オンラインゲームでは、プレイヤー数が時間帯やイベントによって変動します。
ターゲット追跡スケーリングポリシーを使用して、サーバーのCPU使用率やメモリ使用率を一定に保つことで、ゲームのパフォーマンスを最適化します。
例えば、大規模なゲームイベントやアップデートが行われる際に、プレイヤー数の急増に対応することができます。
 
#### ステップスケーリングポリシー
バッチ処理やデータ解析システムで、処理負荷が段階的に増減する場合に使用します。
例えば、夜間に大量のデータを処理するシステムで、負荷が高まるにつれてインスタンスを追加し、処理が終わると減らすといった使い方ができます。

#### シンプルスケーリングポリシー
特定のイベント（例：新製品のリリースやキャンペーンの開始）に応じてスケーリングする場合に使用します。例えば、新製品のリリース時にアクセスが急増することが予想される場合、事前にインスタンスを追加しておくことで、スムーズなサービス提供を実現します。
`ただし、セール等の開始時間が明確なケースの場合は、スケジュールドスケーリングポリシーの方が有効かもしれません。`

なお、これらのスケーリングポリシーは１つのAuto Scalingグループに対して併用することも可能です。


## まとめ
本記事では、以下のサービスについて概要とユースケースをまとめました。
* キーペア
* プレイスメントグループ
* Auto Scalingポリシー

あくまでも作者個人の曖昧な部分を整理したものですが、少しでもお役にたてたら幸いです。

次回は[【AWS-SAA勉強記】第2回_Amazon S3編](https://qiita.com/sknp/items/2776cd157c514e28e8dd)です。