OCI OS Management Hub

解決する課題

数十〜数千台の OS を個別に SSH してパッチを当てる運用は、適用漏れ・バージョン乖離・脆弱性の放置を招きます。OS Management Hub は、Linux と Windows のパッチ／更新／構成をクラウド側から一元的に統制し、フリート全体の状態を可視化します。

• どのインスタンスに未適用の更新やセキュリティパッチがあるかを横断的に把握したい
• パッチ適用をスケジュール化・自動化し、メンテナンスウィンドウ内で安全に回したい
• 環境（開発・本番）ごとに適用するパッケージのバージョンを固定し、構成のドリフトを防ぎたい
• インターネット非接続のプライベートサブネットやオンプレミスのホストにも更新を届けたい
• 監査向けに「いつ・どのホストに・何を適用したか」の履歴とコンプライアンス状況を残したい

主要概念と用語

• マネージドインスタンス（Managed Instance）: OS Management Hub の管理対象となる個々のホスト。OCI 上の Compute だけでなく、エージェントを入れたオンプレや他クラウドのホストも対象にできる
• エージェント: 各ホストで動く管理用エージェント。OCI の Compute では Oracle Cloud Agent の OS Management Hub プラグインとして提供され、更新の検出・適用やインベントリ収集を担う
• グループ／フリート（Managed Instance Group）: 複数のマネージドインスタンスをまとめて一括操作する単位。グループ単位でパッチ適用や更新の実行ができる
• ライフサイクル環境（Lifecycle Environment）: 開発・テスト・本番のように更新を段階的に昇格させるための環境ステージ。各ステージへ順に適用し、検証済みの更新だけを本番へ進められる
• ソフトウェアソース（Software Source）: パッケージの配信元（リポジトリ）。ベンダー提供のものに加え、必要なパッケージだけを束ねたカスタムソフトウェアソースを作って配布内容を統制できる
• 管理ステーション（Management Station）: プライベート環境向けの中継・プロキシ兼ミラー。インターネット非接続のインスタンスへ更新を配信する経路となり、コンテンツのミラーリングも担う
• スケジュールジョブ（Scheduled Job）: パッチ適用やパッケージ操作などを指定時刻・繰り返しで実行する定義。メンテナンスウィンドウの実装に使う
• コンプライアンス（Compliance）: 各インスタンスが期待する更新状態を満たしているかの評価。未適用の更新の有無で準拠／非準拠が示される

仕様・制限・クォータ

• 対応 OS: 主要な Linux ディストリビューション（Oracle Linux などの RPM 系）と Windows をサポートする。ディストリビューションやバージョンごとに利用できる機能が異なる場合があるため、対象 OS の対応状況を事前に確認する
• エージェント前提: 管理対象には OS Management Hub のエージェント（プラグイン）が稼働している必要がある。プラグインが無効・未到達だと検出も適用も行われない
• ネットワーク到達性: エージェントは管理サービスのエンドポイントへ到達できる必要がある。プライベートサブネットでは Service Gateway や管理ステーション経由など、経路の設計が前提になる
• リージョン単位のサービス: 管理対象やソフトウェアソースはリージョンに紐づく。クロスリージョンの一括操作は標準では行わず、リージョンごとに構成する
• クォータ: 管理ステーションやグループ、ソフトウェアソースなどの作成数にはテナンシ／リージョン単位の上限があり、上限引き上げはサービスリクエストで申請する。変動し得るため、最新の上限はコンソールのリミット表示で確認する

内部の仕組み

各ホストのエージェントが、インストール済みパッケージと利用可能な更新を定期的に検出し、結果を OS Management Hub サービスへ報告します。サービス側はこれを集約してコンプライアンス状態を算出し、コンソール／API でフリート横断のビューを提供します。パッチ適用や更新の実行は、サービスからエージェントへ指示が降り、エージェントが対象ホスト上でパッケージマネージャ（Linux なら RPM 系のパッケージ管理）を呼び出して行います。

• 配信経路の二系統が要点です。
  • パブリックに到達できるインスタンスは、ソフトウェアソース（リポジトリ）から直接更新を取得できる
  • インターネット非接続のインスタンスは、管理ステーションをプロキシ兼ミラーとして経由し、内部ネットワーク内で更新を受け取る
• ソフトウェアソースで配布内容を固定できます。カスタムソフトウェアソースに許可するパッケージとバージョンを定義し、ライフサイクル環境のステージへ割り当てることで、環境ごとに何が入るかを統制します。
• ライフサイクル環境を使うと、同じ更新セットを開発から本番へ段階的に昇格でき、検証していない更新が本番へ流れ込むのを防げます。

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

