【OCI_11_01】オートスケーリングの検証（インスタンスをベースにインスタンス構成を作成した場合）
インスタンスのオートスケーリングについて、検証してみます。
OCIではインスタンス・プールのオートスケーリングを設定することにより、状況に応じてインスタンス・プール内のインスタンス数を増減させることができます。
今回もOCIチュートリアルを参考にしています。
インスタンスのオートスケーリングを設定する
https://oracle-japan.github.io/ocitutorials/intermediates/autoscaling/
わざわざ題名に「インスタンスをベースにインスタンス構成を作成した場合」としたのは、インスタンスをベースにしたインスタンス構成は、OSの設計情報のみで、アプリやアプリの設定を含まないからです。
今回、WEBサーバをもとにインスタンス構成を作成しています。私はてっきりオートスケーリングでWEBサーバが複数台作成されると思っていました。
ですが、作成されたインスタンスには httpd がインストールされていませんでした。
調べたところ、アプリなども引継ぎたい場合は、カスタム・イメージを作成して、そのカスタム・イメージをベースにして「インスタンス構成」を作成すれば、アプリ（httpd、ファイル設定など）を完全に引き継いだ状態でスケールアウト時に新規インスタンスが起動するそうです。
次回、試してみたいと思います。ほか、オートスケーリングの考え方は、AWSとほぼ同じでした。
■手動作成した既存インスタンス と オートスケーリング の関係
オートスケーリングは、自分が起動したインスタンスだけを管理します。
そのため、手動作成した既存インスタンスを停止、起動してもオートスケーリングは、一切反応しません。
ロード・バランサ配下でも状況は同じです。
目次
ベースとなるインスタンスの作成
ベースとなるインスタンスはWEBサーバを作成しましたが、本記事の手順であるインスタンスをベースにインスタンス構成を作成した場合は、Apacheなどのアプリ情報は引き継がれません。（後でわかりました・・・）
そのため、ここではOS最低限の設定でもかまいません。
オートスケーリングの元となるインスタンスを作成します。
インスタンスは、ApacheのWEBページでホスト名やIPアドレスを動的に表示するよう設定しています。
インスタンスの作成とWEBサーバの設定は、以下の記事を参照してください。
インスタンス構成の作成
ベースになるインスタンスからインスタンス構成を作成します。
インスタンス構成は、オートスケーリング用インスタンスを起動する元になり、イメージ、シェイプ、sshキー情報、ブロックボリューム、ネットワーク情報などが定義されています。
左上ハンバーガーメニューから コンピュート > インスタンス を選択し、該当インスタンスのリンクをクリックします。
右上の「アクション」> その他のアクション > インスタンス構成の作成 をクリックします。
インスタンス構成の作成画面で以下を入力、選択し、右下の「インスタンス構成の作成」をクリックします。
コンパートメントに作成：自身の権限のあるコンパートメント
名前：任意名
インスタンス構成が作成されました。
インスタンス・プールの作成
作成したインスタンス構成をもとに、インスタンス・プールを作成します。
インスタンス・プールを作成すると、インスタンス構成で設定したインスタンスがインスタンス・プールで設定した数だけ起動します。
公式チュートリアルに習いサイズを「0」で作成し、あとでスケーリングしてこの数を増やしてみたいと思います。
左上ハンバーガーメニューから コンピュート > インスタンス構成 を選択し、作成したインスタンスの構成のリンクをクリックします。
右上の「アクション」> インスタンス・プールの作成 をクリックします。
インスタンス・プールの作成画面で以下を入力、選択し、「次」をクリックします。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
インスタンス数：０ （※ここを１にするとインスタンス・プールを作成した時点で１台インスタンスが起動します）
インスタンス構成コンパートメント：自身の権限のあるコンパートメント
インスタンス構成：作成したインスタンス構成
インスタンス表示名フォーマッタ：何もしない（デフォルト）
インスタンス・ホスト名フォーマッタ：何もしない（デフォルト）
インスタンス構成詳細、タグも何もしない
プール配置の構成画面で以下を入力、選択し、「次」をクリックします。
可用性ドメイン：可用性ドメイン1（大阪リージョンは可用性ドメインが１つしかないため）
フォルト・ドメイン：何もしない（デフォルト）※任意のフォルト・ドメインを選択することもできます
仮想クラウド・ネットワークの選択コンパートメント：自身の権限のあるコンパートメント
仮想クラウド・ネットワークの選択：自身のVCNを選択
サブネットの選択コンパートメント：自身の権限のあるコンパートメント
サブネットの選択：インスタンスを展開したいサブネットを選択（今回はパブリック・サブネット）
ロード・バランサのアタッチ：OFF（デフォルト）
設定内容を確認し、右下の「送信」をクリックします。
インスタンス・プールが作成されました。
オートスケーリングの設定
作成したインスタンス・プールを元にオートスケーリングを作成します。
公式チュートリアルに習い、インスタンス・プール内の平均CPU使用率が70%を上回ったら1インスタンス増やす、30%未満になったら1インスタンス減らす、というポリシーを設定します。
スケーリングするインスタンス数は、最小1インスタンス、最大3インスタンスに設定します。
左上ハンバーガーメニューから コンピュート > インスタンス・プール を選択し、作成したインスタンス・プールのリンクをクリックします。
右上の「アクション」> 自動スケーリング構成の作成 をクリックします。
自動スケーリング構成の作成画面で以下を入力、選択し、「次」をクリックします。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
インスタンス・プール：作成したインスタンス・プール
自動スケーリング・ポリシーの構成で以下を入力、選択します。
メトリックベースの自動スケーリング
続いて、以下を入力、選択します。
自動スケーリング・ポリシーの構成
自動スケーリング・ポリシー名：任意名
クールダウン（秒）：300（デフォルト）
パフォーマンス・メトリック：CPU使用率
続いて、以下を入力、選択します。
スケールアウト・ルール
スケールアウト演算子：次より大きい（>）
しきい値パーセンテージのスケールアウト：70
追加するインスタンスの数：１
続いて、以下を入力、選択します。
スケールイン・ルール
スケールイン演算子：次より小さい（<）
しきい値パーセンテージのスケールアウト：30
削除するインスタンスの数：１
続いて、以下を入力、選択し、「次」をクリックします。
スケーリング制限
インスタンスの最小数：１
インスタンスの最大数：3
インスタンスの初期数：１
確認画面で内容を確認し、「作成」をクリックします。
自動スケーリング構成が作成できました。
インスタンスの確認
インスタンス画面でオートスケーリングで設定した「インスタンスの初期数」の１台が起動して「実行中」になりました。
パブリックIPアドレスを指定してSSH接続することができました。
CPU負荷を上げてスケールアウトを確認する
オートスケーリングで起動してきたインスタンスにOS上からCPU負荷をかけてCPU使用率が閾値（ここでは70%）を上回るように設定し、インスタンスが1台増えることを確認します。
インスタンスへログインします。
stressパッケージを含むEPELリポジトリが有効になっているか確認します。
おそらく「disabled」となっているのでyum-config-managerコマンドでenabledにします。
sudo yum repolist all | grep -i epel
利用しているイメージのバージョンを確認し、有効化のためのコマンドを実行します。
あらためて有効化されたことを確認します。
sudo yum-config-manager –enable ol9_developer_EPEL
sudo yum repolist all | grep -i epel
stressパッケージをインストールします。「Complete!」が表示されればインストール完了です。
sudo yum -y install stress
stressコマンドでCPUに負荷をかけます。該当インスタンスは「VM.Standard3.Flex」のシェイプを利用しています。
stress -c 2 &
topコマンドで確認してみます。
公式チュートリアルとシェイプは違いますが、下記コマンドでCPU負荷が100%になりました。（※タイミングによって 100 でない時もあります）
top
上記状態で、クールダウン期間で指定した300秒が過ぎると、スケーリングします。
作成したインスタンス・プールをクリック、「詳細」タブを選択し、「アタッチされたインスタンス」を確認すると２台目のインスタンスが起動していました。
次にインスタンス・プールをクリック、「モニタリング」タブを選択し、「CPU使用率」を確認します。
2台の平均CPU使用率が、だいたい50%になっていることが確認できます。
もし、２台目のインスタンスでもCPU使用率を100%にすれば、2台の平均CPU使用率は100%となり、3台目のインスタンスが起動することになります。
今回は2台目までにしておきます。
1台目のインスタンスのCPU使用率：100%
2台目のインスタンスのCPU使用率：0%
2台の平均CPU使用率：50%
CPU負荷を下げてスケールインを確認する
次は、CPU使用率を下げてスケールインすることを確認します。
バックグラウンドで動いているすべての stress プロセスを一括停止する場合、pkill stressを実行します。
pkill stress
topコマンドで確認してみます。
CPU使用率は、0 % になりました。
top
この状態で、クールダウン期間で指定した300秒が過ぎると、スケーリングします。
作成したインスタンス・プールをクリック、「詳細」タブを選択し、「アタッチされたインスタンス」を確認するとインスタンスが１台「終了中」⇒「終了済」になっており、スケールインしていることが確認できます。
【おまけ】オートスケーリングから起動したインスタンスを停止、起動するには？
■停止する場合
画像はないのですが「自動スケーリング構成」を「無効化」しただけでは、オートスケーリングから起動したインスタンスはそのまま起動したままでした。
「インスタンス・プール」を「停止」すると起動していたインスタンスは「停止済」になりました。
■起動する場合
「インスタンス・プール」を「起動」すると停止していたインスタンスは「実行中」になりました。
まとめ
オートスケーリングの検証として、インスタンスをベースにインスタンス構成を作成した場合の動作検証を行いました。次回は、カスタム・イメージをベースにインスタンス構成を作成し、オートスケーリングを検証してみたいと思います。
以下、他の記事をまとめた一覧です。OCI以外にAWSもまとめています。
