LAPORAN TUGAS CLOUD COMPUTING

“Buat resume dari artikel yang diBaca”

DISUSUN OLEH :
[Mufti Kalean] [3411171136]

KELAS
AIG -

PROGRAM STUDI INFORMATIKA

FAKULTAS SAINS DAN INFORMATIKA
UNIVERSITAS JENDERAL ACHMAD YANI
TAHUN 2022
 DAFTAR ISI
BAB I. A. PENGANTAR……………………………………………….………………….……2
BAB II. PEMBAHASAN………………………………………………………………..……….3
A. Gambaran Caching…………………………………..……………………….………...3
B. Jenis-Jenis Caching …………………………….…….……………………….……….3
C. Praktik Terbaik Caching ……………………………………..………….……………..3
D. Jasa Caching ……………………………..…………………..………….……………..3

BAB III. KESIMPULAN………………………………………………………………………….4

 BAB I. A. PENGANTAR
A. Gambaran Caching
o Caching berlaku untuk berbagai macam kasus penggunaan, tetapi
mengeksploitasi sepenuhnya caching memerlukan beberapa perencanaan.
Saat memutuskan apakah akan meng-cache sepotong data, pertimbangkan
pertanyaan berikut:

o Apakah aman menggunakan nilai yang di-cache? Sepotong data yang sama
dapat memiliki persyaratan konsistensi yang berbeda dalam konteks yang
berbeda. Misalnya, selama pembayaran online, Anda memerlukan harga
otoritatif suatu item, sehingga penyimpanan dalam cache mungkin tidak
sesuai. Namun, di halaman lain, harga mungkin beberapa menit kedaluwarsa
tanpa berdampak negatif pada pengguna.
o Apakah caching efektif untuk data itu? Beberapa aplikasi menghasilkan pola
akses yang tidak cocok untuk caching—misalnya, menyapu ruang kunci dari
kumpulan data besar yang sering berubah. Dalam hal ini, memperbarui cache
dapat mengimbangi keuntungan apa pun yang ditawarkan oleh caching.
o Apakah data terstruktur dengan baik untuk caching? Cukup menyimpan
catatan database seringkali cukup untuk menawarkan keuntungan kinerja
yang signifikan. Namun, di lain waktu, data paling baik di-cache dalam format
yang menggabungkan beberapa catatan secara bersamaan. Karena cache
adalah penyimpanan nilai kunci yang sederhana, Anda mungkin juga perlu
meng-cache rekaman data dalam beberapa format berbeda, sehingga Anda
dapat mengaksesnya dengan atribut yang berbeda dalam rekaman.
 BAB II. PEMBAHASAN

A. Gambaran Caching

a. Apa itu Caching?

Dalam komputasi, cache adalah lapisan penyimpanan data berkecepatan tinggi
yang menyimpan subset data, biasanya bersifat sementara, sehingga
permintaan di masa mendatang untuk data tersebut dilayani lebih cepat daripada
yang dimungkinkan dengan mengakses lokasi penyimpanan utama data.
Caching memungkinkan Anda menggunakan kembali data yang diambil atau
dihitung sebelumnya secara efisien.
b. Bagaimana cara kerja Caching?
Data dalam cache umumnya disimpan dalam perangkat keras akses cepat seperti
RAM (memori akses acak) dan juga dapat digunakan dalam korelasi dengan
komponen perangkat lunak. Tujuan utama cache adalah untuk meningkatkan kinerja
pengambilan data dengan mengurangi kebutuhan untuk mengakses lapisan
penyimpanan yang lebih lambat.

- Menukar kapasitas untuk kecepatan, cache biasanya menyimpan subset data

secara sementara, berbeda dengan database yang datanya biasanya lengkap
dan tahan lama.

c. Ikhtisar Caching
- Mesin RAM dan In-Memory: Karena tingkat permintaan yang tinggi atau IOPS
(operasi Input/Output per detik) yang didukung oleh mesin RAM dan In-Memory,
caching menghasilkan peningkatan kinerja pengambilan data dan mengurangi
biaya dalam skala besar. Untuk mendukung skala yang sama dengan database
tradisional dan perangkat keras berbasis disk, diperlukan sumber daya
tambahan. Sumber daya tambahan ini menaikkan biaya dan masih gagal
mencapai kinerja latensi rendah yang disediakan oleh cache Dalam Memori.

- Aplikasi: Cache dapat diterapkan dan dimanfaatkan di berbagai lapisan

teknologi termasuk Sistem Operasi, lapisan Jaringan termasuk Jaringan
Pengiriman Konten (CDN) dan DNS, aplikasi web, dan Basis Data. Anda dapat
menggunakan caching untuk mengurangi latensi secara signifikan dan
meningkatkan IOPS untuk banyak beban kerja aplikasi berat baca, seperti portal
Tanya Jawab, game, berbagi media, dan jejaring sosial. Informasi yang di-cache
 dapat mencakup hasil kueri database, penghitungan intensif komputasi,
permintaan/respons API, dan artefak web seperti HTML, JavaScript, dan file
gambar. Beban kerja intensif komputasi yang memanipulasi kumpulan data,
seperti mesin rekomendasi dan simulasi komputasi performa tinggi juga
mendapat manfaat dari lapisan data In-Memory yang berfungsi sebagai cache.
Dalam aplikasi ini, set data yang sangat besar harus diakses secara real-time di
seluruh kelompok mesin yang dapat menjangkau ratusan node. Karena
kecepatan perangkat keras yang mendasarinya, memanipulasi data ini di
penyimpanan berbasis disk merupakan hambatan yang signifikan untuk aplikasi
ini.

- Pola desain: Dalam lingkungan komputasi terdistribusi, lapisan caching khusus

memungkinkan sistem dan aplikasi berjalan secara independen dari cache
dengan siklus hidup mereka sendiri tanpa risiko mempengaruhi cache. Cache
berfungsi sebagai lapisan pusat yang dapat diakses dari sistem yang berbeda
dengan siklus hidup dan topologi arsitekturnya sendiri. Ini sangat relevan dalam
sistem di mana node aplikasi dapat diskalakan masuk dan keluar secara
dinamis. Jika cache berada di node yang sama dengan aplikasi atau sistem yang
menggunakannya, penskalaan dapat memengaruhi integritas cache. Selain itu,
ketika cache lokal digunakan, mereka hanya menguntungkan aplikasi lokal yang
mengonsumsi data. Dalam lingkungan caching terdistribusi, data dapat
menjangkau beberapa server cache dan disimpan di lokasi terpusat untuk
kepentingan semua konsumen data tersebut.

- Praktik Terbaik Caching: Saat menerapkan lapisan cache , penting untuk

memahami validitas data yang sedang di-cache. Cache yang berhasil
menghasilkan hit rate yang tinggi yang berarti data ada saat diambil. Kehilangan
cache terjadi ketika data yang diambil tidak ada di cache. Kontrol seperti TTL
(Waktu untuk hidup) dapat diterapkan untuk kedaluwarsa data yang sesuai.
Pertimbangan lain mungkin apakah lingkungan cache harus Sangat Tersedia
atau tidak, yang dapat dipenuhi oleh mesin In-Memory seperti Redis. Dalam
beberapa kasus, lapisan In-Memory dapat digunakan sebagai lapisan
penyimpanan data yang berdiri sendiri berbeda dengan data caching dari lokasi
utama. Dalam skenario ini, penting untuk menentukan RTO (Tujuan Waktu
Pemulihan--waktu yang diperlukan untuk pulih dari pemadaman) dan RPO
(Tujuan Titik Pemulihan--titik terakhir atau transaksi yang diambil dalam
pemulihan) pada data yang ada di mesin In-Memory untuk menentukan apakah
ini cocok atau tidak. Strategi desain dan karakteristik mesin In-Memory yang
berbeda dapat diterapkan untuk memenuhi sebagian besar persyaratan RTO
dan RPO
 Gambaran Caching

Lapisan Sisi klien DNS Web Aplikasi Basis data

Gunakan Mempercepat Resolusi Mempercepat Mempercepat Kurangi latensi
Kasus pengambilan Domain ke IP pengambilan konten kinerja aplikasi yang terkait
konten web dari web dari server dan akses data dengan
situs web web/aplikasi. Kelola permintaan kueri
(browser atau Sesi Web (sisi server) basis data
perangkat)
Teknologi Header Cache Server DNS Header Cache HTTP, Penyimpanan Buffer basis data,
HTTP, Browser CDN, Proksi Terbalik, data Kunci/Nilai, penyimpanan data
Akselerator Web, cache lokal Kunci/Nilai
Penyimpanan
Kunci/Nilai
Solusi Khusus Peramban Rute Amazon Amazon CloudFront , Kerangka Kerja ElastiCache untuk
53 ElastiCache untuk Redis Aplikasi, Redis ,
, ElastiCache untuk ElastiCache untuk ElastiCache untuk
Memcached , Solusi Redis , Memcached
Mitra ElastiCache untuk
Memcached ,
Solusi Mitra

d. Caching dengan Amazon ElastiCache

Amazon ElastiCache adalah layanan web yang memudahkan penerapan,
pengoperasian, dan penskalaan penyimpanan data dalam memori atau cache di
cloud. Layanan ini meningkatkan kinerja aplikasi web dengan memungkinkan Anda
mengambil informasi dari penyimpanan data dalam memori yang cepat, terkelola,
alih-alih mengandalkan sepenuhnya pada basis data berbasis disk yang lebih
lambat.
e. Manfaat Caching
- Tingkatkan Performa Aplikasi
Karena memori jauh lebih cepat daripada disk (magnetik atau SSD), membaca
data dari cache dalam memori menjadi sangat cepat (sub-milidetik). Akses data
yang jauh lebih cepat ini meningkatkan kinerja aplikasi secara keseluruhan.
- Mengurangi Biaya Database
Satu instans cache dapat menyediakan ratusan ribu IOPS (operasi Input/output
per detik), berpotensi menggantikan sejumlah instans database, sehingga
menurunkan total biaya. Ini sangat penting jika database utama membebankan
biaya per throughput. Dalam kasus tersebut, penghematan harga bisa puluhan
poin persentase.
- Kurangi Beban di Backend
Dengan mengalihkan sebagian besar beban baca dari database backend ke
lapisan dalam memori, caching dapat mengurangi beban pada database Anda,
dan melindunginya dari kinerja yang lebih lambat saat dimuat, atau bahkan dari
crash saat terjadi lonjakan.
- Performa yang Dapat Diprediksi
Tantangan umum dalam aplikasi modern adalah menghadapi lonjakan
penggunaan aplikasi. Contohnya termasuk aplikasi sosial selama Super Bowl
atau hari pemilihan, situs web eCommerce selama Black Friday, dll. Beban yang
meningkat pada database menghasilkan latensi yang lebih tinggi untuk
mendapatkan data, sehingga kinerja aplikasi secara keseluruhan tidak dapat
diprediksi. Dengan memanfaatkan cache dalam memori throughput tinggi,
masalah ini dapat dikurangi.
- Hilangkan Hotspot Basis Data
Dalam banyak aplikasi, ada kemungkinan sebagian kecil data, seperti profil
selebriti atau produk populer, akan lebih sering diakses daripada yang lain. Hal
ini dapat mengakibatkan hot spot di database Anda dan mungkin memerlukan
penyediaan sumber daya database yang berlebihan berdasarkan persyaratan
throughput untuk data yang paling sering digunakan. Menyimpan kunci umum
dalam cache dalam memori mengurangi kebutuhan untuk menyediakan secara
berlebihan sambil memberikan kinerja yang cepat dan dapat diprediksi untuk
data yang paling sering diakses.
- Tingkatkan Throughput Baca (IOPS)
Selain latensi yang lebih rendah, sistem dalam memori juga menawarkan tingkat
permintaan (IOPS) yang jauh lebih tinggi dibandingkan dengan database
berbasis disk yang sebanding. Instance tunggal yang digunakan sebagai cache
samping terdistribusi dapat melayani ratusan ribu permintaan per detik.
f. tentang berbagai kasus penggunaan caching

