【エッジコンピューティング第1回】マイクロデータレイクの登場
マークベース代表 キム・ソンジン
エッジコンピューティングの概要
エッジコンピューティングとは、中央のデータセンターから離れた場所にあるローカルの計算機で、データを処理する技術的なアプローチです。特にIoT（Internet of Things）機器や産業機器など、大量のデータが発生する現場での分析・処理に重要な役割を果たします。Ciscoがクラウドの弱点を補う「フォグコンピューティング」を提唱するなど、関連する技術体系が発展し、エッジコンピューティングという名称が広く使われるようになりました。2010年代後半からは、さまざまな技術や企業が登場しています。概要を下図に示します。
出典：Samsung Semiconductor（リンク）
要するに、データ処理を担うのがクラウドサーバーなのか、エッジ側のコンピューターなのか、という観点で区別できます。
エッジコンピューティングとクラウドコンピューティング
では、両者の違いと長所・短所を比較してみましょう。
区分 | クラウドコンピューティング | エッジコンピューティング |
長所 | ・集中管理により、管理と保守を行いやすい | ・遅延を減らし、リアルタイム処理を実現できる |
・大量のデータを処理・保存できる（データレイクの構築） | ・必要な帯域を減らし、ネットワーク費用を抑えられる | |
・リソースの拡張性と柔軟性が高い | ・ローカル処理により、データを現場に保持できる | |
・専門的なセキュリティ・バックアップサービスを利用できる | ・ネットワーク障害時もサービスを継続できる | |
短所 | ・インターネット接続が必要 | ・初期構築費用が比較的高くなる場合がある |
・データの集中に伴うセキュリティリスク | ・分散構成のため、管理と保守が複雑になる | |
・通信遅延が発生する可能性がある | ・大規模データ処理に制約がある |
このように、両技術は互いの弱点を補うものと捉えられます。本稿執筆時点の市場では、クラウドコンピューティングのほうが広く普及しています。
エッジコンピューティングで語られていないこと
どちらも「コンピューティング」という言葉を軸に、処理や分析を行う場所でクラウドとエッジを分けています。一見もっともですが、よく考えると、重要な点が一つ抜けています。
クラウドを語るときは、すべてのデータをサーバーに集め、その大量のデータを分析する、という流れが自然に想定されます。一方、エッジでは現場で処理する点が強調されるものの、データの保存やその後の活用はあまり語られません。リアルタイム処理はエッジで行っても、データは当然クラウドのデータレイクに集める、という前提があるのかもしれません。
データはクラウド事業者の主要な関心事
データレイクは、データを収集・統合し、分析に利用できるようにする保存基盤です。そして、このデータに強い関心を持つのがクラウド事業者です。
クラウド事業者の基本的なビジネスモデルでは、多くのデータが自社クラウドに蓄積されることが、継続的な利用につながります。データの取り込みが無料でも、外部への転送に料金がかかるサービスがある点も忘れてはなりません。具体的な料金条件は事業者やサービスによって異なります。
筆者がAmazon、Google、Microsoft Azureのサービスを調べた範囲では、クラウドよりもエッジを主要な保存先とする構成は、あまり前面に出ていませんでした。事業者側には、そうした構成を積極的に提案する動機が小さいのかもしれません。
各社も技術動向に合わせてエッジコンピューティングを掲げています。ただし、筆者がここで問題にしているのは、現場で計算してもデータはクラウドへ送る、という構成です。エッジでの「計算」だけでなく、保存と継続的な活用まで含まれているかを見極める必要があります。
一例として、Amazonの「AWS for the Edge」のページを見てみましょう。
筆者が参照したページには、エッジコンピューティングに関する主要な用語は並んでいます。しかし、エッジ上のデータについてはセキュリティに触れる程度で、具体的な規模や処理方法は詳しく説明されていませんでした。中心にあるのは「計算」です。データ量が少なく、クラウドで十分に処理でき、顧客が費用を負担できるなら、双方にメリットがあります。では、現場のデータ量や機器数が予想を上回り、クラウドに集まるデータが膨れ上がったら、その費用は誰が負担し、誰にとって有利なモデルになるのでしょうか。
海外の記事から
LinkedInでさまざまなテーマについて発信しているDerek Mak氏が、2020年に公開した興味深い記事を紹介します。
記事では多様な観点が論じられています。特に印象に残ったのは、「データは原油」であり、まず集めることで活用の可能性が見えてくること、そして費用削減と独立した処理のため、エッジにもデータを中心に据えた「マイクロデータレイク」が必要だという考え方です。
エッジに関する記事を数多く読んできましたが、現場にもデータレイクが必要だという発想には驚かされました。
エッジに「手に負えないデータの怪物」が現れたとき
時は流れ、2024年になりました。2020年の記事が、現場で爆発的にデータが発生する具体的な事例を想定していたかは分かりません。おそらく、エッジを考える中で、将来起こり得る状況とその解決策を見通した結果なのではないでしょうか。
最近の顧客事例を紹介します。秘密保持契約のため社名は出せませんが、先端機器や素材を幅広く生産する大企業グループの一社で、毎年さまざまな設備や品質関連の製品を手掛けています。
生産は連続工程で行われ、各段階の設備状態を把握するため、特定のセンサーが毎秒1,000件以上のサンプルを収集しています。設備によっては、センサー数が数百個を超えます。
担当者の使命は、この膨大なデータをリアルタイムに分析するAIモジュールを開発し、異常を事前に検知して、品質や生産上の問題を防ぐことです。
ところが、最初は手のひらサイズの小さな恐竜だと思っていた問題が、実はティラノサウルスだったのです。
課題を簡単に整理してみましょう。
データの収集
収集したデータは、現在CSVファイルに保存しています。
ところが、数GBのファイルが毎日数百個も増え、すでに数千個を超えています。
データの抽出
AI学習用に、データを抽出する必要があります。
しかし、Pythonなどのインタープリター言語で何百ものファイルを一つずつ処理するには、長い時間がかかります。
データの加工
学習データの作成では、複数のCSVファイルのデータを操作し、特定のパターンで組み合わせたデータセットをいくつも保存します。
ところが学習してみると、適切なデータではないと分かり、同じ工程を繰り返します。
データの可視化
本当に学習させたいデータなのか、目で確認したくなります。
しかし、一度表示するだけでも、収集・抽出・加工のために、数百GBにわたるCSVファイル全体を繰り返し読み書きしなければなりません。
クラウド（サーバー）への転送と統合・管理費用
実際のAI学習サーバーは別にあるため、データをクラウドストレージへ転送する必要があります。数千ものファイルを個別に送るため、転送そのものが難しいだけでなく、すべてが完全に届いたかを確認することも極めて困難です。
気付けば、クラウドのデータレイクに蓄積された量は膨大になり、今も増え続けています。
最後にストレージと管理の費用を考えると、このやり方でよいのかという疑問が残ります。
担当者は、クラウドへデータを集中させるモデルが、現実的に実行可能なのか悩み始めました。
さらに、データ量を定量的に見ると、その規模に圧倒されます。
センサー1個の収集頻度：毎秒1,000件
設備1台あたりのセンサー数：40個
1ラインの設備数：150台
1工場の生産ライン数：32本
世界の生産拠点数：4か所
では、1ライン分のデータを3か月間収集し、1件を10バイトとすると、どれほどの量になるでしょうか。ここでは、AI学習に必要な量として3か月分を確保すると仮定します。
設備1台の90日分の件数＝1,000（Hz）×40（センサー）×60（秒）×60（分）×24（時間）×90（日）＝311,040,000,000件（約3,110億件）
これに150台を掛けると、1ラインで46,656,000,000,000件（約46.7兆件）になります。1件10バイトなら、データ本体だけで約466.56TB、2進単位では約424.33TiBです。CSVの区切り文字や文字列表現などの追加容量は含みません。さらに加工用データや索引も必要になれば、まさに未知の「データの怪物」と向き合うことになります。この規模をクラウドで管理するには、インフラと運用にどれほどの費用がかかるでしょうか。
エッジのデータに命を吹き込む——マイクロデータレイク
こうして、Derek Mak氏が提唱したマイクロデータレイクの概念が、現実の意味を持つようになりました。
エッジで発生するデータは現場にデータレイクを構築して管理し、クラウドにはアラーム、イベント、障害記録、メタデータなど、本当に必要なデータを送ります。現場での演算、つまりエッジコンピューティングはそのまま維持します。これなら、全体のつじつまが合うのではないでしょうか。
先ほどの事例も、設備ごとに2〜3TB程度のストレージを持つマイクロデータレイクを、圧縮などを考慮して適切に構築できれば、状況を改善できそうです。
これを詩的に表現するなら、「データに命を吹き込むこと」です。データが活用される時間と場所が生まれるからです。例えば、次のような可能性が開けます。
リアルタイムにデータを保存できる
毎秒数万件のデータを失わずに済みます。マイクロデータレイクがすべてのデータを保存し、リアルタイムに索引を作成するからです。
過去の出来事や履歴をエッジに保持できる
問題が発生したとき、その期間のデータを調べて原因を追えます。マイクロデータレイクに必要な履歴が残っているからです。
リアルタイムにデータを抽出できる
1,000億件の中から、必要な部分を取り出せます。索引付きのデータを保持するマイクロデータレイクだからこそ可能になります。
データの保守・管理費用を大幅に抑えられる
初期のエッジストレージ費用を負担すれば、クラウドで継続的に発生する保存料金を抑えられます。元記事は機器故障を除く追加費用がゼロに近づくという理想像を述べていますが、実際には電力、運用、保守などの費用も考慮する必要があります。
しかし、本当に実現できるのでしょうか
ここまで、さまざまな前提を重ねながら、エッジ向けのマイクロデータレイクを説明してきました。しかし、実現可能性を技術的にはまだ説明していません。誰もが次のような制約を思い浮かべるからです。
データレイクに必要な計算能力を、エッジで確保できるのでしょうか。エッジサーバーに企業向けデータ基盤をどう導入するのでしょうか。
数千億件のデータを、小さなエッジ機器でどうリアルタイム管理するのでしょうか。CSVに保存するだけでは、高速検索の課題は解決しません。
毎秒4万件を取り込みながら、エッジコンピューティングのためのリアルタイム抽出も同時に行う必要があります。本当に可能でしょうか。
必要な容量が大きいため、圧縮も必要です。圧縮したままデータへアクセスできないでしょうか。
可視化はどうするのでしょうか。現場ですべてを管理するなら、表示も現場で行えるべきです。3,000億件のデータについて、日次・週次・月次の傾向や統計を可視化する必要もあります。
これらは、実際に現場の専門家から一つずつ指摘された要件です。一見難しい要件でも、満たせて初めてエッジの保存基盤に意味が生まれます。顧客の立場からは、どれも妥当で当然の指摘です。
こうした問いに答えられなかったからこそ、先駆者たちもエッジでの大量保存を要件として掲げなかったのかもしれません。
「マイクロデータレイク」
見方によっては、まだ実現が難しい未来の技術なのかもしれません。
いずれにせよ、実現は無理だと思われそうな市場の要望は確認できました。次回は、これをどのように実装すべきか考えていきます。
