CloudFront untuk aplikasi e-commerce dan marketplace

Aplikasi e-commerce atau pasar melayani tiga jenis konten yang berbeda melalui satu CloudFront distribusi: aset statis (gambar produk, CSS, JavaScript), halaman dinamis (daftar produk, hasil pencarian), dan respons API (keranjang, inventaris, harga). Setiap jenis konten memerlukan perilaku cache, TTL, dan konfigurasi asal yang berbeda untuk menyeimbangkan kesegaran terhadap kinerja.

Untuk kontrol keamanan yang berlaku untuk distribusi pasar dan e-commerce, lihatDaftar periksa keamanan untuk distribusi pasar.

Gambaran umum arsitektur

Distri CloudFront busi pasar menggunakan beberapa perilaku cache untuk merutekan permintaan ke asal yang benar berdasarkan pola jalur URL. Aset statis dilayani dari Amazon Simple Storage Service (Amazon S3), sementara konten dinamis dan permintaan API diteruskan ke Elastic Load Balancer (Application Load Balancer) di depan server aplikasi Anda. Cluster ElastiCache (Valkey) menyediakan cache tingkat aplikasi antara ALB dan database Anda untuk data produk yang sering diakses.

Komponen arsitektur distribusi

Komponen	Konten yang disajikan	Tujuan
CloudFront distribusi	Semua konten (domain tunggal)	Caching tepi global, penghentian TLS, perutean permintaan dengan menggunakan perilaku cache
Asal Amazon S3 (aset statis)	Gambar produk, CSS, JS, font	Penyimpanan objek tahan lama dengan kontrol akses asal (OAC). Konten yang tidak dapat diubah dengan TTL panjang.
Asal ALB (konten dinamis)	Halaman produk, pencarian, titik akhir API	Rute ke server aplikasi. TTL pendek atau tanpa caching untuk konten yang dipersonalisasi.
ElastiCache cluster (Valkey)	Katalog produk, jumlah inventaris, data sesi	Application-level cache antara ALB dan database. Sub-millisecond membaca untuk data yang sering diakses.

Perilaku cache untuk e-commerce

Perilaku cache menentukan cara CloudFront menangani permintaan berdasarkan pola jalur URL. Untuk pasar, konfigurasikan perilaku terpisah untuk setiap jenis konten dengan kebijakan cache dan TTL yang sesuai.

Perilaku cache yang disarankan