- Caching Basis Data

Performa, baik dalam kecepatan maupun throughput yang disediakan database
Anda dapat menjadi faktor yang paling berdampak pada performa keseluruhan
aplikasi Anda. Dan terlepas dari kenyataan bahwa banyak database saat ini
menawarkan kinerja yang relatif baik, untuk banyak kasus penggunaan, aplikasi
Anda mungkin membutuhkan lebih banyak. Caching basis data memungkinkan
Anda meningkatkan throughput secara dramatis dan menurunkan latensi
pengambilan data yang terkait dengan basis data backend, yang hasilnya,
meningkatkan kinerja aplikasi Anda secara keseluruhan. Cache bertindak
sebagai lapisan akses data yang berdekatan ke database Anda yang dapat
digunakan aplikasi Anda untuk meningkatkan kinerja. Lapisan cache basis data
dapat diterapkan di depan semua jenis basis data, termasuk basis data
relasional dan NoSQL. Teknik umum yang digunakan untuk memuat data ke
dalam cache Anda termasuk pemuatan lambat dan metode penulisan.klik di sini .

- Jaringan Pengiriman Konten (CDN)

Ketika lalu lintas web tersebar secara geografis, mereplikasi seluruh infrastruktur
Anda di seluruh dunia tidak selalu layak dan tentu saja tidak hemat biaya. CDN
memberi Anda kemampuan untuk memanfaatkan jaringan lokasi tepi globalnya
untuk mengirimkan salinan konten web yang di-cache seperti video, halaman
web, gambar, dan sebagainya ke pelanggan Anda . Untuk mengurangi waktu
respons, CDN menggunakan lokasi edge terdekat dengan pelanggan atau lokasi
asal permintaan untuk mengurangi waktu respons. Throughput meningkat secara
dramatis karena aset web dikirimkan dari cache. Untuk data dinamis, banyak
CDN dapat dikonfigurasi untuk mengambil data dari server asal.

Amazon CloudFront adalah layanan CDN global yang mempercepat pengiriman

situs web, API, konten video, atau aset web Anda lainnya. Ini terintegrasi dengan
produk Amazon Web Services lainnya untuk memberi pengembang dan bisnis
cara mudah mempercepat konten ke pengguna akhir tanpa komitmen
penggunaan minimum

- Caching Sistem Nama Domain (DNS).

Setiap permintaan domain yang dibuat di internet pada dasarnya meminta server
cache DNS untuk menyelesaikan alamat IP yang terkait dengan nama domain.
Caching DNS dapat terjadi pada banyak tingkatan termasuk pada OS, melalui
ISP dan server DNS.
- Manajemen Sesi
Sesi HTTP berisi data pengguna yang dipertukarkan antara pengguna situs
Anda dan aplikasi web Anda seperti informasi login, daftar keranjang belanja,
item yang dilihat sebelumnya, dan sebagainya. Hal penting untuk memberikan
pengalaman pengguna yang luar biasa di situs web Anda adalah mengelola sesi
HTTP secara efektif dengan mengingat preferensi pengguna dan menyediakan
konteks pengguna yang kaya. Dengan arsitektur aplikasi modern, memanfaatkan
penyimpanan data manajemen sesi terpusat adalah solusi ideal untuk beberapa
alasan termasuk menyediakan, pengalaman pengguna yang konsisten di semua
server web, daya tahan sesi yang lebih baik saat armada server web Anda
elastis dan ketersediaan yang lebih tinggi saat data sesi direplikasi di server
cache.
- Antarmuka Pemrograman Aplikasi (API)
Saat ini, sebagian besar aplikasi web dibangun di atas API. API umumnya
adalah layanan web RESTful yang dapat diakses melalui HTTP dan
memperlihatkan sumber daya yang memungkinkan pengguna untuk berinteraksi
dengan aplikasi. Saat mendesain API, penting untuk mempertimbangkan beban
yang diharapkan pada API, otorisasi untuk itu, efek perubahan versi pada
konsumen API dan yang paling penting kemudahan penggunaan API, di antara
pertimbangan lainnya. API tidak selalu perlu membuat instance logika bisnis
dan/atau membuat permintaan backend ke database pada setiap permintaan.
Terkadang menyajikan hasil API yang di-cache akan memberikan respons yang
paling optimal dan hemat biaya. Ini terutama benar ketika Anda dapat meng-
cache respons API agar sesuai dengan tingkat perubahan data yang
mendasarinya. Katakanlah misalnya, Anda memaparkan API cantuman produk
kepada pengguna Anda dan kategori produk Anda hanya berubah sekali sehari.
Mengingat bahwa respons terhadap permintaan kategori produk akan identik
sepanjang hari setiap kali panggilan ke API Anda dilakukan, cukup untuk meng-
cache respons API Anda untuk hari itu. Dengan melakukan caching respons API
Anda, Anda menghilangkan tekanan pada infrastruktur Anda termasuk server
aplikasi dan database Anda. Anda juga mendapatkan keuntungan dari waktu
respons yang lebih cepat dan menghadirkan API yang lebih berperforma baik.
Anda menghilangkan tekanan pada infrastruktur Anda termasuk server aplikasi
dan database Anda. Anda juga mendapatkan keuntungan dari waktu respons
yang lebih cepat dan menghadirkan API yang lebih berperforma baik. Anda
menghilangkan tekanan pada infrastruktur Anda termasuk server aplikasi dan
database Anda. Anda juga mendapatkan keuntungan dari waktu respons yang
lebih cepat dan menghadirkan API yang lebih berperforma baik.

 Amazon API Gateway adalah layanan terkelola penuh yang memudahkan

pengembang untuk membuat, menerbitkan, memelihara, memantau, dan
mengamankan API dalam skala apa pun.
- Caching untuk Lingkungan Hybrid
Di lingkungan cloud hibrid, Anda mungkin memiliki aplikasi yang hidup di cloud
dan sering memerlukan akses ke database lokal. Ada banyak topologi jaringan
yang dapat digunakan untuk membuat konektivitas antara cloud Anda dan
lingkungan lokal termasuk VPN dan Direct Connect. Dan meskipun latensi dari
VPC ke pusat data lokal Anda mungkin rendah, mungkin optimal untuk meng-
cache data lokal Anda di lingkungan cloud Anda untuk mempercepat kinerja
pengambilan data secara keseluruhan.
- Caching Web
Saat mengirimkan konten web ke pemirsa Anda, sebagian besar latensi yang
terkait dengan pengambilan aset web seperti gambar, dokumen html, video, dll.
dapat sangat dikurangi dengan menyimpan artefak tersebut ke dalam cache dan
menghilangkan pembacaan disk dan beban server. Berbagai teknik caching web
dapat digunakan baik di server maupun di sisi klien. Caching web sisi server
biasanya melibatkan penggunaan proxy web yang mempertahankan respons
web dari server web yang berada di depannya, secara efektif mengurangi beban
dan latensinya. Caching web sisi klien dapat menyertakan caching berbasis
browser yang mempertahankan versi cache dari konten web yang dikunjungi
sebelumnya.
- Cache Umum
Mengakses data dari memori jauh lebih cepat daripada mengakses data dari disk
atau SSD, jadi memanfaatkan data dalam cache memiliki banyak keuntungan.
Untuk banyak kasus penggunaan yang tidak memerlukan dukungan data
transaksional atau ketahanan berbasis disk, menggunakan penyimpanan nilai
kunci dalam memori sebagai database mandiri adalah cara terbaik untuk
membuat aplikasi berperforma tinggi. Selain kecepatan, aplikasi mendapat
manfaat dari throughput yang tinggi dengan harga yang hemat biaya. Data yang
dapat direferensikan seperti pengelompokan produk, daftar kategori, informasi
profil, dan sebagainya merupakan kasus penggunaan yang bagus untuk cache
umum.
- Cache Terintegrasi
Cache terintegrasi adalah lapisan dalam memori yang secara otomatis meng-
cache data yang sering diakses dari database asal. Paling umum, basis data
yang mendasarinya akan menggunakan cache untuk melayani respons terhadap
permintaan basis data masuk mengingat datanya ada di cache. Ini secara
dramatis meningkatkan kinerja database dengan menurunkan latensi permintaan
dan mengurangi penggunaan CPU dan memori pada mesin database.
Karakteristik penting dari cache terintegrasi adalah bahwa data yang di-cache
konsisten dengan data yang disimpan di disk oleh mesin database.
g. berbagai industri dan berbagai kasus penggunaan caching

- Seluler
Aplikasi seluler adalah segmen pasar yang tumbuh sangat cepat mengingat
adopsi perangkat konsumen yang cepat dan penurunan penggunaan peralatan
komputer tradisional. Baik itu untuk game, aplikasi komersial, aplikasi kesehatan,
dan sebagainya, hampir setiap segmen pasar saat ini memiliki aplikasi mobile
friendly. Dari perspektif pengembangan aplikasi, membuat aplikasi seluler sangat
mirip dengan membuat bentuk aplikasi lainnya. Anda memiliki bidang perhatian
yang sama, tingkat presentasi, tingkat bisnis, dan tingkat data. Meskipun ruang
layar dan alat pengembangan Anda berbeda, memberikan pengalaman
pengguna yang luar biasa adalah tujuan bersama di semua aplikasi. Dengan
strategi caching yang efektif, aplikasi seluler Anda dapat memberikan performa
yang diharapkan pengguna, menskalakan secara masif, dan mengurangi biaya
keseluruhan.

