Aplikasi bisa terasa lambat meskipun koneksi internet sudah cepat. Data tetap perlu melewati jaringan, lalu diproses di server sebelum hasilnya muncul di layar. Karena itu, latency jaringan dan cara aplikasi mengolah permintaan ikut menentukan berapa lama kita harus menunggu.
Saat berbelanja online, misalnya, gambar produk bisa cepat terbuka sementara halaman pembayaran masih loading. Keduanya ada di aplikasi yang sama, tetapi proses di baliknya bisa berbeda. Dalam artikel ini, kita akan mengenal latency, memahami cara kerja CDN dan peran edge computing, serta melihat bagaimana arsitektur cloud memengaruhi kecepatan respons aplikasi.
Table of Contents
Apa itu Latency & Apa Bedanya dengan Bandwidth?
Latency adalah waktu yang dibutuhkan data untuk berpindah dari satu titik ke titik lain dalam jaringan, biasanya diukur dalam milidetik. Sementara itu, bandwidth menunjukkan seberapa banyak data yang bisa dikirim per detik.
Saat mengunduh file besar, kapasitas transfer yang memadai sangat membantu. Namun, ketika membuka akun atau memeriksa status transaksi, kita juga membutuhkan respons cepat meskipun data yang dikirim berukuran kecil.
Menambah bandwidth bisa membantu jika kapasitas transfer memang menjadi kendala. Kalau waktu habis untuk menjangkau server yang jauh atau menunggu proses aplikasi, bagian itulah yang perlu diperiksa.
Saat Kita Mengklik, Apa yang Sebenarnya Terjadi?
Sebelum hasil muncul di layar, permintaan kita harus melewati beberapa tahap. Secara sederhana, waktu respons bisa terpakai untuk:
Melewati jaringan, dengan jarak dan kondisi koneksi yang berbeda-beda.
Menunggu giliran, ketika server sedang menangani banyak permintaan.
Memproses hasil, termasuk memeriksa akun dan membaca database.
Pada contoh belanja tadi, gambar mungkin sudah tersedia dalam cache sehingga bisa langsung ditampilkan. Sementara itu, pembayaran bisa perlu memeriksa akun dan data transaksi terlebih dahulu. Karena alurnya berbeda, mempercepat satu bagian belum tentu membuat bagian lainnya ikut cepat.
Seberapa Cepat Aplikasi Perlu Merespons?
Jawabannya bergantung pada apa yang sedang kita lakukan. Dalam video call, jeda kecil bisa membuat percakapan saling tumpang tindih. Pada dashboard bisnis, pembaruan dengan jeda lebih panjang mungkin masih cukup untuk membantu pengambilan keputusan.
Kebutuhan seperti ini berkaitan dengan real-time workloads, yaitu pekerjaan sistem yang perlu selesai dalam batas waktu tertentu. Targetnya mengikuti fungsi aplikasi dan dampak keterlambatan bagi pengguna.
Kestabilan respons juga perlu diperhatikan. Respons yang sesekali cepat lalu tiba-tiba terlambat bisa mengganggu interaksi. Variasi latency ini disebut jitter. Karena itu, performa perlu dilihat saat aplikasi benar-benar digunakan, termasuk ketika koneksi berubah atau traffic meningkat.
Bagaimana Membuat Perjalanan Data Lebih Efisien?
Setelah memahami sumber keterlambatan, kita bisa melihat di mana konten, proses, dan data sebaiknya ditempatkan. Dalam arsitektur cloud, beberapa pendekatan berikut bisa membantu pada bagian yang berbeda.
CDN untuk Konten yang Sering Diakses
CDN adalah singkatan dari Content Delivery Network, yaitu jaringan server yang menyajikan konten dari berbagai lokasi. CDN menyimpan salinan konten melalui caching, sehingga pengguna bisa mengaksesnya tanpa selalu mengambil dari origin server, yaitu server sumber konten.
Bayangkan gambar yang sama dibuka oleh banyak orang. Jika salinannya sudah tersedia dekat jaringan pengguna, perjalanan untuk mengambil gambar itu bisa lebih pendek. Kita tetap perlu mengatur kapan cache boleh digunakan dan kapan harus diperbarui. Konten personal juga membutuhkan aturan yang menjaga data tetap diakses oleh pengguna yang tepat.
Edge Computing dan Lokasi Pemrosesan
Edge computing menempatkan pemrosesan lebih dekat dengan pengguna atau sumber data. Sebagian pekerjaan, seperti mengarahkan pengguna berdasarkan lokasi atau menyesuaikan konten, bisa dilakukan di sana sebelum respons dikirim.
Lokasi datanya juga perlu diperhatikan. Kalau proses di edge masih harus bolak-balik mengambil data dari database yang jauh, waktu menunggunya tetap bertambah. Saat menentukan lokasi pemrosesan, perhatikan juga komponen yang paling sering diajak berkomunikasi. Dengan begitu, kita bisa menilai apakah pemindahan proses benar-benar mempersingkat perjalanan data.
Multi-Region untuk Aplikasi di Berbagai Wilayah
Dengan multi-region, aplikasi dijalankan di beberapa wilayah geografis. Permintaan pengguna bisa diarahkan ke wilayah yang sesuai, sementara data perlu disiapkan agar tersedia saat dibutuhkan.
Tantangannya muncul ketika data berubah. Pembaruan dari satu wilayah perlu diteruskan ke wilayah lain, sehingga konsistensi data, waktu replikasi, dan biaya ikut menjadi pertimbangan.
Multi-zone memiliki cakupan berbeda karena menggunakan beberapa zona dalam satu region. Pendekatan ini membantu menjaga layanan saat salah satu zona mengalami gangguan. Pemilihannya perlu mengikuti lokasi pengguna, kebutuhan data, dan tingkat keandalan yang diharapkan.
Mengapa Koneksi Lokal Perlu Diperhatikan?
Di Indonesia, pengalaman mengakses aplikasi bisa berbeda dari satu wilayah ke wilayah lain. Selain jarak, jalur jaringan dan koneksi penyedia internet ikut memengaruhi waktu yang dibutuhkan data untuk sampai ke pengguna.
Salah satu contohnya ada pada studi kasus Net TV yang dipublikasikan BytePlus. Penerapannya mencakup penempatan PoP, atau Point of Presence, di dalam gateway salah satu penyedia telekomunikasi besar di Indonesia. BytePlus melaporkan penurunan latency sebesar 51,5%.
Laporan itu tidak merinci kondisi awal dan cara pengukurannya. Dari kasus ini, kita bisa mengambil pelajaran bahwa kedekatan server perlu dilihat bersama koneksi nyata ke pengguna. Pengujian dari lokasi dan penyedia internet yang berbeda akan membantu memberi gambaran yang lebih relevan.
Bagaimana Membuat Aplikasi Lebih Responsif?
Mulailah dari bagian yang paling lama membuat pengguna menunggu. Jika masalahnya ada pada query database, periksa cara data diakses. Jika pengiriman konten memakan waktu, lihat lokasi server dan pengaturan cache.
Angka rata-rata juga bisa membuat beberapa respons yang sangat lambat luput dari perhatian. Karena itu, perhatikan p95 dan p99, yaitu batas waktu respons yang mencakup 95 persen dan 99 persen permintaan. Uji juga saat traffic tinggi untuk melihat apakah performanya tetap terjaga.
Pekerjaan yang bisa menunggu, seperti laporan berkala, dapat diproses di latar belakang agar tidak menahan respons utama. Setelah perbaikan dilakukan, bandingkan hasil pengukurannya dengan biaya compute, storage, dan transfer data. Perubahan yang dipilih pun punya alasan yang jelas.
Ingin Memahami CDN Lebih Dalam?
Di balik aplikasi yang kita gunakan sehari-hari, ada banyak keputusan menarik tentang jaringan, data, dan pemrosesan. Indonesia Cloud Community atau iCCom menjadi ruang untuk membahasnya bersama, mulai dari dasar cloud hingga pengalaman penerapannya.
Keanggotaan iCCom gratis dan terbuka bagi pemula maupun profesional. Bergabunglah dengan iCCom untuk mengikuti diskusi dan kegiatan komunitas, belajar dari para praktisi, serta terhubung dengan sesama cloud enthusiast di Indonesia.
Author: Danurdhara Suluh Prasasta
CTI Group Content Writer
