柔軟なリソース増減を実現するAWSのオートスケーリング
目次
柔軟なリソース増減を可能にするAmazon EC2 Auto Scaling
AWS（Amazon Web Services）を導入する際には、QCD（Quality、Cost、Delivery）の観点から様々なメリットを得ることができます。しかし、AWSは導入時だけでなく、導入後についても運用を軽減できる仕組みが多数存在します。そのうちの一つが、Auto Scaling（オートスケーリング）です。Auto Scalingを利用することで、リソースを最適に保つだけでなく、構築したITシステムの可用性を向上させることにもつながります。
Auto Scalingのメリットや、使う際に気を付けるべきことについて、本記事で記載していきます。
Auto Scalingとは？
Auto Scalingとは、特定の条件によりITインフラのリソースを増減（スケーリング）調整するものです。AWSでは、様々なサービス（例えばEC2やDynamoDB）でAutoScalingの仕組みが利用できますが、本記事では、AWSのコンピューティングサービスであるEC2のAuto Scalingに絞って記載をしていきます。
EC2のAuto Scalingは、指定した条件によりインスタンス（サーバ）の台数を自動的に増減させることができます。Auto Scalingを利用することで得られるメリットは大きく分けて以下の3つです。
- ITシステムの可用性の維持
- 負荷分散
- コストの最適化
具体的なメリットについて、詳しく記載していきます。
オートスケーリング機能をフル活用して柔軟なシステムを実現するスタイルズのAWS導入・移行サービスはこちら→
Auto Scalingのメリット1：可用性の維持・向上
Auto Scalingは正常なインスタンスの数を維持し、システムの可用性を向上させることができます。AutoScalingは最低限のインスタンス数を指定し、そのインスタンス数を下回らないように設定しておくことが可能です。Auto Scalingの設定を行っているAmazon EC2 インスタンス群を「フリート」（Fleetは「艦隊」の意）と呼びますが、このフリート内の各EC2の状態をモニタリングして、インスタンス数を維持し続けることができます。
フリートの中のEC2に対して、Health Checkを行い、正常稼働しているかを確認し続け、万が一、異常なインスタンスが検出された場合は自動的に削除されて新しいインスタンスに置き換える、といったことを行います。
Auto Scalingのメリット2：負荷分散
Auto Scalingによりインスタンス数の増減をおこなうことで、システムの負荷分散を行うことができます。2台のインスタンスより4台のインスタンスのほうが、各インスタンスで処理されるアクセスの軽減が可能になるため、稼働が安定します。
このように、繁忙期にスケジューリングして意図的にインスタンス台数を増やし、負荷分散を行うことができます。また、CPUなどのEC2リソースが高騰した場合についてもインスタンスを増やす、といった動的なインスタンスの増減も可能です。
Auto Scalingのメリット3：コストの最適化
ITシステムの利用者は時間や時期によって一定であることは少なく、常に増減を繰り返します。実際のオンラインのサービスやシステムでは、繁忙期の利用増や閑散期の利用減などが生じる場合が多いです。例えば、仕事で利用するSaaSなどは、仕事をしている人が多い昼間であれば利用者が多い一方で、夜間の利用者は非常に少ないことが容易に想像できます。
大学入試の合格発表システムは、合格発表が行われる2月～3月に、通常より多くの利用者が予想されます。そして合格発表が行われる期間が終了すれば、それ以外の期間はほとんど利用者が現れないでしょう。従来のITインフラであれば、繁忙期のアクセス数を予想して物理サーバを購入し、データセンターにラッキングするため、閑散期には購入した物理サーバが無駄になってしまいます。
Auto Scalngのように、インスタンス数の増減を時間や時期によって柔軟にしておくことができれば、リソースのコストを最適化しておくことができます。
AZ分散方式でもできるAuto Scaling
Auto Scalingによりインスタンス数を増やしても、サーバが起動しているAZ（Availability Zone）が偏ってしまっていると、AZ障害が発生した場合に可用性が確保できません。そのような事態に備え、Auto Scalingはインスタンスの配置先AZも分散設定を行うことが可能です。
これにより、さらなる可用性の向上が見込めます。
Auto Scalingを導入する上での注意点とは？
Auto Scalingは非常に便利な機能ですが、同時に注意点も存在します。注意点について記載していきますので、運用の際には考慮に入れておくといいでしょう。
インスタンスの作成や削除の状態を監視する
Auto ScalingはHealth chechを行い、インスタンスが正常に稼働しているか否かを判断して、インスタンスの増減を行います。Auto Scalingにより起動したインスタンスは、起動後すぐにアプリケーションとしての稼働やアクセスなどの処理が可能な状態にとなり、Health Checkに合格するようになっていなければいけません。
頻繁にインスタンスが起動と終了を繰り返しているのであれば、Auto Scalingで起動するインスタンスの元となる、AMI(Amazon Machine Image)に異常がある可能性があります。また、アプリケーションのコンテンツやコードの更新を行ったのに、AMIには更新が反映されておらず、Auto Scalingが行われた際にインスタンスの状態がデグレートしてしまう、といったこともよく発生します。インスタンスのもととなるAMIの運用は事前に考慮しておくといいでしょう。
オートスケーリング機能をフル活用して柔軟なシステムを実現するスタイルズのAWS導入・移行サービスはこちら→
インスタンス消滅時の、永続的データ消失に注意
Auto Scalingで起動したインスタンスは、停止は行われず、消滅（Terminate）されます。つまり、Auto Scalingで起動したインスタンスに置いてあるデータは、いつ消えるかわからないということになります。したがって、Auto Scalingにより起動したインスタンスの内部にはデータは保持しないことが重要となります。具体的には、以下のようなデータはインスタンスの終了とともに消えないように、S3などに退避しておくように工夫しましょう。
- 監査ログやセキュリティログなどの、アプリケーションで生成された永続的に保管すべきデータ・利用者からアップロードされたデータなど
- 利用者のセッションデータ
- OSやミドルウェアが出力するログファイルのうち、障害対応などで必要なもの
上記のようなデータについては、『ライフサイクルフック』という機能を使い、保持しておくといいでしょう。ライフサイクルフックでは、インスタンスが終了する際に、ログをS3に送る、EBSスナップショットを取得する、といったアクションを設定しておくことができます。このようなアクションを行うことで、データの保持が可能になります。
急激なトラフィック増には対応が間に合わないことも
Auto Scalingは、クールダウン期間と言って、新しいインスタンスが追加されるまでの待ち時間が存在します。なぜクールダウン期間が必要かというと、CPUの使用率が80%でインスタンスが増えるという設定がされていた場合、インスタンスが増えるまでは数分の時間を要するため、その間CPUの使用率が閾値を超え続け、インスタンスが増え続けてしまうためです。
したがって、急速にサーバ台数を増やすことができないため、急激な負荷の増加に対して対応するのは困難です。CloudFrontなどを利用して、インスタンスの負荷が増大しないように工夫するといいでしょう。
まとめ
Auto Scalingは自動でサーバの増減を実現できる、クラウドならではの非常に便利な機能です。Auto Scalingを使うことで、可用性の確保や負荷分散が可能になり、高品質なITシステムの提供が可能になります。また、自動でサーバの増減が可能になるため、運用における人的リソースも削減ですることが可能です。
様々な機能があり非常に便利な機能である一方で、運用面で考慮すべきことも多いことも特徴です。運用面で不安がある場合には、詳しいベンダー等に相談してみるといいでしょう。