トラブルシューティング

仮想化ベースの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のネットワークボトルネックを完全に解消しました。 ...