エッジプログラミングを成功させるための6つの教訓

エッジプログラミングを成功させるための6つの教訓

​翻訳者 |ブガッティ

校正:孫淑娟

多くの組織が、レイテンシ、柔軟性、コスト、パフォーマンスの面でエッジ コンピューティングがもたらすメリットを享受しているため、エッジ コンピューティングは急速に成長しています。 IDC は、エッジ ハードウェア、ソフトウェア、サービスへの世界的な支出が 2022 年に 1,760 億ドルを超え、前年比 14.8% 増となり、2025 年までに 2,740 億ドルに達すると予測しています。したがって、開発者が現在エッジ アプリケーションを開発しているか、近い将来に開発する可能性は十分にあります。

積極的に試してみる前に考慮すべき点がいくつかあります。私は、いくつかの開発組織で働いた経験のあるエンタープライズ アーキテクトであり、エッジ アプリケーションの作成に関していくつかの重要な教訓を提供できます。これらの教訓を念頭に置くことで、イライラする結果を回避し、エッジ コンピューティングを最大限に活用できるようになります。

レッスン1: 自分の考えに疑問を持つ

開発者は、エッジ アプリケーションをデータ センターやクラウド向けのアプリケーションであるかのように作成することがよくあります。しかし、エッジは異なるパラダイムであり、コードの記述には異なるアプローチが必要であり、どのアプリケーションがエッジに適しているかを慎重に選択する必要があります。

ほとんどの開発者は、少数のサーバーが大量のコンピューティング リソースを持つ集中型コンピューティング環境に慣れています。しかし、エッジ コンピューティングでは、適度な量のリソースをさまざまな場所にある複数のサーバーに分散することで、この状況を一変させます。これは、あらゆる種類のエッジ ワークロードのスケーラビリティに影響を与えます。たとえば、大量のメモリを使用するアプリケーションは、数百または数千のエッジインスタンスに適切に拡張できない可能性があります。このため、ほとんどのエッジ アプリケーションは、既存のデータ センターやクラウド デプロイメントから「リフト アンド シフト」されるのではなく、エッジ専用に構築されます。

エッジ アーキテクチャがアプリケーションにどのような影響を与えるか、またどのアプリケーションがこの分散アプローチからメリットを得られるかについて、慎重に考える必要があります。データがある場所にロジックを導入する方が簡単な場合がよくあります。したがって、データが分散している場合や、大規模な集中データ ストアにアクセスする必要がある場合は、クラウド ベースのアプローチが適切である可能性があります。しかし、エッジ コンピューティングが真価を発揮するのは、オンライン ユーザーからのリクエスト/レスポンス、Cookie、ヘッダーなど、エッジで生成されたデータをアプリケーションが使用するときです。

レッスン2: 基本を無視しない

コードをエッジに配布するとレイテンシとスケーラビリティは向上しますが、すぐに実行速度が速くなるわけではありません。非効率的なコードは、エッジでも非効率的です。前述したように、エッジの各アクセス ポイントは、特にサーバーレス エッジ環境では、一般的な集中型コンピューティング環境よりもリソースが制限されます。エッジ用のコードを作成する場合、このアーキテクチャを最大限に活用するには、効率を最適化することが重要です。

機能をエッジにプッシュするのは比較的迅速かつ簡単ですが、通常のコードに適用するのと同じ適切なガバナンス プロセスを適用する必要があります。これには、適切な変更管理プロセス、ソース コード管理システムへのコードの保存、コード レビューを使用したコード品質の評価が含まれます。

レッスン3: スケーラビリティを再考する

エッジを使用する場合は、「スケールアップ」ではなく「スケールアウト」することになります。したがって、各サーバーの制約を考慮するのではなく、各リクエストの制約に対応するようにコードを開発する必要があります。これには、メモリ使用量、CPU サイクル、リクエストごとの時間に対する制約が含まれます。制約は使用しているエッジ プラットフォームによって異なるため、制約を理解し、それに応じてコードを設計することが重要です。

