Fusicの@maimyです。今年10月にjoinしていました🙋🏻♀️
日々楽しくたくさんのインプットをさせてもらっています。
この記事はFusic Advent Calendar 2023の9日目の記事です。
何を書くか迷いましたが、AWS認定試験の対策も兼ねてAWS EC2のあれやこれやを整理してみます。試験勉強をしている誰かの助けにもなれば幸いです。
はじめに
話すこと
- EC2オートスケーリング
- EC2プレイスメントグループ
何があるのか？という部分をざっくりまとめます。
話さないこと
- EC2そのものや設定方法についての詳しい話とメリデメ
EC2とは
Amazon EC2（Amazon Elastic Compute Cloud）とはAWSが提供する仮想マシンサービスです。コンピュータを仮想化するためのハイパーバイザーと物理的な部分全てをAWSがいい感じに管理・運用してくれています。
AWSが管理するのはあくまでハイパーバイザー層と物理領域のみです。EC2の利用者は使いたい仮想マシンを「どこに」「どのように」「どれくらい」確保して「どのように動かすか」設定することができます。
そういった「使い方」をユースケースに応じて柔軟に設定できるため、EC2にまつわる設定は様々です。
参考：AWS Black Belt Online Seminar AmazonEC2入門
オートスケーリング
EC2はCPU/GPUやメモリ、ストレージ等を重視して最適化したインスタンスタイプを選択し、需要に合わせた必要数を準備することで使い始めることができます。しかし実際のビジネスにおいて需要は一定ではなく予測不能なことがあります。そこで決められたキャパシティのインスタンスを固定で準備するとどうなるでしょうか？
波のある需要に対して固定のインフラを用意しておくと、必要以上に準備して無駄なコストを使ってしまったり、あるいは必要なキャパシティーが足りずに機会を損失したりしてしまいます。
その問題を解決するのが AutoScaling です。「いつ」「どれくらい」「どのように」インスタンスを起動するかを需要に応じて柔軟に制御できます。
AutoScalingの動き
-
必要なキャパシティ（インスタンス台数）の維持
希望容量（DesiredCapacity）を指定することでその数にインスタンス数を維持します。例えば希望容量を4に指定すると、4台のインスタンスを起動中に1台のインスタンスで何か障害が起きて3台になってしまった場合にAutoScalingが自動的にインスタンスを1台補填することでインスタンス数4を維持します。
-
条件に応じてインスタンスの台数を増減
さらに最小値（min）と最大値（max）、条件（CPU使用率などのメトリクス）を指定することで希望容量（Desired Capaciry）を自動的に増減します。
-
使用AZにインスタンスを均等配置
複数AZにまたがるAutoScalingでは、各AZに均等にインスタンスを配置しようとします。
また3AZ構成で6台のインスタンスを起動していた場合は通常各AZに2台配置されますが、1AZで障害発生時に2AZ構成になると各AZに3台配置（＝合計6台）という動きをします。
スケーリングポリシー
-
簡易スケーリング、ステップスケーリング
CloudWatchアラームのスケーリングメトリクスとその閾値を指定します。
簡易スケーリングもステップスケーリングもアラームの上限閾値と下限閾値を指定しますが、ステップスケーリングの場合は閾値にステップ調整を設けることができ、それぞれに対してインスタンス数を指定することができます。（簡易スケーリングはほぼ非推奨） -
ターゲット追跡スケーリング
指定したメトリクスの目標値を指定することで自動的にスケーリングします。ステップスケーリングとの違いは、ターゲット追跡スケーリングで設定するのはメトリクスの目標値のみでインスタンス数の指定が不要という点です。例えばCPU使用率の目標を50%に指定した場合、CPU使用率が50%になるようにインスタンス数を自動的に増減します。
需要曲線に厳密に従うことができるため、AWSはこちらを推奨しています。
より細かいステップ、インスタンス数の指定が必要な場合にステップスケーリングを採用します。
ターゲット追跡スケーリングとステップスケーリングの違い -
予測スケーリング
指定した期間のメトリクスを分析して、次の需要を予測してインスタンス数を増減します。予測される負荷に先立ってインスタンスを起動するためスケーリングがより迅速です。
営業日時によるサイクルや定期的なワークロードパターンがある場合、アプリケーションの初期化に時間がかかる場合などに役立ちます。 -
スケジュールスケーリング
日付・時刻によって予測可能なワークロードがある場合に指定した日時・キャパシティに応じてスケーリングすることができます。
これらのスケーリングポリシーを組み合わせることで柔軟かつ需要に合ったスケーリングを行いコスト最適化につながります。またスケーリング時の挙動などさらに細かく設定できる機能もあります。
参考：AWS Black Belt Online Seminar Amazon EC2 Auto Scaling 入門編 / Amazon EC2 Auto Scaling スケーリングポリシーとおすすめ機能編
プレイスメントグループ
またオートスケーリングとは全く異なる機能として、インスタンスを「どこに」「どのように」配置するかを設定できる プレイスメントグループ があります。
ネットワーク遅延をなるべく低くしてパフォーマンスを向上させたり、基盤となるハードウェアで障害が発生した際の影響を最小限に抑えたりすることを目的とします。
プレイスメントグループは三種類あり、インスタンスの物理的な配置方法を指定することができます。
クラスタープレイスメントグループ
単一AZ内で物理的に近いハードウェア上にインスタンスを配置します。
物理的に近い場所でインスタンスを起動することで、インスタンス同士の通信においてレイテンシーを最小限に抑え、高スループットを実現します。
【ユースケース】 高性能コンピューティング（HPC）、大規模データのクラスタリング
パーティションプレイスメントグループ
単一AZ内で複数のパーティションに分割してインスタンスを配置します。
パーティションは「仕切り」を意味します。一つのパーティション内で独自のハードウェアを使用し、各パーティションはそれぞれ物理的に異なる場所に配置されます。これにより、ハード障害が発生した場合にそのパーティション内のみに影響を抑えます。
【ユースケース】 Cassandra、Apachce Hadoop（分散処理技術）等の分散システム
スプレッドプレイスメントグループ
単一AZ内で各インスタンスそれぞれに独自のハードウェアを割り当てます。
パーティションプレイスメントグループでは複数のインスタンスを均等に分割するのみでしたが、スプレッドプレイスメントグループではインスタンスそれぞれに固有のハードを用意します。少数の重要なインスタンスを互いに確実に分離する必要がある場合はこちらが推奨。
まとめ
EC2はハードの部分をAWSが管理・運用しており利用側はサーバーを必要な時に必要なだけ簡単に使用することができる（リソースを使い捨てられる）というメリットがあります。「必要なだけ」を柔軟に指定することができ、その設定方法・運用方法は多岐に渡ります。
個人的にはEC2は 5W1H をかなり柔軟に細かく設定できるのだと思いました。調べていく中で1記事におさめるには膨れすぎる！と感じるほど多く運用方法がありました。書ききれなかったこととして特に購入オプションやEC2フリートなどについてまた記事にできればと考えています。
Discussion