Oracle Analytics Cloud (OAC)

解決する課題

各部門がスプレッドシートや個別ツールでバラバラにレポートを作る「サイロ化したレポーティング」から脱却し、データへの接続・準備から可視化・配信までを単一のクラウド基盤に集約できます。

• 複数のデータソース（DB・データウェアハウス・ファイル・SaaS）を横断して可視化したい
• IT 部門に依頼せず、現場がセルフサービスでダッシュボードを作成・共有したい
• 既存の Oracle BI Enterprise Edition（OBIEE）資産をクラウドへ移行したい
• 自然言語の問い合わせや機械学習による予測・異常検知（拡張分析）を分析に組み込みたい

AWS では Amazon Quick Sight が同じ領域を担います。OAC は Quick Sight よりもエンタープライズ BI（共有メタデータ層・ピクセルパーフェクトな帳票）に寄った機能を併せ持つのが特徴です。

主要概念と用語

• OAC インスタンス: 分析環境の実体。契約に合わせて OCPU 数またはユーザー数のキャパシティを指定する。AWS Quick Sight が SaaS でインスタンスを意識しないのに対し、OAC は明示的にインスタンスを払い出す
• ワークブック（Workbook）／キャンバス（Canvas）: ビジュアライズの単位。1 つのワークブック内に複数のキャンバス（ページ）を持ち、グラフ・表・フィルタを配置する。Quick Sight のダッシュボード／分析に近い
• データセット（Dataset）: 分析対象のデータ定義。データソースへの接続とテーブル／列・結合・データ準備手順を含む。Quick Sight のデータセット／SPICE 取り込みに相当
• セマンティックモデル（Semantic Model）／RPD: 物理データを業務用語（ディメンション・メジャー・階層）へ写像する共有メタデータ層。OBIEE 由来の概念で、組織で一貫した指標定義を提供する
• データフロー（Data Flow）: 抽出・変換・結合・機械学習適用などの前処理パイプラインをコードレスで組み立てる機能
• 拡張分析（Augmented Analytics）: 自然言語質問、自動インサイト、説明（Explain）、機械学習モデル適用などの AI 支援機能群
• ピクセルパーフェクト帳票（Pixel-Perfect / BI Publisher）: 帳票レイアウトを精密に制御する定型レポート機能。請求書・規制報告書などに使う

仕様・制限・クォータ

• インスタンスは契約に合うキャパシティ種別（OCPU またはユーザー）でサイズを決め、同じ範囲内でスケールアップ／ダウンできる。BYOL は OCPU キャパシティを使う
• 接続できるデータソースは多種多様で、Autonomous Database / Oracle Database / MySQL HeatWave などの OCI データベースに加え、各種 RDB・データウェアハウス・SaaS・ファイル（CSV/Excel）をサポートする
• 大量データはソース DB へライブクエリするか、OAC 内へ取り込んで（キャッシュ）処理するかを選べる。QuickSight の SPICE のような専用インメモリエンジン名は用語として持たないが、取り込みキャッシュで応答性を高められる
• ユーザー・ロール・権限はテナンシの IAM／IDCS（アイデンティティドメイン）と統合して管理する
• 1 インスタンスあたりのデータセット数・接続数・取り込み量などにはサービス上の上限があり、テナンシ／リージョン単位のクォータとして管理される（上限の引き上げはサービスリクエストで申請）

内部の仕組み

横にスクロール

OAC は、データソースへの接続層、業務用語へ写像するセマンティックモデル層、ビジュアライズのプレゼンテーション層を 1 つのマネージドインスタンス上で提供します。ユーザーがワークブックを開くと、OAC はデータセットの定義に従い、ソース DB へ直接クエリを発行するか、取り込み済みキャッシュを参照して結果を描画します。

• 接続とクエリ: ライブ接続ではフィルタ条件をソース DB へプッシュダウンし、ソース側の性能を活かす。取り込み（キャッシュ）方式では一度 OAC 内へデータを取り込み、以後の操作を高速化する
• セマンティックモデル: 複数の物理テーブルを論理的なディメンション・メジャー・階層へまとめ、利用者は SQL を意識せずドラッグ＆ドロップで分析できる。OBIEE の RPD と互換性があり、既存資産を持ち込める
• 拡張分析: 自然言語クエリは入力文を解析してビジュアライズへ変換し、自動インサイトや Explain は統計・機械学習でデータの背景要因を提示する
• 配信: ダッシュボードはブラウザ・モバイルで共有し、ピクセルパーフェクト帳票はスケジュール配信（メール等）にも対応する

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

