Apa Itu CDN? Cara Web Tetap Ngebut di Seluruh Dunia

Bayangkan website-mu tinggal di satu server di Singapura. Pengunjung dari Singapura membukanya, dan halamannya langsung muncul seketika. Tapi pengunjung dari Brasil membuka halaman yang sama, dan setiap gambar, setiap skrip, setiap byte harus menempuh setengah keliling planet bolak-balik sebelum mereka melihat apa pun. Situsnya sama persis, tapi pengalamannya beda jauh — dan satu-satunya yang berubah cuma jaraknya.

CDN adalah solusi standar untuk masalah itu. Kepanjangannya Content Delivery Network, dan ide di baliknya sederhana sekali: alih-alih melayani semua orang dari satu mesin yang jauh, kamu menaruh salinan kontenmu di banyak mesin yang tersebar di seluruh dunia, lalu memberi tiap pengunjung salinan yang paling dekat dengannya. Ayo kita bedah cara kerjanya dan kenapa hal ini penting banget.

CDN itu sebenarnya apa

CDN adalah jaringan server yang ditempatkan di banyak lokasi di seluruh dunia, dengan tugas mengantarkan konten ke pengunjung dari lokasi yang paling dekat dengan mereka. Server-server itu disebut edge server, karena mereka berada di “tepi” (edge) jaringan — dekat dengan pengguna sungguhan — bukan di satu titik pusat.

Ini pergeseran cara pikir yang penting. Tanpa CDN, ada satu tempat situsmu tinggal: origin server (mesin tempat berkas asli yang sesungguhnya berada). Semua orang di dunia mengambil dari satu tempat itu. Dengan CDN, origin server tetap menyimpan salinan utama, tapi CDN menyimpan salinan cache kontenmu di edge server-nya di seluruh penjuru bumi. Pengunjung dilayani dari edge, bukan dari origin — dan origin baru diganggu kalau edge belum punya hal yang dibutuhkan.

Jadi CDN itu bukan pengganti server-mu. Dia adalah lapisan yang duduk di depan server-mu, menyebarkan kontenmu supaya secara fisik dekat dengan semua orang sekaligus.

CDN tidak menjalankan kodemu — dia melayani kontenmu

Ini sering bikin pemula salah paham. CDN jago mengantarkan konten: gambar, CSS, berkas JavaScript, video, font, dan halaman utuh yang tidak berubah-ubah per pengunjung. Secara bawaan, dia tidak menjalankan logika aplikasi atau database-mu. Itu semua tetap tinggal di origin. Anggap CDN sebagai lapisan pengantaran dan cache berskala dunia, bukan tempat program-mu dijalankan. (Sebagian CDN modern memang memungkinkan kamu menjalankan potongan kode kecil di edge, tapi itu fitur tambahan — tugas intinya tetap pengantaran konten yang cepat.)

Kenapa jarak jadi masalah sejak awal

Untuk paham kenapa CDN membantu, kamu perlu menyadari bahwa data di internet tidak berpindah seketika. Dia menjalar sebagai sinyal lewat kabel — termasuk kabel serat optik panjang di dasar laut yang menghubungkan benua — dan itu butuh waktu yang nyata. Makin jauh data harus pergi, makin lama tiap perjalanan bolak-baliknya. Tundaan ini disebut latency, biasanya diukur dalam milidetik.

Kedengarannya kecil, tapi cepat sekali menumpuk. Memuat satu halaman web bukan cuma satu permintaan — sering kali puluhan: HTML-nya dulu, lalu CSS, lalu gambar, font, skrip, dan lainnya. Banyak di antaranya terjadi berurutan, di mana browser belum bisa meminta hal berikutnya sebelum hal sebelumnya tiba. Kalau tiap perjalanan ke server yang jauh makan 250 milidetik alih-alih 20 milidetik, tundaan itu bertumpuk satu sama lain dan halamannya jadi merangkak.

TANPA CDN — semua orang mengambil dari satu origin di Singapura

   Pengunjung (Brasil) ──── perjalanan jauh ────►  Origin (Singapura)
                       ◄─── perjalanan jauh ─────
   (lambat: data menyeberangi planet bolak-balik, berkali-kali)


DENGAN CDN — konten disimpan di edge dekat tiap pengunjung

   Pengunjung (Brasil)  ──► Edge (São Paulo)  ◄── perjalanan pendek, cepat
   Pengunjung (Jepang)  ──► Edge (Tokyo)       ◄── perjalanan pendek, cepat
   Pengunjung (Jerman)  ──► Edge (Frankfurt)   ◄── perjalanan pendek, cepat
                                │
                                │ (hanya saat cache miss)
                                ▼
                          Origin (Singapura)

Memperpendek jarak fisik memperpendek latency, dan memperpendek latency bikin halaman terasa cepat. Itulah seluruh trik sulapnya. Kalau kamu mau menyegarkan ingatan soal bagaimana data secara fisik berpindah dari satu mesin ke mesin lain sejak awal, artikel tentang cara kerja internet meletakkan dasar yang dibangun di sini.

