OCI Operations Insights

解決する課題

メトリクスやアラームが「いま閾値を超えたか」を教えてくれるのに対し、Operations Insights は「この先いつ容量が足りなくなるか」「フリート全体でどの SQL が悪化しているか」を教えてくれます。個々の DB を 1 台ずつ眺めていては、数十〜数百台規模のデータベース群の傾向や枯渇時期を把握できません。

• 数か月先に CPU・ストレージがいつ枯渇するかを、過去のトレンドから定量的に予測したい
• 多数の DB をまたいで、フリート全体で遅い SQL・劣化した SQL を横断的に見つけたい
• AWR や ADDM の所見を 1 台ずつ手で開かず、まとめて分析したい
• 過剰にプロビジョニングした DB・ホストを見つけ、ダウンサイズでコストを下げたい
• Exadata の CPU・ストレージ・I/O をシステム横断で俯瞰し、増設時期を見極めたい

主要概念と用語

• Ops Insights / Operations Insights: DB・ホスト・Exadata の使用量と性能を収集・分析し、容量予測と SQL 診断を提供するサービス。本記事では Operations Insights と表記する
• キャパシティプランニング（Capacity Planning）: 収集した CPU・ストレージ・メモリ等のトレンドから、将来の使用量と枯渇時期を予測する機能
• SQL Insights / SQL Warehouse: フリート横断で SQL の実行統計を収集し、遅い SQL や劣化した SQL を特定する分析機能
• Database Insights: 個々の DB を Operations Insights に登録（有効化）し、その性能・容量データを取り込む対象単位
• Exadata Insights: Exadata システム単位で CPU・ストレージ・I/O・データベースを集約分析する機能
• Host Capacity Planning: コンピュートホスト（OS レベル）の CPU・メモリ・ストレージ使用量を収集し容量を予測する機能
• AWR Hub: 複数 DB の AWR（Automatic Workload Repository）スナップショットを集約・保管し、横断的に性能分析する仕組み
• ADDM Spotlight: ADDM（Automatic Database Diagnostic Monitor）の所見をフリート横断で集約し、性能ボトルネックを俯瞰する機能
• News Report: 容量・性能の傾向を定期的に要約し、運用者へ届けるレポート機能

仕様・制限・クォータ

• 対象は主にデータベースとホスト。Autonomous Database、Base Database、Exadata（クラウド／ExaCS／ExaC@C）など OCI のデータベースと、コンピュートホストの OS メトリクスを扱う。アプリのトレースは APM の役割で、本サービスの対象外
• 有効化（オプトイン）方式。各 DB・ホストを Operations Insights に個別に有効化することでデータ収集が始まる。フリート全体を自動で取り込むわけではない
• ホスト収集には Management Agent が要ることがある。OS レベルのメトリクス収集など一部機能はエージェント前提で、DB 側の性能データ収集とは収集経路が異なる
• 予測は履歴の蓄積が前提。十分な期間のトレンドが溜まるほど予測精度が上がる。導入直後は予測が安定しない
• リージョン単位のサービス。リソースはリージョンに属し、複数リージョンのフリートを 1 画面に集約するには各リージョンでの考慮が要る
• 具体的な保持期間・対象 DB バージョン・収集間隔などの数値や対応範囲は変動しうるため、最新値は公式ドキュメントで確認する

内部の仕組み

Operations Insights の中核は「フリート全体の使用量・性能データを継続収集し、機械学習で傾向と将来を推定する」ことです。個々のリソースの瞬間値ではなく、長期トレンドからの予測と異常検知に重心があります。

• 有効化したリソースからデータを取り込む。DB の性能・容量データ、ホストの OS メトリクス、Exadata のシステム指標などを定期収集し、サービス側の分析基盤に蓄積する
• キャパシティプランニングは、蓄積した CPU・ストレージ・メモリのトレンドに対し回帰／予測モデルを当て、いつ閾値に達するかを推定する。過去の季節性や成長率を加味した予測になる
• SQL Insights / SQL Warehouseは、各 DB から SQL の実行統計を集約し、実行回数・経過時間・I/O などの軸でフリート横断のランキングや劣化検知を行う。1 台ずつ AWR を開く作業を集約で置き換える
• AWR Hubは複数 DB の AWR スナップショットを 1 か所にまとめ、ADDM Spotlightは ADDM 所見を横断集約して、ボトルネックの共通パターンを浮かび上がらせる
• 収集・分析した結果は News Report として定期要約され、容量・性能の変化を運用者へ届ける

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

