エッジ コンピューティング - エンタープライズのクラウド アーキテクトの課題と機会

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

このシリーズのパート 1 で説明したように、今日のエッジ コンピューティングの環境は、それによって可能になる新たなユースケースと、コスト削減という 2 つの点で、企業にとって大きなチャンスとなっています。しかし同時に、エッジ コンピューティングは、アプリケーションの設計方法に大きな変化をもたらします。新たにエッジ アプリケーションの構築を検討するときに、念頭に置くべきいくつかの課題があります。

1. 断続的な接続

エッジデバイスは、データセンターから切断されていることがよくあります。クラウド アーキテクトは、エッジデバイスが工場フロアのセンサーであろうと、コネクテッド カーであろうと、信頼性が高く高速なネットワーク接続を常に想定できるとは限りません。

そのため、設計については、重要な考慮事項がいくつかあります。1 つは、リモート ロケーション内で、接続を隔離できるようにすることです。実際問題として、ネットワーク上のすべてのエッジデバイスが、ローカルのプライベート サービス クラスターへのルートを 1 つしか持っていない場合があり、プライベート サービス クラスターからマザーシップ（クラウドや企業のデータセンターのアグリゲーション ホップ）へのリンクがダウンしている可能性があります。つまり、リモートのエッジシステムはフォールト トレラントとして設計する必要があり、コアへの接続とは独立して機能する必要があります。

2. 切断とデータ キャプチャ

エッジでサイト ネットワークが停止すると、ダウンストリームへの影響が生じる可能性があります。

たとえば、キャプチャをクラウドに送信する前に、自動スケーリングのコンテナ化されたサービス デプロイメントに保存する、ローカルなビデオカメラを想像してみてください。多くのカメラがアクティブになると、Pod レシーバーがディスクを起動して書き込みをします。ただし、転送用のデータを準備するローカル クラスターは、計画された時間に、またはたくさんのローカル フィルタリングのワークロードが適用された後にのみ、メインの会社のデータセンターまたはクラウドにデータを送り返す場合があります。データ同期に大きなギャップが生じた場合に、エッジディスクがキャプチャ ビデオでいっぱいにならないようにするために、戦略を立てておく必要があります。

この場合、エッジのロケーションはキャッシュと同様の動作を示します。つまり、システム障害を回避するには、長時間の切断が発生した場合のために、キャプ チャデータの有効期間（TTL）が必要です。ほとんどのエッジ構成はリアルタイムでモニタリングされていないため、これは特に重要であり、そのため、接続不良状態で機能できる必要があります。より広範なシステムの場合は、予期しない長時間の切断に対応するために、データ キャプチャのギャップを許容する必要もあります。

三重の連鎖反応により、エッジサイトで予期しない障害が引き起こされる場合があります。そのため、アーキテクトは、障害に対する計画に加えて、検出フェーズで、リモートのシステムがオンラインに戻ったときに、どうデプロイして構成するかについても計画しておく必要があります。

3. ハードウェア障害と保守性

ハードウェア障害とアップグレード失敗は発生します。たとえば、エッジデバイスまたはサービスのアップグレードが失敗し、クラスターまたはデバイスが失敗した状態のままになる可能性があります。または、ディスクで不良セクタが発生、NIC が失敗、または電源が故障したりします。これらすべてのケースで、物理的な保守サービスが必要になる可能性があります。障害の影響範囲を制限するようにアプリケーションを設計することもできますが、エッジ環境のサービス スケジュールとアクション プランも必要です。店舗責任者に故障したエッジハードウェアのメンテナンスは期待できません。フリート全体でエッジ クラスターの冗長化とブルーグリーン デプロイメントを検討する必要があります。また、リモートサイトへのアクセスはエッジ プログラムの一部であるべき、ということを念頭に置く必要があります。  

4. 複雑なフリートの管理と構成

エッジのアーキテクチャは急速に進化し成熟しており、構成管理を容易にするツールが成功の鍵となります。特に、不安定性や断続的な接続に適切に対処できるツールが重要です。これは、システム構成のプッシュ、ソフトウェアやセキュリティの更新、新しいソフトウェアのプル、処理作業の実行時に新しいまたは更新されたモデルや、アルゴリズムの更新をデプロイする、といったタスクにとって重要です。リモートのフリートを管理するには、どこかのタイミングで接続できる、という最低限の保証も必要です。再接続できないリモート ロケーションはもはやエッジではなく、第三者によって物理的に管理される必要があります。

企業の利点

企業のアーキテクトが効果的なエッジ アプリケーションを作成するにはたくさんのチャレンジがありますが、企業がエッジ コンピューティングの使用に特に適している理由もいくつかあります。

1 つは、ほとんどの企業のシナリオでは、エッジでのプライベート サービスを前提としています。その理由は、企業が一般に公開するサービスは通常、コア データセンターまたはクラウドにあり、ロードバランサ、冗長構成、自動スケーリングを備えています。これらの公開サービスでは、多くの場合、99.99% 以上の稼働率が求められます。しかし、ほとんどのエッジサービスでは、ここまでのサービスレベル目標は求められません。エッジ アプリケーションはプライベートである可能性が高く、ローカルのテレメトリーをキャプチャまたは処理能力をリモート ロケーションに分散したりするために使用され、エッジサービスがダウンしても企業は完全に機能し続けます。たとえば、エッジを使用してデータの収集やフィルタリングを行い、それを中央の ML エンジンに送り返してクラウド プロバイダでモデルを構築し、それらのモデルをリモートで受信して提供するかもしれません。パブリック IP やベアメタルのロードバランサが必要になることはめったになく、最新のエッジサービスのエンドポイントには最小限のインターネット帯域幅の要件しかありません。実際、定期的に接続できるだけでよいのです。（当然ながら、公開サービスは一般的にエッジサービスのユースケースとして妥当ではありません。）

関連して、エッジで、マイクロ クラスターや、コモディティ ハードウェアを使用したシングルノードさえも実行できます。アーキテクトは、太いネットワーク パイプと完全なモニタリングを備えた、99.9%～99.99% 稼働するデータセンター環境を設計する傾向があります。エッジのロケーションにおいては、特にそれが多数ある場合は、その限りではありません。断続的な障害に対するエッジ アーキテクチャの計画に関して、エッジはコア データセンターやクラウド プロバイダで許容されるよりも高い頻度のハードウェア障害を許容して設計します。そして、そのようなフォールト トレラントな設計が導入されれば、ハードウェア自体についても、多少の障害は許容されることになります。   

エッジの課題 = ビジネス チャンス

特定のクラスのエンタープライズ アプリケーションに関して言えば、エッジの弱点が強みになる可能性があります。他のアプリに相互依存せず、コア データセンター システムの機能から切り離されても長時間機能できるアプリケーションがある場合、リモート サービスを使用してエッジ アーキテクチャを実装することは、組織のデジタル化されていない部分のデジタル トランスフォーメーションを推進するための重要な手段になります。

次回の投稿では、このアーキテクチャの一部として使用できる Google Cloud のツールとテクニックのいくつかを紹介します。

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

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