AWS EC2(7)Auto Scaling

EC2 Auto Scalingとは

EC2 Auto Scalingを用いることで、アプリケーションの負荷を処理するための適切な数のEC2インスタンスを利用することができる、。Auto Scalingを利用するためには、Auto Scalingグループと呼ばれるEC2インスタンスの集合を定義し、このグループに含まれる最小と最大のインスタンスの数を定義する。また、希望するインスタンス数(Desired capacity)を定義することも可能。また、Auto Scalingグループ内のEC2インスタンスを複数のAZに分散配置することで、地理的な冗長性や安全性を実現できる。

Auto Scaling グループ

Auto Scalingを用いることで、耐障害性や可用性が向上する。また、必要な数のインスタンスのみ起動されるため安定的なパフォーマンスを低コストで実現することができる。

Auto Scalingグループ内の各EC2インスタンスの負荷に偏りが発生した場合は、古いインスタンスを終了して新しいインスタンスを起動させる。この場合にスムーズに処理が継続されるように、一時的に最大容量に対して10%のマージンが確保される

ライフサイクル

Auto Scalingのライフサイクルは以下の通り。

ライフサイクル

Auto Scalingグループはグループ内のインスタンスに対して定期的にヘルスチェックを行なっている。スケールイン/アウトは、手動もしくはスケーリングポリシースケジュールに基づき実行される。スケールイン、ヘルスチェックの失敗、Auto Scalingグループからの離脱等が発生した場合には、Auto Scalingグループ内のEC2インスタンスは終了処理が実施される。

Auto Scalingグループ

起動設定

Auto Scalingグループ内のEC2インスタンスは、起動テンプレートもしくは起動設定の設定内容に基づいて起動される。これらには、AMIのIDやインスタンスタイプ、ネットワーク設定、ストレージの設定、オンデマンドインスタンスとスポットインスタンスの配分等が含まれる。また、起動設定は、既に起動済みのインスタンスの属性を使用して作成することも可能である。Auto Scalingグループに関連付けられる起動設定は1つだけであり、グループ作成後に変更することはできない。Auto Scalingグループに関連づける起動設定を変更する場合は、現在の起動設定をコピーした上で新たな起動設定を作成し、これを当該のAuto Scalingグループに紐づける。

ロードバランサとの連携

Auto Scalingで増減したインスタンスに対して適切にトラフィックが分散されるようにするためには、Elastic Load Balancingの受信トラフィックの通信先にAuto Scalingグループを指定する。Auto Scalingのヘルスチェックは、通常EC2のステータスチェックのみであるが、オプションでELBのヘルスチェックを用いてAuto Scalingグループのヘルスチェックを行う設定にすることも可能である。この場合、ELBから送られる定期的なPINGに応答しないなど、ELBのヘルスチェック合格しなかった場合、このインスタンスは異常ありと判定されて他のインスタンスに置き換えられる。

スケーリング

