エッジ コンピューティング - ハイブリッド クラウドを超えるパラダイム シフト

※この投稿は米国時間 2021 年 11 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウドの活用か自社のデータセンターの活用かに違いはあっても、企業によるコンピューティング リソースの統合と一元化が加速の一途をたどっています。しかし、これまでにないほど高機能なモバイル デバイスが台頭し、モバイル ネットワークの高性能化が進んだことで、アプリケーション アーキテクトは、データセンターの枠を超え、エッジに目を向けるようになっています。

エッジとは具体的に何を意味しているのでしょうか。エッジとは、スマートフォンはもちろん、工場の設備センサーや産業機器、また遠隔地にある研究室の温度や反応のモニタリングなど、従来とは異なるさまざまなデバイス上で実行される分散コンピューティングのことです。エッジデバイスはコネクテッド デバイスであり、無線ネットワークやモバイル ネットワークを介して接続先の母艦と通信できます。

これらのエッジデバイスに搭載されるプロセッサの性能はますます向上し、従来の IT ではまったく範囲外であったタスクを実行することが求められています。企業にとっては、車両の受信テレメトリの前処理やショッピング モールのキオスクでの動画収集、倉庫内のカメラによる品質管理データの収集、小売店へのインタラクティブ メディアの配信などがそれに当てはまります。また、石油採掘装置や農機具など、接続が不安定な辺境地やデバイスからデータを取り込み、そのデータをフィルタリングして品質を向上させ、情報量の負荷を適正化してからクラウドで処理するなどの目的で、エッジを採用している企業もあります。新しいデータやモデルがその後エッジに push されますが、さらに設定やソフトウェア、メディアの更新を push し、処理ワークロードを分散させることもできます。

エッジは単に新しいユースケースを可能にするだけではなく、環境規模の適正化やリソース使用率の向上などにも応用できます。たとえば、エッジモデルを採用することで、既存のデータセンターの負荷を軽減することも可能です。

ただし、エッジ コンピューティングは企業にとって有望株であるとはいえ、まだまだ未完成な部分が多く残されています。さらに、エッジ ワークロードの開発は、永続的なデータ接続というメリットを享受し、十分なリソースを備えたハードウェア プラットフォーム上で実行できる従来のアプリケーションの開発とは大きく異なります。そのため、クラウド アーキテクトはまだ、自社でエッジをどのように使用し実装するかについて、検討の初期段階にあります。

幸いなことに、簡単にエッジ コンピューティングに移行できるよう支援するツールは揃っていますので、組織の既存のコンピュート システムに合ったツールが見つかるかもしれません。Kubernetes はもちろんのこと、クラウド、プライベート データセンター、エッジの各拠点で一貫したコントロール プレーンを提供する、Anthos のような上位レベルの管理ツールもあります。Anthos ファミリーのその他のプロダクト、すなわち、Anthos Config Management や Anthos Service Mesh では、さらに一歩進んで、エッジとクラウドのデプロイに整合性のとれた一元管理を提供します。今後も引き続き新たな機能のリリースを予定しています。

今回のブログ投稿の残りの部分では、エッジ コンピューティングのこれまでと現在の状況について、またエッジ コンピューティングに対しアーキテクトやデベロッパーが期待できるメリットについて、深く掘り下げていきます。次の投稿では、エッジを考慮した設計の課題と、一般的な企業がエッジモデルを採用した場合のメリットをいくつか詳しく説明します。最後に、エッジ環境の構築に今すぐ使える Google Cloud ツールや、現時点で実現可能な初期事例の一部をご紹介します。こうした事例から今後の取り組みのヒントが得られることになれば幸いです。

エッジ コンピューティングの進化

エッジは決して新しいコンセプトではありません。実際のところ、この 20 年間で、現在普及しているようなユースケースが多数生まれました。エッジの最初のアプリケーションの 1 つは、コンテンツ配信ネットワーク（CDN）を利用して、クライアントの近くにある静的ウェブサイト ページを毎日キャッシュして提供するものでした。たとえば、カリフォルニアのデータセンターにあるウェブサーバーが、欧州の顧客に財務データを提供するケースがこれに当てはまります。

接続環境が向上しソフトウェアが進化したことで、エッジも進化し、エッジを利用してサービスを提供するという方向に焦点が移ってきています。まず、シンプルなサービスは、静的な HTML から JavaScript ライブラリやイメージ リポジトリへと拡大していきました。その後、画像変換やクレジットおよび住所確認サポート サービスなどの一般的な機能が登場しました。やがて組織では、より複雑なクラウドレットやマイクロサービスのクラスタ構成をデプロイするとともに、データセットの分散や複製を行うようになりました。「エンドポイント」という言葉が一般的になり、API の数は急増しました。

それと並行して、ハードウェアやマイクロコントローラ、専用のエッジデバイスに関する創意工夫も飛躍的に向上しました。目的に合ったサービスがグローバルにデプロイされていきました。Google Cloud の IoT Core のようなサービスによって、これらの分散したデバイスを管理し安全に接続する機能が拡張されました。その結果、プラットフォームの管理者がツールを登録して、Pub/Sub や Dataflow などのマネージド サービスを活用してデータを取り込めるようになりました。また、Kubernetes を使えば、大規模なリモートのクラスタ（それ自体が小さいプライベート クラウド）を、より広範囲なインターネットで自己修復および自動スケーリングできるサービスとして動作させることが可能になり、アプリケーションやアーキテクチャ パターンの新しいモデルの開発へとつなげることができます。一言でいえば、分散型の非同期システムだけでなく、経済も開花したことになります。

