OCI Big Data Service

解決する課題

オープンソースの Hadoop / Spark を自前でクラスタ構築すると、ノードのプロビジョニング、HDFS の設定、各コンポーネントのバージョン整合、パッチ適用、スケール調整といった運用負荷が重くのしかかります。OCI Big Data Service（BDS）は、これらをマネージドに肩代わりし、分析ワークロードそのものに集中できるようにします。

• Hadoop / Spark クラスタを短時間で構築し、すぐに分析を始めたい
• 既存の Hadoop エコシステム資産（Hive、Spark ジョブ、HDFS 上のデータ処理）をそのまま動かしたい
• データ量や処理負荷に応じてノードを増減してスケールさせたい
• 大量データを Object Storage に安価に保管しつつ、分散処理エンジンから読みたい

主要概念と用語

• クラスタ（Cluster）: BDS が構築・管理する Hadoop/Spark の実行単位。マスターノードとワーカーノードで構成される。EMR のクラスタに相当
• マスター／ユーティリティノード: NameNode やリソースマネージャ、各サービスの管理機能を担う制御系ノード
• ワーカーノード: 実際の分散処理とデータ格納を担うノード。台数を増やすことでスループットを上げる
• HDFS: クラスタ内の分散ファイルシステム。ローカルディスク上に大容量データを保持する
• Hadoop エコシステム: HDFS、YARN、Hive、Spark などのオープンソース群を統合して提供する
• Spark: インメモリ中心の分散処理エンジン。バッチ・SQL・機械学習などに用いる
• HDFS Connector / Object Storage 連携: Object Storage 上のデータを HDFS のように参照し、ストレージと計算を分離できる仕組み
• セキュアクラスタ: Kerberos による認証を有効化したクラスタ構成。本番利用で推奨される

仕様・制限・クォータ

• クラスタはマスター系ノードとワーカーノードの組み合わせで構成し、ノードの**形状（シェイプ）**とブロックボリューム容量を選択する
• スループットや処理能力は主にワーカーノード数とノード形状で決まり、ノード追加でスケールアウトする
• 高可用性（HA）構成では制御系ノードを冗長化できる。最小構成の検証用クラスタも作成可能
• データは HDFS（ノードのブロックボリューム） と Object Storage のいずれにも置け、計算とストレージの分離設計が可能
• ノード数・形状・ブロックボリューム総量などはテナンシのサービス制限の範囲内で確保し、不足時は引き上げ申請を行う
• 具体的な上限値・対応コンポーネントのバージョンは更新されるため、最新の公式ドキュメントで確認すること

内部の仕組み

BDS は内部で Hadoop のディストリビューションを構成し、マスター／ユーティリティノードに NameNode・YARN リソースマネージャ・各管理サービスを、ワーカーノードに DataNode・NodeManager を配置します。ジョブを投入すると YARN がワーカーノードへタスクをスケジューリングし、Spark や Hive がそれぞれの実行エンジンとして分散処理を行います。

• ストレージは二層で考えられる。クラスタ内の HDFS（低レイテンシ・反復処理向き）と、クラスタ外の Object Storage（安価・永続・クラスタから独立）
• HDFS Connector を介して Object Storage をデータレイクとして扱えるため、クラスタを停止・破棄してもデータは Object Storage に残る設計にできる
• ノードはコンパートメント内の VCN サブネットに配置され、ネットワーク到達性とセキュリティリストで保護される
• スケール操作（ワーカーノードの追加など）はマネージドに行われ、クラスタを稼働させたまま処理能力を拡張できる

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

• 永続データは Object Storage、作業用データは HDFS に分けて配置し、ストレージと計算を疎結合にする
• バッチ処理が断続的なら、処理が必要なときだけクラスタを起動して終了時に破棄し、データは Object Storage に残す
• 負荷の変動に対してはワーカーノードのスケールアウト／スケールインで対応し、固定的な過剰プロビジョニングを避ける
• 既存の Hive / Spark ジョブは接続先のストレージパスを調整するだけで移行できる場合が多く、アプリ改修を最小化する
• 本番クラスタは**セキュアクラスタ（Kerberos 有効）**で構築し、認証なしの素のクラスタを本番に使わない

運用・監視

• クラスタの状態・ノードの稼働は OCI コンソールおよび OCI Monitoring のメトリクスで監視する
• Hadoop / Spark 標準の 管理 UI（リソースマネージャや各種 Web UI） からジョブの実行状況・リソース使用率を確認できる
• ノード追加・削除・クラスタ作成／削除などの操作は OCI Audit に記録され、変更履歴を追跡できる
• パッチ適用やコンポーネントの整合はマネージド側で支援されるため、自前運用に比べ保守工数を削減できる
• ジョブの遅延やリソース不足が見られる場合は、ワーカーノードの増設やノード形状の見直しを検討する

コスト

BDS のコストは主に「クラスタを構成するノードのコンピュート時間」と「ブロックボリューム容量」、および Object Storage を併用する場合のストレージ料金で構成されます。クラスタが稼働している間ノードに課金されるため、稼働時間の管理が最適化の鍵です。

セキュリティ

• 制御系・ワーカーの各ノードは VCN のサブネット内に配置し、セキュリティリストやネットワークセキュリティグループでアクセスを制限する
• 本番では Kerberos によるセキュアクラスタを構成し、Hadoop コンポーネントへの認証を有効化する
• データアクセス権限は IAM ポリシーで最小権限に絞り、Object Storage への読み書き範囲も限定する
• 保存データは Object Storage 側で暗号化され、OCI Vault のカスタマー管理キー（CMK） を利用した鍵管理も可能
• 機密情報やクレデンシャルは設定ファイルへ直書きせず、Vault のシークレットで管理する

Well-Architected の観点

• パフォーマンス効率: ワーカーノード数と形状でスループットを調整し、反復処理は HDFS、低レイテンシが不要な永続層は Object Storage と使い分ける
• コスト最適化: 断続的なバッチは都度起動・破棄、データは安価な Object Storage に残す設計で、アイドル時のノード課金を避ける
• 計算とストレージの分離は、性能とコストの両方を同時に最適化する基本戦略になる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1. クラスタ一覧を確認（コンパートメント内）
oci bds instance list \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table

# 2. 既存クラスタの詳細を取得（ノード構成・状態を確認）
oci bds instance get \
  --bds-instance-id ocid1.bdsinstance.oc1..xxxx

# 3. ワーカーノードを追加してスケールアウト
oci bds instance add-worker-nodes \
  --bds-instance-id ocid1.bdsinstance.oc1..xxxx \
  --number-of-worker-nodes 2

# 4. 不要になったクラスタを削除（データは Object Storage に残す設計で）
oci bds instance delete \
  --bds-instance-id ocid1.bdsinstance.oc1..xxxx