さくらのクラウドのコンパネから設定できるオートスケール(オープンβ)を試してみる

さくらのクラウドのコンパネから設定できるオートスケールを試してみる

5月26日(木)よりリリースされた、さくらのクラウドのコントロールパネルで設定できる「オートスケール」機能を試してみましょう。

オートスケールとは

さくらのクラウドの「オートスケール」機能とは、サーバーの負荷を監視し、必要に応じて設定した負荷の閾値に到達したときにサーバーのリソースを追加したり、負荷が減った場合はリソースを減らす機能です。 これによって、監視者がパフォーマンスを常に監視してリソースのコントロールをする必要がなくなります。

制御方法

オートスケールのリソースコントロールの考え方は主に2つあります。

垂直スケール

サーバーのスペックを上げたり、下げたりしてコントロールする方法が垂直スケールです。上げることをスケールアップ、下げることをスケールダウンと呼んだりもします。 スペックの変更時にサーバーを停止する必要があるため、ダウンタイムが発生します。アプリケーションの継続稼働を考えると、後述の水平スケールと比較して、採用は少ないでしょう。

水平スケール

サービスを提供するサーバーのグループを構成し、サーバーを新たに追加したり、削除したりしてコントロールする方法が水平スケールです。追加をスケールアウト、削除をスケールインとも呼びます。この機能は一般的に「サーバーなどリソースのグループ」内でサーバー数を自動操作します。そのため、新しいサーバーの追加時、グループ内で既に存在するサーバー上のアプリケーションを停止することなく稼働できます。 一般的なクラウドサービスで単に”オートスケール”として提供される場合はこちらを指すことが多いでしょう。

垂直スケールを試してみる

それではまず、スペックの増減をコントロールする垂直スケールを試してみましょう。

スケールさせるサーバーを作成する

垂直スケールの動作確認には、サーバーは1台あれば良いでしょう。

まず、サーバーを1台作成します。ゾーンは好きなところで良いですが、今回は石狩第1ゾーンにしましょう。

名前プランNICOS
auto-scale-server11仮想コア / 1GB共有セグメント インターネットAlmaLinux 8.4

サーバー一覧画面から、次の画面のように作成されたサーバーを確認できます。

サーバー一覧画面

垂直スケールの設定をする

さくらのクラウドの「オートスケール」機能をコントロールパネルから利用する場合、事前に「作成・削除」の権限があるAPIキーを作成する必要があります。さくらのクラウドホーム画面よりAPIキーを作成しておきます。 コントロールパネル左のメニューより、オートスケールを選択し、右上の追加ボタンをクリックして設定していきましょう。

オートスケール追加ボタン画像

すると、次の画面になります。

オートスケール設定画面

必須の設定項目は以下の項目です。

  • APIキー
  • 設定ファイル
  • 監視対象が存在するゾーン
  • 監視対象のサーバー名のプリフィックス
  • 性能アップするCPU使用率
  • 性能ダウンするCPU使用率

1. APIキー

APIキーはさくらのクラウドホーム画面よりAPIキーを作成しておけば、リストから選択して利用できます。

2. 設定ファイル

今回は次のようにしました。

resources:
  - type: Server
    selector:
        names: ["auto-scale-server"]
        zones: ["is1a"]

    shutdown_force: false
    plans:
      - core: 1
        memory: 1
      - core: 2
        memory: 2
      - core: 4
        memory: 4

3段階でスケールするようにしています。最小は「1仮想コア / 1GB」、次に「2仮想コア / 2GB」、最大は「4仮想コア / 4GB」となります。

3. 監視対象が存在するゾーン

オートスケールによってコントロールさせたいサーバーがあるゾーンを選択してください。 複数選択も可能なので、他のゾーンも同時にオートスケールの対象にできます。 今回は、サーバーを作成した「is1a(石狩第1ゾーン)」を選択します。

4. 監視対象のサーバ名のプリフィックス

