みなさんこんにちは、もう今年もあとわずかですが、資格を取って有終の美を飾りたいですね！
ということで対策編の最終回は、これぞクラウドともいえる、Auto Scalingについてご紹介します。

まずスケールって言葉はご存知ですか？
インフラ系の仕事ではよく耳にする言葉ですが、日本語にすると「規模」。
大勢の人が利用するシステムは、サーバ一台では到底さばききれないので、予めどれくらい需要があるかを推測し、さらに余裕を持たせた規模（スケール）のリソース（サーバ、ディスク、ネットワークなどなど）を用意します。

ですが、例えば役所のオンラインサイトなど、昼間はアクセスが多いのに、夜はほとんどアクセスがないケースもよくあります。

それでもシステムダウンを防ぐため、リソースは最大の需要を満たすように用意しなければなりません。
オンプレミスでリソースを用意すると、どうしても無駄が発生してしまいます。
また、あるオンラインゲームのサービスを始めたところ、急に人気が出て需要予測を超え、リソースが足りずダウンしました、なんてこともあったりします。

そんな悩みを解決してくれるのが、Auto Scalingです。
その名の通り、需要に応じてリソースのスケールを自動で増やしたり減らしたりしてくれる機能です。

それでは早速、EC2を例にAuto Scalingを作成してみましょう。

EC2のダッシュボードの左メニューから、AUTO SCALINGを選択すると、作り方が図解されています。
Auto Scalingは、どんな条件のときにスケーリングするかを設定したグループを作成します。
そのグループがスケーリング時に起動するEC2のインスタンスをまず作成します（起動設定）

AMIの選択やストレージ、ネットワークやセキュリティの設定は、通常のEC2インスタンスの作成時と同じです。

起動設定の作成は数秒で完了します。

今度はAuto Scalingグループを作成します。

どんな条件になったらこのインスタンスを起動するかの設定を行います。
例えば、EC2のCPU使用率が一定値を超えたらインスタンスを増やすようにしてみましょう。
その逆に、CPU使用率が下がったら、インスタンスを減らして定常運転させるような設定もできます。

通知の設定を行うと、スケーリングが実行された際にメール等で通知を受けることができます。

グループを作成すると、起動設定に沿ったEC2インスタンスが作成されるので、少し時間がかかります。

EC2ダッシュボードに戻ると、EC2インスタンスが起動されています。
あとはこのEC2を使ってWEBサーバを構築するなりし、負荷が増えて条件に達したら、新たなインスタンスが起動されます。

さて、Auto Scalingグループの設定を見ていただくとわかるように、スケーリングのために様々な条件が用意されています。

例えば、先の例ではCPU使用率が上限を超えた場合を条件としました。このような単一の条件の設定をSimple scalingといいます。

これに対し上限を複数設け、それにより段階的に増やしていく設定を、Step scalingと言います。
（例えばCPU使用率が50%を超えたら一つ、80%を超えたら二つ、など）

さらに、CPU使用率が一定の値を維持するように（例えば負荷が上がっても50%を維持）、インスタンスを増減させる設定も可能です。これをTarget tracking scalingと呼びます。
このように、要件によってどのスケーリング設定を行うのが最適なのかを考える。それがソリューションアーキテクトに求められる能力なのです。

さてここまで、八回に渡りAWSの主要な機能を紹介してきました。
まだまだ説明しきれてない機能が沢山あるのですが、それこそ大規模な基幹システム向けであったり、使うには高度な知識と経験が必要となりますので、参考書の知識レベルで十分かと思います。
（決して手抜きではなく、効率化です^^;）
よって次回はいよいよ最終回、模擬試験と実際の試験の流れをご紹介しますので、お楽しみに！

お疲れ様です。大阪フットサル部です。

11月の快晴の日の活動報告になります。

秋も終わりに近づきつつあるこの時期でしたが、
気温も穏やかで最高の運動日和でした。

上手な方との練習試合は、個々人の上達に繋がっていきます。
継続は力なりとも言いますので、少しずつでも質が上がれば、
より楽しいフットサルができるようになります。

ただ、私は少し運動不足気味で、
技術については現状維持のまま。。。

もっと絞って華麗なプレイで
大勢を魅了できるようになりたく、
これからも精進していきます。

あと、興味持たれた方、
参加自由ですので、どしどしご参加ください。