さくらのクラウドでオートスケールを検証|CPU負荷に応じてWebサーバを自動で増減させる

さくらのクラウド

こんにちは。kuuです。

今回は、さくらのクラウドの「オートスケール」を使って、
CPU使用率に応じてWebサーバを自動で増減させる構成を検証しました。

サーバが自動で作成されるところから、エンハンスドロードバランサへの登録、
アクセスの振り分け、負荷が下がった後のサーバ削除まで確認していきます。

今回検証する構成

オートスケールには、CPUやメモリなどのスペックを変更する「垂直スケール」と、サーバの台数を変更する「水平スケール」があります。

今回は、サーバの台数を増減させる水平スケールを使用します。

常時稼働するベースサーバを1台用意し、そのCPU使用率が高くなったら追加サーバを1台作成します。CPU使用率が下がったら追加サーバを削除し、元の1台構成に戻します。

リソース名前役割
ベースサーバAutoScale-base常時稼働するWebサーバ。CPU使用率の監視対象
追加サーバAutoScale-worker-001オートスケールによって作成・削除されるWebサーバ
アーカイブAutoScale-template追加サーバの作成に使用するテンプレート
エンハンスドLBAutoScale-elbWebサーバへのアクセスを振り分ける
オートスケール設定AutoScale-testCPU使用率の条件と追加サーバの構成を設定する

今回のポイントは、CPUを監視するベースサーバと、自動で増減する追加サーバを分けていることです。

ベースサーバは常に残し、追加サーバだけを0〜1台の範囲で増減させます。そのため、Webサーバの合計台数は1〜2台になります。

主な設定は次のとおりです。

項目設定
サーバ・アーカイブのゾーン石狩第3ゾーン(is1c)
OSAlmaLinux 9系
WebサーバApache
エンハンスドLB石狩リージョン、100cpsプラン
通信HTTP/80番ポート
スケールアウト条件監視対象の平均CPU使用率が50%以上
スケールイン条件監視対象の平均CPU使用率が20%以下

今回は、CPU負荷を直接かけて自動増減の動作を確認します。Webサイトの処理性能を測る負荷試験とは異なります。

ベースサーバを準備する

サーバの作成

コントロールパネルで石狩第3ゾーンを選択し、ベースとなるサーバを作成します。

ホスト名は AutoScale-baseとし、AlmaLinux 9系のディスクを使用します。SSH接続用の公開鍵も登録しておきます。

Apacheのインストール

ベースサーバにSSH接続し、Apacheをインストールします。以降のサーバ上の操作はroot権限で行います。

dnf install httpd

続いて、テストページを配置するディレクトリを作成します。

mkdir -p /var/www/autoscale

Apacheの設定ファイルを作成します。

vi /etc/httpd/conf.d/autoscale.conf

設定内容は次のとおりです。

<VirtualHost *:80>
    ServerName example.com

    DocumentRoot /var/www/autoscale

    <Directory /var/www/autoscale>
        Require all granted
    </Directory>

    ErrorLog /var/log/httpd/autoscale_error.log
    CustomLog /var/log/httpd/autoscale_access.log combined
</VirtualHost>

テストページの作成

ロードバランサを経由した際に、どちらのサーバが応答したか分かるよう、ページ内にサーバ名を表示します。

vi /var/www/autoscale/index.html

以下の内容を記載します。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>オートスケールテスト</title>
    <style>
        body {
            font-family: sans-serif;
            text-align: center;
            margin-top: 100px;
        }
    </style>
</head>
<body>
    <h1>オートスケールテスト</h1>
    <p>server: autoscale-base</p>
</body>
</html>

Apacheの設定を確認します。

httpd -t

構文エラーがないことを確認したら、Apacheを起動し、自動起動を有効にします。

systemctl enable httpd --now

起動状態も確認しておきます。

systemctl status httpd

AlmaLinux 9の環境ではデフォルトでfirewalldが動作しているため、HTTP通信を許可しました。

firewall-cmd --zone=public --add-service=http --permanent

設定を再読み込みします。

firewall-cmd --reload

追加サーバ用のアーカイブを作成する

追加サーバは、Apacheを設定済みのベースサーバから取得したアーカイブを使って作成します。

これにより、スケールアウトするたびにApacheをインストールすることなく、Webサーバとして必要な設定を引き継げます。

石狩第3ゾーンの「ストレージ」→「アーカイブ」を開き、追加します。

項目設定
アーカイブソースディスク
コピー元AutoScale-base に接続している20GBのディスク
名前AutoScale-template