Auto Scalingでは、以下のスケーリング方法を実施可能である。

  • 現在のインスタンスレベルの維持
  • 手動スケーリング
  • スケジュールに基づくスケーリング
  • 要求に基づくスケーリング(動的スケーリング

CloudWatchのメトリクスを利用して複数のスケーリングポリシーを適用することも可能である。例えば、EC2のCPU使用率を指標としたポリシーと、SQSのメッセージ処理に関するメトリクスを指標としたポリシーを同時に適用する、といったような場合である。複数のポリシーが適用となった場合は、より影響を与えるポリシーの実行命令が優先される

スケジュールされたスケーリング

あらかじめ指定したスケジュールに沿って、スケーリングアクションが実行されるように指定することが可能である。スケーリングアクションが有効になる時間と、最小/最大サイズ希望するサイズを指定する。このスケジュールは、1回のみ実行することも定期的に実行することもできる。

スケジュールされたスケーリングを作成する場合、ほとんどの場合指定した時刻から数秒以内に実行されるが、最大2分ほど遅れる可能性もあるので留意が必要である。また、複数のスケジュールを同時刻に設定することはできない。

動的スケーリング

動的スケーリングは、以下の方法をサポートしている。

ポリシー名 トリガおよび動作
Target tracking scaling 特定のメトリクスのターゲット値を維持するようにスケーリング
Step scaling 複数のスケーリング調整値をトリガにスケーリング
Simple scaling 1つのスケーリング調整値をトリガにスケーリング

Simple scaling および Step scaling

トリガに基づいてスケーリングが実行される際には、以下の調整タイプに基づいてスケーリングが実行される。

調整タイプ 動作
ChangeInCapacity 指定した数だけ増減する
ExactCapacity 指定した数になるように増減する
PercentChangeInCapacity 割合指定する

また、Step scalingの場合は、新しく起動されたインスタンスがAuto Scalingグループに追加されるまでの待ち時間(ウォームアップ)を指定できる。

SQSに基づくスケーリング

SQSにキューが積み上がり、処理が遅延することがないようにするには、 SQSのデータを読み取り処理を行うEC2をAuto Scalingさせる必要がある。このAuto Scalingを適切にスケーリングさせるためには、 Amazon SQS メトリックスApproximateNumberOfMessagesを用いてキューの長さを測定した上で、1インスタンスあたりの処理能力を計算しどの程度スケーリングさせる必要があるか指定する。

SQSに基づくスケーリング

クールダウン

メトリクス値が短期間で増減し、その度にスケーリングが実行されることを防ぐために、クールダウン期間が設けられている。デフォルトのクールダウン値は300秒。クールダウン期間は新たなスケーリングは実行できない。なお、このクールダウンが有効なのは、Simple scalingのみ。

インスタンスの停止

スケールイン時に停止されるインスタンスは以下の条件で決定される。

  1. インスタンスが最も多いAZ
  2. 最も古い起動設定またはテンプレートを使用している
  3. 次の課金開始時間に近いインスタンス

終了時ポリシーはカスタマイズが可能である。また、終了から保護するインスタンスを指定することもできる。

ポリシー名 実行内容
OldestInstance 最も古いインスタンス
NewestInstance 最も新しいインスタンス
OldestLaunchConfiguration 最も古い起動設定のインスタンス
ClosestToNextInstanceHour 次の課金開始時間に近いインスタンス
Default デフォルト(上記)
OldestLaunchTemplate 最も古い起動テンプレート
AllocationStrategy オンデマンド/スポットの割り当て戦略に合わせて決定

ライフサイクルフック

インスタンスの起動時もしくは削除時に一時停止して、カスタムアクションを実行できる機能。ソフトウェア等をインストールできる。

ライフサイクルフック

スケーリングプロセスの中断と再開

スケーリングプロセスの1つ以上を停止し、あとで再開できる。

スケーリングプロセス 内容
Launch インスタンスを追加
Terminate インスタンスを削除
HealthCheck ヘルスチェック
ReplaceUnhealthy 異常なインスタンスを削除し代替インスタンスを作成
AZRebalance AZ間のバランスを調整
AlarmNotification CloudWatchからアラーム通知を受け取る
ScheduledActions スケジュールされたアクションを実施
AddToLoadBalancer ELBに追加

注意事項

Auto Scalingは、バーストトラフィックには対応できない

AWS(1)AWSの概要とメリット

クラウドとは

クラウドとは、従量課金でWEB上からオンデマンド提供されるITリソースである。

AWSのメリット

AWSのメリットは、先行投資となる先行投資資本となるインフラコストを、ユーザのビジネス拡大にあわせた低額の変動費に移行できることである。また、スケールによる大きなコストメリットを享受することが可能で、自社環境よりも低い低額コストを実現できる。スケールアップおよびスケールダウンがわずか数分で実現できることから、キャパシティーの推測が不要となる。1クリックでITリソースを手に入れることが可能となるため、リソースを用意する時間が大幅に短縮され、組織の速度と迅速性が向上する。またこれらのことから、ユーザはデータセンターの運用や保守への投資が不要となり、ビジネスを差別化するプロジェクトに集中できる。また複数のリージョンに簡単にデプロイできることから、グローバル化も容易である。

グローバルインフラストラクチャ

リージョン

リージョンとは、世界中の物理的場所であり、リージョンに複数のアベイラビリティゾーン(AZ)が配置される。他のリージョンとは完全に分離されている

アベイラビリティゾーン(AZ)

独立したデータセンターで、冗長性ある電源とネットワーク、接続性を実現している。洪水の影響が及ばない場所に設置され、複数のTier1プロバイダに接続されている。各AZ間は低遅延リンクで接続されている。

サービス

AWSの各種サービスには、次の3つのサービスレベルがある。

種類 サービスの例
AZサービス EC2, RDS, ELB, ElastiCache
リージョンサービス S3, DynamoDB, SQS
グローバルサービス IAM, Route 53, Cloudfront

AWS導入の道のり

AWSを導入するためには、まず調査を行う。移行対象は非クリティカルなアプリケーションとし、セキュリティとユーザロール、VPCをセットアップ、開発/テスト環境をデプロイする。次に本番環境へアプリケーションを移行し、分析ワークロードをデプロイする。

本番環境に移行後に検討チームを結成し、プラットフォームの検討とAWSを拡張を行う。また、IT戦略を見直しクラウドに一致させる。また、DevOpsの導入オートメーションとコードリファクタリングを行う。

ベストプラクティス

AWSでは、オンプレミスとは異なるベストプラクティスが存在する。

  1. 故障に備えた設計で障害を回避
  2. コンポーネント間を疎結合で柔軟に
  3. 伸縮自在性を実装
  4. 全ての層でセキュリティを強化
  5. 制約を恐れない
  6. 処理の並列化を考慮
  7. さまざまなストレージの選択肢を活用

APNパートナーに提供されるサービス

APNパートナーは、AWSを導入する企業をサポートすることができる。APNパートナーには以下のツールが提供される。

AWSクイックスタート

人気の高いソリューションの AWS へのデプロイを支援するために、AWS ソリューションアーキテクトおよびパートナーによって構築されたもの

AWS コンピテンシープログラム

習熟した技術を持ち、専門的なソリューションエリアでお客様を成功させられることを実証した APN パートナーに付与

AWS Marketplace

AWSに最適化されたITおよびビジネスソフトウェアのカタログ

費用

AWSの費用体系は従量課金である。どの程度費用が掛かるかは簡易見積もりツールで計算できる。

総所有コスト

オンプレミス環境とクラウド環境の費用を比較する場合は、総所有コスト(TCO)を比較する必要がある。これは、購入と運用、撤去と廃止、機会コスト、サーバ、ストレージ、ネットワーク、人件費、機会コストなどを含む。施設のデフォルトコストは1ラックあたり月25万円+電気代とAWSでは考えている。総所有コストを計算し正しくオンプレミス環境とクラウド環境の費用を比較するためには、TCO計算ツールを利用する。