Pola jalur	asal	TTL	Kebijakan cache	Alasannya
/static/*	Amazon S3	365 hari	CachingOptimized	Nama file berversi (misalnya,app.a1b2c3.js) memungkinkan TTL maksimum. Pembatalan cache tidak pernah diperlukan — gunakan versi baru dengan nama file baru.
/images/*	Amazon S3	30 hari	CachingOptimized	Gambar produk jarang berubah. Gunakan pembatalan cache-tag saat penjual memperbarui gambar. TTL lebih rendah daripada aset statis karena URL gambar dapat digunakan kembali.
/api/products/*	ALB	60 detik	Kustom (termasuk string kueri)	Daftar produk dan API pencarian sering berubah tetapi mentolerir kebuntuan singkat. Sertakan parameter string kueri dalam kunci cache untuk paginasi dan filter.
/api/cart/*	ALB	0 (tanpa cache)	CachingDisabled	Operasi keranjang bersifat khusus pengguna dan harus selalu mencapai asal. Nonaktifkan caching sepenuhnya.
/api/inventory/*	ALB	5 detik	Kustom (termasuk string kueri)	Jumlah inventaris berubah dengan cepat selama acara penjualan. TTL yang sangat pendek mencegah overselling sekaligus mengurangi beban asal.
Default (*)	ALB	0 (tanpa cache)	CachingDisabled	Perilaku default meneruskan permintaan yang tidak di-cache ke aplikasi untuk rendering sisi server. Halaman yang menyertakan konten yang dipersonalisasi (rekomendasi, nama pengguna) tidak boleh di-cache di tepi.

catatan

Urutkan perilaku cache dari yang paling spesifik ke yang paling tidak spesifik. CloudFront mengevaluasi pola jalur dalam urutan yang tercantum dan menggunakan kecocokan pertama. Tem /api/cart/* patkan sebelumnya /api/* untuk memastikan permintaan keranjang melewati caching.

Untuk informasi selengkapnya tentang perilaku cache, lihatPengaturan perilaku cache.

Strategi TTL untuk konten pasar

Konfigurasi TTL menentukan berapa lama CloudFront menyajikan konten yang di-cache sebelum memeriksa asal untuk pembaruan. E-commerce aplikasi memerlukan strategi TTL yang berbeda tergantung pada bagaimana kesegaran konten mempengaruhi pengalaman pelanggan.

Aset yang tidak dapat diubah (CSS, JS, font)

Tetapkan TTL maksimum (365 hari). Gunakan nama file yang di-hash konten sehingga setiap penerapan membuat URL baru. Jangan pernah membatalkan - versi lama kedaluwarsa secara alami saat pengguna memuat nama file baru. Tet Cache-Control: public, max-age=31536000, immutable apkan di asal.

Gambar produk

Setel TTL ke 30 hari dengan pembatalan tag cache pada pembaruan. Saat penjual mengunggah gambar baru, batalkan dengan tag cache produk, bukan dengan jalur. Ini hanya menargetkan objek yang terpengaruh tanpa pembatalan wildcard yang luas. Tet Cache-Control: public, max-age=2592000 apkan di asal.

Katalog Produk API

Atur TTL ke 60 detik. Daftar produk, deskripsi, dan harga mentolerir kebuntuan singkat. Ini mengurangi beban asal selama lonjakan lalu lintas (penjualan kilat, peluncuran produk) sambil menjaga data tetap terkini. Set Cache-Control: public, max-age=60, stale-while-revalidate=30 el untuk menyajikan konten basi sambil CloudFront mengambil respons baru di latar belakang.

API inventaris dan harga

Setel TTL menjadi 5 detik. Nilai-nilai ini sering berubah dan memengaruhi keputusan pembelian. Caching yang sangat singkat masih mengurangi beban asal secara berurutan selama lonjakan lalu lintas - ribuan pengguna bersamaan melihat respons cache 5 detik yang sama alih-alih masing-masing mengenai asal.

User-specific konten (keranjang, rekomendasi)

Nonaktifkan caching (TTL = 0). Konten yang bervariasi per pengguna harus selalu mencapai asal. Jika Anda melakukan cache konten khusus pengguna secara tidak sengaja, CloudFront mungkin menyajikan data satu pengguna ke pengguna lain. Gunakan kebijakan CachingDisabled terkelola untuk perilaku ini.

Konfigurasi asal

Asal Amazon S3 untuk aset statis

Gunakan bucket Amazon S3 sebagai sumber untuk gambar produk dan aset statis. Konfigurasikan kontrol akses asal (OAC) untuk membatasi akses langsung ke bucket — semua permintaan harus mengalir melalui CloudFront.

Pengaturan asal Amazon S3

Pengaturan	Nilai	Alasannya
Domain asal	marketplace-assets.s3.amazonaws.com	Gunakan titik akhir Amazon S3 REST API (bukan titik akhir situs web) untuk mendukung OAC.
Akses asal	Kontrol akses asal (OAC)	Membatasi akses bucket CloudFront hanya. Mencegah akses URL S3 langsung ke aset Anda.
Perisai Asal	Diaktifkan (wilayah terdekat dengan bucket)	Menambahkan lapisan caching terpusat antara lokasi tepi dan asal. Mengurangi biaya permintaan S3 dan meningkatkan rasio hit cache untuk gambar.
Upaya koneksi	3	Default. Mencoba lagi pada kesalahan S3 sementara.

Asal ALB untuk konten dinamis

Gunakan Application Load Balancer sebagai asal untuk halaman produk dinamis, pencarian, dan titik akhir API. ALB merutekan ke server aplikasi Anda (instans Amazon EC2, tugas Amazon ECS, atau fungsi Lambda dengan menggunakan grup target).

Pengaturan asal ALB

Pengaturan	Nilai	Alasannya
Domain asal	Nama DNS ALB	Gunakan nama DNS ALB secara langsung. Jangan gunakan alamat IP — IP ALB berubah.
Protokol	Hanya HTTPS	Mengenkripsi lalu lintas antara CloudFront dan asal. Diperlukan untuk data sensitif (sesi pengguna, info pembayaran).
Header kustom asal	X-Origin-Verify: <secret-value>	Membatasi akses ALB ke permintaan dari CloudFront. ALB memeriksa header ini dan menolak upaya akses langsung.
Batas waktu koneksi	10 detik	Lebih pendek dari default (30s). Gagal cepat pada masalah asal daripada membuat koneksi tepi menunggu.
Waktu tunggu respons	30 detik	Memungkinkan waktu untuk kueri pencarian yang kompleks dan operasi katalog. Tingkatkan jika API Anda memiliki operasi yang berjalan lama.
Keep-alive batas waktu	5 detik	Menggunakan kembali koneksi ke ALB. Mengurangi overhead jabat tangan TLS untuk permintaan berikutnya.

Application-level caching dengan ElastiCache (Valkey)

CloudFront menyimpan konten di tepi, tetapi data yang sering diakses yang memerlukan kueri database mendapat manfaat dari cache tingkat aplikasi tambahan. ElastiCache Cluster yang menjalankan Valkey berada di antara server aplikasi Anda dan database, menyediakan pembacaan sub-milidetik untuk data katalog produk, jumlah inventaris, dan status sesi.

Two-tier strategi caching

Lapisan	Apa yang disimpan	TTL	Perilaku kehilangan cache
CloudFront tepi	Tanggapan HTTP lengkap (API JSON, halaman HTML, gambar)	5s - 365d (berdasarkan perilaku)	Meneruskan permintaan ke asal ALB
ElastiCache (Valkey)	Objek data aplikasi (catatan produk, inventaris, sesi)	30s - 5 menit (berdasarkan tipe data)	Aplikasi menanyakan database dan menulis hasilnya ke cache

Pada permintaan halaman produk:

1. CloudFront memeriksa cache tepinya. Saat dipukul, segera mengembalikan respons yang di-cache.

2. Jika gagal, CloudFront maju ke ALB.

3. Aplikasi memeriksa ElastiCache data produk. Saat dipukul, membangun respons dari data yang di-cache (sub-milidetik).

4. Jika ElastiCache ketinggalan, menanyakan database, menulis ke ElastiCache, dan mengembalikan respons.

5. CloudFront menyimpan respons di tepi sesuai dengan pengaturan TTL perilaku.

Ketika penjual memperbarui produk:

1. Aplikasi membatalkan kunci produk di. ElastiCache

2. Aplikasi mengirimkan pembatalan tag cache ke CloudFront tag produk.

3. Permintaan berikutnya memicu respons baru melalui kedua lapisan cache.

Pertanyaan umum

Bagian berikut menjawab pertanyaan umum tentang strategi caching untuk beban kerja e-commerce dan pasar.

Bagaimana cara menangani konten yang dipersonalisasi dengan caching?

Pisahkan elemen yang dipersonalisasi dari konten yang dapat di-cache. Sajikan shell halaman (detail produk, gambar, deskripsi) dari CloudFront cache, dan muat elemen yang dipersonalisasi (rekomendasi, jumlah keranjang, nama pengguna) dengan menggunakan panggilan API sisi klien yang melewati caching. Dengan pendekatan ini, Anda dapat menyimpan rendering halaman yang mahal dan menjaga personalisasi tetap terkini.

Bagaimana cara memilih antara TTL pembatalan dan TTL pendek?

Gunakan TTL pendek (5—60 detik) untuk konten yang sering berubah dan dapat diprediksi (inventaris, harga). Gunakan pembatalan untuk konten yang jarang berubah tetapi harus segera diperbarui saat terjadi (gambar produk setelah penjual mengedit, deskripsi produk setelah tinjauan kepatuhan). Pembatalan memiliki biaya per permintaan dan batas konkurensi — jangan menggunakannya sebagai pengganti TTL yang sesuai.

Bagaimana cara mempersiapkan penjualan kilat dan lonjakan lalu lintas?

CloudFront menskalakan secara otomatis untuk menangani lonjakan lalu lintas. Untuk memaksimalkan rasio hit cache selama penjualan: lakukan pemanasan halaman produk dengan memintanya sebelum acara dimulai, tingkatkan TTL API sementara (misalnya, tingkatkan TTL inventaris dari 5 detik menjadi 15 detik) untuk menyerap lebih banyak lalu lintas di tepi, dan pastikan ElastiCache cluster Anda memiliki ruang memori yang cukup untuk peningkatan penulisan cache. Pantau metrik rasio hit CloudFront cache selama acara berlangsung.

Haruskah saya menggunakan Origin Shield untuk pasar saya?

Ya. Origin Shield menambahkan lapisan cache terpusat antara cache tepi regional dan asal Anda. Untuk beban kerja e-commerce, ini mengurangi permintaan asal untuk produk populer (karena hit cache di Origin Shield melayani semua lokasi tepi), mengurangi biaya S3 GET untuk gambar, dan memperlancar lonjakan lalu lintas ke ALB. Aktifkan di Wilayah terdekat dengan asal Anda. Lihat informasi yang lebih lengkap di Gunakan Amazon CloudFront Origin Shield.