- AWS Mobile Hub adalah konsol yang memberikan pengalaman terintegrasi

untuk menemukan, mengonfigurasi, dan mengakses layanan cloud AWS untuk
membangun, menguji, dan memantau penggunaan aplikasi seluler.

- Internet of Things (IoT)

Internet of Things adalah konsep di balik pengumpulan dan pengiriman informasi
dari perangkat dan dunia fisik melalui sensor perangkat ke internet atau aplikasi
yang mengonsumsi data. Nilai IoT adalah mampu memahami data yang
ditangkap pada interval waktu nyata yang mendekati yang pada akhirnya
memungkinkan sistem dan aplikasi yang mengkonsumsi kemampuan untuk
merespons data tersebut dengan cepat. Ambil contoh, perangkat yang
mentransmisikan koordinat GPS-nya. Aplikasi IoT Anda dapat merespons
dengan menyarankan tempat menarik terkait kedekatan koordinat tersebut.
Selain itu, jika Anda telah menyimpan preferensi yang terkait dengan pengguna
perangkat, Anda dapat menyempurnakan rekomendasi tersebut yang
disesuaikan dengan individu tersebut. Dalam contoh khusus ini, kecepatan
aplikasi dapat merespons koordinat sangat penting untuk mencapai pengalaman
pengguna yang luar biasa. Caching dapat memainkan peran penting di sini,
misalnya, tempat menarik bersama dengan koordinat geografis dapat disimpan
di penyimpanan kunci/nilai seperti Redis untuk mengaktifkan pengambilan cepat.
Dari perspektif pengembangan aplikasi, Anda pada dasarnya dapat
mengkodekan aplikasi IoT Anda untuk merespons peristiwa apa pun yang
diberikan jika ada cara terprogram untuk melakukannya. Pertimbangan penting
yang harus dilakukan saat membangun arsitektur IoT mencakup waktu respons
yang terlibat dengan analisis data yang diserap, merancang solusi yang dapat
menskalakan N sejumlah perangkat, dan menghadirkan arsitektur yang hemat
biaya. Anda pada dasarnya dapat mengkodekan aplikasi IoT Anda untuk
 menanggapi peristiwa apa pun yang diberikan karena ada cara terprogram untuk
melakukannya. Pertimbangan penting yang harus dilakukan saat membangun
arsitektur IoT mencakup waktu respons yang terlibat dengan analisis data yang
diserap, merancang solusi yang dapat menskalakan N sejumlah perangkat, dan
menghadirkan arsitektur yang hemat biaya. Anda pada dasarnya dapat
mengkodekan aplikasi IoT Anda untuk menanggapi peristiwa apa pun yang
diberikan karena ada cara terprogram untuk melakukannya. Pertimbangan
penting yang harus dilakukan saat membangun arsitektur IoT mencakup waktu
respons yang terlibat dengan analisis data yang diserap, merancang solusi yang
dapat menskalakan N sejumlah perangkat, dan menghadirkan arsitektur yang
hemat biaya.

- AWS IoT adalah platform cloud terkelola yang memungkinkan perangkat

terhubung dengan mudah dan aman berinteraksi dengan aplikasi cloud dan
perangkat lain.

- Teknologi Periklanan
Aplikasi Ad Tech modern sangat menuntut dalam hal kinerja. Contoh area
pertumbuhan yang signifikan di AdTech adalah penawaran waktu nyata (RTB),
yang merupakan pendekatan berbasis lelang untuk bertransaksi iklan bergambar
digital secara waktu nyata, pada tingkat tayangan yang paling terperinci. RTB
adalah metode transaksi yang dominan pada tahun 2015, menyumbang 74,0
persen dari iklan yang dibeli secara terprogram, atau 11 miliar dolar di AS
(menurut Analisis eMarketer). Saat membuat aplikasi penawaran waktu nyata,
satu milidetik dapat menjadi perbedaan antara mengajukan tawaran tepat waktu
dan menjadi tidak relevan. Ini berarti mendapatkan informasi penawaran dari
database harus sangat cepat. Caching basis data, yang dapat mengakses detail
penawaran dalam sub milidetik, merupakan solusi hebat untuk mencapai kinerja
tinggi tersebut.
- Game
Interaktivitas adalah persyaratan landasan untuk hampir semua game modern.
Tidak ada yang membuat pemain frustrasi lebih dari permainan yang lambat atau
tidak responsif, dan itu jarang berhasil. Persyaratan kinerja bahkan lebih
menuntut untuk game multipemain seluler, di mana tindakan yang dilakukan oleh
satu pemain perlu dibagikan dengan orang lain secara waktu nyata. Caching
memainkan peran penting dalam menjaga kelancaran game dengan
memberikan respons kueri sub-milidetik untuk data yang sering diakses.
- Media
Perusahaan media sering berurusan dengan kebutuhan untuk mengirimkan
sejumlah besar konten statis ke pelanggan mereka dengan jumlah
pembaca/pemirsa yang terus berubah. Contohnya adalah layanan streaming
video seperti Netflix atau Amazon Video, yang mengalirkan konten video dalam
jumlah besar ke pemirsa. Ini sangat cocok untuk Jaringan Pengiriman Konten,
tempat data disimpan di kumpulan server caching yang terdistribusi secara
global. Aspek lain dari aplikasi media adalah bahwa beban cenderung melonjak
dan tidak dapat diprediksi. Bayangkan sebuah blog di situs web yang baru saja
di-tweet oleh selebritas, atau situs web tim sepak bola selama Super Bowl.
Lonjakan permintaan yang begitu besar ke subkumpulan konten yang kecil
merupakan tantangan bagi sebagian besar database karena mereka dibatasi
dalam throughput per kuncinya. Karena memori memiliki throughput yang jauh
lebih tinggi daripada disk, cache database akan menyelesaikan masalah
dengan mengarahkan ulang bacaan ke cache memori.
- Perdagangan elektronik
Aplikasi eCommerce modern menjadi lebih canggih, menawarkan pengalaman
belanja yang dipersonalisasi, termasuk rekomendasi waktu nyata berdasarkan
data pengguna dan riwayat belanja. Itu sering juga termasuk melihat jejaring
sosial pengguna dan memberikan rekomendasi berdasarkan apa yang disukai
atau dibeli teman-temannya. Sementara jumlah data yang dibutuhkan untuk
diproses meningkat, kesabaran pelanggan tidak. Oleh karena itu, menjaga
kinerja aplikasi secara real-time bukanlah suatu kemewahan, tetapi suatu
keharusan; strategi caching yang dijalankan dengan baik adalah aspek penting
dari kinerja aplikasi, dan bisa menjadi pembeda antara keberhasilan atau
kegagalan aplikasi, antara melakukan penjualan atau kehilangan pelanggan.

- Media sosial
Aplikasi Media Sosial telah menggemparkan dunia. Jejaring sosial seperti
Facebook, Twitter, Instagram, dan Snapchat memiliki sejumlah besar pengguna
yang mengonsumsi konten dalam jumlah yang terus bertambah. Saat pengguna
membuka feed-nya, dia berharap untuk melihat konten terbarunya yang
dipersonalisasi hampir secara real-time. Itu bukan konten statis karena setiap
pengguna memiliki teman, gambar, minat, dll. yang berbeda, memperburuk
kebutuhan kompleksitas rekayasa dari platform yang mendasarinya. Aplikasi
Media Sosial juga sangat rentan terhadap lonjakan penggunaan seputar acara
hiburan, olahraga, dan politik utama. Ketahanan lonjakan dan kinerja real-time
seperti itu dicapai melalui beberapa lapisan caching – termasuk Jaringan
Pengiriman Konten untuk konten statis seperti gambar latar belakang, cache
sesi untuk melacak data sesi pengguna saat ini, dan cache basis data untuk
menyimpan data yang sering diakses seperti berita terbaru dari teman terdekat
dan beberapa gambar terakhir.
- Kesehatan dan Kebugaran
Industri perawatan kesehatan sedang mengalami revolusi digital, membuat
perawatan tersedia dan dapat diakses oleh semakin banyak pasien di seluruh
dunia. Beberapa aplikasi memungkinkan pasien melihat Dokter untuk konsultasi
video, dan sebagian besar penyedia layanan utama memiliki aplikasi yang
memungkinkan pasien melihat hasil tes mereka dan berinteraksi dengan staf
medis. Di sisi kesehatan, ada banyak aplikasi mulai dari melacak aktivitas sensor
khusus pengguna (mis. FitBit dan Jawbone), hingga pelatihan dan data
kesehatan yang komprehensif. Mengingat sifat interaktif dari aplikasi tersebut,
kebutuhan akan aplikasi berperforma cepat, bisnis, dan tingkatan data harus
diperhatikan. Dengan strategi caching yang efektif, Anda akan dapat
memberikan kinerja yang cepat, mengurangi biaya infrastruktur secara
keseluruhan, dan menskalakan seiring bertambahnya penggunaan Anda.

- Keuangan dan Teknologi Keuangan

Cara kita mengonsumsi layanan keuangan telah berkembang secara dramatis
selama beberapa tahun terakhir. Aplikasi termasuk mengakses layanan
perbankan dan asuransi, deteksi penipuan, layanan investasi, mengoptimalkan
pasar modal melalui algoritme waktu nyata, dan banyak lagi. Memberikan akses
real-time ke data keuangan pelanggan, memungkinkannya melakukan transaksi
seperti mentransfer uang, atau melakukan pembayaran merupakan tantangan.
Pertama, kendala serupa berlaku seperti pada aplikasi lain di mana pengguna
ingin berinteraksi dengan aplikasi hampir secara real-time. Selain itu, aplikasi
keuangan dapat memberlakukan persyaratan tambahan seperti peningkatan
keamanan dan deteksi penipuan. Arsitektur yang efisien, termasuk strategi
caching multi-layer, sangat penting untuk mencapai kinerja yang diharapkan oleh
pengguna. Berdasarkan kebutuhan aplikasi, lapisan caching akan mencakup a
cache sesi untuk menyimpan data sesi pengguna, Jaringan Pengiriman Konten
untuk menyajikan konten statis, dan cache database untuk data yang sering
diakses seperti 10 pembelian terbaru pelanggan.
B. Jenis-Jenis Cahcing

1) Tantangan Basis Data

Saat membuat aplikasi terdistribusi yang memerlukan latensi dan skalabilitas
rendah, ada sejumlah tantangan yang dapat diajukan oleh database berbasis disk
ke aplikasi Anda. Beberapa yang umum termasuk:

- Kueri pemrosesan lambat: Meskipun ada sejumlah teknik pengoptimalan kueri

dan desain skema yang dapat membantu meningkatkan kinerja kueri, kecepatan
pengambilan data dari disk ditambah waktu pemrosesan kueri yang ditambahkan
umumnya akan menempatkan waktu respons kueri Anda dalam kecepatan
milidetik dua digit, pada terbaik. Ini mengasumsikan Anda memiliki beban yang
stabil dan database Anda bekerja secara optimal.
- Biaya untuk menskalakan: Apakah data didistribusikan dalam basis data NoSQL
berbasis disk atau ditingkatkan secara vertikal dalam basis data relasional,
penskalaan untuk pembacaan yang sangat tinggi dapat menjadi mahal dan
mungkin memerlukan sejumlah replika pembacaan basis data untuk
mencocokkan apa yang di- node cache memori dapat mengirimkan permintaan
per detik.
- Kebutuhan untuk menyederhanakan akses data: Sementara database relasional
menyediakan sarana yang sangat baik untuk hubungan model data, mereka
tidak optimal untuk akses data. Ada beberapa contoh di mana aplikasi Anda
mungkin ingin mengakses data dalam struktur atau tampilan tertentu untuk
menyederhanakan pengambilan data dan meningkatkan kinerja aplikasi.

o Sebelum mengimplementasikan caching basis data, banyak arsitek dan insinyur

berusaha keras untuk memeras sebanyak mungkin kinerja dari basis data
mereka. Dan meskipun melakukannya dengan harapan yang masuk akal itu
bagus, itu kontraproduktif untuk mencoba dan memecahkan masalah dengan
alat yang salah. Misalnya, Anda mencoba menurunkan latensi kueri basis data
Anda, melakukan ini dengan harapan yang masuk akal adalah praktik terbaik,
tetapi mencoba menentang hukum fisika yang terkait dengan pengambilan data
dari disk hanya membuang-buang waktu.

o Bagaimana Caching Membantu

Cache basis data melengkapi basis data utama Anda dengan menghilangkan
tekanan yang tidak perlu padanya, biasanya dalam bentuk data baca yang sering
diakses. Cache itu sendiri dapat hidup di sejumlah area termasuk database
Anda, aplikasi, atau sebagai lapisan yang berdiri sendiri.
o Tiga jenis cache database yang paling umum adalah sebagai berikut:

- Cache Terintegrasi Database: Beberapa database seperti Amazon Aurora

menawarkan cache terintegrasi yang dikelola di dalam mesin database dan
memiliki kemampuan tulis-tayang bawaan. Ketika data yang mendasarinya
berubah pada tabel database, database memperbarui cache-nya secara
otomatis, dan itu bagus. Tidak ada apa pun dalam tingkat aplikasi yang
diperlukan untuk memanfaatkan cache ini. Di mana cache terintegrasi gagal
dalam ukuran dan kemampuannya. Cache terintegrasi biasanya terbatas
pada memori yang tersedia yang dialokasikan ke cache oleh instans
database dan tidak dapat dimanfaatkan untuk tujuan lain, seperti berbagi data
dengan instans lain.
- Cache Lokal: Cache lokal menyimpan data yang sering Anda gunakan di
dalam aplikasi Anda. Ini tidak hanya mempercepat pengambilan data Anda
tetapi juga menghapus lalu lintas jaringan yang terkait dengan pengambilan
data, membuat pengambilan data lebih cepat daripada arsitektur caching
lainnya. Kerugian utama adalah bahwa di antara aplikasi Anda, setiap node
memiliki cache penduduknya sendiri yang bekerja dengan cara terputus.
Informasi yang disimpan dalam node cache individual, baik data yang di-
cache database, sesi web, atau keranjang belanja pengguna, tidak dapat
dibagikan dengan cache lokal lainnya. Ini menciptakan tantangan dalam
lingkungan terdistribusi di mana berbagi informasi sangat penting untuk
mendukung lingkungan dinamis yang dapat diskalakan. Dan karena sebagian
besar aplikasi menggunakan beberapa server aplikasi, jika setiap server
memiliki cache sendiri, mengoordinasikan nilai di seluruh server ini menjadi
tantangan besar.

 Selain itu, saat pemadaman terjadi, data di cache lokal akan hilang dan
perlu direhidrasi secara efektif untuk meniadakan cache. Sebagian besar
kontra ini dikurangi dengan cache jarak jauh. Cache jarak jauh (atau
"cache samping") adalah instance terpisah (atau beberapa instance) yang
didedikasikan untuk menyimpan data yang di-cache di dalam memori.

 Ketika latensi jaringan menjadi perhatian, strategi caching dua tingkat

dapat diterapkan yang memanfaatkan cache lokal dan jarak jauh secara
bersamaan. Kami tidak akan membahas strategi ini secara detail, tetapi
biasanya digunakan hanya jika benar-benar dibutuhkan karena
menambah kerumitan. Untuk sebagian besar aplikasi, tambahan
overhead jaringan yang diasosiasikan dengan cache jarak jauh menjadi
perhatian kecil karena permintaan untuk itu umumnya dipenuhi dalam
kinerja sub-milidetik.
- Cache jarak jauh: Cache jarak jauh disimpan di server khusus dan biasanya
dibangun di atas penyimpanan NoSQL kunci/nilai seperti Redis dan Memcached
Mereka menyediakan ratusan ribu hingga satu juta permintaan per detik per
node cache. Banyak solusi seperti Amazon ElastiCache for Redis juga
menyediakan ketersediaan tinggi yang diperlukan untuk beban kerja penting.

Selain itu, latensi rata-rata permintaan ke cache jarak jauh dipenuhi dalam
latensi sub-milidetik, jauh lebih cepat daripada basis data berbasis disk. Pada
kecepatan ini, cache lokal jarang diperlukan. Dan karena cache jarak jauh
berfungsi sebagai kluster terhubung yang dapat dimanfaatkan oleh semua
sistem Anda yang berbeda, mereka ideal untuk lingkungan terdistribusi.
 Dengan cache jarak jauh, orkestrasi antara menyimpan data dalam cache
dan mengelola validitas data dikelola oleh aplikasi Anda dan/atau proses
yang memanfaatkannya. Cache itu sendiri tidak terhubung langsung ke
database tetapi digunakan secara berdekatan. Kami akan memfokuskan
perhatian kami pada memanfaatkan cache jarak jauh dan khususnya Amazon
ElastiCache for Redis untuk menyimpan data database relasional ke dalam
cache.
o Teknik Caching Database Relasional
Banyak teknik yang akan kami ulas dapat diterapkan ke semua jenis database.
Namun, kami akan fokus pada database relasional karena ini adalah kasus
penggunaan caching database yang paling umum.

Paradigma dasar saat meminta data dari database relasional dari aplikasi
termasuk mengeksekusi pernyataan SQL dan mengulangi kursor objek
ResultSet yang dikembalikan untuk mengambil baris database. Saat ingin meng-
cache data yang dikembalikan, ada beberapa teknik yang dapat Anda terapkan,
namun yang terbaik adalah memilih metode yang menyederhanakan pola akses
data dan/atau mengoptimalkan tujuan arsitektur aplikasi.

Untuk memvisualisasikan ini lebih lanjut, kami akan memeriksa cuplikan kode
sampel untuk tujuan menjelaskan logika caching database. Kami juga akan
menggunakan pustaka klien Jedis Redis untuk menghubungkan ke Redis
meskipun pustaka Java Redis apa pun termasuk Lettuce dan Redisson akan
berfungsi. Perlu juga dicatat bahwa beberapa kerangka kerja aplikasi mungkin
merangkum beberapa teknik logika caching basis data di bawah ini. Dengan
demikian, masih penting untuk memahami detail implementasi terutama saat
tidak menggunakan abstraksi tingkat yang lebih tinggi tersebut.
o Setelah mengeluarkan kueri terhadap database pelanggan untuk catatan tertentu
dan dari sana kita akan memeriksa strategi caching yang dapat dimanfaatkan.
Asumsikan kueri SQL berikut mengembalikan catatan:
PILIH FIRST_NAME, LAST_NAME, EMAIL, KOTA, NEGARA, ALAMAT,
NEGARA DARI PELANGGAN MANA CUSTOMER_ID = “1001”;

...
Pernyataan stmt = connection.createStatement();

ResultSet rs = stmt.executeQuery(permintaan);

while (rs.next()) {

Pelanggan pelanggan = Pelanggan baru();

pelanggan.setFirstName(rs.getString("FIRST_NAME"));

pelanggan.setLastName(rs.getString("LAST_NAME"));

dan seterusnya…

}
...

- Mengulangi kursor ResultSet memungkinkan Anda untuk mengambil bidang dan

nilai dari baris database dan dari titik itu, aplikasi dapat memilih di mana dan
bagaimana memanfaatkan data tersebut. Karena ini bukan diskusi desain
aplikasi, kami mengalihkan fokus pada kode dan lebih menekankan pada logika
caching.
Asumsikan juga Anda tidak menggunakan kerangka kerja aplikasi yang dapat
digunakan untuk mengabstraksi implementasi caching Anda. Dengan semua
yang disebutkan, pertanyaannya kemudian adalah, bagaimana cara terbaik
untuk meng-cache data database yang dikembalikan?
o Cache database SQL ResultSet
Cache objek ResultSet berseri yang berisi baris database yang diambil.
- Pro: Ketika logika pengambilan data diabstraksikan (misalnya seperti dalam Data
Access Object , atau lapisan “DAO”) kode yang dikonsumsi hanya
mengharapkan objek ResultSet dan tidak perlu diberi tahu asal-usulnya. Apakah
ResultSet berasal dari database atau deserialized dari cache, hasilnya sama,
ResultSet, dan siap untuk diulang, sangat mengurangi logika integrasi. Pola ini
juga dapat diterapkan ke basis data relasional apa pun.

- Con: Pengambilan data masih memerlukan penggalian nilai dari kursor objek
ResultSet dan tidak lebih menyederhanakan akses data; itu hanya mengurangi
latensi pengambilan data.
Catatan, saat melakukan cache baris, penting agar baris tersebut dapat diserialisasi.
Contoh di bawah menggunakan implementasi CachedRowSet untuk tujuan ini. Juga
saat menggunakan Redis, ini disimpan sebagai nilai array Byte.

...
// rs berisi ResultSet