対象が存在するゾーンの接頭辞に合致したサーバーを指定します。 今回、対象にしたいサーバー名は”auto-scale-server1″で、石狩第1ゾーンに他のサーバーはないので、”auto-scale-server”を指定してみましょう。

5. 性能アップするCPU使用率

今回はオートスケール機能を試したいだけですので、閾値は低めに設定します。「60」を指定します。

6. 性能ダウンするCPU使用率

サーバーで特定のアプリケーションを動かさなければ20%を下回ると思われますので、「20」を指定します。

垂直スケールの動作を確認する

それでは、サーバー「auto-scale-server1」にログインして、負荷をかけてみましょう。 世の中には様々なベンチマークツールや、負荷を計測するツールがありますが、CPUに負荷がかかればよいので、さくらのクラウドのAlmaLinux 8.4で最初から使えるyesコマンドの出力を/dev/nullに捨てることで大きく負荷をかけ、topコマンドでチェックしましょう。

yes > /dev/null &

このようにしてバックグラウンドで実行できます。その後、topコマンドで負荷の状況を確認してみます。 topコマンドで大きな負荷がかかっていると確認できます。しかし、実際のところ、オートスケール機能がトリガーとするのは、アクティビティグラフ の「CPU TIME」であることに注意してください。 負荷が足らない場合、前述のコマンドを追加で動かせば更に負荷をかけられます。

topコマンド実行画面

さくらのクラウドのドキュメントによると10分間隔で検知するようですので、少し待ちます。

スケールアップが始まると、サーバーは一度、シャットダウンされます。コントロールパネルでサーバーのスペックが変更されているか確認してみましょう。

サーバー一覧画面

2仮想コア / 2GB のスペックに変更されているのが確認できると思います。

この時のログをコントロールパネルから確認できます。オートスケールの画面から、対象のオートスケール設定を選択し「詳細」をクリックしてください。

詳細ボタン

この時の該当のログは次のように表示されていました。

Jun 06 17:55:43 prod1 systemd[1]: Started SakuraCloud AutoScaler Input for XXXXXXXXXXXX.
Jun 06 17:55:44 prod1 cpu_threshold_scaling.sh[1923568]: 2022/06/06 17:55:44 auto-scale-server1 zone:is1a cores:1 cpu:1.030000 time:2022-06-06 17:50:00 +0900 JST
Jun 06 17:55:44 prod1 cpu_threshold_scaling.sh[1923568]: 2022/06/06 17:55:44 auto-scale-server1 avg:103.000000
Jun 06 17:55:44 prod1 cpu_threshold_scaling.sh[1923568]: Do Up
Jun 06 17:55:44 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:55:44+09:00 level=info request=Up message="request received"
Jun 06 17:55:44 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:55:44+09:00 level=info request=Up source=default resource= status=JOB_ACCEPTED
Jun 06 17:55:44 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:55:44+09:00 level=info request=Up source=default resource= status=JOB_RUNNING
Jun 06 17:55:44 prod1 cpu_threshold_scaling.sh[1923568]: status: JOB_ACCEPTED, job-id:
Jun 06 17:55:44 prod1 systemd[1]: autoscaler_113401014571_input.service: Succeeded.
Jun 06 17:55:44 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:55:44+09:00 level=info request=Up source=default resource= status=ACCEPTED
Jun 06 17:55:44 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:55:44+09:00 level=info request=Up source=default resource= status=RUNNING
Jun 06 17:55:44 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:55:44+09:00 level=info request=Up source=default resource= status=RUNNING log="shutting down..."
Jun 06 17:56:16 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:56:16+09:00 level=info request=Up source=default resource= status=RUNNING log="shut down"
Jun 06 17:56:16 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:56:16+09:00 level=info request=Up source=default resource= status=RUNNING log="plan changing: {Core:2, Memory:2}"
Jun 06 17:56:17 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:56:17+09:00 level=info request=Up source=default resource= status=RUNNING log="plan changed: {ServerIDFrom:XXXXXXXXXXXX, ServerIDTo:113401032293}"
Jun 06 17:56:17 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:56:17+09:00 level=info request=Up source=default resource= status=RUNNING log=starting...
Jun 06 17:57:09 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:57:09+09:00 level=info request=Up source=default resource= status=RUNNING log=started
Jun 06 17:57:09 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:57:09+09:00 level=info request=Up source=default resource= status=RUNNING log="waiting for setup to complete: setup_grace_period=60"
Jun 06 17:58:09 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:58:09+09:00 level=info request=Up source=default resource= status=DONE
Jun 06 17:58:10 prod1 autoscaler[1918713]: timestamp=2022-06-06T17:58:10+09:00 level=info request=Up source=default resource= status=JOB_DONE

