パブリッククラウドなら自動でサーバー台数が変更できる
イベント系のWebサイトを運営していると、
時期によってリクエスト数が10倍や100倍になってしまうこともあるでしょう。
いや、嬉しんことではあると思うんです。
ビジネス的にはアクセスが増える分、儲けが多かれ少なかれ増えるということになりますから。
でも、2〜3倍程度だったらまだしも、
100倍って、そりゃー高負荷すぎてサーバーの処理が追いつかないよ。
って話じゃないですか？
だって、100倍ですよ？
あなたが１日８時間働いているサラリーマンだとします。
残業とかしまくって、頑張って12時間分の仕事をしました。
これでも1.5倍です。
１日で１人で800時間分の仕事をしなくちゃならないと思ったら、そりゃ無理って話ですよ。
オンプレミスでシステム構築する場合、
設計段階で、あらかじめこのような特性を想定してリソースを多く積むというのが常識です。
例えば上記のようなケースの場合、○の最大ポイントが処理できるリソースを確保するというわけです。
もし○のポイントが来てしまった場合、処理がさばけなくなってサービスに影響が出てしまいますからね。
お気づきかと思いますが、このような考え方だと、たしかに○のポイントは処理できますが、
それ以外のポイントは超リソースが余っている状態となってしまいます。
なんなら半分や1/3のリソースでも問題なく処理できてしまうでしょう。
つまり無駄なリソースにお金を払っている状態ということ。
無駄なお金を払っているならば、都度リソースを上げたり下げたりすればいいじゃん！
とお思いでしょうが、オンプレミスの場合、それをするために人の手が必要だった。
人の手がかかると、当たり前ですがお金がかかります。
工賃というやつです。
また、オンプレミスは従量課金制ではありません。
CPUやメモリを”買う”わけなので、必要なくなったから返却するなんてことはできません。
そんな中、パブリッククラウドが新しい概念を作り出しました。
自動でサーバー台数を増減させちゃおうぜ、ってこと。
AWSでは、自動でサーバー台数を増やしてくれるAutoScaling機能があります。
リクエスト数が増えてサーバーの負荷が高まると、
それを検知して自動でサーバーを複製して台数を増や（または減らす）します。
AWSは従量課金制ですから、このAutoScalingを上手く使うことで
無駄なリソース投資を限りなく０に近づけることが可能になります。
今回はAmazon EC2のAutoScalingをテーマにお話させていただきます。
AutoScalingとは？
AutoScalingとはEC2の機能の一つです。
例えば上記の図のように、ELB(Elastic Load Balancing)の配下に２台のEC2サーバーがあったとします。
リクエストが届くと、ELBがまず受け取って、配下のEC2サーバーへリクエストを渡します。
リクエスト数が増えるとサーバーへかかる負荷が高まります。
負荷が高まると、サーバーのCPUやメモリの使用率が増えます。
そのCPUやメモリの使用率をCloudWatchというAWSサービスが随時モニタリングをしていて、
ある一定の基準になるとアラートを出します。
そのアラートをきっかけとして、あらかじめ設定しておいたバックアップからEC2インスタンスを立ち上げます。
これが基本的なAutoScalingの仕組みです。
AutoScalingの利用料金
AutoScaling自体に料金はかかりません。
どんなに使っても無料です。
ただし、AutoScalingによってEC2インスタンスを増やしたら、
そのEC2インスタンスの利用分は課金されますのでご注意ください。
AutoScalingで注意すべきこと
便利なAutoScaling機能ですが、いくつか注意点があります。
- ELB(ロードバランサ)の利用が前提
- サーバーのローカルディスクにリクエストに依存する情報(例えばセッション情報等)を持たないこと
- サーバーの起動後すぐにサービス稼働できること
- サーバーの停止ができない（停止＝インスタンス削除）
- サーバーが立ち上がるまでに約10分前後の時間がかかること
そして、これが一番の注意点なのですが、
AutoScalingでスパイク対応することは無理です。
スパイクとは、突発的にリクエスト数が爆発的に増える現象の事を言います。
↓グラフで書くとこんな感じ。
で、上記5でも記載した通り、
AutoScalingを使ってサーバーを増やすためには10分前後の時間がかかります。
多少の準備時間がかかってしまうため、スパイクに対応させることは不可能なのです。
スパイク対応は、別の手段を考えましょう。
AutoScalingの設定方法
AutoScalingを使用する際、基本的には大きく以下の2つの設定が必要です。
- 起動設定の作成
- AutoScalingグループの作成
※尚、前提としてELBが作成されていることが必要です。
以下、「起動設定の作成」と「AutoSalingグループの作成」についてご紹介します。
起動設定の作成
それではAutoScalingによって自動で立ち上げるEC2自体の設定となる
起動設定を作成します。
(1)EC2コンソール画面を開きます
(2)左メニューの[起動設定]をクリックします
(3)[起動設定の作成]をクリックします
(4)立ち上げるAMIを選択します
※AMIとはEC2サーバーをまるっとコピーしたものです。EC2のテンプレートとも言えます。
AMIについてより詳しく知りたい場合は、こちらの記事をお読みください。
(5)インスタンスタイプを選択して[次の手順：詳細設定]をクリックします
(6)任意の起動設定の”名前”を入力し、[次の手順：ストレージの追加]をクリックします
(7)[確認]をクリックします
(8)[起動設定の作成]をクリックします
(9)キーペアを設定し[起動設定の作成]をクリックします
AutoScalingグループの作成
では次にAutoScalingグループの作成です。
ここでは、上記で作成したEC2自体の設定となる”起動設定”を使って、
いつ、どのような条件でEC2を立ち上げる（または落とす）のかを設定するグループを作成します。
(1)EC2コンソール画面を開きます
(2)左メニューの[AutoScalingグループ]をクリックします
(3)[AutoScalingグループの作成]をクリックします
(4)先ほど作成した”起動設定”を選択して、[次のステップ]をクリックします
(5)任意の”グループ名”を入力し、どのVPC、どのサブネットに所属させるかを設定します
(6)”高度な設定”で”ロードバランシング”にチェックを入れ、あらかじめ作成しておいたELBのターゲットグループを選択します
(7)[スケーリングポリシーの設定]をクリックします
(8)以下の2つから選択します
- このグループを初期のサイズに維持する
- スケーリングポリシーを使用して、このグループのキャパシティを調整する
1は、インスタンス数を固定するということ。例えば初期のサイズを2として、何らかの原因により1つダウンしても自動で2に戻してくれます。
2は、リクエスト状況によって動的にインスタンス数を変えるということ。例えば全体のCPU使用率が60%を超えたらインスタンスを１つ追加する等
下記画像では、インスタンス数は1〜3つの範囲とし、全体のCPU平均使用率が60%以上になったらインスタンスを1つ追加するルールとなります。
ちなみに「スケーリング後にウォームアップする秒数」というのは、
クールダウンの秒数です。
AutoScalingにてEC2を増やしてもすぐにリクエストを受け付けない等の理由でリクエストをさばくのに多少のタイムラグが発生する場合があります。
そのあいだ、他のEC2のCPU利用率は高いままとなりますので、AutoScalingが誤ってさらにインスタンスを増やしてしまいます。
これを防ぐために「この秒数は一旦様子みてね」という設定になります。
※デフォルトは300秒です。
(9)[次の手順：通知の設定]をクリックします
(10)通知設定を行い[次の手順：タグを設定]をクリックします
ここでは、インスタンスの増減や起動失敗等の際にEメール等で通知することを設定できます。
(11)タグ設定を行い[確認]をクリックします
(12)[AutoScalingグループの作成]をクリックします
AutoScalingグループが完成です。
以上がAutoScalingの基本的な設定方法となります。
これ以外にもAutoScalingには様々な設定がありますし、
今後のAWSのアップデートによって、さらに多くの機能が追加されていくと思います。
ぜひAutoScalingを活用してより良いシステムを開発していきましょう！
以上、hidesanでした！