クラウドサービス

Fleet Application Management

既存フリートのアプリ層パッチとライフサイクル運用を自動化するサービス。2026年5月6日に非推奨となり、新規採用は不可。既存利用者は2027年5月1日の終了までに代替サービスへ移行する。

中級運用上の優秀性セキュリティ信頼性
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. 既存利用者向けに、アプリやミドルウェアのパッチとメンテをフリート単位で実行する。
  2. 2026年5月6日に非推奨となり、新規顧客は採用できない。
  3. 2027年5月1日の終了までに JMS、Database Management など適切な代替へ移行する。

解決する課題

非推奨。2027年5月1日にサービス終了

Fleet Application Management は2026年5月6日に非推奨となり、新規採用できません。既存テナンシとリージョンでは2027年5月1日まで利用できますが、それまでに Java は Java Management Service、データベースは Database Management、その他は対象に合う Observability & Management サービスへ移行します。

OS のパッチは仕組み化できても、その上で動くアプリケーションやミドルウェア(データベース、Java ランタイム、アプリサーバーなど)のパッチ適用や定型メンテは、依然として個別の手作業に頼りがちです。対象が数十〜数百に増えると、適用漏れ・手順のばらつき・実行記録の欠落が積み上がります。Fleet Application Management は、こうしたアプリ層の運用を「フリート」という群の単位で標準化・自動化します。

  • 多数のアプリ/ミドルウェアのパッチ適用を計画的に回し、適用漏れをなくしたい
  • バックアップ・再起動・健全性チェックといった定型メンテを手順化して反復実行したい
  • 群ごとにコンプライアンス状態(パッチ準拠か)を横断的に可視化したい
  • 手作業の SSH や個別スクリプトをやめ、監査可能で繰り返せるプロセスへ移したい
  • メンテナンスウィンドウ内でスケジュール実行し、影響を局所化したい

主要概念と用語

  • フリート(Fleet): 同種の運用をまとめて適用する対象の群。アプリケーションやリソースを束ね、パッチやライフサイクル操作を一括で実行する単位
  • 製品(Product)/プラットフォーム: フリートが扱う対象の種類。データベースや Java ランタイム、アプリサーバーなど、パッチや運用手順が定義された対象を指す
  • パッチ(Patch): 対象へ適用する更新の単位。利用可能なパッチを把握し、フリートへ計画的に適用する
  • コンプライアンスポリシー(Compliance Policy): 対象が満たすべきパッチ水準の定義。これに照らして各リソースの準拠/非準拠を評価する
  • ライフサイクル操作(Lifecycle Operation): 起動・停止・再起動・バックアップなど、定型化して反復実行する運用アクション
  • ランブック(Runbook): 一連の手順を定義した実行テンプレート。パッチ適用や定型メンテの流れをタスクの並びとして表現し、フリートに対して走らせる
  • スケジュール(Schedule): パッチ計画やライフサイクル操作を指定時刻・繰り返しで実行する定義。メンテナンスウィンドウの実装に使う
  • タスク/ジョブ: ランブックを構成する個々の実行ステップと、その実行インスタンス。実行結果やログが記録される

仕様・制限・クォータ

  • 対象の種類: データベースやミドルウェアなど、サービスが運用手順を定義した製品・プラットフォームを対象とする。扱える対象や利用できる操作は提供範囲に依存するため、対象が対応しているかを事前に確認する
  • 新規採用不可・終了予定: 2026年5月6日から非推奨で新規顧客は利用できない。既存利用者も2027年5月1日までに移行を完了する
  • エージェント/到達性の前提: 対象上で運用アクションを実行するため、管理エージェントの稼働や、サービスから対象へ指示を届けられるネットワーク経路・権限が前提になる。プライベートサブネットでは経路設計が必要
  • リージョン単位のサービス: フリートやコンプライアンスの評価はリージョンに紐づく。クロスリージョンの一括操作は標準では行わず、リージョンごとに構成する
  • コンパートメント境界: 操作は IAM のコンパートメント/ポリシーの範囲に従う。フリートに含められる対象も権限の及ぶ範囲に限られる
  • クォータ: フリートやランブック、スケジュールなどの作成数にはテナンシ/リージョン単位の上限があり、上限引き上げはサービスリクエストで申請する。変動し得るため、最新の上限はコンソールのリミット表示で確認する
