製造データ

仮想化ベースのEdgeデプロイ · Pub/Sub Payload制限回避 · 冪等性ベースの整合性確保 パイロット現場の突発変数とクラウドの限界を克服したMDE最適化プロセス Cloud Tech Unit · GCP Delivery SA 3 Yoon Sung-jae | 2026-02-23 問題定義 — 泥沼の中のエンジニアリング アーキテクチャ設計図がどれほど完璧でも、製造現場のラックマウントサーバーとネットワークケーブルの前では無力になることがあります。前回の記事で「優雅な」アーキテクチャを紹介しましたが、今回はパイロット期間中に現場エンジニアが全力で立ち向かった泥沼のようなトラブルシューティングの過程を紹介します。 本記事では、パイロット運用報告書に記録された3つの激しい問題解決プロセスを包み隠さず共有します。 Challenge 1：ハードウェア互換性とエッジデプロイの悪夢 ベアメタルマルチディスク（RAID）ボリューム構成の制約 工場現場に配置されたDell物理サーバー（ベアメタル）にエッジゲートウェイであるMCe（Manufacturing Connect Edge）OSを直接インストールしようとした際に直面した問題です。 現場のDellサーバーは、エンタープライズ環境の安定性と容量を確保するためにOS領域（ミラーリングされたディスク2台）とデータ格納領域（RAID 5構成のディスク4台）、計2つの論理ドライブ（パーティション）で構成されていました。しかしMCeの公式デプロイイメージは、インストール時にシングルパーティション（Single Volume）構成のみを対応するという制約がありました。そのため、2パーティションに分離された現場サーバーのストレージアーキテクチャをMCeが受け入れられず、ベアメタルへの直接インストールが不可能な状況でした。 仮想化（Virtualization）によるハードウェアデカップリング ハードウェアパーティションの制約をソフトウェア的に解決するため、ベアメタルへの直接インストールを断念し、仮想化レイヤーを挿入する戦略に転換しました。 物理サーバーにマルチパーティションおよびハードウェアドライバー互換性に優れたUbuntu OSをまずインストールし、ハードウェア制御権を汎用OSに委譲しました。 その上にVirtualBoxベースの仮想環境を構成し、仮想マシン（VM）に単一の仮想ディスクを割り当ててMCeイメージをデプロイしました。 この回避策は初期セットアップの制約を突破しただけでなく、エッジに問題が発生した際にVMスナップショット（Snapshot）によって5分でシステムをロールバックできる優れた運用柔軟性（Resilience）ももたらしました。 Challenge 2：大容量データ処理の限界とPub/Sub Payload制限の克服 エッジOOM（Out of Memory）とクラウドの物理的限界 工場のデータはセンサーログだけではありません。収集対象にはファイル1つが2GBを超える巨大なCSVファイルや、高解像度の品質検査画像（JPG、BMP、PNG）、工程映像（MPG、MP4）も含まれていました。 ここで2つの物理的限界に直面しました。第一に、初期の標準パイプラインフローに従い2GB以上のCSVファイルを一括でメモリにロードしてシリアライズしようとしたところ、MCeエッジ側でOOM（Out of Memory）が発生しました。第二に、Google Cloud Pub/Subのメッセージあたりの最大許容サイズ（Payload Limit）は10MBに制限されており、大容量データを直接ストリーミングで送ること自体がアーキテクチャ上不可能でした。 ツートラック（Two-Track）解決戦略：ChunkingとClaim-Check この問題を解決するため、エッジレベルのデータ処理方式とクラウド転送アーキテクチャの両方を修正するツートラック戦略を採りました。 1. MCeレベルのチャンク（Chunk）単位分割ローディング 2GB以上の大容量CSVファイルは、ファイル全体を一括でメモリにロードする既存方式を廃止しました。代わりにMCe収集フロー（Flow）内部でファイルを複数の小さなチャンク（Chunk）に分割し、逐次的（Incremental）にロード・処理する方式に変更し、エッジ側のOOM問題を根本的に解消しました。 2. Claim-Checkアーキテクチャパターンの適用 クラウドメッセージング環境で大容量ペイロードを処理するための標準アーキテクチャであるClaim-Checkパターンを適用し、パイプラインフローを2系統に分離しました。 データタイプ サイズ 転送経路 動作方式 Telemetry（センサー） 10MB未満 MCe → Pub/Sub 標準JSONシリアライズ後にリアルタイムストリーミング転送 Large Files（大容量画像・映像） 10MB以上 MCe → GCS 原本ファイルをCloud Storage（GCS）バケットに直接アップロード 大容量ファイルの場合、Edgeは実際のデータの代わりに「GCSファイルパス（URI）とメタデータ」のみを含む数KBの軽量メッセージ（Claim-Check Token）だけをPub/Subに送信します。その後Dataflowがこのメッセージをサブスクライブすると、該当URIを参照してGCSから直接データを並列で読み取り処理することで、Pub/Subのネットワークボトルネックを完全に解消しました。 ...

