OCI Instance Pools

解決する課題

同じ役割のインスタンスを1台ずつ作成・配置・更新すると、設定差や作業漏れが生まれます。Instance Pools は、同一リージョンの複数インスタンスを1つの管理単位として扱い、指定台数、配置、負荷分散登録、終了前処理をそろえます。

• 同一構成のインスタンスを1つ1つ手作業で作りたくない、台数もまとめて変えたい
• 障害で台数が減ったら自動で補充して、目標台数を維持したい
• 複数の配置先へ分散し、正常化した台だけをLoad Balancer / Network Load Balancerへ登録したい
• スケールインやプール終了の前に、通信排出、ログ保存、外部資源の解放を完了したい
• 需要やスケジュールで台数を変える場合の、Autoscaling の実行基盤が欲しい

主要概念と用語

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

仕様・制限・クォータ

• インスタンスプールは1つのインスタンス構成を参照する。構成を変えたい場合は、別の構成を作って差し替える
• プール作成後に既存インスタンスをアタッチでき、1つ以上の Load Balancer / Network Load Balancer を関連付けられる
• AD、FD、サブネットはプールの配置設定がインスタンス構成内の値より優先される
• 1つのプールは複数の可用性ドメイン/フォールトドメインに分散配置でき、これがプール内の可用性を高める
• FDへの厳密な均等配置を指定すると、特定FDの容量不足で作成Work Requestが失敗し得る。既定のベストエフォート分散との違いを選ぶ
• 1プールに Autoscaling 構成は1つ。構成にはメトリクス方式1ポリシーまたは予定方式最大50ポリシーのどちらかを設定する
• メトリクスベースでは、スケールアウト用のしきい値（上限）とスケールイン用のしきい値（下限）をそれぞれ設定する
• スケーリングは最小台数と最大台数の範囲内でのみ動作し、範囲外には増減しない
• プール自体や Autoscaling の台数調整に追加料金はかからない（課金されるのは起動された Compute やストレージなどのリソース）
• プール数・Autoscaling 構成数・プール内インスタンス数などはテナンシ/リージョン単位のサービス制限/クォータで管理され、引き上げ申請が可能
• メトリクスベースのスケーリングは、対象インスタンスにCompute メトリクスを提供する仕組み（監視エージェント等）が有効である前提で評価される

内部の仕組み

Instance Pool は、参照するインスタンス構成をテンプレートとして、目標台数ぶんのインスタンスを指定の AD / FD へ分散して起動します。配置先 AD、FD、サブネットはプール設定が優先されます。台数が目標を下回ると、プールは差分を埋めて設定台数を維持しようとします。

Autoscaling は関連する別機能で、メトリクスやスケジュールに従ってプールの台数またはライフサイクル状態を変更します。プール単体でも、管理者や API がサイズを変更し、一括停止・開始・再起動を実行できます。

• スケールアウトで増えたインスタンスは、ロードバランサをアタッチしていれば自動でバックエンドに登録され、スケールインで減るときは登録解除される
• 複数 AD への分散配置により、1つの AD で問題が起きても残りで処理を継続しやすい
• 終了前アクションを有効にすると、削除対象は TerminationAwait で待機する。終了続行 API を送るかタイムアウトすると終了し、タイムアウト時のブート / ブロックボリューム保持方針が適用される

横にスクロール

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

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

運用・監視

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

コスト

Instance Pools の管理機能自体に追加料金はかからず、課金対象は実際に起動された Compute インスタンス、ブート / ブロックボリューム、ネットワークなどです。必要台数へ手動または Autoscaling で調整し、終了前アクションで保持するボリュームの費用も追跡します。

セキュリティ

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

Well-Architected の観点

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

押さえるポイント

関連サービス・比較

OCI Instance Pools は、AWS Auto Scaling group の台数・配置管理に近く、OCI Autoscaling を追加するとメトリクスや予定による自動操作まで対応します。

ハンズオン / CLI例

典型的な流れは、まずインスタンス構成を作り、それを使ってインスタンスプールを起動し、Work Request とプール状態を確認することです。Autoscaling は必要な場合だけ別途紐付けます。

# 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. 現在のプール状態と台数を確認
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