通常、各操作に必要な最小限のデータ セットを使用して操作する必要があります。たとえば、エッジで A/B テストを実行している場合は、ルールセット全体ではなく、処理している特定のリクエストまたはページに必要なデータの部分のみを保存したい場合があります。位置情報に基づくエクスペリエンスの場合、軽量クエリでエッジ インスタンスが提供する特定の州または地域のデータのみが必要であり、すべての地域のデータは必要ありません。

レッスン 4: 信頼性を重視したコードを書く

エッジ アプリケーションの信頼性を確保することは、良好なユーザー エクスペリエンスを提供するために重要です。品質保証 (QA) 計画にエッジ コードのテストが含まれていることを確認します。問題が発生した場合のフォールバック動作の計画とテストなど、コードがエラーを適切に処理できるようにするために、適切なエラー処理を追加することも重要です。たとえば、コードがプラットフォームによって課された制限を超えた場合、ユーザー エクスペリエンスに影響するエラー メッセージがユーザーに表示されないように、デフォルトのコンテンツにフォールバックするフォールバック メカニズムを作成する必要があります。

分散負荷テストを実行することは、アプリケーションがスケーラブルであることを証明する優れた方法です。コードをデプロイしたら、プラットフォームを継続的に監視して、CPU とメモリの制限を超えないようにし、エラーを追跡します。

レッスン5: パフォーマンスを最適化する

エッジ コンピューティングの主な利点は、データとコンピューティング リソースをユーザーの近くに移動することで、レイテンシを大幅に削減できることです。数百または数千のプレゼンス ポイント (PoP) に拡張する場合、この利点を実現するには、軽量で効率的なコードを作成することが重要です。機能を完了するために必要なデータもエッジにある必要があります。集中型データ ストアからデータを取得する必要があるコードを開発すると、エッジがもたらすレイテンシのメリットが無効になります。

効率的な実行に対する同様の重点は、エッジ アプリケーションで使用する可能性のあるサードパーティ コードにも適用されます。既存のコード ベースの中には非効率なものがあり、パフォーマンスを低下させたり、エッジ プラットフォームの CPU やメモリの制限を超えたりするものがあります。したがって、展開されたエッジ環境にコードを組み込む前に、慎重に評価する必要があります。

教訓6: 車輪の再発明はしない

エッジは新しいパラダイムですが、すべてをゼロからコーディングする必要があるわけではありません。ほとんどのエッジ プラットフォームはさまざまなコンテンツ配信ネットワーク (CDN) 機能と統合されており、キャッシュなどの既存の CDN 機能を表す出力を生成するカスタム ロジックを作成できます。

また、エッジコンピューティング環境と集中型コンピューティング環境の両方でコードを実行できるように、再利用性を確保するようにコードを構造化することもお勧めします。コア機能を、ブラウザ、Node.JS、または特定のプラットフォーム機能に依存しないライブラリに抽出することで、コードを「同型」にし、クライアント、サーバー、エッジで実行できるようになります。

既存のオープンソース ライブラリを使用することは、共通機能の書き換えを回避するもう 1 つの方法です。ただし、Node.JS またはブラウザ機能を必要とするライブラリには注意してください。また、使用しているエッジ プラットフォームと統合する製品を開発するサードパーティの開発者と協力することも検討してください。これにより、実証済みの相互運用性の利点を享受しながら、時間と労力を節約できます。

経験を実践する

これらのベスト プラクティスの影響を説明するために、実際の例を考えてみましょう。ある組織がエッジでジオフェンシング アプリケーションを実装するのに苦労していました。組織は、CPU とメモリに関してプラットフォームの制限を超えたために、高いエラー率に直面していました。

組織がアプリケーションを構築した方法を見ると、すべてのジオフェンス ゾーンのデータが、各エッジ PoP に 900 KB の JSON として保存されています。各ジオフェンスでは、CPU を集中的に使用するアルゴリズムを使用して関心ポイントがチェックされ、チェックされた最初の数エリアで関心ポイントが見つからない場合は CPU タイムアウトがトリガーされます。

これを修正するために、各ジオフェンス領域のデータはキー値ストア (KVS) システムに移動され、各領域は個別のエントリに保存されます。特定の関心ポイントが存在する可能性がある「候補領域」(通常は 1 ~ 3 つの候補) を識別するための軽量チェックが追加されました。完全なデータと CPU を集中的に使用するチェックは候補領域に対してのみ実行されるため、CPU のワークロードが大幅に削減されます。これらの変更により、次の図に示すように、エラー率が無視できるレベルまで低下し、初期化時間も短縮され、メモリ使用量も削減されました。