• グループ＋スケジュールジョブでメンテナンスウィンドウを実装: フリートをグループ化し、深夜帯のスケジュールジョブで一括適用する。再起動を伴う更新は対象を分割し、可用性を保ちながらローリングで回す
• ライフサイクル環境で段階適用: 開発→テスト→本番の順に同じ更新を昇格させ、問題があれば本番到達前に止める
• カスタムソフトウェアソースでバージョン固定: 本番に入れてよいパッケージ・バージョンを明示し、構成ドリフトと想定外のメジャー更新を防ぐ
• プライベート環境は管理ステーション前提で設計: 非公開サブネットやオンプレのホストには管理ステーションを置き、内部経由で更新を配信する。可用性が要るなら冗長配置を検討する
• コンプライアンスを定期レビュー: 非準拠インスタンスの一覧を定期的に確認し、未適用のセキュリティ更新を運用 KPI として追う
• 段階ロールアウトで影響を局所化: まず少数のホストへ適用して安定を確認し、問題なければ残りへ展開する

運用・監視

• インスタンスが管理対象に出てこない: エージェント（OS Management Hub プラグイン）が有効か、サービスエンドポイントへ到達できるネットワーク経路と IAM ポリシーがあるかを確認する
• 更新が検出・適用されない: ソフトウェアソースが正しく割り当てられているか、プライベート環境なら管理ステーション経由の経路が機能しているかを点検する
• 適用後の不具合: ライフサイクル環境の前段ステージで再現するか確認し、カスタムソフトウェアソースで問題バージョンを除外してから再展開する
• 可観測性の連携: スケジュールジョブの実行結果やパッチ適用の成否は OCI Logging へ、操作の監査証跡は OCI Audit へ残す。アラートが要る指標は Monitoring／Notifications と組み合わせる
• 管理ステーションの健全性: ミラーの同期状況・ディスク使用量・到達性を監視し、配信が滞らないようにする

コスト

OS Management Hub の課金は、概ね管理対象インスタンス（マネージドインスタンス）の数に応じた従量制が基本です。エージェントの導入そのものや、コンソールでのコンプライアンス可視化に追加の大きなコストは通常かかりませんが、管理ステーションを動かす Compute やミラー用ストレージなど、周辺リソースのコストは別途発生します。最新かつ正確な料金はリージョンや契約により変動するため、公式の料金ページで確認してください。コスト最適化の観点では、不要になったインスタンスを管理対象から外し、管理ステーションのサイジングを実需要に合わせるのが基本です。

セキュリティ

• IAM ポリシーで最小権限: パッチ適用やソフトウェアソース管理など、操作種別ごとに必要なグループ／動的グループへ限定して権限を付与する
• 動的グループ＋インスタンスプリンシパル: エージェントの認証に長期キーを埋め込まず、インスタンスプリンシパルで認証させる（AWS の IAM ロール相当）
• 配布内容の統制でサプライチェーンを守る: カスタムソフトウェアソースで許可パッケージを明示し、想定外のリポジトリや未検証バージョンの混入を防ぐ
• セキュリティ更新の優先適用: コンプライアンス評価を使い、脆弱性に対応する更新を優先してフリートへ展開する。重大度の高い未適用更新を放置しない
• 役割分担: 「何を適用したか」の操作監査は OCI Audit、実行ログは OCI Logging が担う。OS Management Hub 自体は適用と状態管理にフォーカスする

Well-Architected の観点

• 運用上の優秀性（operational）: パッチ適用をスケジュール化・標準化し、フリート横断でコンプライアンスを定量把握できる。手作業の SSH 運用から、繰り返し可能で監査可能なプロセスへ移行できる
• セキュリティ（security）: セキュリティ更新を漏れなく追跡・適用し、配布内容をカスタムソフトウェアソースで統制することで、脆弱性の放置と未検証パッケージの混入リスクを下げられる
• ライフサイクル環境による段階適用は、変更を本番に入れる前に検証する運用と相性がよく、可用性への影響を抑える助けになる

試験で問われるポイント

関連サービス・比較

OS Management Hub は OS レイヤの運用を担い、メトリクス監視・通知・監査・ログ収集はそれぞれ別サービスが分担します。AWS では Systems Manager がパッチに加え多機能を内包しますが、OCI では OS 運用に焦点を当てたサービスとして整理されています。

ハンズオン / CLI例

# 1) 管理対象インスタンスのグループ（フリート単位）を作成
oci os-management-hub managed-instance-group create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "prod-linux-fleet" \
  --os-family "ORACLE_LINUX_9" \
  --arch-type "X86_64"

# 2) グループ内のインスタンス一覧を確認（管理対象として認識されているか）
oci os-management-hub managed-instance-group list-managed-instances \
  --managed-instance-group-id "$GROUP_OCID"

# 3) グループ全体へ利用可能な更新を一括適用（ジョブとして実行）
#    再起動を伴う更新は対象や時間帯を絞り、ローリングで回すのが安全
oci os-management-hub managed-instance-group install-packages \
  --managed-instance-group-id "$GROUP_OCID" \
  --package-names "[\"all\"]"

# 4) フリートのコンプライアンス状況を取得（未適用更新の有無を把握）
oci os-management-hub managed-instance list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query "data.items[].{name:\"display-name\",status:\"status\"}"