250以上の産業プロトコル対応 · Edge-to-Cloudパイプライン · 物理レベルのプロジェクト分離 セキュリティとコストのトレードオフを考慮したManufacturing Data Engine実践構築記 Cloud Tech Unit · GCP Delivery SA 3 Yoon Sung-jae | 2026-02-23 事業背景 — PINNモデル基盤の融合データプラットフォーム 製造業のデジタルトランスフォーメーション（DX）における最大のハードルは、現場のITとOTデータをクラウドへ安全かつシームレスに移行する「ラストマイル（Last Mile）」にあります。 本記事は、韓国政府主導で進められた「2025年PINN（Physics-Informed Neural Networks）モデル製造融合データ収集・実証事業」のクラウドインフラパートナーとして、8つの製造企業の異種データをGoogle Cloud Manufacturing Data Engine（MDE）基盤で統合構築した事例を紹介します。 当初の事業計画書における収集目標は185TBでしたが、250以上の産業プロトコルに対応する高性能パイプラインを構築し、目標比150%を超える合計279TBの製造データ（時系列センサー、画像、映像など）の収集に成功しました。本記事では、その巨大なデータダムを構築するために徹底的に議論したアーキテクチャ意思決定（ADR）を共有します。 問題定義 — OT-IT融合の3つのジレンマ PINNモデルの学習を成功させるには、高品質の生データ（Raw Data）が不可欠です。しかしプロジェクトの核心である**「IT-OT融合」**を実現するには、まず両領域のデータが持つ性質と違いを理解する必要がありました。 IT（情報技術）データ： ERP、MESなど業務を支援する経営システムから生成されるデータ OT（運用技術）データ： PLC、SCADAなど物理的な設備を制御し生産を担う現場技術から生成されるデータ この2つの領域を統合する過程で、以下の現実的な障壁に直面しました。 断片化された設備環境とプロトコル（Heterogeneous Environment） 8つの工場はそれぞれ異なる機器を使用していました。IT領域ではERP、MESなどのシステムごとに使用中のデータベースが異なり、OT領域も工場ごとに導入した設備メーカーが異なっていました。さらに収集対象のデータフォーマットも、CSV、JSON、Parquetなどの構造化データから画像（JPG、PNG、BMP）、映像（MPG、MP4）などの非構造化データまで混在しており、これらを網羅する標準化された収集体系の策定は非常に困難でした。 ネットワーク帯域幅の限界とデータ欠損リスク（Network Reliability） 製造現場のネットワーク環境は、大容量データをクラウドに転送するには不十分でした。外部インターネット接続は回線の冗長化が行われておらず、既存の内部業務ネットワークと回線を共有していたため、慢性的な帯域幅不足が発生していました。ネットワーク遅延や切断が発生した場合でも、データはエッジ側で安全にバッファリングされ、ネットワーク復旧時に欠損なく順序通りクラウドに転送できる堅牢なアーキテクチャが必要でした。 厳格な企業間データ分離（Strict Multi-Tenancy） 参加する8つの製造企業は潜在的な競合関係にある可能性があります。クラウドという「共有リソース」を使用しながらも、企業間のデータ混入懸念を完全に払拭する物理レベルの論理的分離（Isolation）がプロジェクト成功の鍵でした。 全体アーキテクチャ — Edge-to-Cloud Pipeline 上記の問題を解決するため、Google Cloudの特化ソリューションであるMDE（Manufacturing Data Engine）とMC（Manufacturing Connect）をコアとして採用しました。全体アーキテクチャは「現場設備に影響を与えない」という大原則の下、4つのLayerで設計されました。 Layer コンポーネント 主な役割 Edge MCe（Manufacturing Connect Edge） 現場ネットワーク内に配置。250以上のプロトコルに対応。ネットワーク切断時はInfluxDBを活用したエッジローカルバッファリングを実行 Transport Cloud Pub/Sub 毎秒数百万件のイベントを処理する大容量非同期ストリーミング。トラフィックスパイク時のシステムダウンを防ぐバッファーゾーンとして機能 Processing Cloud Dataflow リアルタイムデータ正規化（Normalization）。センサー値に設備名・ライン位置などのメタデータを結合（Contextualization）してビジネス価値を付与 Storage BigQuery / Bigtable / GCS ラムダアーキテクチャ（Lambda Architecture）を採用。大規模分析用BQ、リアルタイムクエリ用BT、大容量ファイル用Cloud Storageに分散格納 核心的意思決定 — セキュリティとコストのトレードオフ クラウドアーキテクトとして最も悩んだのは「マルチテナンシー（Multi-tenancy）環境をどう設計するか」でした。収集対象が8つの異なる（しかも潜在的競合関係にある）企業だったため、データ分離レベルに関するアーキテクチャ上の決定が必要でした。 ...