OCI Data Flow

解決する課題

Apache Spark でのバッチ処理や ETL を行いたいが、Spark クラスタの構築・スケール・パッチ・停止忘れといった運用負担を抱えたくない、という課題に応えます。OCI Data Flow は実行（Run）のたびに必要なリソースを確保し、ジョブが終われば自動的に解放します。

• 常時起動のクラスタを持たずに Spark ジョブをオンデマンド実行したい
• ETL・大規模集計・機械学習の前処理などを 使った分だけの課金で回したい
• 既存の Spark アプリ（PySpark / Scala / Java / SQL）をほぼそのまま動かしたい
• クラスタのサイズ調整やバージョン管理の運用から解放されたい

AWS でいえば、サーバーレスに Spark を動かす Amazon EMR Serverless、あるいはマネージド ETL の AWS Glue に近い立ち位置です。

主要概念と用語

• Application（アプリケーション）: 再利用可能なジョブ定義。Spark アプリのコード（Object Storage 上のアーティファクト）、言語、引数、デフォルトのリソース構成などをまとめたテンプレート
• Run（実行）: アプリケーションを実際に走らせた1回分のインスタンス。実行ごとにドライバ・エグゼキュータが起動し、終了するとリソースは解放される
• Driver / Executor（ドライバ／エグゼキュータ）: Spark の実行プロセス。ドライバが処理を統括し、複数のエグゼキュータが並列で計算する。Data Flow では各プロセスに割り当てるシェイプ（CPU/メモリ）と数を指定する
• Shape（シェイプ）: ドライバ／エグゼキュータに割り当てる計算リソースの種別。スループットやコストはここで決まる
• Spark バージョン: Data Flow がサポートする Apache Spark のランタイムバージョン。アプリ作成時に選択する
• Library / Dependency（依存ライブラリ）: 追加の Python パッケージや JAR。アーカイブとして Object Storage に置き、実行時に取り込む
• Spark UI / Spark History Server: 実行の DAG・ステージ・タスクを可視化する Spark 標準の UI。Data Flow から各 Run の詳細を参照できる

仕様・制限・クォータ

• アプリケーションのアーティファクトやログ、依存ライブラリは Object Storage に保存する前提で動作する
• 対応言語は PySpark（Python）・Scala・Java・Spark SQL。Spark のランタイムバージョンは選択式で、サポート対象が更新される
• リソースはドライバ／エグゼキュータのシェイプとエグゼキュータ数で構成し、ジョブの並列度に合わせて調整する
• 実行は基本的にバッチ指向。ストリーミング常駐サービスというより、起動して処理して終わるモデル
• 同時実行数や利用できる総コア数などは**サービス制限（リミット）**として管理され、必要に応じて引き上げ申請ができる

内部の仕組み

OCI Data Flow は、Run を起動するたびに専用の Spark 実行環境（ドライバ1つと指定数のエグゼキュータ）をプロビジョニングし、ジョブの完了とともにそれらを破棄します。クラスタを利用者が常時保持するのではなく、サービス側がマルチテナントな基盤上で実行環境を都度払い出す方式です。

• アプリのコード・入出力データ・依存物・ログはいずれも Object Storage とやり取りする。コンピュートとストレージが分離されているため、リソースを使い捨てにできる
• 各 Run はほかの Run から隔離され、互いの実行に影響しない
• 実行状況は Spark History Server / Spark UI で DAG・ステージ・タスク単位まで追跡でき、終了後にも参照できる
• データソースは Object Storage のほか、Autonomous Database や外部 JDBC ソースなどに Spark のコネクタ経由でアクセスする設計

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

