grasys blog

Apache のメトリクスを用いたオートスケールの動作検証

shirota

こんにちは。shirota です。

今回のテーマは WEB サーバーのオートスケールです。

本ブログを通して、以下の内容をお伝えできればと思います。

  • オートスケールについて
  • Google Cloud でオートスケールを使用する方法
  • WEB サーバー（Apache）の負荷状況でオートスケールをさせる方法

なお、今回の記事は仮想マシン（VM）のオートスケールについて扱います。
Google Cloud で GCE（Google Compute Engine）を利用しているケースに向けた記事になります。

オートスケールについて

サーバーの台数を増やすことをスケールアウト、逆に減らすことをスケールインと言います。
そしてオートスケールは何かしらをトリガーにして、このスケールアウトとスケールインを自動で行うシステムです。
この何かしらのトリガーとして、指標を設ける必要があります。WEB サーバーの場合、例えばアクセス数だったり、サーバーの CPU 使用率を指標として考えることができます。

Google Cloud でオートスケールを使用する

Google Cloud ではインスタンスグループ（VM の集まり）の管理について、マネージドまたはアンマネージド（非マネージド）を選択することができます。
マネージドインスタンスグループ（以下、MIG）を選択することでオートスケールの機能を使用することができます。

MIG の特徴はオートスケールだけではなく、
障害が発生した VM を自動で再作成するオートヒーリングという機能があったり、
VM を複数のゾーンに分散して配置することで高い可用性を実現できたりと色々ありますが、
ここでは Google Compute Engine をオートスケールさせるには、MIG を作成する必要があるという点を押さえていただければ大丈夫です。

動作検証

ここからは実際に Apache のメトリクスを元にオートスケールできるのかを確認していきます。

今回は Apache の busyworker 数を指標にします。
ops-agent を使用して Cloud Monitoring に送った Apache のメトリクスを元に MIG のオートスケールの設定をしていきます。

以下の流れで作業をしていきます。

  1. イメージの元となる VM の作成
  2. VM からイメージを取得
  3. テンプレートを作成
  4. MIG を作成
  5. 負荷をかけてオートスケールの動作確認

1. イメージの元となる VM の作成

以下のバージョンで動作検証いたします。

  • OS: Rocky Linux9.4
  • Apache: 2.4.57
  • ops-agent: 2.50.0 1.el9
  • php-fpm: 8.0.30

php-fpm は負荷をかける際に php を使用するため、インストールしました。
各ミドルウェアのインストールや設定は本記事では割愛して、Apache のメトリクスの取得に必要な箇所にしぼって記載いたします。

1.1. Apache mod status を有効にする

curl コマンドでステータスが表示できれば mod status は有効になっています。

curl http://localhost:80/server-status?auto

パッケージマネージャーを使用してインストールしたのですが、デフォルトでは有効になっていなかったため、
以下の設定を追加しました。

<Location /server-status>
SetHandler server-status

Order Deny,Allow
Deny from all
Allow from all
</Location>

1.2. ops-agent インストール

Cloud Monitoring に Apache のメトリクスを送るために ops-agent を使用します。
こちらのドキュメントを参考に検証時の最新のバージョンをインストールしました。

Apache のメトリクスを取得するため、以下の設定を追加します。

cd /etc/google-cloud-ops-agent
vim config.yaml
metrics:
  receivers:
    apache:
      collection_interval: 10s
      server_status_url: http://localhost:80/server-status?auto
      type: apache
  service:
    pipelines:
      apache:
        receivers:
          - apache

Google Cloud の Cloud Monitoring で Apache のメトリクスが確認できるようになりました！

2. VM からイメージを取得

今回は実行中のインスタンスからイメージを取得したため、–force フラグを使用しています。

gcloud compute images create grasys-apache01-image-01 \
    --source-disk=grasys-apache01 \
    --source-disk-zone=asia-northeast1-a \
    --family=grasys-apache01 \
    --storage-location=asia-northeast1 \
    --force

3. テンプレートを作成

MIG にセットするテンプレートを作成します。
作成したテンプレートを使用して VM を作成する際に、先ほど作成したイメージを使用するようにします。