移行先は対象製品ごとに選ぶ

既存の OS パッチは OS Management Hub、Java は Java Management Service、Oracle Database と Exadata は Database Management を候補にします。単一の後継へ機械的に置き換えるのではなく、フリート、資格情報、ランブック、監視要件を棚卸しして移行先を分けます。

内部の仕組み

横にスクロール

Fleet Application Managementについて、既存フリートの運用を継続し、代替サービスへ移行する処理経路と利用者・サービスの責任境界を示す図
Fleet Application Management の処理経路。2026年5月6日に非推奨。2027年5月1日にサービス終了

Fleet Application Management は、フリートに含まれる各リソースについて利用可能なパッチや現在のパッチ水準を把握し、コンプライアンスポリシーと照合して準拠状況を算出します。パッチ適用や定型メンテは、ランブックとして定義された手順をサービスがオーケストレーションし、対象上で順番にタスクを実行する形で進みます。

  • 宣言と実行の分離が要点です。何を満たすべきか(コンプライアンスポリシー)と、どう実現するか(ランブック)を分けて定義し、フリート単位で適用します。
  • ランブックによる手順化: バックアップ→停止→パッチ→起動→健全性チェックのような流れをタスクの並びとして表現し、フリート横断で同じ手順を再現します。途中の失敗を検知して止められるため、影響を局所化できます。
  • スケジュール実行: パッチ計画やライフサイクル操作を指定時刻・繰り返しで走らせ、メンテナンスウィンドウ内で安全に回します。
  • 可視化の集約: 各リソースの準拠/非準拠や実行結果を集約し、コンソール/API でフリート横断のビューとして提供します。

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

  • フリートを運用粒度で切る: 同じパッチ周期・同じメンテ手順でまとめられる対象を 1 フリートにする。本番と非本番、製品種別ごとに分けると一括操作の影響範囲が読みやすい
  • ランブックで手順を標準化: バックアップと健全性チェックを前後に挟み、パッチ失敗時に止まる設計にする。手順をコード相当の資産として管理し、属人化を防ぐ
  • 段階ロールアウト: まず少数の非本番フリートへ適用して安定を確認し、問題なければ本番フリートへ展開する。検証していない更新を本番へ直接流さない
  • スケジュールでメンテナンスウィンドウを実装: 深夜帯など影響の小さい時間にスケジュール実行し、再起動を伴う操作は対象を分割してローリングで回す
  • コンプライアンスを運用 KPI に: 非準拠リソースの件数を定期的に追い、未適用のセキュリティパッチを放置しないルールを置く

運用・監視

  • 対象がフリートに出てこない/操作されない: 管理エージェントが有効か、サービスから対象へ到達できるネットワーク経路と IAM ポリシーがあるかを確認する
  • パッチ適用が途中で失敗する: ランブックのどのタスクで止まったかを実行ログで切り分ける。前段のバックアップ・健全性チェックの結果も併せて確認する
  • 適用後の不具合: 非本番フリートで再現するか確認し、問題のパッチを除外した計画で再展開する。バックアップからの復旧手順も併せて整備しておく
  • 可観測性の連携: パッチ計画やライフサイクル操作の実行結果は OCI Logging へ、操作の監査証跡は OCI Audit へ残す。アラートが要る指標は Monitoring/Notifications と組み合わせる
  • スケジュールの重なりに注意: 同じ対象に複数のスケジュールがかからないよう整理し、メンテナンスウィンドウの衝突を避ける

コスト

