OCI Data Science

解決する課題

機械学習をビジネスに使うには、データの前処理、特徴量づくり、モデルの学習と評価、本番デプロイ、再学習までの一連の流れ（ML ライフサイクル）を回す基盤が要ります。これを各自のローカル PC やバラバラな仮想マシンで進めると、環境差異・再現性の欠如・本番化の難しさといった問題に直面します。OCI Data Science は、この一連の作業をマネージドな環境に集約します。

• データサイエンティストごとに再現可能なノートブック環境を素早く用意したい
• GPU を含む計算資源を必要なときだけ確保し、使い終えたら解放したい
• 試行錯誤した学習をジョブとして自動実行・スケジュール化したい
• 学習済みモデルをチームで共有・バージョン管理し、承認を経て本番に出したい
• モデルをHTTPS の推論エンドポイントとして安全に公開し、運用・監視したい

AWS で同種の課題に応えるのが Amazon SageMaker です。OCI Data Science はその OCI 版にあたり、ノートブック・学習ジョブ・モデルレジストリ・推論エンドポイントといった構成要素が対応します。

主要概念と用語

• プロジェクト（Project）: ノートブックセッションやモデルをまとめる作業単位。チームの取り組み単位で分割する
• ノートブックセッション（Notebook Session）: マネージドな JupyterLab 環境。シェイプ（CPU/GPU）とブロックボリュームを選んで起動し、対話的に前処理・学習・可視化を行う。SageMaker のノートブックインスタンス／Studio に相当
• Conda 環境（Conda Environment）: ライブラリ一式をまとめた再現可能な実行環境。Oracle 提供の環境に加え、独自に作って Object Storage で共有できる
• ADS（Accelerated Data Science SDK）: データ読み込み・前処理・モデル評価・カタログ登録・デプロイを簡潔に書ける Python SDK。OCI Data Science の操作を抽象化する
• ジョブ（Job）: 学習や前処理のスクリプトを、ノートブックとは独立した計算リソース上でバッチ実行する仕組み。再現性のある反復・自動化に使う。SageMaker のトレーニングジョブに相当
• モデルカタログ（Model Catalog）: 学習済みモデルのアーティファクトとメタデータ（来歴・スキーマ・タグ）を登録・バージョン管理するレジストリ。SageMaker の Model Registry に相当
• モデルデプロイ（Model Deployment）: カタログのモデルをマネージドなHTTPS 推論エンドポイントとして公開する仕組み。負荷分散とスケールを担う。SageMaker のリアルタイム推論エンドポイントに相当
• パイプライン（ML Pipeline）: 前処理・学習・評価・登録などの複数ステップを有向グラフとして定義し、順序・依存・並列を制御して実行する仕組み。SageMaker Pipelines に相当
• リソースプリンシパル（Resource Principal）: ノートブックやジョブ自身が IAM 上の主体として OCI API を呼べる認証方式。鍵の埋め込みを避けられる

仕様・制限・クォータ

• ノートブックセッション・ジョブ・モデルデプロイは、それぞれ選択したコンピュートシェイプ（CPU/GPU、メモリ、コア数）で課金・制限が決まる。GPU など強力なシェイプはサービスリミットの対象になりやすく、引き上げ申請が要る場合がある
• モデルカタログに登録するアーティファクトのサイズやデプロイ時のモデルサイズには上限があり、大きなモデルは Object Storage を併用した参照方式を検討する
• モデルデプロイのリクエストペイロードサイズ・タイムアウトには制限があるため、大きな入力はバッチ処理やストレージ経由に切り替える
• ノートブックやジョブで使えるConda 環境の保存先として Object Storage バケットを構成する必要がある
• 各リソース数（同時起動ノートブック数、デプロイ数など）にはテナンシ・リージョン単位のサービスリミットがあり、コンソールから現在値を確認できる
• 具体的なシェイプ名・上限値・対応リージョンは変動しうるため、最新値は公式ドキュメントとコンソールのサービスリミット画面で確認する

内部の仕組み

OCI Data Science は、各構成要素をマネージドなコンピュート上のコンテナ／インスタンスとして動かし、ストレージ・ネットワーク・IAM と連携させることで ML ライフサイクルを成立させています。

• ノートブックセッションは、選んだシェイプの専有環境上で JupyterLab を起動します。作業データはアタッチされたブロックボリュームに保持され、ライブラリは Conda 環境として切り替えます。停止すれば計算課金は止まり、再開できます
• ジョブは、学習スクリプトとその実行環境（コンテナ／Conda）をジョブ定義として登録し、実行のたびに使い捨ての計算リソースを確保してスクリプトを走らせます。終了するとリソースは解放され、ログとアーティファクトが残ります
• モデルカタログは、学習済みモデルの本体（シリアライズしたファイル）と、入出力スキーマ・来歴・スコアリングスクリプトなどのメタデータを一緒に保存します。これにより「どのデータ・どのコードから生まれたモデルか」を追跡できます
• モデルデプロイは、カタログのモデルを推論用コンテナにロードし、ロードバランサ配下のHTTPS エンドポイントとして公開します。背後のインスタンス数を増減してスケールします
• 各リソースはリソースプリンシパルで認証され、IAM ポリシーで許可された範囲だけ Object Storage や Vault などへアクセスします

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

