こんにちは。kuuです。
今回は、さくらのクラウドの「オートスケール」を使って、
CPU使用率に応じてWebサーバを自動で増減させる構成を検証しました。
サーバが自動で作成されるところから、エンハンスドロードバランサへの登録、
アクセスの振り分け、負荷が下がった後のサーバ削除まで確認していきます。
今回検証する構成
オートスケールには、CPUやメモリなどのスペックを変更する「垂直スケール」と、サーバの台数を変更する「水平スケール」があります。
今回は、サーバの台数を増減させる水平スケールを使用します。
常時稼働するベースサーバを1台用意し、そのCPU使用率が高くなったら追加サーバを1台作成します。CPU使用率が下がったら追加サーバを削除し、元の1台構成に戻します。
| リソース | 名前 | 役割 |
|---|---|---|
| ベースサーバ | AutoScale-base | 常時稼働するWebサーバ。CPU使用率の監視対象 |
| 追加サーバ | AutoScale-worker-001 | オートスケールによって作成・削除されるWebサーバ |
| アーカイブ | AutoScale-template | 追加サーバの作成に使用するテンプレート |
| エンハンスドLB | AutoScale-elb | Webサーバへのアクセスを振り分ける |
| オートスケール設定 | AutoScale-test | CPU使用率の条件と追加サーバの構成を設定する |
今回のポイントは、CPUを監視するベースサーバと、自動で増減する追加サーバを分けていることです。
ベースサーバは常に残し、追加サーバだけを0〜1台の範囲で増減させます。そのため、Webサーバの合計台数は1〜2台になります。
主な設定は次のとおりです。
| 項目 | 設定 |
|---|---|
| サーバ・アーカイブのゾーン | 石狩第3ゾーン(is1c) |
| OS | AlmaLinux 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:19 | CPU使用率52%を確認し、スケールアウト要求を受け付け |
| 21:27:21 | AutoScale-worker-001 を作成 |
| 21:29:30 | ディスクの作成が完了し、サーバの起動処理へ |
| 21:30:10 | セットアップ猶予時間120秒の待機を開始 |
| 21:32:10 | 待機が終了し、エンハンスドLBへの登録処理へ |
| 21:32:12 | LB設定の反映が完了し、ジョブが終了 |
コントロールパネルのサーバ一覧にも、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:24 | CPU使用率約1.3%を確認し、スケールイン要求を受け付け |
| 22:08:25 | 追加サーバをエンハンスドLBの実サーバから削除 |
| 22:08:27 | LB設定の反映が完了し、サーバのシャットダウンを開始 |
| 22:08:58 | シャットダウンが完了し、サーバ・ディスクの削除へ |
| 22:09:05 | 削除が完了し、ジョブが終了 |
コントロールパネルでも、追加サーバが停止状態になった後、一覧から削除されることを確認できました。


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

今回、スケールイン要求の受け付けからジョブ完了までは約40秒でした。
サーバの台数が減るだけでなく、エンハンスドLBの振り分け先からの解除も連動して行われることを確認できました。
まとめ
今回は、さくらのクラウドのオートスケールを使用し、CPU使用率に応じてWebサーバを自動で増減させる構成を検証しました。
確認できたのは、次の一連の動作です。
- CPU使用率の上昇に応じて、アーカイブから追加サーバを作成する。
- 追加サーバをエンハンスドLBに自動登録する。
- 同じVIPへのアクセスが、ベースサーバと追加サーバへ振り分けられる。
- CPU使用率が下がると、追加サーバを振り分け先から解除する。
- 追加サーバとディスクを削除し、元の1台構成に戻る。
サーバの作成・削除とロードバランサの設定変更をまとめて自動化できるため、台数を増減させるたびに手動で振り分け先を変更する必要がありませんでした。
次回は、エンハンスドLBのSSL化と、LB経由のアクセスでクライアントIPを確認するためのApacheのログ設定をご紹介します。