Fleet Application Management 自体の利用に対する課金の考え方はリージョンや契約により変わり得ます。一般に大きいのは、運用の対象となるアプリ/ミドルウェアやその基盤リソース(Compute、ストレージ、データベースなど)のコストであり、管理機能はそれらの運用を効率化する位置づけです。パッチ実行時の一時的なリソース(バックアップ用ストレージなど)も別途発生します。最新かつ正確な料金は公式の料金ページで確認してください。コスト最適化の観点では、不要になった対象をフリートから外し、スケジュールやランブックの実行頻度を実需要に合わせるのが基本です。

課金/負担の対象Fleet Application ManagementAWS Systems Manager(Automation 等)
基本の管理機能アプリ層の運用を効率化する位置づけ基本の自動化・パッチ機能は追加料金が小さい構成が多い
主なコスト要因対象アプリと基盤リソースの稼働費対象リソースと一部の自動化ステップ実行
一時リソースバックアップ等のストレージが別途発生スナップショットやログ保存の費用
最適化ポイント不要対象を外し実行頻度を適正化対象スコープと自動化の実行回数を絞る

セキュリティ

  • IAM ポリシーで最小権限: フリート管理・パッチ適用・ランブック実行など、操作種別ごとに必要なグループ/動的グループへ限定して権限を付与する
  • 動的グループ+プリンシパル認証: 自動実行の認証に長期キーを埋め込まず、インスタンス/リソースプリンシパルで認証させる(AWS の IAM ロール相当)
  • 手順の統制でサプライチェーンを守る: ランブックと適用するパッチ計画をレビュー対象にし、未検証の手順やパッチが本番へ流れ込むのを防ぐ
  • セキュリティパッチの優先適用: コンプライアンス評価を使い、脆弱性に対応するパッチを優先してフリートへ展開する。重大度の高い非準拠を放置しない
  • 役割分担: 「何を実行したか」の操作監査は OCI Audit、実行ログは OCI Logging が担う。Fleet Application Management 自体は運用の実行と状態管理にフォーカスする
本番適用前の検証を飛ばさない

フリート横断の一括適用は便利ですが、検証していないパッチや手順をいきなり本番フリートへ流すと、影響が群全体に広がります。非本番フリートでの段階適用と、ランブックへのバックアップ・健全性チェックの組み込みを前提にしてください。一括化の利点は、標準化された安全な手順とセットで初めて活きます。

関連サービス・比較

Fleet Application Management に単一の後継サービスはありません。Java は Java Management Service、Oracle Database と Exadata は Database Management、その他は対象に合う OCI Observability & Management サービスを選びます。OS 更新は OS Management Hub、IaC は Resource Manager が引き続き分担します。

観点OCIAWS
アプリ層のパッチ/運用Fleet Application ManagementSystems Manager(Automation/Patch)
OS のパッチ/更新OS Management HubSystems Manager Patch Manager
IaC プロビジョニングResource ManagerCloudFormation
メトリクス/アラームOCI MonitoringAmazon CloudWatch
操作の監査証跡OCI AuditAWS CloudTrail
ログ収集・検索OCI LoggingCloudWatch Logs

ハンズオン / CLI例

# 1) 既存フリートを棚卸し
oci fleet-apps-management fleet list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query "data.items[].{name:\"display-name\",state:\"lifecycle-state\"}"

# 2) 移行対象フリートの詳細を取得
oci fleet-apps-management fleet get \
  --fleet-id "$FLEET_OCID"

# 3) 残っている定期ジョブを棚卸し
oci fleet-apps-management scheduler-job list \
  --compartment-id "$COMPARTMENT_OCID"

OCI Service

Fleet Application Managementを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

管理・ガバナンス

比較で見る軸

クラウド: OCI / カテゴリ: 管理・ガバナンス / 難易度: intermediate

導入後に効く点

2026年5月6日に非推奨となり、新規顧客は採用できない。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
OCI
カテゴリ
管理・ガバナンス
難易度
intermediate
関連資格
設計柱
operational / security / reliability

判断チェックリスト

  • 自社の用途が「管理・ガバナンス / operational」に近いか確認する。
  • 強みである「既存利用者向けに、アプリやミドルウェアのパッチとメンテをフリート単位で実行する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

管理・ガバナンスoperationalsecurityreliability