3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

さくらのクラウドのオートスケールをやんわり試す

Last updated at Posted at 2021-06-24

概要

さくらのクラウドでautoscaleを実現する何だかすごそうなのを
#さくらのマイクロコミュニティ (CLI/APIユーザの会) vol.2 で知ったので試してみた。

この記事の前提

  • とにかく試したかったのでスケールアップダウンのトリガーは手動
    https://github.com/sacloud/autoscaler にもあるように本当は監視ツールからの
    アラートとかをトリガーにするのが想定されている。
  • APIキーは準備済み
  • スケールアップダウンしたいインスタンスは最小(1Core1GB)でubuntu20.04LTSをインストールしただけで起動済み。名前はautoscaled01。
  • スケールアップダウンを指示するサーバも最小(1Core1GB)でubuntu20.04LTSをインストールしてdockerをインストールしただけで起動済み。
  • READMEに書いている手段のうち、Dockerで試す
  • インスタンスは全部同じローカルネットワーク内にいる

準備

yamlを書く

スケールアップダウンを指示するサーバにて書く。
書き方は、getting_started.md に載ってます。
ファイル名は autoscaler.yaml にしておくとちょっとだけ後で楽です。
tokenにはアクセストークンを、secretにはアクセストークンシークレットをそれぞれ書く。

今回書いたのは以下の感じ。
autoscaled01 という名前のis1bになるインスタンスを

  • 1core 1GB
  • 2core 4GB
  • 4core 8GB

の範囲で垂直スケールさせる。
すぐに何回もアップしたりダウンしたりしたいので、cooldownの時間は短くしている。

# 操作対象のリソースの定義
resources:
  tmkgrp: 
    resources:
      # サーバ(垂直スケール)
      - type: Server
        selector:
          names: ["autoscaled01"]
          zone: "is1b"
        plans:
        - core: 1
          memory: 1
        - core: 2
          memory: 4
        - core: 4
          memory: 8
        option:
          shutdown_force: true

autoscaler:
  cooldown: 1 # デフォルト: 6000(10分)

sakuracloud:
  token: "himitsu"
  secret : "superhimitsu"

実行する

作ったyamlと同じディレクトリで実行する。

# coreの起動
sudo docker run --rm -w /work -v ${PWD}/:/work ghcr.io/sacloud/autoscaler:v0.0.1 server start

もしもyamlのファイル名を変えている場合は、 --config string でyamlのファイル名を指定しよう。
e.g. server start --config ownyaml.yaml

次にターミナルをもう一つ開いて、トリガーを引くための別のコンテナを作る。(コマンドの違いは最後のupかdownかって部分だけ)

# スケールアップしたい場合  
sudo docker run --rm -w /work -v ${PWD}/test_autoscale_sacloud:/work ghcr.io/sacloud/autoscaler:v0.0.1 inputs direct up

# スケールダウンしたい場合
sudo docker run --rm -w /work -v ${PWD}/test_autoscale_sacloud:/work ghcr.io/sacloud/autoscaler:v0.0.1 inputs direct down

ログを見てみる

トリガーを引くとcoreの方のコンテナのログに

timestamp=2021-06-24T11:22:21Z level=info message="request received" request-type=Up
timestamp=2021-06-24T11:22:21Z level=info request-type=Up scaling-job-id=default-default-default status=JOB_ACCEPTED

とか出ている。

コントロールパネルを眺めているとインスタンスがシャットダウンされて
インスタンスのサイズが変更され、インスタンスが起動してくるのが分かる。

ログも

=Server zone=is1b id=113301188092 step=Handle handler=server-vertical-scaler log="shutting down server: 113301188092"
(中略)
=Server zone=is1b id=113301188092 step=Handle handler=server-vertical-scaler log="server plan changing - to {Core: 4, Memory: 8}"

とか出てて分かりやすい。

最後に

ツールの想定通りに監視ツールを使うとCPUのアラートとかメモリのアラートとかをトリガーにしゅしゅっとインスタンスを大きくできそう!
今度は監視ツールを使って試してみたいところ。

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?