OCI Roving Edge Infrastructure

解決する課題

工場・船舶・建設現場・遠隔地・移動体など、クラウドへの安定した回線が前提にできない環境では、データをいったんクラウドへ送ってから処理する方式が成り立ちません。回線が細い・断続的・あるいはまったく無い状況でも、現場でデータを取り込み、その場で計算し、結果を返す必要があります。Roving Edge Infrastructure は、堅牢で可搬な専用デバイスに OCI の Compute とストレージを載せて現場へ持ち出すことで、これを解決します。

• 回線が乏しい・断続的な現場で、収集したデータをその場で処理したい
• 衛星回線などへの送信前に、現場で前処理・フィルタリング・推論を行いデータ量を絞りたい
• 一時的に切り離し（ディスコネクト）状態でも、クラウドと同じ流儀でワークロードを動かしたい
• 災害対応や軍事・遠征用途など、インフラが整っていない場所に計算資源を持ち込みたい

AWS で言えば、コンピュートとストレージを兼ねる Snowball Edge（Compute Optimized） に相当します。単なるデータ移送ではなく、エッジでの処理能力を持ち出す点が特徴です。

主要概念と用語

• Roving Edge Device（RED）: コンピュートとストレージを内蔵した堅牢・可搬の専用デバイス。現場に持ち込み、切り離し環境でもワークロードを実行できる中核ハードウェア
• Roving Edge Infrastructure（REI）: RED を用いてエッジで OCI の計算・保管を提供するサービス全体の総称。クラスタ構成や管理の枠組みを含む
• クラスタ（Cluster）: 複数の RED をまとめ、可用性や容量を高める構成単位。ノードを束ねて冗長性を確保する
• ノード（Node）: クラスタを構成する個々の RED。1 台でも、複数台のクラスタとしても運用できる
• ワークロード: RED 上で動かす VM インスタンスやコンテナ、オブジェクトストレージなどの処理・保管の実体
• イメージのエクスポート / インポート: クラウド側の Compute イメージを RED に持ち込み、エッジで同じ流儀のインスタンスを起動するための受け渡し
• 同期（Sync）: RED とクラウド側の Object Storage 等とのデータ突き合わせ。再接続時に収集データをクラウドへ取り込む
• ディスコネクト運用: クラウドと切り離された状態でも RED 単体（またはクラスタ）で処理を継続できる運用形態

仕様・制限・クォータ

• RED は Compute（VM 実行）とブロック / オブジェクトストレージを内蔵し、エッジで OCI と同じ流儀のワークロードを動かせる。クラウドの全サービスがそのまま動くわけではなく、エッジで提供される機能の範囲で利用する
• 1 台のスタンドアロン構成から、複数ノードのクラスタ構成まで取れる。クラスタにすると容量と可用性が高まる
• 堅牢・可搬な筐体で、回線が乏しい・断続的・無い環境を前提に設計されている。切り離し状態でも動作する
• デバイス自体の計算・保管容量には上限があり、クラウドのように無制限にスケールはしない。容量設計と持ち出すワークロードの選別が重要
• 注文・受領・現場展開・返送という物理的なライフサイクルを伴い、郵送・配送のリードタイムが前提になる
• 具体的な搭載スペック（CPU・メモリ・容量）、対応リージョン、提供形態などの数値は変動するため、最新は公式ドキュメントで確認する

内部の仕組み

Roving Edge は「クラウドの計算と保管を、切り離せる箱に詰めて運ぶ」という発想を、デバイスのライフサイクルとクラウド側の管理に結びつけます。

• 準備フェーズ: コンソールから RED（またはクラスタ）を注文・構成し、エッジで動かしたい Compute イメージやデータをデバイスへ取り込む（エクスポート / インポート）
• 現場展開フェーズ: RED を現場へ持ち込み、切り離し環境でも VM インスタンスやオブジェクトストレージを起動して、収集データの保管・処理・推論を行う
• 収集と処理: センサーやカメラなどからのデータを RED 上に取り込み、エッジで前処理・フィルタ・推論をかけてから保管する。これにより送信すべきデータ量を減らせる
• 再接続と同期: 回線が回復したら、RED 上のデータをクラウドの Object Storage 等へ同期し、必要に応じてデバイスを返送・再利用する

クラスタ構成では複数ノードが連携して可用性と容量を確保し、ノード障害時にも処理を継続できるよう冗長化されます。クラウド側ではデバイスやクラスタの状態を管理し、イメージの受け渡しや同期を制御します。

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

