EC2 - moriwakihikari/SAA GitHub Wiki
プレイスメントグループ
- 複数のEC2インスタンスを論理的にグループ化し、インスタンス間での低遅延な通信やハードウェア障害による影響を軽減できる機能
クラスタープレイスメントグループ
- グループ内のEC2インスタンスを単一AZ内の物理的に近い距離に配置
- 各EC2インスタンス同士の通信は遅延が発生しにくく高速な通信が可能
- 可用性を犠牲にしてでもEC2インスタンス間の通信遅延を極力なくしたい場合に利用
パーティションプレイスメントグループ
- グループをパーティションと呼ばれる論理グループに分割、それぞれのパーティションに一つ以上のEC2インスタンスが所属する
- 各パーティションには一つのラックが対応して独立した電源とネットワークが配備されている
- グループ内の各パーティションはラックを共有しないからハードウェア障害による影響を軽減する
スプレッドプレイスメントグループ
- グループ内のEC2インスタンスを異なるハードウェア（ラック）に配置します
- パーティションプレイスメントグループではラック内に同一グループのEC2インスタンスを1つ以上配置しますが、スプレッドプレイスメントグループは同一グループのEC2インスタンスを1つしか配置しません
- グループ内の各EC2インスタンスはハードウェアを共有しないので、ハードウェア障害による影響を軽減します
- スプレッドプレイスメントグループは異なるAZにEC2インスタンスを配置することもできます
Amazon マシンイメージ（AMI）
- EC2インスタンスを起動するために必要な、OSやミドルウェアなどのテンプレート
インスタンスの種類
オンデマンドインスタンス
- インスタンスの起動時間に基づいた料金体系で、EC2インスタンスのデフォルトの購入オプションです。開発環境など、利用が短期間のシステムに適しています
スポットインスタンス
- AWS内で使用されていないEC2インスタンスを低価格で利用できる購入オプションです。
- インスタンスの需要が増加した場合やインスタンスの供給が減少した場合は、インスタンスが中断される可能性があります。
- 安定はしていない
リザーブドインスタンス
- 1年もしくは3年の長期契約を結ぶことによって、オンデマンドインスタンスよりも低価格で利用できる購入オプションです
インスタンスファミリー
- インスタンスタイプの用途別の分類です。
- インスタンスファミリーの分類は、汎用、コンピューティング最適化、メモリ最適化、高速コンピューティング、ストレージ最適化に用途が分けられています。
| インスタンスファミリー | インスタンスファミリーの分類 | 説明 |
|---|---|---|
| M | 汎用 | リソースのバランスが取れたインスタンスファミリーです。特定のリソースに偏りが無い為、多くの汎用に適しています。 |
| T | 汎用 (CPUバースト機能) | リソースのバランスが取れたインスタンスファミリーです。CPU使用量のバーストが可能（一時的に利用可能なCPU能力を実行可能）なので、アイドル時間が多い小規模なデータベースサーバーや開発環境に適しています。 |
| C | コンピューティング最適化 | 高性能なCPUを提供するインスタンスファミリーです。計算の高いハイパフォーマンスなサーバー、アプリケーションの計算Webサーバーなど、コンピューティング容量の高い環境に適しています。 |
| R, X | メモリ最適化 | 大容量のメモリを提供するインスタンスファミリーです。リアルタイムでのビッグデータ解析を処理するサーバーや、アクセス頻度の高いデータベースサーバーなど、大量のメモリを使用する環境に適しています。 |
| P, G, F | 高速コンピューティング | 高性能なGPUを提供するインスタンスファミリーです。機械学習実験や3Dグラフィックス生成に処理するサーバーなど、高速処理が求められる環境に適しています。 |
| I, D, H | ストレージ最適化 | 高性能なローカルストレージを提供するインスタンスファミリーです。高速なI/Oスループットや、大容量のローカルストレージが求められる環境に適しています。 |
Auto Scaling
動的スケーリング
シンプルスケーリング
- 一つのメトリクス（CPU使用率などシステムのパフォーマンスに関するデータ）に対する1つのしきい値に基づいて、インスタンスを増減します。
- 例：300秒間の平均CPU使用率が50％を超えたら、インスタンスを1台追加する
ステップスケーリング
- 1つのメトリクスに対する複数のしきい値に基づいて、インスタンスの増減を段階的に行います。
- 例：300秒間の平均CPU使用率が50％を超えたらインスタンスを1台追加し、90％を超えたら2台追加する
ダーゲット追跡スケーリング
- 1つのメトリクスが指定した目標値になるように、インスタンスを増減します。増減するインスタンス数はAWS側で調整されます。
- 例：平均CPU使用率を30％に維持する
動的じゃないスケーリング
スケジュールに基づくスケーリング
- 毎日10時にインスタンス台数を4台にする
ヘルスチェック
- リソースがEC2インスタンスの場合、Auto Scalingのヘルスチェックのタイプには「EC2」と「ELB」があります。
- 「EC2」はインスタンスのステータスチェックの結果を確認し、「ELB」は指定した接続先への応答確認をします。
- デフォルトでは「EC2」が有効、「ELB」は無効になっていますが、「EC2」「ELB」ともに有効にすることが推奨されています。
ライフサイクルフック
- スケーリング発生によるEC2インスタンスの起動または終了時に任意の処理を実行する機能です
- 例えば、スケールアウト（リソースの増加）によって新たに追加したインスタンスに初期化スクリプトを実行させたり、スケールイン（リソースの削減）によって終了するインスタンスのログを収集・退避させるといった処理を行えます。