Fleet Application Management

解決する課題

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

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

主要概念と用語

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

仕様・制限・クォータ

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

内部の仕組み

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

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

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

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

運用・監視

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

コスト

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

セキュリティ

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

関連サービス・比較

Fleet Application Management はアプリ／ミドルウェア層の運用を担い、OS のパッチは OS Management Hub、IaC によるプロビジョニングは Resource Manager が分担します。AWS では Systems Manager が OS からアプリの自動化までを広く内包しますが、OCI では層ごとに焦点を分けたサービスとして整理されています。

ハンズオン / CLI例

# 1) フリート（運用の群）を作成
oci fleet-apps-management fleet create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "prod-db-fleet" \
  --fleet-type "PRODUCT"

# 2) フリート一覧を確認（作成されたか／対象が紐づいているか）
oci fleet-apps-management fleet list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query "data.items[].{name:\"display-name\",state:\"lifecycle-state\"}"

# 3) フリートのコンプライアンス状況を取得（非準拠の有無を把握）
oci fleet-apps-management compliance-record collection \
  --compartment-id "$COMPARTMENT_OCID"

# 4) パッチ計画やランブックの実行（ジョブ）状況を一覧
#    どのタスクで止まったかの切り分けに使う
oci fleet-apps-management scheduler-job list \
  --compartment-id "$COMPARTMENT_OCID"