OCI Instance Pools / Autoscaling

解決する課題

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

• ピークに合わせた過剰プロビジョニングをやめ、必要なときだけ台数を増やしたい
• 急なスパイクに自動でスケールアウトし、落ち着いたらスケールインしてほしい
• 同一構成のインスタンスを1つ1つ手作業で作りたくない、台数もまとめて変えたい
• 障害で台数が減ったら自動で補充して、目標台数を維持したい
• 夜間や週末など予測できる増減はスケジュールで先回りしたい

主要概念と用語

• インスタンス構成（Instance Configuration）: 起動するインスタンスの設計図。シェイプ・イメージ・サブネット・ブートボリューム・メタデータなどをテンプレート化したもの。AWS の起動テンプレート相当
• インスタンスプール（Instance Pool）: インスタンス構成をもとに、指定した台数のインスタンス群を一括で作成・管理する単位。複数の可用性ドメイン（AD）/フォールトドメインにまたがって配置できる
• Autoscaling 構成（Autoscaling Configuration）: プールに対して自動スケーリングのルールを定義するもの。1つのプールに紐付ける
• メトリクスベースのスケーリング: CPU やメモリ使用率などの監視メトリクスがしきい値を超えたら台数を増減するポリシー
• スケジュールベースのスケーリング: 時刻やcron的なスケジュールで台数を変えるポリシー。予測できる負荷に有効
• 目標台数 / 最小・最大台数: プールが維持しようとする台数と、Autoscaling が動ける下限・上限
• クールダウン: スケーリング動作の後、次の判定までメトリクスを安定させるための待機時間
• ロードバランサのアタッチ: プールに OCI Load Balancer や Network Load Balancer を紐付け、増減したインスタンスを自動でバックエンドに登録/解除する仕組み

仕様・制限・クォータ

• インスタンスプールは1つのインスタンス構成を参照する。構成を変えたい場合は、別の構成を作って差し替える
• 1つのプールは複数の可用性ドメイン/フォールトドメインに分散配置でき、これがプール内の可用性を高める
• Autoscaling のポリシーはメトリクスベースとスケジュールベースの2種類。1つの Autoscaling 構成に複数のポリシーを持たせられる
• メトリクスベースでは、**スケールアウト用としきい値（上限）とスケールイン用のしきい値（下限）**をそれぞれ設定する
• スケーリングは最小台数と最大台数の範囲内でのみ動作し、範囲外には増減しない
• プール自体や Autoscaling の台数調整に追加料金はかからない（課金されるのは起動された Compute やストレージなどのリソース）
• プール数・Autoscaling 構成数・プール内インスタンス数などはテナンシ/リージョン単位のサービス制限/クォータで管理され、引き上げ申請が可能
• メトリクスベースのスケーリングは、対象インスタンスに**Compute メトリクスを提供する仕組み（監視エージェント等）**が有効である前提で評価される

内部の仕組み

Instance Pool は、参照するインスタンス構成をテンプレートとして、目標台数ぶんのインスタンスを指定の AD/フォールトドメインへ分散して起動します。台数が目標を下回ると（手動終了や障害など）、プールが差分を検知して自動で補充し、目標台数を維持しようとします。

Autoscaling は、このプールの上に乗ってメトリクスやスケジュールを評価し、目標台数そのものを動かします。メトリクスベースの場合、Monitoring が集めた使用率を一定間隔で評価し、上限しきい値を超え続ければスケールアウト、下限を下回り続ければスケールインを発火します。発火後はクールダウンの間、次の判定を待ってメトリクスを安定させます。

• スケールアウトで増えたインスタンスは、ロードバランサをアタッチしていれば自動でバックエンドに登録され、スケールインで減るときは登録解除される
• 複数 AD への分散配置により、1つの AD で問題が起きても残りで処理を継続しやすい

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

• ステートレスに設計し、状態は Object Storage や Autonomous Database など外部に置く（任意のインスタンスがいつ終了されてもよいように）
• インスタンスの初期化はカスタムイメージやcloud-init / メタデータで自動化し、起動した瞬間にトラフィックを受けられるようにする
• 複数 AD/フォールトドメインに分散配置して、単一障害ドメインの影響を抑える
• 前段にロードバランサを置き、増減したインスタンスを自動でバックエンド登録/解除する
• 予測できる負荷はスケジュールベース、読めないスパイクはメトリクスベースと使い分ける
• しきい値・クールダウン・最小/最大台数を実測に基づいて調整し、ピーク時のキャパシティと普段のコストのバランスを取る

運用・監視

• プールやインスタンスの状態は OCI コンソール/CLI で確認でき、各インスタンスのライフサイクル状態（起動中/実行中/終了中など）を追える
• メトリクスは OCI Monitoring で確認する。スケーリングの判定に使う CPU 使用率などのほか、台数推移を併せて見ると挙動を把握しやすい
• スケーリングが想定通り動かないときは、メトリクスが取得できているか、しきい値とクールダウンの設定、最小/最大台数の範囲を順に確認する
• スケールインで終了されるインスタンスがリクエスト処理中の可能性を踏まえ、コネクションドレインやアプリ側のグレースフルシャットダウンを用意する
• 構成変更（イメージ更新など）は、新しいインスタンス構成を作ってプールに差し替え、段階的に置き換える運用にする

コスト

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

セキュリティ

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

Well-Architected の観点

• 信頼性: 目標台数の自動維持と複数 AD への分散で、障害時も処理を継続しやすい。台数が減っても自動補充される
• コスト: 過剰プロビジョニングをやめ、需要に台数を合わせることで普段のコストを抑える。機能自体は無償
• パフォーマンス: スパイク時にスケールアウトして応答性を保ち、スケジュールで予測負荷に先回りできる

試験で問われるポイント

関連サービス・比較

OCI の Instance Pools / Autoscaling は、AWS の EC2 Auto Scaling に対応します。テンプレート・グループ・スケーリングポリシーという構成要素の対応関係を押さえると理解しやすくなります。

ハンズオン / CLI例

典型的な流れは、まずインスタンス構成を作り、それを使ってインスタンスプールを起動し、最後にAutoscaling 構成を紐付けることです。以下は OCI CLI での骨子です（OCID やしきい値は環境に合わせて置き換えてください）。

# 1. インスタンス構成を作成（インスタンスの設計図。詳細はJSONで指定）
oci compute-management instance-configuration create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --display-name web-config \
  --instance-details file://instance-details.json

# 2. インスタンス構成からプールを起動（目標台数とサブネットを指定）
oci compute-management instance-pool create \
  --compartment-id ocid1.compartment.oc1..xxxxx \
  --instance-configuration-id ocid1.instanceconfiguration.oc1..xxxxx \
  --size 2 \
  --display-name web-pool \
  --placement-configurations file://placement.json

# 3. プールにメトリクスベースの 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"}'

# 4. 現在のプール状態と台数を確認
oci compute-management instance-pool get \
  --instance-pool-id ocid1.instancepool.oc1..xxxxx \
  --query "data.{name:\"display-name\", size:size, state:\"lifecycle-state\"}" \
  --output table