【エッジコンピューティング第2回】マイクロデータレイクに求められる特性
マークベース代表 キム・ソンジン
マイクロデータレイクに求められる特性
本稿を初めて読む方には、先に第1回「マイクロデータレイクの登場」を読むことをお勧めします。
用途
マイクロデータレイクの最大の特性は「特定の目的に特化していること」です。クラウドのデータレイクが汎用性を極限まで追求するのに対し、エッジでは業務目的に最適な機能を選んで提供します。これはエッジ環境の制約を考慮したものです。例えば、次のような用途が挙げられます。
大量のセンサーデータを処理するデータレイク
大量の非構造化画像データを処理するデータレイク
大量の動画などの映像を処理するデータレイク
大量の音声やノイズなど、非構造化音響データを処理するデータレイク
大量のネットワーク関連データ（パケット、セッション）を処理・分析するデータレイク
ほかにも多様な専用データレイクが考えられます。今後、データレイクが提供する機能の範囲はさらに広がっていくでしょう。
動作するハードウェア
これは境界が曖昧な領域です。エッジ機器とサーバーの間には大きなグレーゾーンがあります。計算能力や機能の向上により、数年前にはサーバークラスだったハードウェアが、現在ではエッジ機器になることもあります。ここでは、本稿執筆時点で一般にエッジと呼ばれる構成を基準に整理します。
CPU
主流はx86、x64系CPUで、おおむね1.5〜2.5GHz程度、構成によって1個から8個、16個ほどのCPUを備えるものまで、エッジサーバーと呼ばれています。また、ARM系CPUも高い性能と低価格を両立するようになり、エッジサーバーへの採用が増えています。
メモリ
一般的には1GBから4GB、8GB程度で、価格差も大きくありません。仮想化が必要なら、さらに多くのメモリを搭載する場合もありますが、本稿ではエッジサーバーの想定範囲を超えるものとします。
ネットワーク
エッジサーバーは一般に1〜10Gbps程度のネットワーク性能を備えます。内部ネットワークと外部ネットワークを分けるため、2つ以上のポートを持つ機器もあります。
ディスク（ストレージ）の種類と容量
サーバーより小型のエッジ機器では、信頼性に注意が必要なmicroSDを使う場合もあります。一方、一般的なエッジサーバーでは、256GB程度のSSDストレージが一つの目安になります。ストレージはデータレイクの主目的であるデータ保存・処理を担うため、扱うデータと用途に応じて適切な容量を選ぶ必要があります。
データの種類
構造化データの処理
エッジサーバーが必要な業務で扱う構造化データは、多くの場合、大量の「センサー」または「タグ」データです。そのほか、ネットワークパケットや関連セッション情報、時系列で連続して発生するネットワーク品質指標なども構造化できます。
つまり、大量の構造化時系列データを効率よく保存・処理することは、マイクロデータレイクの主要な目的の一つです。
非構造化データの処理
エッジにおける代表的な非構造化データは、カメラから得られる画像・映像です。AIアプリケーションと密接に連携し、異常な動作を検知して利用者に素早く知らせ、危険や災害を防ぐ分野で広く使われます。
ただし、こうしたデータに「データレイク」という機能が必要かどうかは検討の余地があります。画像・映像は通常ファイルとして保存され、データの形式によっては、索引による高速検索や追加圧縮の余地が限られるためです。収集した映像は、ラベルを付けてAI学習用の生データとして使う場合に価値を持ちます。
エッジで非構造化データが特に意味を持つのは、時刻情報と結び付けて保存・保持する場合です。特定の時間帯におけるセンサーやタグの変化が、実際の画像の変化とどう関連するかを分析できます。例えば戦車などの機器では、カメラが捉えた外部の衝撃や炎が内部に与える影響をセンサーデータで定量的に調べられます。逆に、内部センサーが捉えた急激な変化と、外部の映像との関係を確認することもできます。
データ収集性能
単純な書き込み速度だけを考えれば、テキストファイルへの直接保存は非常に速い方法です。しかし、マイクロデータレイクの「収集」は、次の3つをすべて満たして初めてデータレイクとして機能します。そうでなければ、単なるディスク領域と変わりません。
データ保存性能
入力データは非構造化または半構造化であることが多いため、データレイクが定義する形式へ素早く簡単に変換し、物理ストレージへ高速に保存する必要があります。これは「ディスクI/O帯域をどう最大限に活用するか」という問いでもあり、そのためのさまざまな方法を検討する必要があります。
データの索引作成性能
非常に重要なのは、保存と同時にリアルタイムで索引を作成することです。対照的な例として、従来のHadoop型の処理では、ディスクへの保存と、索引作成または分析（代表例はMapReduce）が別の段階に分かれ、即時性に制約があります。
エッジコンピューティングでは、データの発生からその後の演算までリアルタイム性が前提となります。そのため、このようなバッチ中心のビッグデータ構成は目的に適さず、導入できても非効率になりがちです。RDBMSで挿入速度を上げるため索引を外す方法もありますが、それもここでの目的とは異なります。
データ圧縮性能
これも重要です。エッジサーバーは一度設置すると、ストレージ構成を動的に変更するのが難しく、データ保存後は極めて困難になることもあります。遠隔地にあるうえ、クラウドの伸縮性という利点も使えないからです。限られたストレージを最大限に活用するには、収集時に即座に圧縮し、圧縮された状態で利用できることが不可欠です。
この3つのうち、どれか一つでも不足すれば、十分なマイクロデータレイクとはいえません。
やはり、簡単な課題ではありません。
データ操作性能
利用者は、このデータレイクで何を実現したいのでしょうか。
リアルタイムでのデータ検索・抽出性能
最も本質的な要件である検索性能を満たす必要があります。エッジコンピューティングはクラウドの応答遅延を補うためのものなので、データ発生から抽出までの時間を最小限にしなければなりません。これは前述の索引作成性能と密接に関係します。十分な収集性能があってこそ、索引を使った高速抽出が意味を持ちます。
時系列データの分析性能
これは画像や動画などの非構造化データの処理と深く関わります。ある時刻にイベントが起きたら、その期間の画像、音声、音、ノイズなどの関連データへ直ちにアクセスできる必要があります。鍵は、データレイクが2種類のデータをどう結び付けるかです。大量のセンサーデータと映像・画像が同時に生成される自動運転車などでは、不可欠な機能になります。
統計データの抽出性能
エッジ上のマイクロデータレイクでは、長時間リソースを占有する分析クエリの実行は難しいと考えるべきです。エッジサーバーは24時間365日サービスを継続する必要があり、分析クエリがリソースを過剰に使って既存サービスを妨げれば大きな問題になるからです。したがって、利用者が求める統計・分析データをいかに素早く提供するかについて、明確な手段が必要です。
一方、クラウドのデータレイクは、この点で比較的自由です。リアルタイムサービスよりも、分析を主目的として構築されることが多いためです。
この面では、マイクロデータレイクのほうが厳しい要件を持つといえます。
データの移動
エッジで収集したデータは、容量に限界があるため、一部または全部を定期的に別の場所へ移す必要があります。削除することもできますが、少なくともアラーム、イベント、特定領域の重要な記録などは、クラウドや上位階層へ移すべきです。その際、検索、保存、抽出、ネットワークやストレージ経由の複製に伴う負荷を最小限に抑え、サービスに影響を与えないことが必要です。
データのセキュリティ
この課題は、大きく3つの観点から整理できます。
データ自体の機密性（暗号化）
エッジ機器が盗まれたり、記憶媒体が外部へ持ち出されたりした場合に、情報をどう守るかという問題です。筆者がそれまでに見た案件では、エッジの保存データに暗号化を要求する例は多くありませんでした。センサーや機器のデータは個人情報保護の対象外だと考えられていたためではないか、と推測しています。国が指定する標準暗号方式などの制約がなければ、さまざまな暗号化・復号方式を選べるため、実装上の選択肢は豊富です。当時の筆者の経験では、エッジサーバーで暗号化を求められるケースはまれでした。
データ転送のセキュリティ（通信経路の暗号化）
サーバーとエッジ間の通信には、MQTTがよく使われます。標準的な暗号化技術を組み合わせられるため、一般的な構成であれば導入は比較的容易です。MQTT以外の特殊な通信方式を使う場合は、別途検討が必要になります。
保存先の物理的な場所
企業が実データをクラウドへ送信したくないという要望も、エッジに保存する理由の一つです。マイクロデータレイクを構築できなければ、データを自社の管理範囲内に置くため、プライベートクラウドや社内のサーバーに集約することになります。マイクロデータレイクが実現すれば、管理・制御用サーバーにパブリッククラウドを使いながら、実データは自社側に保持する構成が可能になります。
拡張性
本稿で想定するエッジサーバーでは、主な拡張方法はスケールアップです。将来はエッジでもスケールアウトが必要になる可能性がありますが、近い将来の多くの用途は前者が中心になると考えます。
高可用性
これはエッジコンピューティングの大きな課題です。単独のエッジ機器は単一障害点になりやすく、連続運転する特定の工程などでは、その停止を許容できません。エッジサーバーを冗長化する際は、計算機だけを二重化するのか、ストレージまで二重化するのかを、費用対効果から判断する必要があります。筆者は本稿執筆時点で、エッジにこの水準まで導入した事例をまだ見ていません。
クラウドとエッジの統合・サービス
実際の導入では見落とされがちですが、これも重要な課題を含むテーマです。
一部のデータだけがクラウドやサーバーにあり、大部分がエッジのマイクロデータレイクに保存されているとします。利用者が監視、監査、履歴確認、イベント検索、可視化などのために遠隔からアクセスするには、どうすればよいでしょうか。多くのエッジサーバーは企業内ネットワークにあるため、クラウドや外部ネットワークから各サーバーへ接続するには、適切な仕組みが必要です。
これが実現すれば、クラウド側からデータの所在を意識せずに操作できます。利用者には、データがクラウドにあるのかエッジにあるのかを意識させず、全データを外部へ移さなくても両方を操作・可視化できる、新しいデータ統合モデルが可能になります。
このようなアーキテクチャこそ、マイクロデータレイクの完成形といえるのではないでしょうか。
次の第3回では、マークベースの製品を使ってマイクロデータレイクをどう具体化するか、構成図や事例を通じて見ていきます。
