参考記事
Cloud Foundry apps をつくる
カタログからPHPを作成します。
基本的にはライトな使い方であれば、30日無料なので、請求は問題ないでしょう。
「Running」となっていることを確認します。
Auto-Scaling をつくる
カタログから Auto-Scaling を作成します。
こちらも基本的には無料のサービスです。
「Create connection」から先ほど作成した Cloud Foundry apps を追加して、Restage をかけます。
しばらくすると、「Manage」の画面に正しく表示されます。
Auto-Scaling させてみる
Policy の設定
たとえば、このような設定を入れてみました。
この設定で負荷をかけてテストしてみます。
- Statistic Window
- average を計算する対象となる間隔
- Breach Duration
- 設定された時間の間、閾値を超えるとトリガが発動
- Cooldown period for scaling out
- インスタンス追加後、全インスタンスを含めて処理を計測するまでの待ち時間
- Cooldown period for scaling in
- インスタンス削除後、全インスタンスを含めて処理を計測するまでの待ち時間
負荷テストツール
今回はこちらを使用してみました。
他にも以下のツールが有名です。
メトリクスの統計、スケーリング履歴
テストした結果、メモリ使用量に関する負荷がみてとれます。
インスタンスの追加処理自体は、数秒の範囲で終わっています。
インスタンスの追加・削除時の最短のインターバルは、
「Cooldown period for scaling out(in)」+「Breach Duration 」の240秒(4分)程度になっているので、意図した通りに動いていることが確認できます。
メモリの平均使用率を120秒ごとに出して、トリガが動くようになっているので、4分より間隔が長い場合でも、2分刻みでトリガの判断がおこなわれていることがわかります。
インスタンスごとのメトリクスの統計
若干、タイムスケールが異なる部分がありますが、少し負荷が偏ってしまう部分があります。
これは、1つの Cloud Foundry apps に対する複数インスタンスへのロードバランシングは、ラウンドロビン方式になっているためです。
Auto-Scaling したとはいえ、このラウンドロビン方式はユーザー側で変更できないとのことなので、この状況を変えたい場合、複数のアプリをうまく活用する必要がありそうです。