今回の検証では、コピー元のディスク名も AutoScale-base としています。

作成後はコピーの完了を待ち、有効状態が「利用可能」になったことを確認します。

アーカイブの作成にサーバ停止が必須というわけではありません。ただし、ディスクへの書き込み中に取得すると、データの整合性が取れない場合があります。

公式マニュアルでは、サーバを停止するか、サーバに接続されていないディスクを使用することが推奨されています。データベースなど、書き込みが発生する環境を複製する際は取得方法に注意してください。

参考:さくらのクラウド マニュアル「アーカイブ」

エンハンスドロードバランサを設定する

エンハンスドLBの作成

「グローバル」→「エンハンスドLB」から、AutoScale-elb を作成します。

主な設定は次のとおりです。

項目設定
名前AutoScale-elb
設置先リージョン石狩リージョン
プラン100cps
セッション維持無効
監視方法HTTP
監視パス/
チェック間隔10秒

サーバの作成先は「石狩第3ゾーン」ですが、エンハンスドLBの設置先は「石狩リージョン」となります。

待受ポートの設定

「待受ポート」タブから、HTTPの80番ポートを追加します。

今回はHTTPで動作確認するため、HTTPSへのリダイレクトは無効にします。

ベースサーバの登録

続いて、「実サーバ」タブからベースサーバを登録します。

項目設定
IPアドレス「サーバから選択」で AutoScale-base を選択
ポート番号80
TLS/SSL無効
有効/無効有効

待受ポートと実サーバを追加したら、画面上部の「反映」を押します。

反映後、実サーバのステータスが「UP」になっていることを確認します。

ブラウザからエンハンスドLBのVIPへアクセスし、テストページが表示されることも確認します。

この時点ではベースサーバのみを登録しているため、ページには server: autoscale-base と表示されます。

オートスケールを設定する

APIキーの準備

オートスケールがサーバの作成・削除などを行うために、APIキーを用意します。

さくらのクラウドのホーム画面から対象プロジェクトの「APIキー」を開き、AutoScale-api という名前で作成します。

公式マニュアルに従い、リソース操作APIキーのアクセスレベルは「作成・削除」にします。

作成したAPIキーは、後ほどオートスケールの設定画面で選択します。

CPU使用率の条件を設定する

コントロールパネルの「オートスケール」から追加し、次の内容を設定します。

項目設定
APIキーAutoScale-api
トリガーCPU使用率
自動スケーリング有効
性能アップするCPU使用率50
性能ダウンするCPU使用率20
監視対象のサーバ名のプリフィックスAutoScale-base
監視対象が存在するゾーンis1c(石狩第3ゾーン)
名前AutoScale-test

監視対象のサーバ名のプリフィックスには、ベースサーバの AutoScale-base を指定します。

追加サーバの AutoScale-worker を指定する項目ではない点に注意してください。

設定ファイルを入力する

「設定ファイル」には、追加サーバのスペック、使用するアーカイブ、連携するエンハンスドLBなどをYAML形式で記載します。

今回の設定は次のとおりです。

resources:
  - type: ServerGroup
    name: "AutoScale-worker"
    server_name_prefix: "AutoScale-worker"
    zone: "is1c"

    parent:
      type: ELB
      selector: "AutoScale-elb"

    min_size: 0
    max_size: 1

    plans:
      - name: "minimum"
        size: 0
      - name: "maximum"
        size: 1

    setup_grace_period: 120
    shutdown_force: false

    auto_healing:
      enabled: false

    template:
      interface_driver: "virtio"

      plan:
        core: 1
        memory: 1
        dedicated_cpu: false

      network_interfaces:
        - upstream: "shared"
          expose:
            ports:
              - 80

      disks:
        - source_archive: "AutoScale-template"
          plan: "ssd"
          connection: "virtio"
          size: 20

      edit_parameter:
        disabled: false
        password: ""
        disable_pw_auth: true
        enable_dhcp: false
        change_partition_uuid: true

        ssh_keys:
          - "使用しているSSH公開鍵"

        startup_scripts:
          - |
            #!/bin/bash
            # @sacloud-once
            set -eu

            cat > /var/www/autoscale/index.html <<'HTML'
            <!DOCTYPE html>
            <html lang="ja">
            <head>
                <meta charset="UTF-8">
                <title>オートスケールテスト</title>
                <style>
                    body {
                        font-family: sans-serif;
                        text-align: center;
                        margin-top: 100px;
                    }
                </style>
            </head>
            <body>
                <h1>オートスケールテスト</h1>
                <p>server: {{ .Name }}</p>
            </body>
            </html>
            HTML

            systemctl enable httpd --now