これは企業にとってどのような意味を持つのでしょうか。この目的でいえば、エッジとは、企業ネットワークを超え、クラウド VPC、さらにはハイブリッドを超えることを意味します。最新のエッジは、主要なリモート データセンターにあるわけでも、CDN やクラウド プロバイダ、企業のデータセンターの棚にあるわけでもありません。たとえて言えば、1,000 個のセンサーに 100 個が接続されているようなものです。

わかりやすく言うなら、エッジとは、収集して生成した情報を処理して返すことができるハードウェアやデバイスを遠隔地に設置することです。一方で、エッジ管理の課題は、こうした遠隔地が接続された場合に、構成やソフトウェア、モデル、メディアの更新をプッシュできるかどうかという点です。

新しいユースケースを実現

エッジ コンピューティングが新境地に達した今日、マイクロデータ処理センターが、言うなればフラクタル状のアームのエッジとしてデプロイされはじめています。こうしたエッジが一体となって、非同期データのストリーミング、収集、処理、提供を一手に引き受ける広範で地理的に分散した常時接続フレームワークを形成しています。この、大きく疎結合したアプリケーション システムは呼吸をし、日々成長しているのです。常に変化し、収集したデータから常に学習しながら、ツタとツタがつながるたびに、最新のモデルが生み出されます。

今、5G の出現によってエッジの上限がさらに押し上げられています。5G 対応のデバイスは ISP を必要とせず、モバイル ネットワークを利用して送受信できるため、基地局の通信エリア内であればどこでも接続することが可能です。これらのネットワークの帯域幅は低くなるものの、特定の種類のデータには十分すぎることがよくあります。たとえば、気温や一酸化炭素のデータを定期的に送信する辺境の町に隣接する森林に設置された火災センサーなどが挙げられます。最近、Google Cloud は AT&T と提携し、5G エッジ テクノロジーのビジネス利用を強化する取り組みを始めましたが、これ以外にもできることがたくさんあります。

データセンターへの投資を削減

エッジを採用することで、新たに幅広いユースケースのデジタル化が可能になるだけでなく、既存のデータセンターもメリットを享受できるようになります。

データセンターの維持にコストがかかるのは紛れもない事実です。データセンターの負荷の一部をエッジ ロケーションに移すことで、データセンターのインフラストラクチャへの投資と、そこでのコンピューティングにかかる時間を軽減できます。また、エッジサービスは、データセンター サービスよりもサービスレベル目標（SLO）が低くなる傾向にあるため、ハードウェアへの投資も低く抑えられます。エッジの実装は接続の切断も許容するため、SLO が低くても十分に機能し、コストの削減につながります。

エッジがコスト削減に大きく寄与する例として、ビッグデータを見てみましょう。昔は、モノリシックなシリアル プロセッサ（ステートマシン）を構築していました。これらのプロセッサは、障害が発生した場合に備えて処理中の位置を把握しておく必要がありましたが、何度も繰り返すうちに、細かく分散して処理すれば、コストのかかる大規模な課題を、より費用対効果の高い小規模な課題に分割できることがわかりました。

約 20 年前に爆発的にヒットした、MapReduce を皮切りに、ビッグデータのワークロードはネットワーク上に散らばるクラスタに並列化されました。その結果、状態管理は中間出力を使うことで、チェックポインからの処理の共有、待機、再開を簡素化できるようになりました。以前のモノリシック システムは、値段が安くよりスマートなネットワーク クラスタやデータ リポジトリに取って代わられ、ワークロードの並行処理と実行可能なデータセットへのレンダリングが可能になりました。

今では、エッジのデータ収集ポイントに同じコンセプトが適用され広まっています。このようにビッグデータ処理が進化する中、Google でも機能強化を進め、観測データがあまりにも膨大であれば、まずは事前に絞り込んでから、管理可能で実用的なサイズになるまで前処理でサイズを下げることができるまでになりました。その上で、より多くのリソースを必要とする処理やモデルの構築の場合には、メインのデータ リポジトリに書き戻す必要があります。

つまり、データの収集やクリーンアップ、さらには初期集約をエッジ ロケーションで行うことで、コストのかかるデータストアに保管され続ける不要なデータの量を減らすことができます。これにより、主要なデータ ウェアハウスのパフォーマンスが向上し、ネットワーク転送やストレージのサイズとコストを削減できます。

今日の企業にとって、エッジは絶好のチャンスです。しかしながら、エッジを有効活用できる環境を設計するうえで、課題がないわけではありません。このシリーズのパート 2 では、エッジを念頭に置いて設計する場合に問題になりやすいアーキテクチャ上のいくつかの課題と、その解決方法についてご紹介します。

- Google カスタマー エンジニア / アプリケーション モダナイゼーション スペシャリスト Joshua Landman

- Google カスタマー エンジニア / アプリケーション モダナイゼーション スペシャリスト Praveen Rajagopalan