• 重要 DB から段階的に有効化する: いきなり全台ではなく、本番・基幹 DB から有効化し、トレンドが溜まってから対象を広げる
• 予測は履歴を育ててから使う: 導入直後の予測は鵜呑みにせず、数週間〜数か月のトレンドが蓄積してから容量計画の根拠に使う
• SQL Insights を定例レビューに組み込む: 週次・月次でフリート横断の遅い SQL／劣化 SQL を確認し、リグレッションを早期に捕まえる
• 過剰プロビジョニングをコスト改善に回す: キャパシティプランニングで使用率の低い DB・ホストを洗い出し、ダウンサイズ・統合の判断材料にする
• Monitoring と併用する: 即時の閾値超えは Monitoring のアラームで、枯渇予測や中長期傾向は Operations Insights で、と役割分担して二重監視にしない
• News Report を定期配信に使う: 容量・性能の要約レポートを定期的に運用チームへ共有し、容量計画を運用サイクルに乗せる

運用・監視

• データが表示されない: 対象 DB・ホストが有効化されているか、有効化が「進行中」で止まっていないかを確認する。ホストの OS メトリクスは Management Agent の稼働状況も点検する
• 予測が不安定: 履歴の蓄積期間が短いと予測がぶれる。十分なトレンドが溜まるまで予測値の扱いは慎重にする
• SQL がフリートに出てこない: 該当 DB が有効化済みか、SQL 統計の収集対象になっているかを確認する
• 権限不足で参照できない: Operations Insights の参照・管理に必要な IAM ポリシーが付与されているかを確認する
• コストが想定より増えた: 有効化したリソース数や Exadata の対象規模が増えていないか、不要なリソースまで有効化していないかを見直す

コスト

OCI Operations Insights の課金は概ね、有効化して分析対象にしたリソースの規模（DB 数・ホスト数・Exadata の容量など）に基づく従量制です。閾値超えだけを見るリアルタイム監視（Monitoring）とは課金軸が異なり、分析対象を増やすほどコストが増えるため、有効化するリソースの取捨選択が最適化の主役になります。一方で、本サービスが見つける過剰プロビジョニングの是正やダウンサイズは、DB・ホスト本体のコスト削減につながり得ます。

セキュリティ

• IAM ポリシーで権限分離: リソースの有効化・管理と、分析結果の参照を別グループに分け、最小権限で付与する
• 収集データの扱い: SQL の統計や AWR には業務に関わる情報が含まれ得る。参照範囲を必要な運用者に限定する
• Management Agent の保護: ホスト収集にエージェントを使う場合、エージェントの認証情報・通信経路を適切に管理する
• 役割分担を明確に: 「誰がいつ Operations Insights の設定を変更したか」は OCI Audit、ログ本文は OCI Logging、リアルタイムの閾値監視は OCI Monitoring が担う。これらと役割を混同しない
• 暗号化された経路: 収集データの送信は TLS を前提とし、エージェント経由でも経路全体が暗号化されていることを確認する

関連サービス・比較

OCI の可観測性は、リアルタイムのメトリクス監視は Monitoring、ログは Logging、分散トレースは APM、そして中長期の容量予測とフリート横断の性能分析は Operations Insights と役割が分かれています。AWS では、RDS の性能異常検知に DevOps Guru for RDS、容量・コスト最適化の提言に Compute Optimizer / Trusted Advisor が対応し、Operations Insights はこれらに近い領域を OCI の DB／ホスト向けにカバーします。

ハンズオン / CLI例

# 1) Operations Insights のデータベース一覧（有効化済みリソース）を確認
oci opsi database-insights summarize-database-insight-resource-statistics \
  --compartment-id "$COMPARTMENT_OCID" \
  --resource-metric "CPU"

# 2) 対象 DB を Operations Insights に有効化（Database Insight を登録）
#    対象の種別に応じた --database-id / 接続情報を指定する
oci opsi database-insights enable-database-insight \
  --database-id "$DATABASE_OCID"

# 3) フリート横断で遅い SQL を抽出（SQL Insights のリソース統計）
oci opsi database-insights summarize-sql-statistics \
  --compartment-id "$COMPARTMENT_OCID" \
  --sort-by "TOTAL_DB_TIME" \
  --time-interval-start "2026-06-01T00:00:00Z" \
  --time-interval-end "2026-06-28T00:00:00Z"

# 4) キャパシティ予測（CPU 使用量の将来トレンド）を取得
oci opsi database-insights summarize-database-insight-resource-forecast-trend \
  --compartment-id "$COMPARTMENT_OCID" \
  --resource-metric "CPU" \
  --forecast-days 30