autoscaler:
  cooldown: 300

主な設定の意味を整理します。

設定内容
type: ServerGroupサーバの台数を増減する
parent追加サーバを登録するエンハンスドLBを指定する
min_size: 0/max_size: 1追加サーバの台数を0〜1台に制限する
plans追加サーバが0台の状態と1台の状態を定義する
setup_grace_period: 120サーバ起動後、セットアップのために120秒待機する
source_archive追加サーバの作成元となるアーカイブを指定する
expose.portsエンハンスドLBに登録する実サーバのポートを指定する
auto_healing.enabled: false今回は台数維持機能を無効にする
cooldown: 300連続したスケーリングを抑制するための待機時間を300秒にする

min_size と max_size に、ベースサーバの台数は含まれません。今回は追加サーバが最大1台なので、ベースサーバと合わせて最大2台になります。

参考:さくらのクラウド マニュアル「オートスケール」

CPU負荷をかけてスケールアウトを確認する

stress-ngで負荷をかける

ベースサーバに stress-ng をインストールします。

dnf install stress-ng

続いて、CPU使用率60%を目標に負荷をかけます。

stress-ng --cpu 0 --cpu-load 60

別のSSH接続で top を確認すると、CPU使用率が約60%まで上がっていました。

top
top - 21:21:02 up  1:43,  2 users,  load average: 0.47, 0.30, 0.11
Tasks:  94 total,   2 running,  92 sleeping,   0 stopped,   0 zombie
%Cpu0  : 59.9 us,  0.3 sy,  0.0 ni, 39.1 id,  0.0 wa,  0.3 hi,  0.3 si,  0.0 st
MiB Mem :    957.0 total,    345.5 free,    345.8 used,    432.8 buff/cache
MiB Swap:   4096.0 total,   4049.9 free,     46.1 used.    611.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  21900 root      20   0   39196   7528   4260 R  59.8   0.8   0:05.19 stress-ng-cpu
    630 root      20   0  405156  18328   7216 S   0.3   1.9   0:04.35 fail2ban-server
      1 root      20   0  172692   9788   5592 S   0.0   1.0   0:01.11 systemd
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kthreadd
      3 root      20   0       0      0      0 S   0.0   0.0   0:00.00 pool_workqueue_
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_gp
      5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-sync_wq

ただし、CPU使用率が50%を超えた瞬間に、追加サーバが作成されるわけではありません。

さくらのクラウドのオートスケールは、アクティビティグラフのCPU時間を10分間隔で監視するため、負荷をかけてから判定までには待ち時間があります。

追加サーバの作成を確認する

オートスケールの「ログ」を開き、処理を確認します。

今回の検証では、監視値が52%になったタイミングでスケールアウトが開始されました。

ログに記録された主な処理は次のとおりです。

時刻(JST)処理
21:27:19CPU使用率52%を確認し、スケールアウト要求を受け付け
21:27:21AutoScale-worker-001 を作成
21:29:30ディスクの作成が完了し、サーバの起動処理へ
21:30:10セットアップ猶予時間120秒の待機を開始
21:32:10待機が終了し、エンハンスドLBへの登録処理へ
21:32:12LB設定の反映が完了し、ジョブが終了

コントロールパネルのサーバ一覧にも、AutoScale-worker-001 が追加されました。

今回、スケールアウト要求の受け付けからジョブ完了までは約5分でした。

エンハンスドLBへの登録を確認する

続いて、エンハンスドLBの「実サーバ」一覧を確認します。

ベースサーバに加えて追加サーバも登録され、ヘルスチェック後には2台ともステータスが「UP」になりました。

YAMLで設定した parent と expose.ports により、サーバの追加に合わせてエンハンスドLBへの登録も行われています。

アクセスの振り分けを確認する

サーバが登録されたので、実際に追加サーバにもアクセスが振り分けられるか確認します。

エンハンスドLBのVIPに対して、複数回 curl を実行します。以下の ELB_VIP は、ご自身のエンハンスドLBのVIPに置き換えてください。

curl -i http://ELB_VIP/

検証では、どちらのサーバからも HTTP/1.1 200 OK が返り、レスポンスヘッダに via: 1.1 sac-elb が付いていました。

応答本文のサーバ名部分を抜粋すると、次の2種類を確認できました。