gcloud compute instance-templates create grasys-apache01-template-01 \
--image-family=grasys-apache01 \
--instance-template-region=asia-northeast1 \
--boot-disk-size=20 \
--boot-disk-type=pd-standard

4. MIG を作成

以下の内容で MIG を構成します。

  • 自動スケーリング：オン
  • インスタンスの最小数：1
  • インスタンスの最大数：3
  • オートスケーリングのシグナル：Cloud Monitoring の指標
    • Resource and metric：VM Instance – workload/apache.workers
    • Filter：state = busy （←こちら追加することで busyworker を指標に設定できます。）
    • Aggregation：mean
    • Utilization target：10 Gauge

Aggregation：mean と Utilization target：10 Gauge の設定で MIG 内にある VM の Apache の busyworker 数の平均が10になるように設定しています。
VM１台あたりの busyworker数が11以上になった場合、オートスケールする設定です。
今回は最大で3台までスケールアウトする設定にしています。

5. 負荷をかけてオートスケールの動作確認

ここからは Apache の BusyWorker 数を増やしてオートスケールの動作確認をしていきます。
実際に使う場合はロードバランサーを作成して、バックエンドサービスとして MIG をアタッチしてリクエストを分散しますが、今回はオートスケールすることの確認ができれば良いので、
外からのアクセスではなく、中から自分自身（ローカルホスト）に対してアクセスして負荷を上げてみようと思います。
MIG 内の VM の指標の平均によってスケールするので、この方法で問題ないはず。

今回、VM の最小数は1に設定しているので、負荷がない状況で確認するとターゲットサイズは1です。

# ターゲットサイズの確認
gcloud compute instance-groups managed list | grep grasys-apache-group | awk '{print $6}'
1


負荷がけには、処理の完了まで10秒間かかる PHP ファイルと Apache Bench を使用します。

PHP ファイルには10秒間待機したあとに処理が完了するように記述します。

<?php
sleep（10）;
echo "done";
?>

Apache Bench は ab コマンドを使用して実行します。
-n でリクエスト数を、-c で同時接続数を指定します。
同時接続数を調整することで、BusyWorker を任意の数まで上げる作戦です。

ab -n 1000 -c 10 http://localhost/load.php


Apache のステータスを確認しながら負荷がけします。

watch -n 1 curl http://localhost:80/server-status?auto

Apache Bench の同時接続数を10に設定した場合、Apache のステータス確認と合わせて BusyWorker が11使われます。
この負荷がけを実行すると…

# ターゲットサイズの確認
gcloud compute instance-groups managed list | grep grasys-apache-group | awk '{print $6}'
2

2台にスケールアウトしました。
2台にスケールアウトしたことで MIG 内の VM の BusyWorker の平均が5.5（11 / 2）になるので、これ以上はスケールしません。

次に、BusyWorker 数が31になるように Apache Bench で負荷をかけてみます。

ab -n 1000 -c 30 http://localhost/load.php


最大の3台までスケールアウトしても、BusyWorker の平均が10（31 / 3）を超える負荷がけです。

# ターゲットサイズの確認
gcloud compute instance-groups managed list | grep grasys-apache-group | awk '{print $6}'
3

想定どおり3台までスケールアウトすることが確認できました。

結論

Apache のメトリクスを使用してオートスケールができることを見てきました。
検証の中では ops-agent を使用して簡単に Apache のメトリクスを Google Cloud で使用できたことが印象的でした。
指標として何を用いるのかについてはサービスによって異なりますが、WEB サーバーで Apache を使用している場合、選択肢として検討にいれるハードルが低いのは嬉しいことです。
この記事では触れていませんが、複数の条件の設定（たとえば、CPU 使用率 + Apache の BusyWorker 数など）もできます。
このブログを書きながら、ニーズに合わせた設定を決めるためには多角的な視点のテストが必要になることの難しさを改めて実感しました。
逆説的にニーズに合わせた設定について複数のアプローチを検討できるという点に、オートスケールの可能性を感じました。

最後までお付き合いいただき、ありがとうございました。

参考資料

Monitoring 指標に基づいてスケーリングする 

個々の VM への Ops エージェントのインストール 

Apache ウェブサーバー（httpd）


採用情報
 お問い合わせ    

shirota

＼ 合わせて読みたい ／Related article