if (rs != null) { //mari tulis ke cache

CachedRowSet cachedRowSet = new CachedRowSetImpl();

cachedRowSet.populate(rs, 1);

ByteArrayOutputStream bos = new ByteArrayOutputStream();

ObjectOutput out = new ObjectOutputStream(bos);

keluar.writeObject(cachedRowSet);

byte[] redisRSValue = bos.toByteArray();

jedis.set(key.getBytes(), redisRSValue);

jedis.expire(key.getBytes(), ttl);

}
...
- Cuplikan di atas mengonversi objek CachedRowSet ke dalam ByteArray, lalu
menyimpan array Byte tersebut sebagai nilai Redis Byte Array. Nilai kunci yang
digunakan di atas, adalah pernyataan SQL aktual yang diubah menjadi Bytes.
Hal yang menyenangkan tentang menyimpan pernyataan SQL sebagai kunci
untuk teknik ini adalah membantu mengaktifkan lapisan abstraksi caching
transparan yang menyembunyikan detail implementasi. Manfaat tambahan
lainnya adalah Anda tidak perlu membuat pemetaan tambahan apa pun antara id
kunci khusus dan pernyataan SQL yang dijalankan. Pernyataan terakhir
mengeksekusi perintah kedaluwarsa untuk menerapkan TTL ke kunci yang
disimpan. Kode ini mengikuti logika write-through kami di mana setelah
menanyakan database, nilai yang di-cache disimpan segera sesudahnya.
Untuk populasi yang malas, Anda awalnya akan menanyakan cache sebelum
menjalankan kueri terhadap database. Tip yang bagus untuk menyembunyikan
detail implementasi adalah dengan memanfaatkan pola DAO dan memaparkan
metode generik untuk aplikasi Anda untuk mengambil data. Misalnya, karena kunci
Anda adalah pernyataan SQL yang sebenarnya, tanda tangan metode Anda akan
terlihat seperti berikut:

public ResultSet getResultSet(String key); // kuncinya adalah pernyataan sql

- Pemanggilan kode (mengkonsumsi) metode ini hanya mengharapkan objek

ResultSet terlepas dari detail implementasi yang mendasarinya untuk antarmuka.
Di bawah tenda, metode getResultSet akan mengeksekusi GET untuk kunci SQL
dan jika ada, de-serialize dan mengubahnya menjadi ResultSet.

public ResultSet getResultSet(String key) {

byte[] redisResultSet = null;

redisResultSet = jedis.get(key.getBytes());

ResultSet rs = null;

if (redisResultSet != null) { // jika nilai cache ada, de-serialize dan kembalikan

try {

cachedRowSet = new CachedRowSetImpl();

ByteArrayInputStream bis = new ByteArrayInputStream(redisResultSet);

ObjectInput in = new ObjectInputStream(bis);

cachedRowSet.populate((CachedRowSet) di.readObject());
 rs = cacheRowSet;

} else {

// ambil ResultSet dari database, simpan di objek rs, lalu simpan di cache.

}
kembalikan rs;

- Jika data tidak ada di cache, Anda akan meminta database untuk itu, lalu
menyimpannya sebelum kembali. Seperti disebutkan sebelumnya, praktik terbaik
adalah menerapkan TTL yang sesuai pada KEY juga.
o Cache pilih bidang dan nilai dalam format khusus
Cache subset dari baris database yang diambil ke dalam struktur kustom yang
dapat digunakan oleh aplikasi Anda
- Pro: Pendekatan ini sangat mudah diterapkan. Anda pada dasarnya menyimpan
bidang dan nilai tertentu yang diambil ke dalam struktur seperti JSON atau XML,
lalu SET struktur itu ke dalam Redis String. Format yang Anda pilih harus sesuai
dengan pola akses data aplikasi Anda.
- Con: Aplikasi Anda memanfaatkan berbagai jenis objek saat meminta data
tertentu (yaitu Redis String dan hasil database bila diperlukan).
o Amazon ElastiCache Dibandingkan dengan Redis yang Dikelola Sendiri
Redis adalah sumber terbuka, penyimpanan data dalam memori yang telah
menjadi mesin kunci/nilai paling populer di pasar. Sebagian besar popularitasnya
adalah karena dukungannya untuk berbagai struktur data serta fitur lainnya
termasuk dukungan skrip Lua dan kemampuan pesan Pub/Sub. Manfaat
tambahan lainnya termasuk topologi ketersediaan tinggi dengan dukungan untuk
replika baca dan kemampuan untuk mempertahankan data.
Amazon ElastiCache menawarkan layanan terkelola penuh untuk Redis.
Artinya, semua tugas administratif yang terkait dengan pengelolaan
klaster Redis Anda termasuk pemantauan, penambalan, pencadangan,
dan kegagalan otomatis dikelola oleh Amazon. Ini memungkinkan Anda
untuk fokus pada bisnis dan data Anda daripada berfokus pada operasi.
Manfaat lain menggunakan Amazon ElastiCache for Redis daripada mengelola
sendiri lingkungan cache Anda meliputi:

 Mesin Redis yang disempurnakan yang sepenuhnya kompatibel dengan versi

open source tetapi juga memberikan stabilitas dan ketahanan tambahan.
 Parameter yang mudah dimodifikasi seperti kebijakan penggusuran, batas
buffer, dll.
 Kemampuan untuk menskalakan dan mengubah ukuran klaster Anda menjadi
terabyte data
 Keamanan yang diperketat memungkinkan Anda untuk mengisolasi klaster
Anda dalam Amazon VPC

Diagram Caching Basis Data

2) Caching Jaringan Pengiriman Konten (CDN).
- Jaringan Pengiriman Konten (CDN) adalah komponen penting dari hampir
semua aplikasi web modern. Dulu CDN hanya meningkatkan pengiriman
konten dengan mereplikasi file yang sering diminta (konten statis) di seluruh
kumpulan server caching yang didistribusikan secara global. Namun, CDN
menjadi jauh lebih berguna dari waktu ke waktu. Untuk caching, CDN akan
mengurangi beban pada asal aplikasi dan meningkatkan pengalaman
pemohon dengan mengirimkan salinan konten lokal dari tepi cache terdekat,
atau Point of Presence (PoP). Asal aplikasi bebas untuk membuka koneksi
dan mengirimkan konten secara langsung karena CDN menangani pekerjaan
berat. Hasil akhirnya adalah asal aplikasi tidak perlu diskalakan untuk
memenuhi permintaan konten statis.

- CDN melakukan lebih dari sekadar caching, sekarang CDN mengirimkan

konten dinamis yang unik bagi pemohon dan tidak dapat di-cache.
Keuntungan memiliki CDN yang mengirimkan konten dinamis adalah kinerja
dan penskalaan aplikasi. CDN akan membuat dan memelihara koneksi aman
lebih dekat ke pemohon dan, jika CDN berada di jaringan yang sama dengan
asal, seperti kasus CDN berbasis cloud, perutean kembali ke asal untuk
mengambil konten dinamis dipercepat. Selain itu, konten seperti data formulir,
gambar, dan teks dapat dicerna dan dikirim kembali ke asalnya, sehingga
memanfaatkan koneksi laten yang rendah dan perilaku proxy dari PoP.
Menggabungkan pengiriman konten statis dan dinamis, pelanggan sekarang
menggunakan CDN menyediakan pengiriman dan interaktivitas seluruh situs.

- Cache juga menjadi jauh lebih cerdas, memberikan kemampuan untuk

memeriksa informasi yang terkandung dalam header permintaan dan
memvariasikan respons berdasarkan jenis perangkat, informasi pemohon,
string kueri, atau pengaturan cookie. CDN dapat diarahkan untuk mengambil
objek dari berbagai sumber, menerapkan kebijakan protokol, menegosiasikan
koneksi SSL, dan membatasi akses objek berdasarkan lokasi atau kredensial
autentikasi. Kemampuan yang baru-baru ini dikembangkan untuk melakukan
perhitungan logika di edgelokasi memberikan lebih banyak fleksibilitas untuk
aplikasi web dinamis. CDN dapat dengan cepat memeriksa permintaan dan
mengubah perilaku logika caching, autentikasi, dan bahkan memodifikasi
konten saat dikirimkan atau diserap. Mendorong logika aplikasi ke
keunggulan telah memberikan kemungkinan baru bagi pengembang aplikasi
dan persyaratan komputasi asal yang dimuat ke jaringan cerdas terdistribusi.
- Terakhir, ada kemampuan CDN untuk memberikan perlindungan tingkat
jaringan dan aplikasi yang mencegah kerugian atau kehilangan layanan
dengan memfilter lalu lintas dengan firewall aplikasi web dan layanan
perlindungan DDoS yang terintegrasi di lokasi edge dan terintegrasi ke dalam
jaringan caching. Kombinasi kontrol keamanan dan jumlah bandwidth
jaringan yang sangat besar mencegah bot, pencakar, dan peretas tanpa
mengorbankan ketersediaan atau kinerja aplikasi.

Amazon CloudFront adalah CDN skala besar, global, dan kaya fitur yang
menyediakan penyampaian aplikasi yang aman, dapat diskalakan, dan
terintegrasi secara cerdas. Diagram tentang cara Amazon CloudFront
berintegrasi ke dalam komponen AWS ditampilkan dalam diagram berikut.

Integrasi Amazon CloudFront dengan Komponen AWS

3) Caching Web
- Caching konten web membantu meningkatkan daya tanggap situs web Anda
dengan mengurangi beban pada sumber daya backend dan kemacetan
jaringan. Caching web dilakukan dengan mempertahankan respons HTTP
dan sumber daya web dalam cache untuk tujuan memenuhi permintaan
mendatang dari cache, bukan dari server asal.
- Berbagai teknik caching web dapat diterapkan untuk memanfaatkan cache
web secara efektif. Tingkat paling dasar adalah caching web sisi klien di
mana pengguna situs web memanfaatkan cache HTTP tersemat yang
dibangun di dalam browser. Ini adalah ukuran sederhana yang dapat
digunakan untuk mengurangi latensi yang terkait dengan permintaan sumber
daya web dari situs web. Metodologi caching didasarkan pada arahan header
HTTP yang disediakan oleh respons HTTP dari server asal ke browser.
Header cache HTTP memberikan detail tentang berapa lama browser dapat
memenuhi respons di masa mendatang dari cache untuk konten web yang
diminta.
- Di sisi server berbagai teknik web caching dapat digunakan untuk
meningkatkan performa sebuah website. Reverse cache proxy atau
akselerator aplikasi web dapat ditempatkan di depan aplikasi dan server web
untuk melayani versi cache dari respons HTTP yang disimpan dari mereka.
Cache ini diimplementasikan oleh administrator situs dan bertindak sebagai
perantara antara browser dan server asal. Mereka juga umumnya didasarkan
pada arahan cache HTTP.
- Bentuk lain dari caching web sisi server termasuk memanfaatkan
penyimpanan kunci/nilai seperti Memcached dan Redis . Tidak seperti proxy
terbalik yang digunakan untuk hanya menyimpan respons HTTP untuk
permintaan HTTP yang diberikan. Penyimpanan objek kunci/nilai dapat
digunakan untuk meng-cache konten web apa pun yang diinginkan oleh
pengembang aplikasi. Konten web diambil biasanya melalui kode aplikasi
atau penggunaan kerangka kerja aplikasi yang dapat memanfaatkan
penyimpanan data dalam Memori. Manfaat lain menggunakan key/value store
untuk web caching adalah mereka juga biasa digunakan untuk menyimpan
sesi web dan konten cache lainnya. Ini memberikan solusi tunggal untuk
melayani berbagai kasus penggunaan. Untuk mempelajari selengkapnya
tentang toko kunci/nilai yang ditawarkan di Amazon, kunjungi Amazon
ElastiCache.
- Bentuk lain dari web caching dapat diimplementasikan dalam komponen
jaringan dan dengan ISP.
 Diagram Cache Web