• アプリケーション＝定義、Run＝実行として分離し、引数やリソースだけ差し替えて再利用する
• ジョブごとにドライバ／エグゼキュータのシェイプとエグゼキュータ数を適正化し、過剰なリソースで割高にならないようにする
• 入出力は Object Storage を中心に据え、パーティション分割・列指向フォーマット（Parquet など）でスキャン量を抑える
• 依存ライブラリはアーカイブ化して Object Storage に固定し、実行の再現性を確保する
• 定期実行は Functions やスケジューラ、データパイプラインから Run を起動してオーケストレーションする
• 大規模ジョブはまず小さなデータと少ないエグゼキュータで検証し、Spark UI を見ながら段階的にスケールさせる

運用・監視

• 各 Run のステータス（受付・実行中・成功・失敗）と所要時間・消費リソースを Data Flow のコンソール／API で確認する
• Spark UI / History Server でステージのスキューやシャッフル過多、メモリ不足などボトルネックを特定する
• ドライバ／エグゼキュータのログは Object Storage に出力され、失敗時の原因調査に使う
• OCI Monitoring のメトリクスでジョブ実行の傾向を把握し、OCI Audit でアプリ作成・Run 起動などの操作を追跡する
• 失敗時はシェイプ不足（メモリ）・データスキュー・依存ライブラリ不整合を切り分ける

コスト

課金の中心は **Run の実行時間 × 確保したリソース（ドライバ／エグゼキュータのシェイプ × 数）**です。クラスタを常時起動しないため、アイドル時間に対する課金が発生しにくいのがサーバーレス型の利点です。具体的な単価は変動するため、見積もりは最新の料金情報で行ってください。

セキュリティ

• アクセス制御は IAM ポリシーで行い、アプリ作成・Run 実行・Object Storage 読み書きなどの権限を最小化する
• Run にはリソースプリンシパルを付与でき、ジョブから他の OCI サービス（Object Storage や Autonomous Database 等）へ静的な認証情報を埋め込まずにアクセスできる
• 保存データは Object Storage の暗号化で保護され、**OCI Vault のカスタマー管理キー（CMK）**を利用できる
• ネットワークを隔離したい場合は VCN/サブネットと連携したプライベート接続を構成し、データソースへインターネットを経由せずアクセスする

Well-Architected の観点

• パフォーマンス効率: ジョブ単位でシェイプとエグゼキュータ数を選べるため、ワークロードに合わせて並列度を最適化できる。列指向フォーマットとパーティション設計でスキャン量を抑えることが効く
• コスト最適化: 常時起動クラスタを持たず、実行時間とリソース量だけが課金対象。アイドルコストを排除し、ジョブの短縮とリソース適正化が直接コスト削減につながる
• 運用上の優秀性: クラスタのパッチ・スケール・停止管理が不要で、Run の状態と Spark UI で実行を可視化できる
• セキュリティ: IAM ポリシーとリソースプリンシパルで最小権限を徹底し、認証情報の埋め込みを避けられる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1. Spark アプリの定義（Application）を作成する
#    file-uri は Object Storage 上のアーティファクト（例: PySpark スクリプト）
oci data-flow application create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name etl-daily \
  --language PYTHON \
  --file-uri oci://my-bucket@my-namespace/scripts/etl.py \
  --spark-version 3.5.0 \
  --driver-shape VM.Standard.E4.Flex \
  --executor-shape VM.Standard.E4.Flex \
  --num-executors 2

# 2. アプリケーションを実行する（Run を起動）
#    出力やログの保管先として Object Storage を指定
oci data-flow run create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --application-id ocid1.dataflowapplication.oc1..xxxx \
  --display-name etl-daily-run-20260614 \
  --logs-bucket-uri oci://my-logs@my-namespace/dataflow/

# 3. Run の状態を確認する（LIFECYCLE: ACCEPTED -> IN_PROGRESS -> SUCCEEDED）
oci data-flow run get \
  --run-id ocid1.dataflowrun.oc1..xxxx \
  --query 'data."lifecycle-state"' --raw-output

# 4. 実行一覧を確認する
oci data-flow run list \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --query 'data[].{name:"display-name",state:"lifecycle-state"}' \
  --output table