Aplikasi seluler Anda berjalan dengan baik dalam pengujian lokal. Pengguna di London membukanya dan semuanya terasa cepat. Pengguna di Tokyo membukanya versi yang sama dan mengeluh bahwa startupnya lambat, update memakan waktu lama, dan beberapa konten terasa tertunda. Anda tidak mengubah aplikasi untuk satu wilayah dan tidak untuk wilayah lain. Perbedaan itu jaraknya.
Jadi, itulah 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 memerlukan untuk memasukkan perbaikan JavaScript, copy yang diperbarui, atau perubahan aset kecil. Beberapa pengguna mendapatkannya dengan cepat. Lainnya harus menunggu lebih lama, mencoba ulang, atau mengalami timeout tergantung pada lokasi mereka dan jarak permintaan yang harus ditempuh. 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 Pengolahan Edge
- Keuntungan Utama untuk Aplikasi Anda
- Penggunaan Kasus Nyata Jaringan Edge
- Cara Menerapkan Strategi Jaringan Edge
Mengapa Aplikasi Anda Cepat di London tapi Lambat di Tokyo
Seorang pengguna mengetuk ikon aplikasi di London. Aplikasi memeriksa konfigurasi yang segar, menarik 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.
Suatu jaringan edge mengatasi masalah ini dengan memindahkan pengaturan jaringan dan pemrosesan 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 menjelaskan bahwa jaringan edge adalah arsitektur distribusi yang memindahkan fungsi komputasi, penyimpanan, dan pengaturan jaringan dari pusat 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
Jangan lagi infrastruktur yang spesifik. 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 diperkirakan 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 bukanlah 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 kehadiran 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 lebih sedikit perjalanan jauh melalui internet.Jaringan edge Gudang atau toko retail lokalGudang utama
Diagram jaringan edge dengan pusat data, node edge, dan perangkat pengguna akhir
Ini berlaku juga untuk pembaruan. Jika aplikasi Anda memeriksa bundle web baru, file konfigurasi, atau paket aset pada saat peluncuran, setiap perjalanan tambahan akan muncul dalam perilaku startup. Tim yang memantau hal ini biasanya mendapatkan manfaat dari mengatur pengawasan kinerja di aplikasi __CAPGO_KEEP_0__ performance monitoring in Capacitor apps Penyimpanan cache, routing, dan pengolahan lokal
Tiga bagian ini membuat model terlihat jelas bagi sebagian besar pengembang:
Penyimpanan cache menyimpan konten yang sering digunakan di dekatnya.
- Jika banyak pengguna meminta aset aplikasi atau paket pembaruan yang sama, lokasi edge dapat menyimpan salinan yang siap di tempatnya 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 awan utama terlibat.
- Termasuk dapat mencakup penyaringan, pengecekan autentikasi, pengolahan permintaan, atau mempersiapkan data sebelumnya bergerak ke atas. Aturan praktis:
__CAPGO_KEEP_0__ Jika hal yang sama diminta berulang kali oleh pengguna di banyak tempat, kemungkinan besar tidak harus diambil dari 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.
Awak di awan tidak menghilang. Awak di awan menjadi gudang utama, sementara lokasi edge menjadi toko-toko dekat yang menghilangkan jarak dari pengalaman pengguna.
Jaringan Edge vs CDN vs Pengolahan Edge
Ketiga istilah ini sering kali tercampur aduk dan kebingungan adalah wajar karena mereka saling melengkapi dalam produk nyata.
Seorang pengembang mendengar bahwa vendor memiliki 'pengiriman edge', 'pengolahan 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, dan menjelaskan bahwa dengan memproses data di server edge sebelum mencapai awan pusat, jaringan edge memungkinkan beban kerja yang sensitif terhadap latensi seperti analisis waktu nyata dan inferensi AI dalam penjelasannya tentang jaringan edge dan penurunan penundaan.
Perbedaan ini penting bagi tim aplikasi:
- Jika Anda ingin pengiriman gambar atau bundle yang lebih cepat, Anda mungkin hanya memerlukan caching gaya CDN.
- Jika Anda ingin pengelolaan permintaan atau pengambilan keputusan yang 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 membicarakan jaringan edge.
Jika Anda bekerja pada perilaku rilis, jalur startup, atau waktu permintaan, koleksi artikel ini tentang kinerja jaringan untuk tim aplikasi merupakan topik yang berguna untuk disertai. Panduan Cepat: Jaringan Edge vs. CDN vs. Komputasi Edge
Atribut
| Jaringan Edge | CDN (Jaringan Pengiriman Konten) | Komputasi Edge | Tugas Utama |
|---|---|---|---|
| Pindahkan fungsi jaringan lebih dekat dengan pengguna dan perangkat | Jika Anda ingin pengelolaan permintaan atau pengambilan keputusan yang lebih dekat dengan pengguna, Anda masuk ke wilayah komputasi edge. | 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 yang terdistribusi di dekat pengguna | Di lokasi cache yang terdistribusi | Di server edge atau perangkat di dekat sumber |
| Model mental terbaik | Sistem jalan dan titik masuk yang dekat | Shelf lokal dengan barang populer yang sudah tersedia | Pekerja lokal yang mengelola tugas di lokasi |
| Apa yang diketahui pengembang mobile | Penundaan yang lebih rendah di seluruh jalur permintaan | Muatan aset yang lebih cepat dan download | Keputusan yang lebih cepat tanpa harus memanggil asal |
CDN dapat menjadi bagian dari strategi edge, tapi tidak secara otomatis berarti aplikasi Anda melakukan komputasi edge.
Kalimat itu saja 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-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 Kbps, atau sekitar 2 hingga 3 kali lebih cepat dibandingkan dengan 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.
Lebih tahan lama ketika jaringan menjadi berantakan
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 padat 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 lebih dekat sering memberikan pengguna kesempatan yang lebih baik untuk mendapatkan apa yang mereka butuhkan tanpa perlu melakukan perjalanan jauh ke inti.
Langkah selanjutnya yang baik adalah untuk memeriksa daftar periksa optimasi kinerja aplikasi Anda sendiri dan tandai bagian yang sebenarnya adalah masalah jarak jaringan bukan masalah __CAPGO_KEEP_0__. 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 masuk. Ini dapat membantu menghentikan beberapa lalu lintas yang tidak diinginkan sebelum mencapai sistem inti.
Tinggalkan pekerjaan sederhana di dekat pengguna, dan jangan biarkan sistem sumber yang sensitif untuk menangani setiap permintaan secara langsung.
Artinya tidak berarti jaringan edge secara ajaib membuat aplikasi aman. Ini berarti Anda dapat menempatkan perlindungan lebih awal di jalur dan mengurangi radius ledakan pada sistem inti.
Tidak berarti jaringan edge secara ajaib membuat aplikasi aman. Ini berarti Anda dapat menempatkan perlindungan lebih awal di jalur dan mengurangi radius ledakan pada sistem inti.
Kasus Penggunaan Jaringan Edge di Dunia Nyata
Mengapa Jaringan Edge Harus Ada?
Menggunakan produk yang sudah ada di sekitar kita setiap hari adalah cara termudah untuk menjadikan jaringan edge menjadi nyata.
Seorang pria duduk di sofa sambil menonton pemandangan gunung di layar televisi yang dipasang di dinding.
Platform streaming video bergantung pada pengiriman yang dekat sehingga pengguna dapat memulai pemutaran video dengan cepat dan menghindari buffering. Perpustakaan 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. Semakin jauh jalur jaringan, semakin buruk perasaan delay tersebut.
Contoh-contoh tersebut membantu karena mereka dapat dilihat. Anda dapat merasakan manfaatnya langsung ketika video dimulai lebih cepat atau permainan terasa lebih responsif.
Mengapa pembaruan aplikasi mobile adalah masalah edge?
Pembaruan aplikasi mobile kurang jelas, tetapi masalah arsitektur yang sama ada di sana.
Ketika aplikasi Anda memeriksa pembaruan live, mengunduh aset web yang berubah, memverifikasinya, dan menerapkannya pada peluncuran berikutnya, jalur pembaruan menjadi bagian dari kualitas produk. Pengguna tidak peduli apakah delay datang dari ukuran paket, geografi jaringan, atau kongesti asal. Mereka hanya tahu bahwa perbaikan tidak datang ketika mereka membutuhkannya.
A contoh nyata adalah Capgoyang mengirimkan 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 memadupadankan itu dengan pembaruan waktu nyata menggunakan segmentasi pengguna untuk menghindari mengirimkan setiap rilis ke setiap pengguna sekaligus.
A walkthrough singkat membantu memvisualisasikan di mana pengiriman edge masuk dalam alur rilis:
Ketika perbaikan kecil tetapi sangat penting, jalur jaringan ke pengguna sangat penting hampir sebanding dengan perbaikan itu sendiri.
Itu jawaban yang berfokus pada pengembang yang paling umum artikel edge tidak menyebutkan. Jaringan edge tidak hanya tentang skenario IoT masa depan. Mereka menyelesaikan masalah mobile yang sangat biasa: mengirimkan pembaruan yang tepat ke pengguna yang tepat dengan cepat, di mana saja pengguna itu berada.
Bagaimana Menerapkan Strategi Edge
Pemilihan strategi edge dimulai dengan botol leher aplikasi, bukan dengan pemasaran vendor. Jika masalah utama adalah pengiriman aset statis yang lambat, pendekatan yang fokus pada caching mungkin sudah cukup. Jika masalahnya adalah delay permintaan, ketidakkonsistenan regional, atau keandalan pembaruan hidup, Anda mungkin memerlukan pengaturan edge yang lebih luas.
Apa 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 pengguna Anda, bukan hanya di tempat 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 observabilitas 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 netral.
Proses seleksi yang baik dimulai dengan beberapa pertanyaan konkrit:
- Dimana pengguna kami yang paling lambat tinggal?
- Permintaan mana yang terjadi pada saat aplikasi dijalankan?
- 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 setiap 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, pengurangan latency mungkin tidak membenarkan biaya pengelolaan arsitektur terdistribusi, seperti yang dibahas dalam entri kamus Akamai tentang apa itu jaringan edge dan apa yang bukan apa itu jaringan edge dan apa yang bukan.
Kenyataan itu memang berguna.
Jika aplikasi Anda melayani audiens geografis yang terbatas, 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 membutuhkan untuk mengirimkan perbaikan JavaScript, CSS, konfigurasi, salinan, atau aset tanpa menunggu ulasan toko aplikasi, Capgo adalah salah satu pilihan yang dibangun untuk alur kerja itu. Ia menggunakan bundel web yang ditandatangani, pengiriman melalui saluran, perlindungan rollback, dan pengiriman edge untuk membantu tim mengirimkan perubahan terkendali ke pengguna pada peluncuran berikutnya.