「AutoScaler」や「cpu_threshold_scaling.sh」のログから、確かに自動でサーバーのスペックが上がっている様子ですね。

もちろん、このサーバーが「2仮想コア / 2GB」のスペックに対して設定した負荷の閾値を超えれば、「4仮想コア / 4GB」になります。

サーバー一覧画面

そして、負荷をかけずに放置すれば、「4仮想コア / 4GB」→ 「2仮想コア / 2GB」 → 「1仮想コア / 1GB」と設定した最小のスペックである、「1仮想コア / 1GB」まで段階的にスケールダウンしていきます。

サーバー一覧画面

サーバーのスケールダウンのログも確認できますね。

Jun 06 18:51:43 prod1 systemd[1]: Started SakuraCloud AutoScaler Input for XXXXXXXXXXXX.
Jun 06 18:51:44 prod1 cpu_threshold_scaling.sh[1927281]: 2022/06/06 18:51:44 auto-scale-server1 zone:is1a cores:2 cpu:0.050000 time:2022-06-06 18:45:00 +0900 JST
Jun 06 18:51:44 prod1 cpu_threshold_scaling.sh[1927281]: 2022/06/06 18:51:44 auto-scale-server1 avg:2.500000
Jun 06 18:51:44 prod1 cpu_threshold_scaling.sh[1927281]: Do Down
Jun 06 18:51:45 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:51:45+09:00 level=info request=Down message="request received"
Jun 06 18:51:45 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:51:45+09:00 level=info request=Down source=default resource= status=JOB_ACCEPTED
Jun 06 18:51:45 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:51:45+09:00 level=info request=Down source=default resource= status=JOB_RUNNING
Jun 06 18:51:45 prod1 cpu_threshold_scaling.sh[1927281]: status: JOB_ACCEPTED, job-id:
Jun 06 18:51:45 prod1 systemd[1]: autoscaler_113401014571_input.service: Succeeded.
Jun 06 18:51:45 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:51:45+09:00 level=info request=Down source=default resource= status=ACCEPTED
Jun 06 18:51:45 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:51:45+09:00 level=info request=Down source=default resource= status=RUNNING
Jun 06 18:51:45 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:51:45+09:00 level=info request=Down source=default resource= status=RUNNING log="shutting down..."
Jun 06 18:52:16 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:52:16+09:00 level=info request=Down source=default resource= status=RUNNING log="shut down"
Jun 06 18:52:16 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:52:16+09:00 level=info request=Down source=default resource= status=RUNNING log="plan changing: {Core:1, Memory:1}"
Jun 06 18:52:18 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:52:18+09:00 level=info request=Down source=default resource= status=RUNNING log="plan changed: {ServerIDFrom:XXXXXXXXXXXX, ServerIDTo:XXXXXXXXXXXX}"
Jun 06 18:52:18 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:52:18+09:00 level=info request=Down source=default resource= status=RUNNING log=starting...
Jun 06 18:53:10 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:53:10+09:00 level=info request=Down source=default resource= status=RUNNING log=started
Jun 06 18:53:10 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:53:10+09:00 level=info request=Down source=default resource= status=RUNNING log="waiting for setup to complete: setup_grace_period=60"
Jun 06 18:54:10 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:54:10+09:00 level=info request=Down source=default resource= status=DONE
Jun 06 18:54:11 prod1 autoscaler[1918713]: timestamp=2022-06-06T18:54:11+09:00 level=info request=Down source=default resource= status=JOB_DONE