Bagaimana CDN benar-benar melayani sebuah permintaan

Ayo kita telusuri apa yang terjadi saat ada orang membuka situs yang ditopang CDN. Urutan ini adalah jantung dari seluruh konsepnya.

Browser pengunjung meminta sesuatu, misalnya gambar logo di situsmu.
Lewat DNS, permintaan itu diarahkan bukan ke origin-mu, melainkan ke edge server terdekat di jaringan CDN.
Edge server mengecek: apakah aku sudah punya salinan gambar ini yang masih segar di cache?
Kalau ya — sebuah “cache hit” — dia langsung mengirim balik salinan dari cache. Cepat, dan origin-mu bahkan tidak tahu-menahu soal ini.
Kalau tidak — sebuah “cache miss” — edge server mengambil berkas itu dari origin satu kali, mengirimkannya ke pengunjung, lalu menyimpan salinannya supaya orang berikutnya di dekat situ mendapat cache hit.

   Browser ──► Edge server: "kasih aku /logo.png"
                   │
                   ├─ punya salinan di cache & masih segar? ──► YA ──► kirim (cache HIT) ✓
                   │
                   └─ TIDAK (cache MISS)
                         │
                         ├─► ambil sekali dari Origin
                         ├─► simpan salinan di edge
                         └─► kirim ke browser

Bagian indahnya: pengunjung pertama di sebuah wilayah “memanaskan” cache, dan semua orang setelahnya di wilayah itu mendapat versi cache yang cepat. Origin mengerjakan bagian yang amat kecil dari beban yang dulu dia tanggung, karena sebagian besar permintaan tidak pernah sampai ke sana.

Cache hit ratio adalah angka yang paling berarti

Kalau kamu mendengar orang membahas performa CDN, istilah yang paling sering muncul adalah cache hit ratio — persentase permintaan yang dilayani dari cache edge alih-alih balik ke origin. Rasio yang tinggi (katakanlah 95%) berarti hampir semuanya dilayani cepat dan dekat, dan origin-mu nyaris tidak berkeringat. Rasio yang rendah berarti terlalu banyak permintaan yang “meleset” dari cache dan merangkak balik ke origin, yang menggugurkan sebagian besar manfaatnya. Menyetel apa yang di-cache dan untuk berapa lama sebagian besar adalah soal mendorong rasio itu naik.

Caching: bagaimana edge tahu apa yang disimpan, dan untuk berapa lama

Caching adalah mesin di dalam CDN, jadi ada baiknya memahami kendalinya. Pertanyaan besar untuk tiap potong konten adalah: berapa lama aman menyimpan salinan sebelum mengecek lagi ke origin? Durasi itu disebut TTL (time to live) milik konten tersebut.

TTL yang tepat sepenuhnya bergantung pada seberapa sering kontennya berubah:

Aset statis yang jarang berubah — logo, font, berkas CSS, foto produk — bisa di-cache lama (berjam-jam, berhari-hari, bahkan lebih). Isinya sama untuk semua orang dan tidak cepat basi.
Konten yang sering berubah — beranda berita, harga, jumlah stok — butuh TTL pendek atau penanganan hati-hati, supaya pengunjung tidak melihat informasi usang.
Konten personal atau privat — dasbor pengguna yang sudah login, isi keranjangnya — biasanya sebaiknya tidak di-cache di edge bersama sama sekali, karena beda untuk tiap orang dan bisa jadi sensitif.

Origin memberi tahu CDN cara meng-cache tiap berkas lewat header respons HTTP (yang terpenting Cache-Control). Instruksi yang umum terlihat seperti ini:

Cache-Control: public, max-age=86400

Artinya: berkas ini boleh di-cache secara publik, dan tetap dianggap segar selama 86.400 detik — tepat satu hari. Setelah itu, edge mengecek ulang ke origin. Mengatur header-header ini dengan benar adalah sebagian besar keahlian dalam menjalankan CDN dengan baik.

Jebakan klasik: konten basi

Sisi lain dari caching adalah edge bisa saja terus melayani salinan lama setelah kamu memperbarui berkasnya. Kamu mendorong perbaikan ke CSS-mu, tapi pengunjung terus mendapat versi lama dari cache sampai TTL-nya kedaluwarsa. Ada dua cara standar untuk mengatasinya:

Purge (atau “invalidate”) cache — perintahkan CDN membuang sebuah berkas dari cache seketika supaya permintaan berikutnya mengambil ulang yang segar. Cocok untuk “aku baru mengubah sesuatu, perbarui sekarang.”
Cache busting — beri berkas itu nama atau versi baru tiap kali berubah, misalnya style.a1b2c3.css. Karena URL-nya baru, CDN menganggapnya berkas yang benar-benar baru tanpa salinan di cache, jadi pengunjung selalu mendapat yang terbaru. Versi lamanya tinggal usang dengan sendirinya.

Cache busting adalah kebiasaan yang lebih andal untuk aset, karena dia menyiasati masalah basi sepenuhnya alih-alih melawannya.