4) Cache Umum
- Dalam aplikasi, mungkin ada area arbitrer di mana perlu menyimpan dan
mengambil data yang tidak cocok untuk database tradisional agar dapat
merespons permintaan atau menghitung respons secara efisien dan cepat.
Misalnya, aplikasi Anda menerima beberapa input pengguna dan perlu
memeriksa apakah permintaan serupa dibuat dalam waktu satu jam sebelum
merespons kembali. Salah satu cara untuk mendekati ini adalah dengan
meng-cache permintaan pengguna Anda selama satu jam dan memberi kode
pada aplikasi Anda untuk memeriksa cache tersebut saat permintaan
pengguna baru dibuat. Anda mungkin juga memiliki tipe data lain yang di-
cache yang dapat membantu menghitung nilai yang digunakan dalam
respons. Jenis informasi yang di-cache ini bersifat sementara dan
membutuhkan latensi yang sangat rendah.

- Meskipun dimungkinkan untuk menggunakan cache aplikasi di dalam node

aplikasi itu sendiri, itu tidak akan mampu menahan kegagalan. Juga, cache
lokal diisolasi pada masing-masing node dan tidak dapat dimanfaatkan dalam
sekelompok server aplikasi. Cache terdistribusi di sisi lain, memberikan
latensi rendah dan tingkat ketersediaan yang lebih tinggi, saat digunakan
dengan replika baca dan dapat menyediakan lingkungan bersama untuk
semua server aplikasi Anda untuk memanfaatkan data yang di-cache. Kasus
penggunaan lain untuk cache terdistribusi dapat mencakup berbagi informasi
di berbagai aplikasi dalam sistem Anda. Saat Anda memiliki lokasi terpusat
untuk data Anda, ini dapat secara efektif memberi daya pada berbagai
aplikasi dengan data yang sama dan kecepatan latensi rendah.
 - Saat ini sebagian besar penyimpanan kunci/nilai seperti Memcached dan
Redis dapat menyimpan data senilai terabyte. Redis juga menyediakan fitur
ketersediaan tinggi dan persistensi yang membuat penyimpanan data di
dalamnya menjadi pilihan yang sangat baik ketika daya tahan berbasis disk
tidak penting. Untuk mempelajari lebih lanjut, kunjungi Amazon ElastiCache
for Redis .

Diagram Cache Umum

5) Manajemen Sesi
- Ada berbagai cara untuk mengelola sesi pengguna termasuk menyimpan sesi
tersebut secara lokal ke node yang merespons permintaan HTTP atau
menetapkan lapisan dalam arsitektur Anda yang dapat menyimpan sesi
tersebut dengan cara yang dapat diskalakan dan kuat. Pendekatan umum
yang digunakan termasuk memanfaatkan sesi Sticky atau menggunakan
Cache Terdistribusi untuk manajemen sesi Anda. Pendekatan-pendekatan ini
dijelaskan di bawah ini.

o Sesi Sticky dengan Caching Sesi Lokal

Sesi lengket, juga dikenal sebagai afinitas sesi , memungkinkan Anda merutekan
pengguna situs ke server web tertentu yang mengelola sesi pengguna individu
tersebut. Validitas sesi dapat ditentukan dengan sejumlah metode, termasuk
cookie sisi klien atau melalui parameter durasi yang dapat dikonfigurasi yang
dapat diatur pada penyeimbang muatan yang merutekan permintaan ke server
web.
 Beberapa keuntungan menggunakan sesi sticky adalah hemat biaya karena
Anda menyimpan sesi di server web yang sama yang menjalankan aplikasi Anda
dan pengambilan sesi tersebut umumnya cepat karena menghilangkan latensi
jaringan. Kelemahan untuk menggunakan sesi penyimpanan pada node
individual adalah bahwa jika terjadi kegagalan, Anda kemungkinan besar akan
kehilangan sesi yang ada di node yang gagal. Selain itu, jika jumlah server web
Anda berubah, misalnya skenario peningkatan, lalu lintas mungkin tersebar tidak
merata di seluruh server web karena sesi aktif mungkin ada di server tertentu.
Jika tidak dikurangi dengan benar, ini dapat menghambat skalabilitas aplikasi
Anda.

o Manajemen Sesi Terdistribusi

Untuk mengatasi skalabilitas dan menyediakan penyimpanan data bersama
untuk sesi yang dapat diakses dari server web individu mana pun, Anda dapat
mengabstraksi sesi HTTP dari server web itu sendiri. Solusi umum untuk ini
adalah memanfaatkan penyimpanan Kunci/Nilai Dalam Memori seperti Redis
dan Memcached .
Sementara penyimpanan data Kunci/Nilai dikenal sangat cepat dan memberikan
latensi sub-milidetik, latensi jaringan tambahan dan biaya tambahan adalah
kekurangannya. Manfaat tambahan memanfaatkan penyimpanan Kunci/Nilai
adalah mereka juga dapat digunakan untuk meng-cache data apa pun, bukan
hanya sesi HTTP, yang dapat membantu meningkatkan keseluruhan kinerja
aplikasi Anda.
Pertimbangan saat memilih cache terdistribusi untuk manajemen sesi adalah
menentukan berapa banyak node yang diperlukan untuk mengelola sesi
pengguna. Secara umum, keputusan ini dapat ditentukan oleh seberapa banyak
lalu lintas yang diharapkan dan/atau seberapa besar risiko yang dapat diterima.
Dalam cache sesi terdistribusi, sesi dibagi dengan jumlah node di cluster cache.
Jika terjadi kegagalan, hanya sesi yang disimpan di node gagal yang
terpengaruh. Jika mengurangi risiko lebih penting daripada biaya, menambahkan
node tambahan untuk mengurangi lebih lanjut persentase sesi tersimpan pada
setiap node mungkin ideal bahkan ketika lebih sedikit node yang memadai.
Pertimbangan lain mungkin apakah sesi perlu direplikasi atau tidak. Beberapa
penyimpanan kunci/nilai menawarkan replikasi melalui replika baca. Jika terjadi
kegagalan node, sesi tidak akan sepenuhnya hilang. Apakah simpul replika
penting dalam arsitektur individual Anda dapat menginformasikan penyimpanan
kunci/nilai mana yang harus digunakan. Penawaran ElastiCache untuk
penyimpanan kunci/nilai dalam Memori mencakup ElastiCache untuk Redis ,
yang dapat mendukung replikasi, dan ElastiCache untuk Memcached yang tidak
mendukung replikasi.
Ada sejumlah cara untuk menyimpan sesi di penyimpanan Kunci/Nilai. Banyak
kerangka kerja aplikasi menyediakan pustaka yang dapat mengabstraksi
beberapa saluran integrasi yang diperlukan untuk MENDAPATKAN/MENYETEL
sesi-sesi tersebut dalam memori. Dalam kasus lain, Anda dapat menulis
penangan sesi Anda sendiri untuk melanjutkan sesi secara langsung.

Diagram Manajemen Ses

C. Praktik Terbaik Caching

a) Cara menerapkan caching

Caching berlaku untuk berbagai macam kasus penggunaan, tetapi
mengeksploitasi sepenuhnya caching memerlukan beberapa perencanaan. Saat
memutuskan apakah akan meng-cache sepotong data, pertimbangkan
pertanyaan berikut:

 Apakah aman menggunakan nilai yang di-cache? Sepotong data yang

sama dapat memiliki persyaratan konsistensi yang berbeda dalam
konteks yang berbeda. Misalnya, selama pembayaran online, Anda
memerlukan harga otoritatif suatu item, sehingga penyimpanan dalam
cache mungkin tidak sesuai. Namun, di halaman lain, harga mungkin
beberapa menit kedaluwarsa tanpa berdampak negatif pada pengguna.
 Apakah caching efektif untuk data itu? Beberapa aplikasi menghasilkan
pola akses yang tidak cocok untuk caching—misalnya, menyapu ruang
kunci dari kumpulan data besar yang sering berubah. Dalam hal ini,
memperbarui cache dapat mengimbangi keuntungan apa pun yang
ditawarkan oleh caching.
 Apakah data terstruktur dengan baik untuk caching? Cukup menyimpan
catatan database seringkali cukup untuk menawarkan keuntungan kinerja
yang signifikan. Namun, di lain waktu, data paling baik di-cache dalam
format yang menggabungkan beberapa catatan secara bersamaan.
Karena cache adalah penyimpanan nilai kunci yang sederhana, Anda
mungkin juga perlu meng-cache rekaman data dalam beberapa format
berbeda, sehingga Anda dapat mengaksesnya dengan atribut yang
berbeda dalam rekaman.

b) Pola desain cache

Caching malas
Lazy caching, juga disebut lazy population atau cache-aside, adalah bentuk
caching yang paling umum. Kemalasan harus berfungsi sebagai dasar dari
setiap strategi caching yang baik. Ide dasarnya adalah mengisi cache hanya
ketika sebuah objek benar-benar diminta oleh aplikasi. Alur aplikasi keseluruhan
berjalan seperti ini:
1. Aplikasi Anda menerima kueri untuk data, misalnya 10 berita terbaru teratas.
2. Aplikasi Anda memeriksa cache untuk melihat apakah objek ada di cache.
3. Jika demikian (cache terkena), objek yang di-cache dikembalikan, dan aliran
panggilan berakhir.
4. Jika tidak (cache miss), maka database diminta untuk objek. Cache diisi, dan
objek dikembalikan.
c) Pendekatan ini memiliki beberapa keunggulan dibandingkan metode lain:

 Cache hanya berisi objek yang benar-benar diminta oleh aplikasi, yang
