Aplikasi seluler Anda berjalan dengan baik dalam pengujian lokal. Pengguna di London membukanya dan semuanya terasa cepat. Pengguna di Tokyo membuka versi yang sama dan mengeluh bahwa startup terasa lambat, update memakan waktu lama, dan beberapa konten terasa tertunda. Anda tidak mengubah aplikasi untuk satu wilayah dan tidak untuk wilayah lain. Perbedaan itu jarak.
Yaitu alasan praktis mengapa pengembang akhirnya bertanya Apa itu Jaringan Edge. Bukan karena mereka ingin mencari buzzword baru, tetapi karena aplikasi global mengekspos batasan mengirim setiap permintaan, aset, dan pembaruan kembali ke satu tempat yang jauh.
Bagi tim mobile, hal ini menjadi sangat menyakitkan selama proses rilis. Anda perlu memasukkan perbaikan JavaScript, copy yang diperbarui, atau perubahan kecil pada aset. Beberapa pengguna mendapatkannya dengan cepat. Lainnya harus menunggu lebih lama, mencoba lagi, atau mengalami timeout tergantung di mana mereka berada dan berapa jauh permintaan harus perjalanan. Jaringan edge ada untuk mengurangi celah tersebut.
Daftar Isi
- Mengapa Aplikasi Anda Cepat di London tapi Lambat di Tokyo
- Arsitektur Utama dari Jaringan Edge
- Jaringan Edge vs CDN vs Penghitungan Edge
- Keuntungan Utama untuk Aplikasi Anda
- Penggunaan Kasus Nyata Jaringan Edge
- Cara Menerapkan Strategi Edge
Mengapa Aplikasi Anda Cepat di London tapi Lambat di Tokyo
Seorang pengguna mengetuk ikon aplikasi di London. Aplikasi memeriksa konfigurasi yang lebih baru, mengunduh beberapa aset, dan melanjutkan. Seorang pengguna di Tokyo melakukan hal yang sama, tetapi setiap permintaan harus berjalan lebih jauh untuk mencapai infrastruktur Anda. Bahkan jika setiap permintaan hanya terasa sedikit lebih lambat, aplikasi seluler sering membuat beberapa permintaan secara berurutan. Itu ketika pengguna mulai menggambarkan aplikasi sebagai “lambat secara acak.”
Konsep yang hilang adalah latensi jaringan. Jika Anda ingin refresher yang lebih praktis, panduan ini tentang latensi jaringan di aplikasi mobile menghubungkan ide langsung ke perilaku pengembang aplikasi yang di-debug.
Sebuah jaringan edge mengatasi masalah ini dengan memindahkan pengolahan dan jaringan yang lebih dekat ke lokasi pengguna. Sebaliknya dari memaksa setiap perangkat untuk berbicara dengan satu asal yang jauh, sistem dapat melayani permintaan dari lokasi yang lebih dekat. Intel mendeskripsikan jaringan edge sebagai arsitektur distribusi yang memindahkan fungsi komputasi, penyimpanan, dan jaringan dari awal cloud ke titik kehadiran geografis yang lebih dekat, mengurangi jarak data yang harus ditempuh untuk setiap permintaan, seperti yang dijelaskan dalam ringkasan Intel tentang arsitektur jaringan edge.
Mengapa hal ini lebih penting sekarang
Hal ini bukan infrastruktur khusus lagi. Proyeksi satu menunjukkan bahwa pada 2025, 75% dari data yang dihasilkan oleh perusahaan akan dibuat dan diproses di luar pusat data sentral atau clouddan pasar komputasi tepi diproyeksikan akan tumbuh dari $47,0 miliar pada tahun 2023 ke $171,0 miliar pada tahun 2031menurut proyeksi industri komputasi tepi.
Pengguna Anda tidak mengalami "arsitektur." Mereka mengalami menunggu, ulang coba, dan perilaku tidak konsisten oleh wilayah.
Untuk seorang pengembang mobile, itu berarti aturan sederhana. Jika aplikasi Anda memiliki pengguna global, sistem rilis, aset, dan jalur pembaruan perlu berperilaku global juga. Jika tidak, aplikasi Anda hanya cepat untuk orang-orang yang beruntung tinggal dekat infrastruktur Anda.
Arsitektur Inti dari Jaringan Tepi
Cara termudah untuk memahami jaringan tepi adalah dengan berhenti berpikir tentang server dan mulai berpikir tentang logistik.
Konfigurasi cloud tradisional bekerja seperti gudang pusatSemua hal berada di gudang utama satu. Tidak peduli di mana pelanggan berada, setiap pesanan dikirim dari lokasi tersebut. Itu sederhana untuk dikelola, tetapi bukan ide yang ideal ketika pelanggan tersebar di berbagai benua.
Jaringan edge terlihat lebih seperti sistem gudang atau toko retail lokal. Gudang utama masih ada, tetapi barang-barang umum dan beberapa operasi lokal terjadi lebih dekat ke pelanggan.Cloud sentral versus titik-titik kehadiran yang lebih dekat
Diagram yang menggambarkan arsitektur jaringan edge dengan pusat data, node edge, dan perangkat pengguna akhir.
Mereka adalah tempat-tempat yang terdistribusi secara geografis di mana lalu lintas dapat diterima, diproses, dilindungi, dan kadang-kadang disimpan sebelum perlu menghubungi sistem inti. Untuk aplikasi mobile, itu berarti pengguna di Jepang tidak selalu perlu menunggu infrastruktur yang berada di Eropa atau Amerika Utara. Permintaan mereka dapat memasuki jaringan di titik yang lebih dekat dan diproses dengan perjalanan yang lebih singkat di internet.Jaringan edge terlihat lebih seperti sistem gudang atau toko retail lokal. Titik kehadiran atau PoPDiagram yang menggambarkan arsitektur jaringan edge dengan pusat data, node edge, dan perangkat pengguna akhir.
Titik kehadiran atau PoP, atau PoP
Perlu diingat juga untuk pembaruan. Jika aplikasi Anda memeriksa bundle web baru, file konfigurasi, atau paket aset pada saat peluncuran, setiap putaran tambahan akan terlihat dalam perilaku startup. Tim yang memantau hal ini biasanya mendapatkan manfaat dari mengatur pemantauan kinerja di aplikasi __CAPGO_KEEP_0__ performance monitoring in Capacitor apps Penyimpanan cache, routing, dan pengolahan lokal
Tiga bagian ini membuat modelnya terlihat bagi sebagian besar pengembang:
Penyimpanan cache menyimpan konten yang sering digunakan di dekatnya.
- Jika banyak pengguna meminta aset aplikasi atau paket update yang sama, lokasi edge dapat menyimpan salinan siap sedia daripada mengambilnya dari asal setiap kali. Routing mengirim pengguna ke titik masuk terdekat.
- Pikirkan itu sebagai pengatur lalu lintas. Jaringan mencoba menghindari mengirim pengguna ke jalur yang panjang atau sibuk ketika ada jalur yang lebih dekat. Pengolahan lokal menangani pekerjaan sederhana sebelum cloud utama terlibat.
- Termasuk filter, pengecekan autentikasi, pengolahan permintaan, atau mempersiapkan data sebelumnya bergerak ke atas. Aturan praktis:
Perlu diingat juga untuk pembaruan. Jika aplikasi Anda memeriksa bundle web baru, file konfigurasi, atau paket aset pada saat peluncuran, setiap putaran tambahan akan terlihat dalam perilaku startup. Tim yang memantau hal ini biasanya mendapatkan manfaat dari mengatur pemantauan kinerja di aplikasi __CAPGO_KEEP_0__ untuk membandingkan wilayah daripada hanya bergantung pada tes lokal saja. Jika hal yang sama diminta berulang kali oleh pengguna di banyak tempat, kemungkinan besar tidak perlu diambil dari satu asal yang jauh untuk setiap permintaan.
Jawaban inti dari 'apa itu jaringan edge' dalam bahasa Inggris yang sederhana. Ini adalah cara distribusi untuk menempatkan fungsi jaringan lebih dekat ke pengguna sehingga permintaan umum selesai lebih cepat dan dengan kemungkinan gagal yang lebih sedikit.
Awan tidak menghilang. Awan menjadi gudang utama, sementara lokasi edge menjadi toko-toko dekat yang menghilangkan jarak dari pengalaman pengguna.
Jaringan Edge vs CDN vs Penghitungan Edge
Tiga istilah ini sering kali tercampur aduk dan kebingungan adalah wajar karena mereka berlapis di produk nyata.
Seorang pengembang mendengar bahwa vendor memiliki 'pengiriman edge', 'penghitungan edge', dan 'CDN global', dan semuanya terdengar seperti hal yang sama. Tidak.
Dimana pengembang biasanya mengacaukannya
A CDN biasanya konsep yang paling mudah. Tugasnya utamanya adalah mencache dan mengirimkan konten seperti gambar, file JavaScript, stylesheet, segment video, dan aset yang dapat diunduh dari lokasi yang dekat dengan pengguna.
Komputasi Edge adalah lebih luas. Artinya menggunakan logika aplikasi atau pengolahan data di dekat pengguna atau perangkatbukan hanya menyimpan file cache di sana.
Jenis jaringan edge adalah lapisan koneksi distribusi dasar yang membuat pola-pola ini mungkin. Neos Networks menjelaskan efek utama kinerja sebagai penundaan akhir-ke-akhir yang lebih rendahdan menjelaskan bahwa dengan memproses data di server edge sebelum mencapai awan utama, jaringan edge memungkinkan beban kerja yang sensitif terhadap latency seperti analisis waktu nyata dan inferensi AI dalam penjelasannya tentang jaringan edge dan penurunan penundaan.
Hal ini penting bagi tim aplikasi:
- Jika Anda ingin mendapatkan pengiriman gambar atau bundle yang lebih cepat, Anda mungkin hanya memerlukan caching jenis CDN.
- Jika Anda ingin pengelolaan permintaan atau pengambilan keputusan lebih dekat dengan pengguna, Anda masuk ke wilayah komputasi edge.
- Jika Anda ingin jalur seluruhnya lebih dekat geografis dan memiliki latensi yang lebih rendah, Anda sedang berbicara tentang jaringan edge.
Jika Anda bekerja pada perilaku rilis, jalur startup, atau waktu permintaan, koleksi artikel ini tentang performa jaringan untuk tim aplikasi adalah topik yang berguna untuk dipelajari.
Edge Network vs. CDN vs. Komputasi Edge pada Pandangan Umum
| Sifat | Jaringan Edge | CDN (Jaringan Pengiriman Konten) | Komputasi Edge |
|---|---|---|---|
| Tugas Utama | Pindahkan fungsi jaringan lebih dekat dengan pengguna dan perangkat | Cache dan distribusikan konten secara efisien | Jalankan code atau proses data di dekat pengguna atau perangkat |
| Beban kerja biasa | Routing permintaan, pengelolaan lalu lintas, layanan jaringan lokal | Aset statis, file yang dapat diunduh, pengiriman media | Logika API, penyaringan, inferensi, proses waktu nyata |
| Di mana pekerjaan terjadi | Di titik-titik distribusi yang dekat dengan pengguna | Di lokasi cache yang terdistribusi | Di server edge atau perangkat yang dekat dengan sumber |
| Model mental terbaik | Jaringan jalan dan titik masuk yang dekat | Rakitan lokal dengan barang populer yang sudah disediakan | Pekerja lokal yang mengelola tugas di lokasi |
| Apa yang diketahui pengembang mobile | Penundaan yang lebih rendah di seluruh jalur permintaan | Pemuatan aset yang lebih cepat dan download | Keputusan yang lebih cepat tanpa harus selalu menghubungi asal |
CDN dapat menjadi bagian dari strategi edge, tapi tidak secara otomatis berarti aplikasi Anda melakukan komputasi edge.
Kalimat itu satu-satunya yang dapat menghilangkan banyak perdebatan arsitektur.
Manfaat Utama untuk Aplikasi Anda
Saat arsitektur terpaham, manfaat menjadi lebih mudah untuk dinilai. Anda tidak membeli 'edge' sebagai label. Anda memilih cara untuk mengurangi jarak, menghilangkan perjalanan putar yang tidak perlu, dan menjaga aplikasi tetap dapat digunakan ketika jaringan tidak sempurna.
Respons yang lebih cepat yang dapat dirasakan pengguna
IBM mendeskripsikan jaringan edge sebagai memindahkan banyak tugas komputasi dari proses pusat data ke perangkat edge, meningkatkan kecepatan, bandwidth, dan keandalan dengan mengurangi latensi. Contoh IBM mencatat kecepatan download mencapai 384 Kbpsatau sekitar 2 hingga 3 kali lebih cepat dibandingkan jaringan reguler untuk skenario tersebut, seperti yang dijelaskan dalam penjelasan IBM tentang bagaimana jaringan edge meningkatkan kecepatan.
Untuk aplikasi mobile, pengguna tidak berpikir dalam Kbps. Mereka berpikir dalam momen:
- Splash screen menghilang lebih cepat.
- Pengecekan update selesai tanpa menunggu dengan tidak nyaman.
- Aplikasi terasa lebih stabil pada jaringan lemah.
- Patch kecil datang sebelum tiket dukungan menumpuk.
Jika tim Anda mencoba mengirimkan aplikasi full-stack dengan cepatJadi, membantu mengingat bahwa kecepatan pengiriman bukan hanya masalah alur kerja pengembang. Ini juga masalah jalur infrastruktur.
Ketahanan yang lebih baik ketika jaringan menjadi kacau
Sistem yang terdistribusi dapat terus melayani lalu lintas bahkan ketika satu jalur atau lokasi mengalami masalah. Dalam prakteknya, itu berarti pengguna tidak terlalu bergantung pada satu asal jauh yang dapat dijangkau, cepat, dan tidak terlalu sibuk pada setiap saat.
Untuk tim aplikasi, hal ini muncul selama jendela rilis dan tanggapan insiden. Jika Anda membutuhkan untuk mendistribusikan aset yang diperbarui atau konfigurasi global, lokasi edge yang dekat sering memberikan pengguna kesempatan yang lebih baik untuk mendapatkan apa yang mereka butuhkan tanpa perlu melakukan perjalanan panjang kembali ke inti.
Langkah selanjutnya yang baik adalah untuk memeriksa daftar periksa optimasi kinerja aplikasi Anda sendiri dan tandai bagian yang benar-benar masalah jarak jaringan bukan __CAPGO_KEEP_0__ masalah. and mark the parts that are really network-distance problems rather than code problems.
Jaringan edge juga dapat meningkatkan posisi keamanan karena filtering dan penindakan dapat terjadi lebih dekat ke tempat lalu lintas memasuki. Hal ini dapat membantu menghentikan beberapa lalu lintas yang tidak diinginkan sebelum mencapai sistem inti.
Tinggalkan pekerjaan sederhana dekat pengguna, dan jangan biarkan sistem sumber yang sensitif menghandle setiap permintaan secara langsung.
Jangan berpikir bahwa jaringan edge dapat membuat aplikasi aman secara ajaib. Artinya Anda dapat menempatkan proteksi lebih awal di jalur dan mengurangi radius ledakan pada sistem inti.
__CAPGO_KEEP_0__
Kasus Nyata Penggunaan Jaringan Edge
Mengapa Jaringan Edge Perlu Diketahui
Jaringan Edge yang Paling Mudah Diterima
Platform streaming video bergantung pada pengiriman yang dekat sehingga pengguna dapat memulai pemutaran video dengan cepat dan menghindari buffering.
Kolaborasi konten utama mungkin dikonsentrasikan, tetapi konten populer didistribusikan lebih dekat ke pengguna.
Permainan online memiliki masalah yang sama dengan gejala yang berbeda. Sebaliknya, pemain mengalami lag, reaksi yang tertunda, atau perilaku multiplayer yang tidak konsisten.
Jarak jaringan yang lebih jauh, semakin buruk perasaan delay tersebut.
Contoh-contoh tersebut membantu karena mereka dapat dirasakan langsung. Ketika video dimulai lebih cepat atau permainan terasa lebih responsif, manfaatnya dapat dirasakan langsung.
Mengapa Perbarui Aplikasi Seluler adalah Masalah Edge
Perbarui aplikasi seluler kurang jelas, tetapi masalah arsitektur yang sama ada di sana juga.
Akan menjadi contoh nyata adalah CapgoMengirimkan pembaruan hidup untuk aplikasi CapacitorJS dan Electron melalui jaringan edge global dan memungkinkan tim untuk menerbitkan paket web yang ditandatangani, saluran target, dan menerapkan perbaikan tanpa menunggu tinjauan toko aplikasi. Tim yang bekerja pada peluncuran terkendali dapat memadukan itu dengan pembaruan waktu nyata menggunakan segmentasi pengguna untuk menghindari mengirimkan setiap rilis ke setiap pengguna sekaligus.
Ayunan cepat membantu memvisualisasikan di mana pengiriman edge masuk dalam alur rilis:
Ketika perbaikan kecil tetapi sangat mendesak, jalur jaringan ke pengguna sangat penting hampir sebanding dengan perbaikan itu sendiri.
Itu jawaban pengembang yang paling umum tentang edge artikel yang tidak menyentuh masalah mobile yang sangat biasa: mendapatkan pembaruan yang tepat ke pengguna yang tepat dengan cepat, di mana saja pengguna itu berada.
Bagaimana Menerapkan Strategi Edge
Mengambil strategi edge dimulai dengan kelemahan aplikasi Anda, bukan dengan pemasaran vendor. Jika kelemahan utama adalah pengiriman aset statis yang lambat, pendekatan yang fokus pada caching mungkin sudah cukup. Jika kelemahan utama adalah delay permintaan, ketidakkonsistenan regional, atau keandalan pembaruan hidup, Anda mungkin memerlukan setup edge yang lebih luas.
Apakah yang harus dievaluasi sebelum memilih penyedia
Gunakan daftar singkat yang secara langsung terkait dengan perilaku aplikasi Anda:
- Jejak geografis: Penyedia Anda harus memiliki layanan di tempat-tempat di mana pengguna Anda berada, bukan hanya di tempat di mana tim Anda berbasis.
- Pengelolaan lalu lintas: Cari routing, caching, dan kontrol pengiriman yang sesuai dengan beban kerja Anda. Aset aplikasi, API panggilan, dan paket pembaruan tidak semua berperilaku sama.
- Model keamanan: Cek bagaimana penyedia mengelola kontrol akses, enkripsi, kebutuhan kompatibilitas, dan penyaringan sisi edge.
- Kemampuan pengawasan operasional: Anda membutuhkan log, metrik, dan kemampuan observasi yang cukup untuk menjelaskan mengapa satu wilayah lebih lambat dari yang lain.
- Alur kerja pengembang: API, integrasi CI/CD, kontrol rollback, dan target versi berpengaruh sebanding dengan desain jaringan yang murni.
Proses seleksi yang baik dimulai dengan beberapa pertanyaan konkrit:
- Dimana pengguna kami yang paling lambat tinggal?
- Permintaan mana yang terjadi pada saat aplikasi startup?
- Apa yang dapat disimpan di cache dengan aman?
- Bagian mana yang harus kembali ke asal?
- Bagaimana cara debug masalah pengiriman regional?
Ketika Edge bukanlah jawaban yang tepat
Tidak semua aplikasi memerlukan infrastruktur edge yang terdistribusi. Akamai menyebutkan bahwa istilah “edge” dapat menjadi kaburdan bahwa itu bukanlah senjata ajaib . Kasus bisnis bergantung pada beban kerja, kompleksitas operasional, dan pengelolaan, dan untuk beberapa aplikasi, peningkatan latency mungkin tidak membenarkan biaya pengelolaan arsitektur terdistribusi, seperti yang dibahas dalam entri kamus Akamai tentangapa itu jaringan edge dan apa yang bukan Apa itu jaringan edge dan apa yang bukan.
Kenyataan itu sangat berguna.
Jika aplikasi Anda melayani audiens geografis yang sempit, memiliki aktivitas jaringan startup yang sedikit, atau tidak bergantung pada pengiriman aset dan update yang cepat, edge mungkin menambah kompleksitas tanpa cukup imbalan. Lebih banyak lokasi berarti lebih banyak bagian yang bergerak. Lebih banyak bagian yang bergerak berarti lebih banyak keputusan tentang perilaku cache, konsistensi pengiriman, kebijakan keamanan, dan pemantauan.
Pertanyaan yang tepat bukanlah 'Apakah kita harus menggunakan edge karena aplikasi modern?' Tapi 'Mana permintaan yang saat ini terlalu jauh dari pengguna, dan apakah mengurangi jarak itu bernilai biaya operasional?'
Jika tim Anda mengirimkan aplikasi CapacitorJS atau Electron dan perlu mengirimkan perbaikan JavaScript, CSS, konfigurasi, salinan, atau aset tanpa menunggu tinjauan toko aplikasi, Capgo Jika Anda ingin mengirimkan perbaikan ke pengguna tanpa menunggu tinjauan toko aplikasi, Capgo adalah salah satu pilihan yang dibuat untuk itu. Capgo menggunakan bundle web yang ditandatangani, pengiriman melalui saluran, perlindungan rollback, dan pengiriman edge untuk membantu tim mengirimkan update yang terkendali ke pengguna pada peluncuran berikutnya.