Apa yang CDN beri di luar kecepatan

Kecepatan memang jadi judul utama, tapi CDN yang bagus membuktikan nilainya lewat beberapa hal lain juga.

Dia menyerap lonjakan trafik. Karena edge menangani sebagian besar permintaan, banjir pengunjung mendadak menghantam kapasitas terdistribusi CDN yang besar, bukan menggebuk satu origin-mu. Postingan yang mendadak viral jauh lebih kecil kemungkinannya menjatuhkan situsmu.
Dia mengurangi beban (dan biaya bandwidth) di origin. Tiap permintaan yang dilayani dari edge adalah satu permintaan yang tidak perlu ditangani origin. Untuk situs yang menyajikan berkas besar seperti gambar dan video, pengalihan beban itu sangat besar.
Dia menambah lapisan perlindungan. Karena duduk di depan origin, CDN bisa meredam serangan tertentu — terutama serangan DDoS, di mana penyerang berusaha membanjiri situs dengan trafik sampah. Skala CDN memungkinkannya menyerap banjir yang akan merebahkan server tunggal, dan dia bisa menyembunyikan alamat asli origin-mu. Ini berpadu wajar dengan penyaringan lebih luas yang kamu lakukan di firewall.
Dia menangani HTTPS di edge. CDN menutup koneksi aman dekat dengan pengunjung, yang menjaga trafik terenkripsi tetap cepat. Kalau istilahnya masih kabur, tulisan tentang SSL, TLS, dan HTTPS menjelaskan apa yang terjadi di balik layar.

Ada baiknya membedakan ini dengan load balancing. Sebuah load balancer menyebar permintaan ke beberapa server, biasanya di dalam satu data center, untuk berbagi beban. CDN menyebar konten yang di-cache ke banyak lokasi di seluruh dunia untuk memperpendek jarak. Keduanya memecahkan masalah yang berkaitan tapi berbeda, dan situs besar dengan senang hati memakai keduanya.

Bagaimana CDN dipasang (versi singkat)

Kamu tidak perlu membangun ulang apa pun untuk memakai CDN. Dua cara umum menaruhnya di depan situs yang sudah ada adalah:

Arahkan DNS-mu ke CDN. Kamu mengubah catatan DNS domain-mu supaya trafik mengalir lewat edge CDN dulu, yang kemudian berbicara dengan origin-mu di belakang layar. Ini mengalirkan seluruh situsmu lewat CDN. Kalau catatan DNS terasa samar, domain dan DNS membahas persis apa yang dikerjakan catatan-catatan itu.
Sajikan aset tertentu dari URL CDN. Kamu mengunggah atau merujuk berkas tertentu (gambar, skrip, font) lewat CDN dan menautkannya langsung, sementara sisa situsmu tetap di origin. Cara ini umum dipakai untuk aset statis yang berat.

Bagaimanapun caranya, pengunjung tidak pernah merasakan apa-apa. Mereka mengetik domain-mu yang biasa, dan pengalihan diam-diam memberi mereka salinan terdekat dan tercepat.

CDN bukan alasan untuk mengabaikan origin

Menggoda untuk berpikir bahwa CDN membuat kecepatan origin-mu jadi tak relevan — padahal tidak. Tiap cache miss, tiap permintaan yang tak bisa di-cache (login, kiriman form, halaman dinamis), dan pengunjung paling pertama di tiap wilayah semuanya menghantam origin langsung. Kalau origin-mu lambat, permintaan-permintaan itu juga lambat, dan momen viral tetap bisa membebaninya. CDN adalah akselerator ampuh di atas origin yang sehat, bukan pengganti origin. Jaga origin-mu tetap cepat dan tersetel baik bagaimanapun juga.

Penutup

Ini seluruh idenya dalam satu tempat:

CDN (Content Delivery Network) adalah jaringan edge server di seluruh dunia yang menyimpan salinan cache kontenmu dekat dengan pengunjung.
Dia ada untuk mengalahkan latency — tundaan akibat jarak fisik — dengan melayani tiap pengunjung dari edge terdekat alih-alih dari satu origin yang jauh.
Dia bekerja lewat caching: sebuah cache hit dilayani cepat dari edge; sebuah cache miss mengambil sekali dari origin lalu menyimpan salinan untuk lain kali.
TTL dan header Cache-Control menentukan berapa lama konten tetap di-cache; purge dan cache busting menangani pembaruan supaya pengunjung tidak dapat berkas basi.
Di luar kecepatan, CDN menyerap lonjakan trafik, mengurangi beban origin, membantu menahan serangan seperti DDoS, dan menangani HTTPS di edge.
Dia duduk di depan origin-mu, bukan menggantikannya — origin tetap menyimpan salinan utama dan menjalankan logika sungguhanmu.

Berikutnya, ada baiknya melihat mesin-mesin yang diam-diam duduk di antara client dan server untuk mengarahkan, menyaring, dan meneruskan trafik — dunia proxy dan gateway, yang sebenarnya CDN sendiri adalah salah satu contohnya yang besar dan cerdik.