membantu menjaga agar ukuran cache dapat dikelola. Objek baru hanya
ditambahkan ke cache sesuai kebutuhan. Anda kemudian dapat mengelola
memori cache Anda secara pasif, hanya dengan membiarkan mesin yang Anda
gunakan mengeluarkan kunci yang paling jarang diakses saat cache Anda terisi,
yang dilakukannya secara default.
 Saat node cache baru online, misalnya saat aplikasi Anda ditingkatkan, metode
populasi malas akan secara otomatis menambahkan objek ke node cache baru
saat aplikasi pertama kali memintanya.
 Kedaluwarsa cache mudah ditangani hanya dengan menghapus objek yang di-
cache. Objek baru akan diambil dari database saat diminta berikutnya.
 Caching malas dipahami secara luas, dan banyak kerangka kerja web dan
aplikasi menyertakan dukungan di luar kotak.

- Berikut adalah contoh cache malas di pseudocode Python:

# Python

def get_user(user_id):

# Check the cache

record = cache.get(user_id)

if record is None:

# Run a DB query

record = db.query("select * from users where id = ?",user_id)

# Populate the cache

cache.set(user_id, record)

return record

# App code

user = get_user(17
 - dapat menemukan pustaka di banyak kerangka kerja pemrograman populer
yang merangkum pola ini. Tetapi terlepas dari bahasa pemrograman,
pendekatan keseluruhannya sama.
- harus menerapkan strategi caching malas di mana saja di aplikasi Anda di
mana Anda memiliki data yang akan sering dibaca, tetapi jarang ditulis. Di
aplikasi web atau seluler biasa, misalnya, profil pengguna jarang berubah,
tetapi diakses di seluruh aplikasi. Seseorang mungkin hanya memperbarui
profilnya beberapa kali dalam setahun, tetapi profil tersebut dapat diakses
puluhan atau ratusan kali sehari, tergantung penggunanya. Teknologi populer
yang digunakan untuk caching seperti Memcached dan Redis akan secara
otomatis menghapus kunci cache yang jarang digunakan untuk
membebaskan memori jika Anda menetapkan kebijakan penggusuran.
Dengan demikian Anda dapat menerapkan caching malas secara bebas
dengan sedikit kerugian.

d) Menulis melalui
Dalam cache tulis, cache diperbarui secara real time saat database diperbarui.
Jadi, jika pengguna memperbarui profilnya, profil yang diperbarui juga akan
dimasukkan ke dalam cache. Anda dapat menganggap ini sebagai proaktif untuk
menghindari kesalahan cache yang tidak perlu, jika Anda memiliki data yang
benar-benar Anda ketahui akan diakses. Contoh yang baik adalah jenis agregat
apa pun, seperti 100 papan peringkat game teratas, atau 10 berita paling
populer, atau bahkan rekomendasi. Karena data ini biasanya diperbarui oleh
aplikasi tertentu atau kode pekerjaan latar belakang, memperbarui cache juga
mudah dilakukan.
Pola write-through juga mudah didemonstrasikan dalam pseudocode:
# Python

def save_user(user_id, values):

# Save to DB

record = db.query("update users ... where id = ?", user_id, values)

# Push into cache

cache.set(user_id, record)

return record

# App code

user = save_user(17, {"name": "Nate Dogg"})

o Pendekatan ini memiliki keunggulan tertentu dibandingkan populasi yang malas:
 Itu menghindari kesalahan cache, yang dapat membantu aplikasi bekerja
lebih baik dan terasa lebih cepat.
 Ini menggeser penundaan aplikasi apa pun ke pengguna yang memperbarui
data, yang memetakan harapan pengguna dengan lebih baik. Sebaliknya,
serangkaian cache yang hilang dapat memberi kesan kepada pengguna
bahwa aplikasi Anda lambat.
 Ini menyederhanakan kedaluwarsa cache. Cache selalu mutakhir.

o Namun, caching write-through juga memiliki beberapa kelemahan:

 Cache dapat diisi dengan objek yang tidak perlu yang sebenarnya tidak
diakses. Ini tidak hanya menghabiskan memori ekstra, tetapi item yang tidak
terpakai dapat mengeluarkan item yang lebih berguna dari cache.
 Ini dapat mengakibatkan banyak churn cache jika catatan tertentu diperbarui
berulang kali.
 Ketika (bukan jika) node cache gagal, objek tersebut tidak lagi berada di
cache. Anda memerlukan beberapa cara untuk mengisi kembali cache dari
objek yang hilang, misalnya dengan populasi yang malas.
Seperti yang mungkin terlihat jelas, Anda dapat menggabungkan caching lambat
dengan caching tulis untuk membantu mengatasi masalah ini, karena terkait
dengan sisi berlawanan dari aliran data. Lazy caching menangkap cache yang
hilang saat dibaca, dan write-through caching mengisi data saat menulis,
sehingga kedua pendekatan tersebut saling melengkapi. Karena alasan ini,
seringkali yang terbaik adalah memikirkan caching malas sebagai fondasi yang
dapat Anda gunakan di seluruh aplikasi Anda, dan caching tulis sebagai
pengoptimalan bertarget yang Anda terapkan pada situasi tertentu.
e) Waktu untuk hidup
Kedaluwarsa cache bisa menjadi sangat rumit dengan sangat cepat. Dalam
contoh kami sebelumnya, kami hanya beroperasi pada satu rekaman pengguna.
Dalam aplikasi sebenarnya, halaman atau layar tertentu sering menyimpan
banyak hal berbeda sekaligus—data profil, berita utama, rekomendasi,
komentar, dan sebagainya, yang semuanya diperbarui dengan metode berbeda.
o Sayangnya, tidak ada peluru perak untuk masalah ini, dan kedaluwarsa cache
adalah cabang ilmu komputer. Tetapi ada beberapa strategi sederhana yang
dapat Anda gunakan:
 Selalu terapkan waktu untuk hidup (TTL) ke semua kunci cache Anda, kecuali
yang Anda perbarui dengan cache tulis. Anda bisa menggunakan waktu yang
lama, katakanlah berjam-jam atau bahkan berhari-hari. Pendekatan ini
menangkap bug aplikasi, di mana Anda lupa memperbarui atau menghapus
kunci cache yang diberikan saat memperbarui catatan yang mendasarinya.
Akhirnya, kunci cache akan kedaluwarsa secara otomatis dan disegarkan.
  Untuk data yang berubah dengan cepat seperti komentar, papan peringkat,
atau aliran aktivitas, alih-alih menambahkan caching tulis atau logika
kedaluwarsa yang rumit, cukup setel TTL singkat beberapa detik. Jika Anda
memiliki kueri basis data yang dipalu dalam produksi, itu hanya beberapa
baris kode untuk menambahkan kunci cache dengan TTL 5 detik di sekitar
kueri. Kode ini bisa menjadi Band-Aid yang bagus untuk menjaga aplikasi
Anda tetap aktif dan berjalan saat Anda mengevaluasi solusi yang lebih
elegan.
 Pola yang lebih baru, caching boneka Rusia, telah keluar dari pekerjaan yang
dilakukan oleh tim Ruby on Rails. Dalam pola ini, rekaman bersarang dikelola
dengan kunci cache mereka sendiri, lalu sumber daya tingkat atas adalah
kumpulan kunci cache tersebut. Katakanlah Anda memiliki halaman web
berita yang berisi pengguna, cerita, dan komentar. Dalam pendekatan ini,
masing-masing adalah kunci cache sendiri, dan halaman menanyakan
masing-masing kunci tersebut.
 Jika ragu, hapus saja kunci cache jika Anda tidak yakin apakah itu
dipengaruhi oleh pembaruan basis data tertentu atau tidak. Fondasi caching
malas Anda akan menyegarkan kunci saat dibutuhkan. Sementara itu,
database Anda tidak akan lebih buruk daripada tanpa caching.
Untuk ikhtisar yang baik tentang kedaluwarsa cache dan caching boneka Rusia,
lihat Dampak kinerja caching "boneka Rusia" , posting di blog Basecamp Signal
vs Noise.
f) Penggusuran
Penggusuran terjadi ketika memori terisi penuh atau lebih besar dari pengaturan
memori maksimum dalam cache, yang mengakibatkan mesin memilih kunci yang
akan dikeluarkan untuk mengelola memorinya. Kunci yang dipilih didasarkan
pada kebijakan penggusuran yang dipilih.
Secara default, Amazon ElastiCache for Redis menetapkan kebijakan
penggusuran volatile-lru ke klaster Redis Anda. Kebijakan ini memilih kunci yang
paling jarang digunakan yang memiliki nilai kedaluwarsa (TTL). Kebijakan
penggusuran lain yang tersedia dapat diterapkan sebagai parameter kebijakan-
maxmemory yang dapat dikonfigurasi. Kebijakan penggusuran dapat diringkas
sebagai berikut:
allkeys-lfu: Cache menghapus kunci yang paling jarang digunakan (LFU)
terlepas dari set TTL
allkeys-lru: Cache menghapus kunci yang paling jarang digunakan (LRU)
terlepas dari set TTL
volatile-lfu: Cache menghapus kunci yang paling jarang digunakan (LFU ) kunci
dari mereka yang memiliki set TTL
 volatile-lru: Cache menghapus LRU yang paling baru digunakan dari mereka
