OCI Compute Autoscaling

解決する課題

トラフィックは時間帯やイベントで大きく変動しますが、ピークに合わせて常時多めにインスタンスを立てておくとコストが無駄になり、逆に手動で増減すると対応が遅れます。Compute Autoscaling は、インスタンスプールの目標台数を需要に応じて自動で動かし、この「台数を需要に合わせる」運用を自動化します。

• ピークに合わせた過剰プロビジョニングをやめ、必要なときだけ台数を増やしたい
• 急なスパイクに自動でスケールアウトし、落ち着いたらスケールインしてほしい
• 夜間や週末など予測できる増減は時刻で先回りしたい
• 台数調整のために人手で監視・操作する運用から脱したい

主要概念と用語

• Autoscaling 構成（Autoscaling Configuration）: 1つのインスタンスプールに紐付け、自動スケーリングのルールをまとめて定義するリソース。AWS の Auto Scaling グループに付与するスケーリングポリシー群に相当
• インスタンスプール（Instance Pool）: スケーリング対象となる、同一構成のインスタンス群。Autoscaling 構成が目標台数を動かす対象
• メトリクスベースのポリシー: CPU やメモリ使用率などの監視メトリクスがしきい値を超えたら台数を増減するポリシー。読めないスパイク向き
• スケジュールベースのポリシー: cron 形式などの時刻に基づいて台数を変えるポリシー。予測できる増減向き
• スケールアウト / スケールイン: 台数を増やす動作と減らす動作
• しきい値: メトリクスベースで、スケールアウトを発火させる上限と、スケールインを発火させる下限
• 最小台数 / 最大台数: Autoscaling が動ける下限と上限。この範囲を超えて増減はしない
• クールダウン: スケーリング動作の後、次の判定までメトリクスを安定させるための待機時間

仕様・制限・クォータ

• Autoscaling 構成は1つのインスタンスプールに紐付ける。プールがスケーリングの対象となる
• ポリシーにはメトリクスベースとスケジュールベースの2種類があり、1つの Autoscaling 構成に複数のポリシーを持たせられる
• メトリクスベースでは、**スケールアウト用としきい値（上限）とスケールイン用のしきい値（下限）**をそれぞれ設定する
• スケーリングは最小台数と最大台数の範囲内でのみ動作し、範囲外には増減しない
• メトリクスベースの評価は、対象インスタンスに**Compute メトリクスを提供する仕組み（監視プラグイン等）**が有効である前提で行われる
• 機能自体に追加料金はかからない（課金は起動された Compute やストレージなどのリソースに対して発生）
• Autoscaling 構成数などはテナンシ/リージョン単位のサービス制限/クォータで管理され、引き上げ申請が可能

内部の仕組み

Autoscaling 構成は、紐付いたインスタンスプールの上に乗ってメトリクスやスケジュールを評価し、プールの目標台数そのものを動かします。プールは目標台数を維持しようとする基盤なので、Autoscaling が目標台数を上げればプールがインスタンスを追加し、下げればプールが終了します。

メトリクスベースの場合、Monitoring が集めた使用率を一定間隔で評価し、上限しきい値を超え続ければスケールアウト、下限を下回り続ければスケールインを発火します。発火後はクールダウンの間、次の判定を待ってメトリクスを安定させます。スケジュールベースの場合は、指定した時刻に達したタイミングで目標台数を変更します。

• スケールアウトで増えたインスタンスは、プールにロードバランサがアタッチされていれば自動でバックエンドに登録され、スケールインで減るときは登録解除される
• 増減はあくまで最小台数と最大台数の範囲内で行われ、範囲を超えることはない

設計パターン / ベストプラクティス

• ステートレスに設計し、状態は Object Storage や Autonomous Database など外部に置く（任意のインスタンスがいつ終了されてもよいように）
• インスタンスの初期化はカスタムイメージや cloud-init / メタデータで自動化し、起動した瞬間にトラフィックを受けられるようにする
• 前段にロードバランサを置き、増減したインスタンスを自動でバックエンド登録/解除する
• 予測できる負荷はスケジュールベース、読めないスパイクはメトリクスベースと使い分ける。両方を組み合わせてもよい
• しきい値・クールダウン・最小/最大台数を実測に基づいて調整し、ピーク時のキャパシティと普段のコストのバランスを取る
• 最小台数は「許容できる最低限のキャパシティ」、最大台数は「コスト上限とサービス制限」を踏まえて設定する

運用・監視

• メトリクスは OCI Monitoring で確認する。スケーリングの判定に使う CPU 使用率などのほか、台数推移を併せて見ると挙動を把握しやすい
• スケーリングが想定通り動かないときは、メトリクスが取得できているか、しきい値とクールダウンの設定、最小/最大台数の範囲を順に確認する
• スケールインで終了されるインスタンスがリクエスト処理中の可能性を踏まえ、コネクションドレインやアプリ側のグレースフルシャットダウンを用意する
• 構成変更（しきい値や台数の見直し）は、Autoscaling 構成を更新して反映する。負荷傾向の変化に合わせて定期的に見直す

コスト

Compute Autoscaling の機能自体に追加料金はかからず、課金対象は実際に起動された Compute インスタンス・ブートボリューム・ブロックボリューム・ネットワークなどのリソースです。コスト最適化の本質は「必要な台数しか動かさない」ことにあり、Autoscaling はそれを自動化する手段になります。

セキュリティ

• 自動で増減するため、新規インスタンスにもパッチ適用済みの最新カスタムイメージが確実に反映されるよう、参照するインスタンス構成のイメージライフサイクルを管理する
• インスタンスから OCI サービスへアクセスする際は、鍵のハードコードを避けインスタンスプリンシパルを使う（AWS のインスタンスプロファイル相当）
• Autoscaling 構成やプールの操作（作成・スケール・終了）は IAM ポリシーで必要な範囲に限定する
• インスタンスはプライベートサブネットに配置し、NSG / セキュリティリストでネットワーク境界を制御する

関連サービス・比較

Compute Autoscaling はインスタンスプールとセットで使う機能で、プールが台数管理の基盤、Autoscaling がスケーリングルールを担います。役割の違いを押さえると使い分けやすくなります。

ハンズオン / CLI例

既存のインスタンスプールに対して、メトリクスベースの Autoscaling 構成を紐付ける例です。ポリシーの詳細（しきい値・最小/最大台数など）は JSON で指定し、OCID は環境に合わせて置き換えてください。

# 1. 既存プールにメトリクスベースの Autoscaling 構成を作成
#    CPU使用率が高ければスケールアウト、低ければスケールインする
oci autoscaling configuration create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --display-name web-autoscaling \
  --policies file://autoscaling-policies.json \
  --auto-scaling-resources '{"id":"ocid1.instancepool.oc1..xxxxx","type":"instancePool"}'

# 2. 作成済みの Autoscaling 構成を一覧で確認
oci autoscaling configuration list \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --query "data[].{name:\"display-name\", enabled:\"is-enabled\"}" \
  --output table

# 3. 構成の詳細（紐付くプールやポリシー）を取得
oci autoscaling configuration get \
  --auto-scaling-configuration-id ocid1.autoscalingconfiguration.oc1..xxxxx