• 環境を Conda で固定する: 学習・本番で同じ Conda 環境を使い、ライブラリのバージョン差異による「動かない」を防ぐ。共有環境は Object Storage に公開してチームで再利用する
• 探索はノートブック、確定処理はジョブへ: 固まった前処理・学習はジョブ化してパラメータ化し、データやハイパーパラメータを変えて反復できるようにする
• モデルは必ずカタログ経由で本番化する: ローカルから直接デプロイせず、カタログに登録して来歴・スキーマ・バージョンを残す。承認フローやロールバックの起点になる
• パイプラインで一連を自動化: 前処理から評価・登録までをパイプライン化し、新データでの再学習を仕組みとして回す
• 認証はリソースプリンシパル: ノートブックやジョブのコードに API キーを埋め込まず、リソースプリンシパルで OCI サービスにアクセスする
• GPU は使うときだけ: 高価な GPU シェイプは学習ジョブの実行時に限定し、ノートブックは軽量シェイプで起動して必要時のみ強いシェイプに切り替える

運用・監視

• メトリクスは OCI Monitoring: モデルデプロイの推論リクエスト数・レイテンシ・エラー率・帯域などを監視し、しきい値超えで OCI Notifications へアラートを飛ばす
• ログは OCI Logging: ノートブック・ジョブ・モデルデプロイのアクセスログ／予測ログを有効化し、推論時のエラーや入力傾向を追跡する。デプロイ時にログ出力先を構成しておく
• 操作監査は OCI Audit: 誰がいつノートブックを起動・モデルを登録・デプロイを変更したかを追跡する
• デプロイの更新は無停止を意識: モデル差し替え時はトラフィックを維持したままインスタンスを入れ替える方式を使い、ダウンタイムを抑える
• モデルの劣化を監視: 入力データ分布の変化（ドリフト）や精度低下を運用指標として捉え、再学習のトリガーにする
• トラブル時の切り分け: 「起動しない」はシェイプのサービスリミットや Conda 環境の不整合、「推論が 4xx/5xx」はスコアリングスクリプトや入力スキーマ不一致を疑う

コスト

OCI Data Science 自体の利用に加えて、実体として消費するコンピュート（シェイプ）・ストレージ・ネットワークが課金対象になります。コスト最適化の主役は「使っていない計算資源を止めること」と「シェイプを適正化すること」です。

セキュリティ

• 認証はリソースプリンシパル: ノートブックやジョブのコードに認証情報を直書きせず、リソースプリンシパルで OCI API を呼ぶ。鍵の漏えいリスクを下げられる
• IAM ポリシーで最小権限: プロジェクト・ノートブック・モデルの作成／参照／デプロイ権限をグループ単位で分け、本番デプロイ権限は限定する
• ネットワーク分離: ノートブックやデプロイを**カスタムネットワーク（VCN/サブネット）**に配置し、プライベートサブネット＋Service Gateway 経由で内部リソースへアクセスする構成を取れる
• 保存データの暗号化: ブロックボリュームや Object Storage の暗号化を有効にし、必要に応じて **OCI Vault のカスタマー管理キー（CMK）**を使う
• シークレットは Vault へ: 外部 DB や API の資格情報は Vault のシークレットに格納し、実行時に取得する
• 機微データの扱い: 学習データに個人情報が含まれる場合は、アクセス範囲の限定・マスキング・監査ログの保全を徹底する

Well-Architected の観点

• パフォーマンス効率（Performance Efficiency）: シェイプ（CPU/GPU）をワークロードに合わせて選べ、学習は強力なジョブ、推論は適正なデプロイインスタンスへと役割分担できる。スケール可能なエンドポイントで負荷に追従する
• 運用上の優秀性（Operational Excellence）: ノートブック・ジョブ・カタログ・パイプラインで ML ライフサイクルを標準化・自動化でき、Monitoring/Logging/Audit と連携して再現性と可観測性を確保できる。試行から本番化までの手戻りを減らせる

試験で問われるポイント

関連サービス・比較

OCI の AI/ML は層が分かれます。自前でモデルを開発・学習・運用する基盤が OCI Data Science、用途特化の事前学習済み API 群が OCI AI Services（言語・ビジョン・文書理解など）、大規模言語モデルの推論・カスタマイズが OCI Generative AI です。要件が「自分でモデルを作る」のか「既製の AI を呼ぶ」のかで選択が変わります。下表は中心となる Data Science と AWS の相当サービスの対応です。

ハンズオン / CLI例

# 1) プロジェクトを作成（ノートブックやモデルをまとめる単位）
oci data-science project create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "demo-ml-project"

# 2) ノートブックセッションを作成（シェイプとサブネットを指定）
#    notebook-session-configuration-details にシェイプ・ボリューム・サブネットを渡す
oci data-science notebook-session create \
  --compartment-id "$COMPARTMENT_OCID" \
  --project-id "$PROJECT_OCID" \
  --display-name "demo-notebook" \
  --notebook-session-configuration-details '{
    "shape": "VM.Standard.E4.Flex",
    "blockStorageSizeInGBs": 100,
    "subnetId": "'"$SUBNET_OCID"'"
  }'

# 3) 学習をジョブとして実行（ジョブ定義 → ジョブ実行）
oci data-science job create \
  --compartment-id "$COMPARTMENT_OCID" \
  --project-id "$PROJECT_OCID" \
  --display-name "train-job"
oci data-science job-run create \
  --compartment-id "$COMPARTMENT_OCID" \
  --project-id "$PROJECT_OCID" \
  --job-id "$JOB_OCID" \
  --display-name "train-run-001"

# 4) モデルカタログに登録したモデルを HTTPS エンドポイントとしてデプロイ
oci data-science model-deployment create \
  --compartment-id "$COMPARTMENT_OCID" \
  --project-id "$PROJECT_OCID" \
  --display-name "demo-model-endpoint" \
  --model-deployment-configuration-details '{
    "deploymentType": "SINGLE_MODEL",
    "modelConfigurationDetails": {
      "modelId": "'"$MODEL_OCID"'",
      "instanceConfiguration": { "instanceShapeName": "VM.Standard.E4.Flex" }
    }
  }'