エッジ アプリケーションの設計に関する 6 つの考慮事項

あなたのビジネスはこの新しいデータ環境に対応できる準備ができていますか?

エッジ コンピューティングは、データが生成および使用される場所の近くにコンピューティング能力とデータ ストレージを分散します。新しいエッジ アプリケーションは、デバイスとネットワーク ゲートウェイを活用して、クラウドではなくローカルでタスクを実行し、サービスを提供します。

これらのエッジ アプリケーションには、アプリケーションの規模、レイテンシ、可用性、セキュリティのニーズを考慮した新しいデータ アーキテクチャが必要です。今日は、エッジ アプリケーションのデータ アーキテクチャを構築する際に企業が考慮する必要がある主要な設計要素について説明します。

データ アーキテクチャを決定する最初のステップは、データのライフサイクル、つまりデータが生成される場所、データで実行する必要がある処理 (分析、保存と転送、長期保存など)、およびデータが使用される場所を理解することです。データを複数のリージョン間で移動するとレイテンシが大きくなる可能性がありますが、データが生成および処理される場所の近くに配置することで、レイテンシが短縮され、スループットが向上します。一方、クラウドからエッジに移行する場合、データ処理のためのリソースは（クラウドと比較して）減少し、ネットワークの分断やダウンタイムのリスクが大きくなることを考慮する必要があります。

アプリケーションがデータを処理する方法は、データ アーキテクチャがサポートする必要があるものを決定する上で重要な要素になります。たとえば、店舗内の POS デバイスからのデータを分析する小売アプリケーションでは、エッジからクラウドにデータを複製する必要があります。この分析は、すべての小売店のデータを集計して表示する場合にのみ役立ちます。さらに、クラウドには、エッジ ロケーションには不足している可能性がある、高度な機械学習アルゴリズムを実行するために必要なリソースがあります。ただし、小売組織がすべてのエッジ ロケーションに一貫したソフトウェア構成を展開する場合は、コアでマスター構成を作成し、それをすべてのエッジ ロケーションに複製する必要があります。

エッジ環境のデータ アーキテクチャを設計する際には、考慮すべき重要な要素がいくつかあります。

1. 柔軟性

データはどのくらいの速さで増加するのでしょうか?データを生成するユーザーとデバイスの数はいくつですか?データを処理するにはどれくらいの計算能力が必要ですか?システムの弾力性は常にアプリケーションにとって重要なポイントであり、エッジ コンピューティングも例外ではありません。

通常、エッジ ロケーションには、大量のデータに対して詳細な分析を実行するためのコンピューティング リソースとストレージ リソースがありません。さらに、エッジの OLTP データベースでは、デバイスからの大量のデータ入力を処理するためにスループットを拡張する必要がある場合があります。

2. レイテンシとスループット

どれくらいのデータが書き込まれたり読み取られたりするのでしょうか?データはバースト的に送られてくるのでしょうか、それとも比較的安定したストリームで送られてくるのでしょうか?ユーザーとアプリケーションはそれをどのくらいの速さで消費する必要がありますか?

たとえば、コネクテッド ビークルやクレジットカード詐欺検出などのリアルタイム アプリケーションの場合、テレメトリやトランザクション データをクラウド アプリケーションに送り返して、対処方法を決定することは現実的ではありません。このような場合、エッジの生データにリアルタイム分析が適用され、アラートがすぐに生成されます。

3. ネットワーク接続

ネットワーク接続の悪さは、多くのエッジ ロケーションが直面している現実的な問題です。アプリケーションでは、ネットワーク パーティションの処理方法を考慮する必要があります。エッジとクラウド間のネットワーク品質に応じて、さまざまな動作モードが発生する可能性があります。

ほとんどの場合接続:アプリケーションは、API 呼び出し (データの検索など) を実行するために、ほとんどの場合リモートの場所に接続できます。これらの API 呼び出しの一部は、ネットワーク パーティション (数時間にわたる数秒のパーティションなど) が原因で失敗する可能性があります。

半接続:このシナリオでは、数時間にわたってネットワーク パーティションが拡張される可能性があります。アプリケーションは、パーティション ウィンドウ中に発生した変更を認識し、パーティションが回復した後にその状態をリモート アプリケーションと同期できる必要があります。

切断:この場合、主な動作モードは、アプリケーションが外部サイトから独立して実行されることです。時々接続できる場合もありますが、これは通常ではなく例外であると考えられます。

リモートで実行されるアプリケーションとデータベースは、切断された操作または半接続された操作用に設計する必要があります。ニアエッジ アプリケーションでは、半接続またはほぼ接続された操作を採用する必要があります。クラウドは主に接続モードで動作します。ただし、パブリック クラウド サービスがダウンタイムを経験すると、その影響は深刻で、数時間続く可能性があります。

4. 物理デバイスの障害

インフラの停止もさまざまな場所でよく発生します。遠端では、ノードやポッドの障害からリージョン全体に至るまでの障害が頻繁に発生する可能性があります。エッジ付近やクラウドでは、ノードやポッドの停止はよく発生しますが、アプリケーションは地域ラックを使用して回復力を高めることができます。ただし、このように障害を分離しても、リージョン レベルの停止が発生する可能性があります。

5. ソフトウェアスタック

ソフトウェア スタックのコンポーネントを選択するときは、俊敏性と使いやすさを考慮することが重要です。ビジネス サービスには一連のアプリケーションが含まれるため、エンジニアリング チームはアプリケーションの迅速な反復を設計する必要があります。これを実現する 1 つの方法は、開発者の生産性を即座に向上させる成熟したフレームワークと、開発者がすでに使い慣れている機能豊富なオープン ソース データベースを使用することです。

6. セキュリティ

セキュリティは、エッジで実行されるアプリケーションにとって最も重要です。特に、アーキテクチャの本質的に分散された性質により、さまざまな攻撃ポイントが存在することを考慮すると、セキュリティは非常に重要です。すべてのサービスとコンポーネントに対して、最小権限、ゼロ トラスト、ゼロ タッチ アプリケーションを考慮することが重要です。

その他の具体的な安全面については、以下をご覧ください。

• 送信中の暗号化
• 保存時のデータ暗号化
• データベース層でのマルチユーザーサポートと各ユーザーの暗号化分離
• コンプライアンスを確保し、それに関連する地理的アクセス制御を考慮するためのデータの地域的局所性

エッジ コンピューティングの台頭は、ますます分散化が進むデジタル世界の需要に応えるためにアプリケーションを構築および展開する方法におけるパラダイム シフトです。この環境では、すべてのアプリケーションで機能する汎用的なデータベース リファレンス アーキテクチャは存在しません。ただし、アプリケーションの要件と関連するトレードオフに応じて、組織はニーズを満たすためにさまざまな設計選択を行い、要件の変化に応じてそれらの選択を調整します。 IT 組織全体に関連する設計上の決定に重点を置くことで、企業はエッジ アプリケーション データを今後何年にもわたって戦略的リソースとしてさらに活用できるようになります。