以上で垂直スケールの動作を試せました。

水平スケールを試してみる

今度は垂直スケールの場合よりも、少しだけ実際のアプリケーションデプロイ環境を想定した構成で、水平スケールを試してみましょう。

さくらのクラウドドキュメントではエンハンスドロードバランサーを利用し、拠点間を跨いだ構成の例が記載されていますが、今回は分かりやすく試したいので、一つのゾーンのみで構成します。

準備

今回用意する構成は次の図のような構成です。

オートスケール最小構成時

オートスケールの対象とするのは、図中のAuto Scale Server Group です。

負荷がかかると、このサーバーリソースのグループ中でサーバーが増えていくように設定しましょう。

ソーリーサーバーも用意しています。

スケールアウトする際に、サーバーが作成されます。そのため、あらかじめ、必要な設定をしているサーバーの元を用意する必要があります。 そのため、元となるサーバーのディスク(今回の場合はauto-scale-server-baseのディスク)をストレージのアーカイブ機能を使って、作っておきましょう。

ディスクアーカイブ

水平スケールのコントロールパネルにおける設定は、垂直スケールを設定したときと、設定ファイルの記述が異なります。 今回は次のような設定にしています。

resources:
  - type: "ServerGroup"
    name: "AutoScaleServerGroup"
    
    server_name_prefix: "auto-scale-server"
    zone: "is1a"

    min_size: 1 # 最小1台
    max_size: 5 # 最大5台

    template: # 「仮想1コア / 1GB」のスペックのサーバーが追加されます。
      plan:
        core: 1
        memory: 1
        dedicated_cpu: false

      disks:
        - source_archive: "auto-scale-servers-disk" # ディスクは予めアーカイブに用意していたものを使います。
      edit_parameter:
        disabled: false
        host_name_prefix: "auto-scale-server"
        password: "totemohimitu"
        startup_scripts: # Apacheでサーバーを公開しているので、公開するコンテンツを作っておきます。
          - |
            #!/bin/bash
            cat <<EOL > /var/www/html/index.html
            <!DOCTYPE html>
            <html>
            <title>AUTO SCALE TEST SERVER</title>
            <body>
            <p>This is {{ .Name }}</p>
            </body>
            </html>
            EOL

      network_interfaces:
        - upstream:
            names: ["auto-scale-lan"]
          default_route: "192.168.10.1"
          assign_cidr_block: "192.168.10.31/24" # NICに割り当てられるIPの範囲を設定することができます。
          assign_netmask_len: 24

スケールの変更を観測しやすくするため、「仮想1コア / 1GB」にしてます。実際にサービスを提供する場合であれば、「仮想1コア / 1GB」が適切な選択であるとは限りませんので、スペック選択には注意してください。

今回のロードバランサーはアプライアンスの「ロードバランサー」です。バランシングの設定を事前にしておく必要があります。

エンハンスドロードバランサー(エンハンスドLB)であれば、この設定は必要ありません。

LB設定

最小の構成であれば、1台のサーバーのみがAuto Scale Server Groupに存在します。

この構成を構築する詳細な方法は割愛します。詳しくは、さくらのクラウドのドキュメントの「ロードバランサー」を参照してください。

試してみる

HTMLのbody中に設定したサーバー名も含めていますので、curlコマンドでサーバーに対してリクエストを実行し、応答を確認しましょう。

水平スケール最小時リクエストテスト

レスポンスが返ってくることが確認できました。

それでは、この構成で作ったサービスのWebサイト(ロードバランサーのIPアドレス)にApachBenchで負荷をかけてみましょう。 ※注意:やっていることはDoS攻撃とほぼ変わりませんので、実行時は注意してください。

$ watch "ab -n 200 -c 20 -t 600 http://XXX.XXX.XXX.XXX:80/"

topコマンドで確認すると、Load averageの値が高く、確かに負荷はかかっている様子です。

