【備忘録】Azure ScaleSetに対して負荷をかける 実行編

■はじめに

以前のエントリで、Scale Setに負荷をかけるためのテスト準備をしました。

今回は実際に負荷をかけていきます。

閾値の再設定

実は単純にテストを実行するだけで、Selenoidはそれなりに負荷がかかります。
(Standard_D2_v2サイズでCPUの稼働率は20%を超えます)
f:id:theboyalex:20200701225936p:plain

なのでテストジョブを2つ並行実行すれば40%ぐらいにはなるはずです。
今回はあくまでスケールアウトの正常動作確認が目的なので、まずはterraformで設定していたスケールアウトの閾値を下げます。

    rule {
      metric_trigger {
        metric_name        = "Percentage CPU"
        metric_resource_id = azurerm_linux_virtual_machine_scale_set.selenoid_vm01.id
        time_grain         = "PT1M"
        statistic          = "Average"
        time_window        = "PT5M"
        time_aggregation   = "Average"
        operator           = "GreaterThan"
        threshold          = 40
      }

      scale_action {
        direction = "Increase"
        type      = "ChangeCount"
        value     = "1"
        cooldown  = "PT1M"
      }
    }


前回までのtfファイルではこちらの閾値を75%ぐらいにしていましたが、上記では threshold = 40 のときにincreaseします。
なおこのブログで使っているAzureの検証には個人で課金をしていて、予算が心許ないのでmaximum = 2と設定しています。
(金持ちになったら色々やろう。。)

■テストJOBの準備

CircleCIのFreeプランでは実行できるジョブの並列実行数は1つのみです。
ただこれはドキュメントを見る限り、実行リポジトリが1つに限定されている訳ではなく1ジョブのparallelism設定数が2以上に設定できないように読み取れました。(ちゃんと調査できておらず。。)

circleci.com

今回は1リポジトリを並列処理して時間短縮することが目的ではないので、一旦何も考えずに同一テストリポジトリを2つ用意しこれをCircleCIから同時に実行します。
f:id:theboyalex:20200701230851p:plain

【補足】
本当は1リポジトリでブランチを分けて複数実行したかったのですが、mavenテンプレートがCircleCI Orbsで記述されており、ボクの知識が乏しくOrbsを使用したmavenでのブランチ実行がいまいちわからなかった、というのが実情です。
https://circleci.com/orbs/registry/orb/circleci/maven#jobs-parallel_test

こちらはどこかのタイミングで最適化できないか調査してみます。
↓本当はこれがやりたかったですねん。もしかしたらFreeプランではできないかもですが。。
circleci.com

■実行結果

①スケールアウト

さて、Azure ScaleSetに対して実際にテストを実行して負荷をかけます。
f:id:theboyalex:20200701233825p:plain
実行するとCPU稼働率が50%をちょいちょい超えていきます。

Terraformでは1分単位でチェックをかけていますので(time_grain = "PT1M")、しばらく待ちます。
すると以下のようにスケールアウトが確認できます。
f:id:theboyalex:20200701234318p:plain

スケールアウトのルールの適用も確認します。
f:id:theboyalex:20200701234552p:plain
ちゃんと2に増えていますね。

②スケールイン

次にテストが終わり次第、環境を縮小します。
f:id:theboyalex:20200701235023p:plain

VMの数値を確認したところこんな感じ。
f:id:theboyalex:20200701235124p:plain

さらにスケールインのルールの適用も確認します。
f:id:theboyalex:20200701235235p:plain
うん、ちゃんと減ってますね。

■まとめ

というわけで、テスト環境の負荷によって環境を最適化するところまで確認できました。

次回はAndroidコンテナをこの仕組みでスケールしてみようと思っています。
(そもそもAWSじゃなくってAzureを選択している最大の理由はハードウェア仮想化ができることなので)

ではでは。