yang memiliki set TTL
volatile-ttl: Cache menghapus kunci dengan set TTL terpendek
volatile-random: Cache secara acak evicts key dengan TTL set
allkeys-random: Cache secara acak mengeluarkan kunci terlepas dari TTL set
no-eviction: Cache tidak mengeluarkan kunci sama sekali. Ini memblokir
penulisan di masa mendatang hingga memori bebas.
Strategi yang baik dalam memilih kebijakan penggusuran yang tepat adalah
dengan mempertimbangkan data yang disimpan di klaster Anda dan hasil dari
penggusuran kunci.
Secara umum, kebijakan berbasis LRU lebih umum untuk kasus penggunaan
caching dasar, tetapi bergantung pada tujuan Anda, Anda mungkin ingin
memanfaatkan kebijakan penggusuran berbasis TTL atau Acak jika itu lebih
sesuai dengan kebutuhan Anda.
Selain itu, jika Anda mengalami pengusiran dengan klaster Anda, biasanya ini
merupakan tanda bahwa Anda perlu meningkatkan skala (menggunakan node
yang memiliki footprint memori lebih besar) atau menskalakan (menambahkan
node tambahan ke klaster) untuk mengakomodasi tambahan data. Pengecualian
untuk aturan ini adalah jika Anda sengaja mengandalkan mesin cache untuk
mengelola kunci Anda melalui penggusuran, juga disebut cache LRU.
g) Kawanan yang bergemuruh
Juga dikenal sebagai tumpukan anjing, efek kawanan gemuruh adalah apa yang
terjadi ketika banyak proses aplikasi yang berbeda secara bersamaan meminta
kunci cache, mendapatkan cache yang hilang, dan kemudian masing-masing
menemukan kueri basis data yang sama secara paralel. Semakin mahal kueri ini,
semakin besar dampaknya pada database. Jika kueri yang terlibat adalah kueri
10 teratas yang memerlukan peringkat kumpulan data besar, dampaknya bisa
menjadi hit yang signifikan.
Satu masalah dengan menambahkan TTL ke semua kunci cache Anda adalah
dapat memperburuk masalah ini. Misalnya, jutaan orang mengikuti pengguna
populer di situs Anda. Pengguna tersebut belum memperbarui profilnya atau
memublikasikan pesan baru apa pun, namun cache profilnya masih kedaluwarsa
karena TTL. Basis data Anda mungkin tiba-tiba dibanjiri dengan serangkaian
kueri yang identik.
o Selain TTL, efek ini juga umum saat menambahkan node cache baru, karena
memori node cache baru kosong. Dalam kedua kasus tersebut, solusinya adalah
melakukan pra-hangatkan cache dengan mengikuti langkah-langkah berikut:
1. Tulis skrip yang menjalankan permintaan yang sama seperti yang akan
dilakukan aplikasi Anda. Jika itu adalah aplikasi web, skrip ini bisa berupa
skrip shell yang menyentuh sekumpulan URL.
2. Jika aplikasi Anda disiapkan untuk cache yang lambat, cache yang hilang
akan menyebabkan kunci cache diisi, dan node cache yang baru akan
terisi.
3. Saat Anda menambahkan simpul cache baru, jalankan skrip Anda
sebelum memasang simpul baru ke aplikasi Anda. Karena aplikasi Anda
perlu dikonfigurasi ulang untuk menambahkan node baru ke ring hashing
yang konsisten, sisipkan skrip ini sebagai langkah sebelum memicu
konfigurasi ulang aplikasi.
4. Jika Anda mengantisipasi penambahan dan penghapusan node cache
secara teratur, prapemanasan dapat diotomatisasi dengan memicu skrip
untuk dijalankan setiap kali aplikasi Anda menerima peristiwa konfigurasi
ulang klaster melalui Amazon Simple Notification Service (Amazon SNS).
o Akhirnya, ada satu efek samping halus terakhir dari penggunaan TTL di
mana-mana. Jika Anda menggunakan panjang TTL yang sama
(katakanlah 60 menit) secara konsisten, maka banyak kunci cache Anda
mungkin kedaluwarsa dalam jangka waktu yang sama, bahkan setelah
menghangatkan cache Anda. Salah satu strategi yang mudah diterapkan
adalah menambahkan beberapa keacakan ke TTL Anda:

ttl = 3600 + (rand() * 120) /* +/- 2 minutes */

Kabar baiknya adalah bahwa hanya situs berskala besar yang biasanya
harus mengkhawatirkan masalah penskalaan tingkat ini. Ini bagus untuk
disadari, tetapi juga masalah yang bagus untuk dimiliki.
D. Jasa Caching
- Cache File Amazon
Amazon File Cache menyediakan cache berkecepatan tinggi yang terkelola
sepenuhnya di AWS untuk memproses data file, di mana pun data disimpan (on-
premise atau AWS). Amazon File Cache adalah lokasi penyimpanan sementara
berkinerja tinggi, untuk data yang disimpan di sistem file lokal, sistem file AWS, dan
bucket Amazon S3, memungkinkan Anda membuat kumpulan data yang tersebar
tersedia untuk aplikasi berbasis file di AWS dengan satu kesatuan lihat dan pada
kecepatan tinggi – latensi sub-milidetik dan throughput tinggi.

- AmazonElastiCache
Amazon ElastiCache adalah layanan web yang memudahkan penerapan,
pengoperasian, dan penskalaan penyimpanan data dalam memori dan cache di
cloud . Layanan ini meningkatkan kinerja aplikasi web dengan memungkinkan Anda
mengambil informasi dari penyimpanan data dalam memori yang cepat, terkelola,
alih-alih mengandalkan sepenuhnya pada basis data berbasis disk yang lebih
lambat. Amazon ElastiCache mendukung dua mesin dalam memori sumber terbuka:

 Redis - penyimpanan data dan cache yang cepat, open source, dalam
memori. Amazon ElastiCache for Redis adalah layanan dalam memori yang
kompatibel dengan Redis yang memberikan kemudahan penggunaan dan
kekuatan Redis bersama dengan ketersediaan, keandalan, dan kinerja yang
sesuai untuk aplikasi yang paling menuntut. Tersedia klaster single-node dan
hingga 15-shard, memungkinkan skalabilitas hingga 3,55 TiB data dalam
memori. ElastiCache for Redis dikelola sepenuhnya, dapat diskalakan, dan
aman - menjadikannya kandidat yang ideal untuk mendukung kasus
penggunaan berperforma tinggi seperti Web, Aplikasi Seluler, Game, Ad-
Tech, dan IoT.
 Memcached - sistem caching objek memori yang diadopsi secara luas.
ElastiCache mematuhi protokol dengan Memcached, sehingga alat populer
yang Anda gunakan saat ini dengan lingkungan Memcached yang ada akan
bekerja mulus dengan layanan tersebut.
Amazon ElastiCache secara otomatis mendeteksi dan mengganti node yang
gagal, mengurangi overhead yang terkait dengan infrastruktur yang dikelola
sendiri dan menyediakan sistem tangguh yang mengurangi risiko kelebihan
beban database, yang memperlambat waktu muat situs web dan aplikasi. Melalui
integrasi dengan Amazon CloudWatch , Amazon ElastiCache memberikan
visibilitas yang ditingkatkan ke dalam metrik kinerja utama yang terkait dengan
node Redis atau Memcached Anda.
Menggunakan Amazon ElastiCache , Anda dapat menambahkan lapisan dalam
memori ke infrastruktur Anda dalam hitungan menit menggunakan AWS
Management Console. Pengantar Amazon ElastiCache
- Akselerator Amazon DynamoDB (DAX)
Amazon DynamoDB Accelerator (DAX) adalah cache dalam memori yang
dikelola sepenuhnya, sangat tersedia, untuk DynamoDB yang memberikan
peningkatan kinerja hingga 10x – dari milidetik menjadi mikrodetik – bahkan
dengan jutaan permintaan per detik. DAX melakukan semua pekerjaan berat
yang diperlukan untuk menambahkan akselerasi dalam memori ke tabel
DynamoDB Anda , tanpa mengharuskan pengembang mengelola pembatalan
cache, populasi data, atau manajemen kluster. Sekarang Anda dapat berfokus
untuk membuat aplikasi yang hebat bagi pelanggan Anda tanpa
mengkhawatirkan performa dalam skala besar. Anda tidak perlu memodifikasi
logika aplikasi, karena DAX kompatibel dengan panggilan API DynamoDB yang
sudah ada. Anda dapat mengaktifkan DAXhanya dengan beberapa klik di AWS
Management Console atau menggunakan AWS SDK. Sama seperti DynamoDB ,
Anda hanya membayar untuk kapasitas yang Anda sediakan.

- Amazon CloudFront
Amazon CloudFront adalah layanan jaringan pengiriman konten (CDN) global
yang mempercepat pengiriman situs web, API, konten video, atau aset web
Anda lainnya. Ini terintegrasi dengan produk Amazon Web Services lainnya
untuk memberi pengembang dan bisnis cara mudah mempercepat konten ke
pengguna akhir tanpa komitmen penggunaan minimum.

Amazon CloudFront dapat digunakan untuk mengirimkan seluruh situs web

Anda, termasuk konten dinamis, statis, streaming, dan interaktif menggunakan
jaringan global lokasi edge. Permintaan untuk konten Anda secara otomatis
dialihkan ke lokasi edge terdekat, sehingga konten dikirimkan dengan performa
terbaik. Amazon CloudFront dioptimalkan untuk bekerja dengan Layanan Web
Amazon lainnya, seperti Amazon Simple Storage Service ( Amazon S3 ),
Amazon Elastic Compute Cloud ( Amazon EC2 ), Amazon Elastic Load
Balancing , dan Amazon Route 53. Amazon CloudFront juga berfungsi mulus
dengan server asal non-AWS apa pun, yang menyimpan versi asli dan definitif
dari file Anda. Seperti produk Amazon Web Services lainnya, tidak ada kontrak
jangka panjang atau komitmen penggunaan bulanan minimum untuk
menggunakan Amazon CloudFront – Anda hanya membayar sebanyak atau
sesedikit konten yang sebenarnya Anda kirimkan melalui layanan pengiriman
konten.
- Rumput hijau AWS
AWS Greengrass adalah perangkat lunak yang memungkinkan Anda
menjalankan komputasi lokal, perpesanan & caching data untuk perangkat yang
terhubung dengan cara yang aman. Dengan AWS Greengrass , perangkat yang
terhubung dapat menjalankan fungsi AWS Lambda , menjaga sinkronisasi data
perangkat, dan berkomunikasi dengan perangkat lain secara aman – bahkan
saat tidak terhubung ke Internet. Menggunakan AWS Lambda , Greengrass
memastikan perangkat IoT Anda dapat merespons peristiwa lokal dengan cepat,
beroperasi dengan koneksi terputus-putus, dan meminimalkan biaya transmisi
data IoT ke cloud.

AWS Greengrass dengan mulus memperluas AWS ke perangkat sehingga

mereka dapat bertindak secara lokal pada data yang mereka hasilkan, sambil
tetap menggunakan cloud untuk pengelolaan, analitik, dan penyimpanan yang
tahan lama. Dengan Greengrass , Anda dapat menggunakan bahasa dan model
pemrograman yang sudah dikenal untuk membuat dan menguji perangkat lunak
perangkat Anda di cloud, lalu menyebarkannya ke perangkat Anda. AWS
Greengrass dapat diprogram untuk memfilter data perangkat dan hanya
mengirimkan kembali informasi yang diperlukan ke cloud. AWS Greengrass
mengautentikasi dan mengenkripsi data perangkat di semua titik koneksi
menggunakan kemampuan manajemen akses dan keamanan AWS IoT. Dengan
cara ini data tidak pernah dipertukarkan antar perangkat saat mereka
berkomunikasi satu sama lain dan cloud tanpa identitas yang terbukti.
 BAB III KESIMPULAN

Cache adalah salah satu teknologi untuk menyimpan data sementara supaya
dapat ditampilkan dalam sebuah aplikasi, browser, atau situs tanpa perlu
mengulang – ulang kembali dalam pemrosesan data. Jadi, pastikan anda bijak
dalam menggunakan sebuah cache. Lakukan pembersihan cache secara
berkala agar tidak membuat perangkat anda menjadi lambat.