水平スケールtop確認画面]

しばらくすると、auto-scale-server-001という名前が付いたサーバーが立ち上がってきました。

水平スケールコンパネ画面サーバー2台

ログでも確認してみましょう。

Jun 09 12:08:43 prod1 systemd[1]: Started SakuraCloud AutoScaler Input for XXXXXXXXXXXX.
Jun 09 12:08:44 prod1 cpu_threshold_scaling.sh[2224242]: 2022/06/09 12:08:44 auto-scale-server-base zone:is1a cores:1 cpu:0.806667 time:2022-06-09 12:05:00 +0900 JST
Jun 09 12:08:44 prod1 cpu_threshold_scaling.sh[2224242]: 2022/06/09 12:08:44 auto-scale-server-base avg:80.666667
Jun 09 12:08:44 prod1 cpu_threshold_scaling.sh[2224242]: Do Up
Jun 09 12:08:44 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:44+09:00 level=info request=Up message="request received"
Jun 09 12:08:44 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:44+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=JOB_ACCEPTED
Jun 09 12:08:44 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:44+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=JOB_RUNNING
Jun 09 12:08:44 prod1 cpu_threshold_scaling.sh[2224242]: status: JOB_ACCEPTED, job-id: AutoScaleServerGroup
Jun 09 12:08:44 prod1 systemd[1]: autoscaler_XXXXXXXXXXXX_input.service: Succeeded.
Jun 09 12:08:44 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:44+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=ACCEPTED
Jun 09 12:08:44 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:44+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=RUNNING
Jun 09 12:08:44 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:44+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=RUNNING log=creating...
Jun 09 12:08:47 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:47+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=RUNNING log="created: {ID:XXXXXXXXXXXX, Name:auto-scale-server-001}"
Jun 09 12:08:47 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:08:47+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=RUNNING log="creating disk[0]..."
Jun 09 12:10:21 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:10:21+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=RUNNING log="created disk[0]: {ID:113401057143, Name:auto-scale-server-001-disk001, ServerID:XXXXXXXXXXXX}"
Jun 09 12:10:21 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:10:21+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=RUNNING log=starting...
Jun 09 12:10:57 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:10:57+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=DONE log=started
Jun 09 12:10:58 prod1 autoscaler[2223313]: timestamp=2022-06-09T12:10:58+09:00 level=info request=Up source=default resource=AutoScaleServerGroup status=JOB_DONE

この時に、curlコマンドでリクエストを投げると、auto-scale-server-001からレスポンスが返ってくることもあります。

auto-scale-server-001からの応答

更に負荷をかけてみますと、今回の設定では1台ずつ増え、最大5台になります。 今回は1台ずつスケールアウトをしていますが、このスケールの段階も設定ファイルで変更できます。

フルブーストモード

負荷をかけるのをやめ、しばらく放置していると1台に戻ります。

オートスケール放置後

マップから見るとネットワーク構成も確認しやすいですね。

マップ

以上で水平スケールの動作を試せました。

まとめ

オートスケールがさくらのクラウドのコントロールパネルから設定ができるので、オートスケールのためのサーバーの準備は必要ありません。基本的な利用方法であれば、コントロールパネルから設定を入れるだけで利用できます。これでオートスケールを導入する難易度が下がるでしょう。

オートスケールが利用できますと、監視者が常にサーバーを監視し、負荷やアラートを受けて手動でスペックを上げる手間や、サーバークラスタにリソースとなるサーバーを追加する作業がなくなります。 また、サービスに必要な時に必要なだけのリソースを自動で調整できるので、サービスダウンのリスクをコストパフォーマンス良く回避できます。

エンハンスドロードバランサーと共にオートスケールの設定を入れると、ディザスタリカバリも考慮しつつ、コストパフォーマンスを活かした構成も作るのも可能になります。

オートスケールは現在(2022年6月)時点ではまだβ版ですので、ご意見やご要望がありましたらさくらのユーザーフィードバックで問い合わせてみましょう!