【OCI_12】_ロード・バランサとオートスケーリングを連携する
以前の記事でロード・バランサ配下へ手動でWEBサーバを２台組み込み、負荷分散されることを検証しました。
また、オートスケーリングについては、２パターン検証しました。
今回は、以前の検証を参考にロード・バランサとオートスケーリングを連携し、ロード・バランサ配下でWEBサーバがオートスケーリング設定に沿って増減することを検証したいと思います。
ロード・バランサの構成
ロード・バランサは、Webサーバーと同じサブネットや別のサブネットに配置できるそうですが、今回はチュートリアルに習い、Webサーバーが配置されているサブネットとは別のパブリック・サブネットをリージョナル・サブネットとして作成し、そこにロード・バランサを配置します。
リージョナル・サブネットとは
はじめて聞いたので chatgpt へ聞きました。
OCIの「サブネット」は、リージョン全体にまたがるタイプ か特定の可用性ドメイン（AD）に限定されるタイプ かを選択できます。特定の可用性ドメイン（AD）に限定されるタイプは、1つのAD（可用性ドメイン）に限定されるため高可用性を自分で設計する必要があります。
リージョン全体にまたがるリージョナル・サブネットは、リージョン全体をカバー（ADに限定されない）して高可用性をOCIが自動で確保してくれます。
つまり、リージョナルサブネットとは、ADをまたがって利用できるサブネット（＝リージョン全体がスコープ）であり、OCIが裏で自動的に複数ADに冗長構成を取れるように設計されたものです。
ロード・バランサ用セキュリティ・リストの追加
左上ハンバーガーメニューから ネットワーキング > 仮想クラウド・ネットワーク を選択し、Webサーバーが存在するVCN名のリンクをクリックします。
「セキュリティ」タブを選択、セキュリティ・リストの「セキュリティ・リストの作成」をクリックします。
セキュリティ・リストの作成画面で以下入力、選択し、右下の「セキュリティ・リストの作成」をクリックします。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
イングレスのルール許可：なし（ルールが入っていれば削除します）
エグレスのルール許可：なし（ルールが入っていれば削除します）
※チュートリアルによるとロード・バランサを作成した際に、適切なルールが自動的に付与されるとありますが、本検証では自動登録設定を利用していません。後の手順でルールを追加するのでいったんこの時点では、空のセキュリティ・リストを作成してください。
ロード・バランサ用セキュリティ・リストが作成されました。
ロード・バランサ用ルート表の追加
ロード・バランサから出ていく通信は、すべてインターネットゲートウェイへ配送するというルート表を作成します。
左上ハンバーガーメニューから ネットワーキング > 仮想クラウド・ネットワーク を選択し、Webサーバーが存在するVCN名のリンクをクリックします。
「ルーティング」タブを選択、ルート表の「ルート表の作成」をクリックします。
ルート表の作成画面で以下入力、選択します。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
ルート・ルール(オプション)で「別のルート・ルール」をクリックします。
以下入力、選択し、右下の「作成」をクリックします。
ターゲット・タイプ：インターネット・ゲートウェイ
宛先CIDRブロック：0.0.0.0/0
ターゲット・インターネット・ゲートウェイコンパートメント：デフォルトで現在のコンパートメントが選択される
ターゲット・インターネット・ゲートウェイ：VCNのインターネット・ゲートウェイ
ロード・バランサ用のルート表が作成されました。
ロード・バランサ用サブネットの追加
冒頭にも記載しましたがリージョナル・サブネットとして作成していきます。
左上ハンバーガーメニューから ネットワーキング > 仮想クラウド・ネットワーク を選択し、Webサーバーが存在するVCN名のリンクをクリックします。
「サブネット」タブを選択、サブネットの「サブネットの作成」をクリックします。
サブネットの作成画面で以下入力、選択します。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
サブネット・タイプ：リージョナル（推奨）
IPv4 CIDRブロック：10.0.0.3/24 （自身の環境に合わせてください）
以下入力、選択します。
ルート表コンパートメント：自身の権限のあるコンパートメント
ルート表：ロード・バランサ用ルート表
サブネット・アクセス：パブリック・サブネット
DNS解決：チェックを外す
DHCPオプション：デフォルトの選択のまま
以下入力、選択し、右下の「サブネットの作成」をクリックします。
セキュリティ・リストコンパートメント：自身の権限のあるコンパートメント
セキュリティ・リスト：ロード・バランサ用セキュリティ・リスト
リソース・ロギング：OFF（デフォルト）
ロード・バランサ用のサブネットが作成されました。
ロード・バランサの作成
作成の際にロード・バランサに必要なシェイプと配置先として先ほど作成したリージョナル・サブネットを選択します。
左上ハンバーガーメニューから ネットワーキング > ロード・バランサ を選択します。
「ロード・バランサの作成」をクリックします。
ロード・バランサの作成画面で以下入力、選択します。
ロード・バランサ名：任意名
可視性タイプの選択：パブリック
パブリックIPアドレスの割当て：エフェメラルIPアドレス
以下入力、選択します。
シェイプ：最小帯域幅が 10 Mbps、最大帯域幅が 50 Mbps と入力
IPv6アドレス割当ての有効化：OFF（デフォルト）
以下入力、選択し、左下の「次」をクリックします。
仮想クラウド・ネットワークコンパートメント：自身の権限のあるコンパートメント
仮想クラウド・ネットワーク：サブネットを作成したVCN
サブネットコンパートメント：自身の権限のあるコンパートメント
サブネット：事前に作成したリージョナル・サブネット
ネットワーク・セキュリティ・グループを使用してトラフィックを制御：OFF（デフォルト）
管理は、以下のとおり選択し、「次」をクリックします。
バックエンド・サーバーの選択 画面はインスタンスを追加せず、デフォルトのままにします。
オートスケーリングにおける「インスタンス・プール」を設定する際に、「ロード・バランサのアタッチ」という項目があるのでその設定をONにすればバックエンド・サーバーとして認識されるからです。
ヘルス・チェック・ポリシーの指定は、すべてデフォルトのままとし、左下の「次」をクリックします。
バックエンド・セットは、デフォルトのままにします。
「セキュリティ・リスト」は、「バックエンド・サーバーの追加後にセキュリティ・リスト・ルールを手動で構成します」が選択されていることを確認します。
今回の検証では、WEBサーバが配置されているパブリック・サブネットのセキュリティ・リスト（イングレス、エグレス）のルールは、空にしています。
理由は、各インスタンスにネットワーク・セキュリティ・グループを設定しており、そこでセキュリティを担保しているからです。
ロード・バランサが配置されているリージョナル・サブネット用セキュリティ・リストは、後で手動でルールを追加する想定です。
セッション永続性は、デフォルトのままにします。
リスナーの構成 画面で以下の項目を入力、選択し、左下の「次」をクリックします。
リスナー名：任意名
リスナーで処理するトラフィックのタイプを指定します：HTTP
リスナーでイングレス・トラフィックをモニターするポートを指定します：80
ロギングの管理 画面で以下の項目を入力、選択し、「送信」をクリックします。
エラー・ログ：無効
アクセス・ログ：無効（デフォルト）
リクエストID：有効（デフォルト）
内容を確認し、右下の「送信」をクリックします。
ロード・バランサの作成が開始されます。状態が「アクティブ」になるまで待ちます。
全体的なヘルスが「不完全」もしくは「クリティカル」となるのは、おそらくバックエンドにサーバが存在してないからだと思います。
ロード・バランサの設定は、いったんここで完了です。
オートスケーリングの構成
次にオートスケーリングを構成していきます。
カスタム・イメージの作成
ベースとなるインスタンスとオートスケーリングのベースとなるカスタム・イメージを作成していきます。以下の記事を参考にしてください。
インスタンス構成の作成
次は、ベースになるカスタム・イメージからインスタンス構成を作成します。
インスタンス構成は、オートスケーリング用インスタンスを起動する元になり、イメージ、シェイプ、sshキー情報、ブロックボリューム、ネットワーク情報などが定義されています。
左上ハンバーガーメニューから コンピュート > インスタンス構成 を選択し、インスタンス構成の作成 をクリックします。
インスタンス構成の作成画面で以下を入力、選択します。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
インスタンスの作成先のコンパートメント：自身の権限のあるコンパートメント
配置の可用性ドメインは、デフォルトのままにします。
イメージとシェイプのイメージで「イメージの変更」をクリックします。
「イメージの選択」で「マイ・イメージ」を選択します。
画面を下へスクロールし、「カスタム・イメージ」を選択、事前に作成したカスタム・イメージを選択し、「イメージの選択」をクリックします。
カスタム・イメージが選択されました。
必要な場合、シェイプを変更します。
今回は変更するのでシェイプの変更から変更します。
VM.Standard3.Flex
セキュリティは、デフォルトのままで「次」をクリックします。
ネットワーキングは、以下入力、選択します。
VNIC名：空白（デフォルト）
プライマリ・ネットワーク：既存の仮想クラウド・ネットワークを選択
仮想クラウド・ネットワークコンパートメント：自身の権限のあるコンパートメント
仮想クラウド・ネットワーク：サブネットを作成したVCN
サブネットコンパートメント：自身の権限のあるコンパートメント
サブネット：事前に作成したパブリック・サブネット
プライマリVNIC IPアドレスは、以下入力、選択します。
「プライベートIPv4アドレス」は、「プライベートIPv4アドレスの自動割当て」を選択します。
「パブリックIPv4アドレスの自動割当て」は、デフォルトのままONにします。
「IPv6アドレス」は、デフォルトのままOFFにします。
拡張オプション を展開します。
今回の検証では、パブリック・サブネットのセキュリティ・リストの中身（イングレス、エグレス）は空にして利用していません。
セキュリティは、インスタンスにアタッチするネットワーク・セキュリティ・グループで制御したいので事前に作成しておいたネットワーク・セキュリティ・グループを選択します。
「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」をONにして、事前に作成しておいたネットワーク・セキュリティ・グループを選択します。
「SSHキーの追加」は、「キー・ペアを自動で生成」を選択し、「秘密キーのダウンロード」、「公開キーのダウンロード」をクリックし、ダウンロードしておきます。
「次」をクリックします。
ブート・ボリュームは、公式ドキュメントに従って以下のとおり設定します。
「カスタム・ブート・ボリューム・サイズを指定します」は、デフォルトのままOFFとします。
「転送中暗号化の使用」は、デフォルトのままONとします。
「自分が管理するキーでこのボリュームを暗号化」は、デフォルトのままOFFとします。
「次」をクリックします。
確認画面で設定内容を確認し、「作成」をクリックします。
※表示が長いので割愛します
インスタンス構成が作成されました。
インスタンス・プールの作成
作成したインスタンス構成をもとに、インスタンス・プールを作成します。
インスタンス・プールを作成すると、インスタンス構成で設定したインスタンスがインスタンス・プールで設定した数だけ起動します。
今回はサイズを「0」で作成し、あとでスケーリングしてこの数を増やしてみたいと思います。「0」なのでインスタンス・プールを作成しただけではインスタンスは起動してきません。
左上ハンバーガーメニューから コンピュート > インスタンス構成 を選択し、作成したインスタンスの構成のリンクをクリックします。
右上の「アクション」> インスタンス・プールの作成 をクリックします。
インスタンス・プールの作成画面で以下を入力、選択し、「次」をクリックします。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
インスタンス数：０ （※ここを１にするとインスタンス・プールを作成した時点で１台インスタンスが起動します）
インスタンス構成コンパートメント：自身の権限のあるコンパートメント
インスタンス構成：作成したインスタンス構成
インスタンス表示名フォーマッタ：何もしない（デフォルト）
インスタンス・ホスト名フォーマッタ：何もしない（デフォルト）
インスタンス構成詳細、タグも何もしない
プール配置の構成画面で以下を入力、選択し、「次」をクリックします。
可用性ドメイン：可用性ドメイン1（大阪リージョンは可用性ドメインが１つしかないため）
フォルト・ドメイン：何もしない（デフォルト）※任意のフォルト・ドメインを選択することもできます
仮想クラウド・ネットワークの選択コンパートメント：自身の権限のあるコンパートメント
仮想クラウド・ネットワークの選択：自身のVCNを選択
サブネットの選択コンパートメント：自身の権限のあるコンパートメント
サブネットの選択：インスタンスを展開したいサブネットを選択（今回はパブリック・サブネット）
ロード・バランサのアタッチを「ON」にします。
ここを「ON」にすることでロード・バランサのバックエンド・サーバーにアタッチされることになります。
ロード・バランサ 1の設定を以下のとおり入力、選択し、「次」をクリックします。
ロード・バランサ・タイプ：ロード・バランサ
ロード・バランサコンパートメント：自身の権限のあるコンパートメント
ロード・バランサ：利用したロード・バランサ
バックエンド・セット：ロード・バランサ作成時に作成したバックエンド・セット
ポート：80
VNIC：プライマリVNIC（デフォルト）
設定内容を確認し、右下の「送信」をクリックします。
インスタンス・プールが作成されました。
オートスケーリングの設定
作成したインスタンス・プールを元にオートスケーリングを作成します。
公式チュートリアルに習い、インスタンス・プール内の平均CPU使用率が70%を上回ったら1インスタンス増やす、30%未満になったら1インスタンス減らす、というポリシーを設定します。
スケーリングするインスタンス数は、最小1インスタンス、最大3インスタンスに設定します。
左上ハンバーガーメニューから コンピュート > インスタンス・プール を選択し、作成したインスタンス・プールのリンクをクリックします。
右上の「アクション」> 自動スケーリング構成の作成 をクリックします。
自動スケーリング構成の作成画面で以下を入力、選択し、「次」をクリックします。
名前：任意名
コンパートメントに作成：自身の権限のあるコンパートメント
インスタンス・プール：作成したインスタンス・プール
自動スケーリング・ポリシーの構成で以下を入力、選択します。
メトリックベースの自動スケーリング
続いて、以下を入力、選択します。
自動スケーリング・ポリシーの構成
自動スケーリング・ポリシー名：任意名
クールダウン（秒）：300（デフォルト）
パフォーマンス・メトリック：CPU使用率
続いて、以下を入力、選択します。
スケールアウト・ルール
スケールアウト演算子：次より大きい（>）
しきい値パーセンテージのスケールアウト：70
追加するインスタンスの数：１
続いて、以下を入力、選択します。
スケールイン・ルール
スケールイン演算子：次より小さい（<）
しきい値パーセンテージのスケールアウト：30
削除するインスタンスの数：１
続いて、以下を入力、選択し、「次」をクリックします。
スケーリング制限
インスタンスの最小数：１
インスタンスの最大数：3
インスタンスの初期数：１
確認画面で内容を確認し、「作成」をクリックします。
自動スケーリング構成が作成できました。
インスタンスの確認
インスタンス画面でオートスケーリングで設定した「インスタンスの初期数」の１台が起動して「実行中」になりました。
動作確認
ロード・バランサの確認
全体的なヘルスが「OK」になりました。オートスケーリングの初期数で指定したインスタンス１台が起動し、ロード・バランサ配下へ正常に組み込まれ、ヘルスチェックが完了したためです
ロード・バランサ名をクリック、「バックエンド・セット」タブを選択、バックエンド・セット名をクリックします。
「バックエンド」タブを選択するとオートスケーリングから起動したインスタンス１台のプライベートIPアドレスが確認できます。
ロード・バランサのパブリックIPアドレスへブラウザから「http://パブリックIPアドレス」でアクセスしてみます。
オートスケーリングから起動したインスタンスのWEBページが表示されました。
接続元（Client IP）は、10.03.170（ロード・バランサのプライベートIPアドレス）になっていることが確認できます。
CPU負荷を上げてスケールアウトを確認する
オートスケーリングで起動してきたインスタンスにOS上からCPU負荷をかけてCPU使用率が閾値（ここでは70%）を上回るように設定し、インスタンスが1台増えることを確認します。
インスタンスへSSHでログインします。
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
作成したインスタンス・プールをクリック、「モニタリング」タブを選択、「CPU使用率」をCPU使用率が急上昇していることが確認できます。
上記状態で、クールダウン期間で指定した300秒が過ぎると、スケーリングします。
作成したインスタンス・プールをクリック、「詳細」タブを選択し、「アタッチされたインスタンス」を確認すると２台目のインスタンスが起動していました。
インスタンス画面から２台目のインスタンスのプライベートIPアドレスを確認しておきます。
次にインスタンス・プールをクリック、「モニタリング」タブを選択し、「CPU使用率」を確認します。
2台の平均CPU使用率が、だいたい50%になっていることが確認できます。
もし、２台目のインスタンスでもCPU使用率を100%にすれば、2台の平均CPU使用率は100%となり、3台目のインスタンスが起動することになります。
今回は2台目までにしておきます。
１台目のインスタンスのCPU使用率：100%
2台目のインスタンスのCPU使用率：0%
2台の平均CPU使用率：50%
ロード・バランサの確認（スケールアウト後）
引き続き、全体的なヘルスが「OK」であることを確認します。
ロード・バランサ名をクリック、「バックエンド・セット」タブを選択、バックエンド・セット名をクリックします。
「バックエンド」タブを選択するとオートスケーリングから起動したインスタンス２台のプライベートIPアドレスが確認できます。
ロード・バランサのパブリックIPアドレスへブラウザから「http://パブリックIPアドレス」でアクセスしてみます。
オートスケーリングから起動したインスタンスのWEBページが表示されました。
WEBページを更新すると２台のインスタンスへ負荷分散されていることが確認できます。
CPU負荷を下げてスケールインを確認する
次は、CPU使用率を下げてスケールインすることを確認します。
バックグラウンドで動いているすべての stress プロセスを一括停止する場合、pkill stressを実行します。
pkill stress
topコマンドで確認してみます。
CPU使用率は、0 % になりました。
top
この状態で、クールダウン期間で指定した300秒が過ぎると、スケーリングします。
作成したインスタンス・プールをクリック、「詳細」タブを選択し、「アタッチされたインスタンス」を確認するとインスタンスが１台「終了中」⇒「終了済」になっており、スケールインしていることが確認できます。
ロード・バランサの確認（スケールイン後）
引き続き、全体的なヘルスが「OK」であることを確認します。
ロード・バランサ名をクリック、「バックエンド・セット」タブを選択、バックエンド・セット名をクリックします。
「バックエンド」タブを選択するとオートスケーリングからスケールインしてインスタンスが１台になっていることが確認できます。
ロード・バランサのパブリックIPアドレスへブラウザから「http://パブリックIPアドレス」でアクセスしてみます。
オートスケーリングからスケールインしてインスタンスは１台となります。
WEBページを更新してもインスタンスは１台のため、タイムスタンプは変わりません。
まとめ
ロード・バランサとオートスケーリングを連携し、ロード・バランサ配下でWEBサーバがオートスケーリング設定に沿って増減することを検証しました。カスタム・イメージを作成しておけば、アプリをインストールした仮想マシンがオートスケーリング設定に従い、スケールアウト、スケールインすることも確認できました。
以下、他の記事をまとめた一覧です。OCI以外にAWSもまとめています。