• エッジで絞ってからクラウドへ: 現場で前処理・推論を行い、送信するのは要約・抽出結果に絞る。これで細い回線でもクラウド連携が成り立つ
• クラウドと同じイメージを使う: エッジで動かす VM はクラウドと同じイメージから起こし、開発・検証はクラウドで、実行は現場で、という一貫した流儀を保つ
• クラスタで可用性を確保: 単一障害点を避けたい現場ワークロードは複数ノードのクラスタにし、ノード障害でも処理を止めない
• 容量を見越したワークロード選別: デバイス容量は有限なので、本当にエッジで動かす必要があるワークロードとデータだけを持ち出す
• 同期手順の標準化: 再接続時にどのデータをどの順でクラウドへ取り込むか、検証（件数・チェックサム）を含めて手順化しておく
• 物理ライフサイクルの前倒し: 注文・受領・返送のリードタイムを見込み、展開期限から逆算して早めに着手する

運用・監視

• デバイス / クラスタの状態（注文中、受領、稼働、切り離し、同期中など）を中心にライフサイクルを追跡する
• エッジで動く VM やオブジェクトストレージの**リソース使用状況（CPU・メモリ・容量）**を確認し、容量逼迫の兆候を早期に把握する
• 再接続時の同期の成否を確認し、収集データがクラウド側へ欠落なく取り込まれたかを件数や容量で突き合わせる
• API 操作やデバイス管理の記録は Audit で監査し、誰がいつどの操作を行ったかを追跡できるようにする
• 物理プロセスを含むため、デバイスの発送・受領・返送のトラッキングも運用上の確認ポイントになる

コスト

Roving Edge のコストは、デバイス（またはクラスタ）の利用と、その物理的なライフサイクル、そして再接続後にクラウドへ取り込んだデータの保管が中心です。オフライン移送と違い、現場での計算能力を持ち出す点が費用の前提になります。

セキュリティ

• デバイス上の暗号化: RED 上のデータは暗号化して保護する。デバイスが物理的に移動し現場に置かれる前提のため、紛失・盗難時の情報漏えいを防ぐ暗号化は必須の考え方
• 切り離し環境での認証・認可: クラウドの IAM に常時つながれない前提で、デバイス側でも管理者アクセスを安全に制御する。鍵・資格情報の取り扱いに注意する
• アクセス制御: デバイスの注文・管理やイメージの受け渡しは IAM ポリシーで制御し、対象コンパートメントに絞った最小権限を付与する
• 物理セキュリティ: 現場に置かれるデバイスの施錠・保管・受け渡し記録（チェーン・オブ・カストディ）を意識し、不正持ち出しや改ざんを防ぐ
• 同期時の保護: クラウドへの同期通信は TLS で保護し、取り込み先の Object Storage は保存時に暗号化される

関連サービス・比較

Roving Edge Infrastructure は、データを物理媒体で運ぶだけの OCI Data Transfer とよく対比されます。Data Transfer がオフラインの大容量移送に特化するのに対し、Roving Edge は計算とストレージをエッジへ持ち出して現場で処理できる点が決定的に異なります。AWS で言えば、移送専用の Snowball に対する Snowball Edge（Compute Optimized） の関係に近い位置づけです。

ハンズオン / CLI例

RED の管理やクラスタ・ノードの確認は oci CLI で行えます。以下はエッジで動かすノードやクラスタの一覧・状態を確認し、クラウド側のイメージをデバイスへ持ち出す（エクスポート）流れの例です。実際の注文・受領・現場展開は所定の手順に従って実施します。

# 1) 既存の Roving Edge クラスタの一覧を確認
oci rover cluster list \
  --compartment-id "$COMPARTMENT_OCID"

# 2) 個別クラスタの状態（ノード構成・ライフサイクル状態）を確認
oci rover cluster show \
  --cluster-id "$CLUSTER_OCID"

# 3) スタンドアロンのノード（RED）の一覧を確認
oci rover node list \
  --compartment-id "$COMPARTMENT_OCID"

# 4) エッジで起動したい Compute イメージをデバイスへ取り込むため、
#    クラスタにワークロード（イメージ）を関連付ける
oci rover cluster add-workload \
  --cluster-id "$CLUSTER_OCID" \
  --image-id "$IMAGE_OCID" \
  --type "IMAGE"

# この後、デバイスを受領して現場へ展開し、切り離し環境で
# VM やオブジェクトストレージを起動して収集データを処理する。
# 回線が回復したら収集データをクラウドの Object Storage へ同期する。