[root@autoscale-base ~]# curl -i http://ELB_VIP/
HTTP/1.1 200 OK
date: Wed, 30 Sep 2026 12:43:10 GMT
server: Apache/2.4.62 (AlmaLinux)
last-modified: Wed, 30 Sep 2026 12:38:44 GMT
etag: "178-65cb29470e0d7"
accept-ranges: bytes
content-length: 376
content-type: text/html; charset=UTF-8
via: 1.1 sac-elb

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>オートスケールテスト</title>
    <style>
        body {
            font-family: sans-serif;
            text-align: center;
            margin-top: 100px;
        }
    </style>
</head>
<body>
    <h1>オートスケールテスト</h1>
    <p>server: autoscale-base</p>
</body>
</html>
[root@autoscale-base ~]#

[root@autoscale-base ~]# curl -i http://ELB_VIP/
HTTP/1.1 200 OK
date: Wed, 30 Sep 2026 12:43:11 GMT
server: Apache/2.4.62 (AlmaLinux)
last-modified: Wed, 30 Sep 2026 12:30:15 GMT
etag: "17e-65cb2761b7548"
accept-ranges: bytes
content-length: 382
content-type: text/html; charset=UTF-8
via: 1.1 sac-elb

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>オートスケールテスト</title>
    <style>
        body {
            font-family: sans-serif;
            text-align: center;
            margin-top: 100px;
        }
    </style>
</head>
<body>
    <h1>オートスケールテスト</h1>
    <p>server: AutoScale-worker-001</p>
</body>
</html>
[root@autoscale-base ~]#

ベースサーバからの応答:

<p>server: autoscale-base</p>

追加サーバからの応答:

<p>server: AutoScale-worker-001</p>

同じVIPへのアクセスで異なるサーバ名が返っていることから、追加サーバも振り分け先として動作していることを確認できました。

負荷を止めてスケールインを確認する

CPU負荷を停止する

スケールアウトを確認できたので、続いてスケールインを確認します。

stress-ng を実行しているターミナルで Ctrl+C を押し、負荷を止めます。

停止後に top を確認すると、CPUのアイドル率は約99%まで戻りました。

ただし、ここでもすぐに追加サーバが削除されるわけではありません。

今回のログでは、停止後の最初の確認時点で監視値が約29.3%となっており、スケールイン条件の20%以下には達していませんでした。

その次の確認で約1.3%となり、スケールインが開始されました。

手元の top で表示される値と、オートスケールが判定に使用する値・時刻には差があるため、動作確認ではオートスケールのログも合わせて確認すると状況を追いやすくなります。

追加サーバの削除を確認する

スケールイン時のログでは、先にエンハンスドLBの振り分け先から追加サーバが外され、その後にサーバの停止・削除が行われていました。

時刻(JST)処理
22:08:24CPU使用率約1.3%を確認し、スケールイン要求を受け付け
22:08:25追加サーバをエンハンスドLBの実サーバから削除
22:08:27LB設定の反映が完了し、サーバのシャットダウンを開始
22:08:58シャットダウンが完了し、サーバ・ディスクの削除へ
22:09:05削除が完了し、ジョブが終了

コントロールパネルでも、追加サーバが停止状態になった後、一覧から削除されることを確認できました。

エンハンスドLBの実サーバ一覧も、ベースサーバ1台に戻っています。

今回、スケールイン要求の受け付けからジョブ完了までは約40秒でした。

サーバの台数が減るだけでなく、エンハンスドLBの振り分け先からの解除も連動して行われることを確認できました。

まとめ

今回は、さくらのクラウドのオートスケールを使用し、CPU使用率に応じてWebサーバを自動で増減させる構成を検証しました。

確認できたのは、次の一連の動作です。

  • CPU使用率の上昇に応じて、アーカイブから追加サーバを作成する。
  • 追加サーバをエンハンスドLBに自動登録する。
  • 同じVIPへのアクセスが、ベースサーバと追加サーバへ振り分けられる。
  • CPU使用率が下がると、追加サーバを振り分け先から解除する。
  • 追加サーバとディスクを削除し、元の1台構成に戻る。

サーバの作成・削除とロードバランサの設定変更をまとめて自動化できるため、台数を増減させるたびに手動で振り分け先を変更する必要がありませんでした。

次回は、エンハンスドLBのSSL化と、LB経由のアクセスでクライアントIPを確認するためのApacheのログ設定をご紹介します。

この記事を書いた人

kuu

ネットアシスト運用チームのkuuです。

【取得資格】

さくらのクラウド検定