図 1: 成功率とエラー率の前後の比較 (成功とエラーの指標は異なるスケールであるため、直接比較することはできません)

図2: 初期化前後の時間の比較

図 3: 比較前後のメモリ使用量。 (画像提供: Akamai)

エッジを活用する

エッジ コンピューティングは、ユーザーに近いことから恩恵を受けるアプリケーションに多大な利点を提供し、速度と効率だけでなく、パーソナライズされたユーザー エクスペリエンスももたらします。成功の鍵は、アプリケーションがエッジに適合していることを確認し、制約を超えずにエッジ プラットフォームの機能を最大限に活用できるようにコードを最適化することです。

複数の組織と連携して私が学んだことに注意を払えば、頭を悩ませることなく、エッジのメリットをより早く最大限に享受できるようになります。

原題:エッジのためのコーディング: 成功のための 6 つの教訓​​​、著者: ジョシュ・ジョンソン

<<:  マルチクラウドが現実のものとなりました。マルチクラウド管理をより適切に実現するにはどうすればよいでしょうか?

>>:  クラウドネイティブデータ管理の謎を解く: 運用レイヤー

推薦する

ウェブサイトのキーワードパフォーマンス分析: ランキング表示とトラフィッククリック

みなさんこんにちは。私はMuzi Chengzhouです。ウェブサイトの最適化とプロモーションでは、...

クラウドサービスプロバイダーFastlyの障害により数千のウェブサイトが麻痺したが、現在は復旧している。

海外メディアは、米国のクラウドコンピューティング企業ファストリーが8日、1時間にわたる大規模なサービ...

serverhub-Seattle 512Mメモリ OVZ 簡易評価

ServerHub が実は密かにいくつかのコンピュータ ルームを追加したことに気づいていないかもしれ...

2020 年のクラウド移行の最大の課題

クラウド コンピューティングの人気は高まり続けていますが、競争で優位に立つためには、2020 年にク...

17 の側面、4 つの分散メッセージ キュー (Kafka、RabbitMQ、RocketMQ、ActiveMQ) の包括的な比較

1. データの文書化2. 開発言語3. サポートされているプロトコル4. メッセージの保存5. ニュ...

2020年第4四半期のクラウドインフラ支出は400億ドルに迫る

Canalys の新しいデータによると、クラウド インフラストラクチャへの支出は 2020 年第 4...

#618# ufovps: すべての VPS が 20% オフ、最大 20% 追加、香港、日本、米国のデータ センター、複数の回線

ufovps は毎年恒例の年中特別プロモーションを実施し、すべての VPS サービスが 20% オフ...

friendhosting: ロサンゼルスデータセンターのVPSの簡単なレビュー、実際のデータの共有

Friendhosting は比較的長い歴史を持つ VPS 業者と言えますが、全体的にはまだ知名度は...

百度の大型アップデートが6つの業界に与える影響を推測する

今回、Baiduの6.22と6.28のアップデートと調整(まだ停止していない)は、中小規模のウェブマ...

kazila 7 USD/月 512M メモリ xen kvm vps

Kazila は、米国テキサス州に登録され、XEN と KVM ベースの VPS を提供する、数年の...

Baidu のアルゴリズムは「常に変化」しています。ウェブマスターはどうすれば素早く適応できるでしょうか?

ウェブマスターが何かを投稿するたびに、管理者がそれを常に「広告ジャンク」と見なすのはなぜでしょうか。...

ウェブサイトは21日前にKから復旧されました

百度6月28日の事件以来、多くのウェブサイトがブロックされている。私のウェブサイトもその一つで、完全...

123systems の新しい XEN VPS が初年度半額で販売中

正直に言うと、123systems の openvz はあまり理想的ではありません。 過剰販売などの...

クラウドベースの新しい通信シナリオ:ファーウェイクラウドカンファレンスが世界を手の届く範囲に

ハーバード・ビジネス・レビューは2018年に、CEOがどのように時間を管理しているかを具体的に調査し...