• 共有指標はセマンティックモデルに集約する。各ワークブックで指標を再定義せず、組織共通の定義を一箇所で管理して「集計のブレ」を防ぐ
• ライブ接続と取り込みを使い分ける。ダッシュボードの応答性が重要な画面は取り込み、最新性が要る画面はライブ接続にする
• データフローで前処理を標準化する。結合・クレンジング・機械学習適用を再利用可能なパイプラインにまとめ、ワークブック側を軽く保つ
• ロールベースで配布する。閲覧者・作成者・管理者を IAM／アイデンティティドメインのグループで分け、最小権限でダッシュボードを共有する
• OCI データベースとの近接配置を活かす。Autonomous Database や HeatWave を分析ソースにすると、同一クラウド内の低レイテンシ・高帯域で大規模分析を行える
• 検証環境はインスタンス停止でコスト最適化する。常時稼働が不要な環境は業務時間外に停止する

運用・監視

• インスタンスのライフサイクル管理: 起動・停止・スケール（キャパシティ変更）をコンソール／CLI／API で実施。スケール中もサービスは利用できるが、最大約60分は性能が低下する可能性があるため、繁忙時間を避けて行う
• OCI Monitoring 連携: インスタンスの稼働状況に関するメトリクスを Monitoring で監視し、しきい値超過時に Notifications で通知する。性能劣化や同時利用増はキャパシティ見直しのサインになる
• OCI Audit による監査: インスタンスの作成・停止・スケール・設定変更といった管理操作は OCI Audit に記録される
• バックアップと移行: セマンティックモデルやワークブックはスナップショットとしてエクスポート／インポートでき、環境間移行や復旧に使う
• 容量の見極め: 同時アクティブユーザーが増えダッシュボードの応答が鈍ったら、まずキャパシティ（OCPU）の引き上げを検討する

コスト

OAC の課金は契約したキャパシティ種別により、OCPU 時間またはユーザー月額です。Professional／Enterprise、License Included／BYOL の組み合わせでもメーターが変わります。停止はアクセスを止めて費用を抑える操作ですが、契約済みのユーザー月額まで都度消えるとは限らないため、自社の契約と Cost Analysis で確認します。

セキュリティ

• IAM／アイデンティティドメインと統合したユーザー・グループ管理を行い、閲覧／作成／管理のロールを最小権限で割り当てる
• 転送時は TLS で保護され、保存データは暗号化される。データソースへの接続情報（資格情報）は安全に保管する
• ネットワーク分離: プライベート接続を構成し、VCN 内のデータソースへインターネットを経由せずアクセスする経路を取れる
• 行レベル・列レベルのデータ制御: セマンティックモデルやデータセットの権限で、ユーザーごとに見える行・列を制限できる
• 資格情報の取り扱い: データソースの接続資格情報は OAC の接続定義で安全に管理し、平文での共有や直書きは避ける

Well-Architected の観点

OAC は分析プラットフォームの運用を支える土台です。運用上の卓越性の観点では、ダッシュボード資産（セマンティックモデル・ワークブック）をスナップショットでバージョン管理・移行可能にし、環境差分を再現できる状態を保つことが重要です。

• 運用面: 指標定義をセマンティックモデルに集約して属人化を排し、スナップショットで開発・本番環境の構成を再現可能にする
• コスト面: インスタンスの停止・キャパシティ調整で稼働コストを需要に追従させる
• 性能面: ライブ接続と取り込みの選択、ソース DB の近接配置で応答性を確保する
• 信頼性面: スナップショットによるエクスポートで分析資産を復旧可能にする

試験で問われるポイント

関連サービス・比較

OAC は分析の「見せる層」で、データの「貯める層」である Autonomous Database や HeatWave、「流す層」である Streaming と組み合わせて使います。AWS の Amazon Quick Sight と比較すると次の通りです。

ハンズオン / CLI例

# 1) OAC インスタンスを作成（OLPU_COUNT または USER_COUNT を契約に合わせる）
oci analytics analytics-instance create \
  --compartment-id "$COMPARTMENT_OCID" \
  --name "demo-oac" \
  --feature-set "ENTERPRISE_ANALYTICS" \
  --capacity-type "OLPU_COUNT" \
  --capacity-value 2 \
  --license-type "LICENSE_INCLUDED"

# 2) インスタンスの一覧と状態を確認
oci analytics analytics-instance list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query 'data[].{name:name,state:"lifecycle-state",url:"service-url"}' \
  --output table

# 3) 業務時間外はインスタンスを停止してコンピュート課金を抑える
oci analytics analytics-instance stop \
  --analytics-instance-id "$OAC_OCID"

# 4) 利用再開時に起動する
oci analytics analytics-instance start \
  --analytics-instance-id "$OAC_OCID"

# 5) 同時利用が増えたらキャパシティ（OCPU）をスケールアップ
oci analytics analytics-instance scale \
  --analytics-instance-id "$OAC_OCID" \
  --capacity '{"capacityType":"OLPU_COUNT","capacityValue":4}'