【エッジコンピューティング第3回】マイクロデータレイクのアーキテクチャ

42 分前

読了時間: 7分

Machbase代表 Andrew Sungjin Kim

本シリーズを初めて読む方は、先に第1回と第2回をご覧いただくことをお勧めします。

まず全体像から

次の図は、Machbaseが目指すアーキテクチャです。各構成要素と、その背景にある考え方を順に見ていきましょう。

마이크로 데이터레이크의 구축 아키텍쳐 — マイクロデータレイクの構築アーキテクチャ

利用者から見た透過的なデータアクセス

シリーズ全体を一言で表すなら、「透過的なデータアクセス」です。これまでの説明は、すべてこの考え方につながっています。

エッジコンピューティングにおいて、それは何を意味するのでしょうか。

A. データの物理的な場所を抽象化する

まず重要なのは、保存場所を利用者から切り離すことです。簡単に言えば、アクセスするデータがクラウドにあるのか、エッジにあるのかを、利用者が意識せずに済むようにします。管理者は、もちろん場所を把握できます。

前の記事では、エッジで生成されたデータをクラウドや中央のデータレイクへ集め、その保存先を中心にサービスを構築する、従来の考え方を紹介しました。

利用者にとって、すべてが一か所にあるのは分かりやすい状態です。保存場所を気にせず分析・活用できます。ただし、その見方では毎月の費用が意識されにくくなるかもしれません。

マイクロデータレイクでも、インターフェース上では同じように利用できることが重要です。「アラームデータ」「装置Aの生データ」「過去1年間の傾向データ」といった論理的な名前で、物理的な場所を意識せずにアクセスします。

これらの名前に保存場所の情報が含まれないことがポイントです。大部分をマイクロデータレイクに保持すれば、そのデータに関わるクラウド保存・アクセス料金を大きく抑えられます。次の節で詳しく見てみましょう。

B. 統合・管理コストを減らす

多くのデータをマイクロデータレイクに保存すれば、クラウド側に必要な保存容量は減ります。

オフィスのPCからクラウド経由でエッジデータにアクセスする場合も、処理の大部分をエッジ機器側で行えます。クラウドへの入力通信が課金されない構成であれば、中間結果をエッジから送る際の入力料金も抑えられます。一方、クラウドからPCへの配信は課金対象になる場合があります。狙いは、すべての生データの転送・処理を、従量課金のクラウドサービスへ集中させないことです。

費用を抑える代わりに、性能面のトレードオフがあります。結果が離れたエッジ機器からクラウドを経由して利用者に届くためです。ただし実験では、大量の生データをクラウド経由でダウンロードする場合を除き、保存場所による差はほとんど感じられませんでした。近年のエッジとクラウドのハードウェアが、これを支えています。

商用クラウドのデータレイクやDBaaSでは、保存だけでなく、アクセスやクエリ処理にも課金されることが一般的です。大量のデータを中央で分析すると、その費用がアプリケーションの設計や利用を制約することがあります。予想外に高い請求が発生するのも、資源利用を十分に管理できない場合の一例です。

C. データ管理の柔軟性と自由度

第2回では、ある企業が抱えるデータ処理の課題を紹介しました。用途によっては、時間や予算があってもエッジデータを有効に集中管理できず、転送によって価値が失われる場合もあります。エッジのデータレイクがなければ、一時的に処理して捨てるか、分析しにくいテキストファイルとして蓄積することになりがちです。

マイクロデータレイクがあると、選択肢はどう変わるでしょうか。

データ量が少なければ、違いは小さいかもしれません。しかし一定の規模を超えると、費用対効果を比較し、エッジに保持するか、クラウドへ送るかを選べます。これは、データ管理の自由度を大きく高めます。

転送できないほど大量のデータがエッジで発生し、捨てることもできず、迅速な分析も必要な場合、マイクロデータレイクはその制約に対応する現実的な方法となります。

クラウドに置くデータ

中央には、どのようなデータを保存するとよいでしょうか。この概念はまだ発展の途中であり、答えは固定されていません。一つの考え方は、サービス全体とデータの状況を理解するために必要な主要情報を置くことです。

個々のエッジの全記録ではなく、サービス運用や横断的な分析に役立つ情報を集約します。例えば、次のものです。

アラームとイベント
選択した統計情報
主要な傾向と統合分析の結果
重要な保管用データ

これらは、中央で保存する候補になります。

利用者はクラウドでこれらを監視・分析し、特定の問題が起きたときに、エッジの詳細データへアクセスして調べることができます。

20対80のモデルで考えるなら、業務に必要なデータの約20%をクラウドに保存し、アクセスの約80%をそこで処理する構成を想定できます。これは考え方を示す仮定であり、普遍的な実測比率ではありません。

エッジに置くデータ

エッジのマイクロデータレイクには、次のデータが適しています。

生データ、履歴データ、詳細データ
一定期間保持する関連メタデータ

生データや履歴については、エッジで生成される関連測定値を、できるだけ広く保存することを想定します。過去のある時点で起きたアラームやイベントの原因を調べるための証拠になります。

同じ20対80のモデルでは、業務データの80%以上をマイクロデータレイクに保存し、アクセス頻度は全体の約20%になると考えられます。

メリットとトレードオフ

メリット

主な利点は、次のように整理できます。

保存コストの削減
- 保存先を分散し、同じ予算でより多くの容量を確保できます。
アクセス・管理費用の削減
- マイクロデータレイク内で処理するデータについて、クラウドサービスのクエリ料金を避けられます。
柔軟性の向上
- アーキテクチャに合わせ、保存場所とデータ形式を選べます。
高頻度データへの対応
- 毎秒数千～数万件に達する振動、電流、圧力などのデータを保存・分析・処理できます。
データセキュリティの管理強化
- 社内や生産拠点のエッジサーバーに生データを保持し、外部へ送る必要を減らせます。
サービスの応答性向上
- 生データがエッジにあるため、分析と対応を迅速に行えます。
ネットワーク障害時のデータ保全
- エッジとクラウドの通信が停止しても、マイクロデータレイクへの保存を続けられます。

トレードオフ

利点だけの技術はなく、マイクロデータレイクも例外ではありません。

生データへのアクセス性能が低下する可能性
- クラウドのデータへ直接アクセスする構成が概念上2層なのに対し、マイクロデータレイクでは3層になります。そのため、ネットワークや配置条件が、生データの取得性能に影響します。
管理するエッジ機器の増加
- データが複数の機器へ分散するため、ハードウェア、ソフトウェア、可用性を管理する負担が増えます。
技術の成熟度と運用上の安定性
- 本提案の時点では、マイクロデータレイクの実用例はまだ限られていました。技術的な制約や運用時の動作を、丁寧に評価する必要があります。