Tantangan dan strategi Caching

Selama bertahun-tahun membangun layanan di Amazon, kami telah mengalami berbagai versi skenario berikut: Kami membangun layanan baru, dan layanan ini harus melakukan beberapa panggilan jaringan untuk memenuhi permintaannya. Ini dapat berupa panggilan ke database relasional, atau layanan AWS seperti Amazon DynamoDB, atau ke layanan internal lain. Dalam pengujian sederhana atau pada tingkat permintaan rendah, layanan ini bekerja dengan amat baik, tetapi kami melihat mulai ada masalah. Masalahnya mungkin bahwa panggilan ke layanan lain ini lamban atau bahwa scale-out database-nya mahal seiring meningkatnya volume panggilan. Kami perhatikan juga banyak permintaan menggunakan sumber daya hilir yang sama atau hasil kueri yang sama, jadi kami pikir caching untuk data ini bisa menjadi jawaban bagi masalah kami. Kami menambah cache dan layanan kami tampak jauh lebih baik. Kami amati latensi permintaan menurun, biaya berkurang, dan sedikit penurunan ketersediaan hilir dapat diperkecil lagi. Sebentar kemudian, tidak ada yang bisa mengingat apa pun sebelum cache. Dengan demikian, dependensi mengurangi ukuran armada, dan database diperkecil. Bila semuanya tampak berjalan dengan baik, layanan dapat bersiap untuk bencana. Mungkin ada perubahan pola trafik, kegagalan armada cache, atau keadaan tak terduga lainnya yang dapat menyebabkan cache dingin atau pun tidak tersedia. Ini pada gilirannya dapat menyebabkan lonjakan trafik ke layanan hilir yang dapat menyebabkan pemadaman baik dalam dependensi maupun layanan kami.

Kami baru saja menjelaskan layanan yang telah menjadi kecanduan pada cache-nya. Cache secara tidak sengaja ditingkatkan dari tambahan yang bermanfaat bagi layanan menjadi bagian dari kemampuan operasional yang penting dan vital. Inti dari masalah ini adalah perilaku modal yang ditimbulkan oleh cache, dengan perilaku yang berbeda tergantung pada apakah objek tertentu di-cache. Pergeseran tak terduga dalam distribusi perilaku modal ini dapat berpotensi menyebabkan bencana.

Kami telah berpengalaman dalam manfaat maupun tantangan caching selama membangun dan mengoperasikan layanan di Amazon. Artikel ini selebihnya menjelaskan pelajaran yang kami petik, praktik terbaik, dan pertimbangan untuk menggunakan cache.

Cache layanan dapat diimplementasikan baik di memori ataupun eksternal ke layanan. Cache on-box, yang umum diterapkan di memori proses, relatif cepat dan mudah diimplementasikan dan dapat memberikan peningkatan signifikan dengan kerja minimal. Cache on-box seringkali merupakan pendekatan pertama yang diterapkan dan dievaluasi begitu kebutuhan caching diidentifikasi. Berbeda dengan cache eksternal, cache on-box tidak memiliki overhead operasional tambahan, sehingga risikonya rendah bila diintegrasikan ke layanan yang ada. Kami sering mengimplementasikan cache on-box sebagai tabel hash dalam memori yang dikelola melalui logika aplikasi (misalnya, secara eksplisit menempatkan hasil ke cache setelah panggilan layanan selesai) atau tertanam di klien layanan (misalnya, dengan menggunakan klien HTTP caching).

Terlepas manfaat dan kesederhanaan menarik cache dalam memori, memang terdapat beberapa kelemahan. Salah satunya adalah bahwa data ter-cache tidak selalu konsisten dari server ke server di seluruh armadanya, sehingga menimbulkan masalah koherensi cache. Jika klien melakukan panggilan berulang ke layanan, data lebih baru yang digunakan dalam panggilan pertama dan data lama dalam panggilan kedua mungkin akan diperoleh, tergantung server mana yang menangani permintaan tersebut.

Kelemahan lain adalah bahwa beban hilir kini sebanding dengan ukuran armada layanan, sehingga ketika jumlah server bertambah, masih mungkin untuk mengatasi layanan dependen. Kami dapati bahwa cara yang efektif untuk memantau ini adalah dengan mengeluarkan metrik pada hit/miss cache dan jumlah permintaan ke layanan hilir.

Cache dalam memori juga rentan terhadap masalah “start dingin”. Masalah-masalah ini terjadi ketika server baru diluncurkan dengan cache yang benar-benar kosong, yang dapat menyebabkan ledakan permintaan ke layanan dependen selagi mengisi cache-nya. Ini bisa menjadi masalah besar selama penerapan atau dalam keadaan lain di mana cache digelontorkan di seluruh armada. Koherensi cache dan masalah cache kosong umumnya dapat diatasi dengan penggabungan permintaan, yang dijelaskan secara rinci kelak dalam artikel ini.

Cache eksternal dapat mengatasi banyak masalah yang baru saja kita bahas. Cache eksternal menyimpan data ter-cache di armada terpisah, misalnya dengan menggunakan Memcached atau Redis. Masalah koherensi cache berkurang karena cache eksternal memegang nilai yang digunakan semua server pada armada. (Perlu dicatat masalah ini tidak sepenuhnya teratasi karena mungkin ada kasus kegagalan saat memperbarui cache.) Beban keseluruhan pada layanan hilir berkurang dibandingkan dengan cache di memori dan tidak sebanding dengan ukuran armada. Tidak ada masalah start dingin selama berlangsungnya peristiwa seperti penerapan karena cache eksternal tetap terpopulasi di seluruh penerapan. Akhirnya, cache eksternal menyediakan lebih banyak ruang penyimpanan daripada cache di dalam memori, sehingga mengurangi eviksi cache karena kendala ruang.

Akan tetapi, cache eksternal memiliki kekurangannya sendiri yang harus dipertimbangkan. Yang pertama adalah peningkatan kompleksitas sistem dan beban operasional secara keseluruhan, karena ada armada tambahan untuk memantau, mengelola, dan membuat skala. Karakteristik ketersediaan armada cache akan berbeda dari layanan dependen yang digunakannya sebagai cache. Armada cache sering kali bisa saja kurang tersedia, misalnya, jika tidak memiliki dukungan untuk pemutakhiran zero-downtime dan jika memerlukan jendela pemeliharaan.

Agar ketersediaan layanan tidak terdegradasi karena cache eksternal, ternyata kami harus menambahkan kode layanan untuk menangani ketidaktersediaan armada cache, kegagalan simpul cache, atau kegagalan penyimpanan/pengambilan cache. Satu opsi adalah kembali menggunakan layanan dependen, tetapi kami sadar bahwa kami harus berhati-hati mengambil pendekatan ini. Selama gangguan cache berkepanjangan, ini akan menyebabkan lonjakan trafik yang tidak lazim ke layanan hilir, menyebabkan pelambatan atau pengurangan layanan dependen itu dan pada akhirnya mengurangi ketersediaan. Kami lebih memilih menggunakan cache eksternal sekaligus cache dalam memori yang dapat digunakan kembali jika cache eksternal menjadi tidak tersedia, atau menggunakan pelepasan muatan dan membatasi tingkat maksimum permintaan yang dikirim ke layanan hilir. Kami menguji perilaku layanan dengan caching dinonaktifkan untuk memvalidasi apakah pengaman yang kami buat untuk mencegah penurunan dependensi benar-benar berfungsi sesuai harapan.

Pertimbangan kedua adalah penskalaan dan elastisitas armada cache. Saat armada cache mulai mencapai tingkat permintaan atau batas memori, simpul harus ditambahkan. Kami menentukan metrik mana yang merupakan indikator utama batas ini agar kami dapat mengatur monitor dan alarm. Misalnya, pada layanan yang baru-baru ini saya kerjakan, tim kami menemukan bahwa pemanfaatan CPU menjadi sangat tinggi karena tingkat permintaan Redis mencapai batasnya. Kami menggunakan pengujian beban dengan pola trafik realistis untuk menentukan batas dan mencari ambang alarm yang tepat.

Saat menambah kapasitas ke armada cache, kami berhati-hati agar tidak memicu gangguan atau hilangnya data cache dalam jumlah besar. Teknologi caching yang berbeda memiliki pertimbangan unik.. Misalnya, beberapa server cache tidak mendukung penambahan simpul ke cluster tanpa downtime, dan tidak semua perpustakaan klien cache menyediakan hashing yang konsisten, yang diperlukan untuk menambahkan simpul ke armada cache dan me-redistribusi data ter-cache. Karena variabilitas dalam implementasi hashing yang konsisten oleh klien dan penemuan simpul di armada cache, kami secara menyeluruh menguji menambah dan menghapus server cache sebelum tahap produksi.

Dengan cache eksternal, kami sangat berhati-hati untuk memastikan ketahanan ketika format penyimpanan diubah. Data ter-cache diperlakukan seolah terus menerus disimpan. Kami memastikan bahwa perangkat lunak yang diperbarui selalu dapat membaca data yang ditulis oleh versi perangkat lunak sebelumnya, dan bahwa versi lama dapat menangani tampilan/bidang baru dengan baik (misalnya, selama penerapan bila ada campuran kode lama dan baru pada armada). Mencegah pengecualian tak tertangkap saat ditemukannya format tak terduga diperlukan untuk mencegah pil racun. Tetapi, ini tidak cukup untuk mencegah semua masalah terkait format. Mendeteksi ketidakcocokan format versi dan membuang data ter-cache dapat menyebabkan penyegaran massal cache, yang dapat menyebabkan pelambatan atau brownout layanan dependen. masalah format serialisasi dicakup dalam kedalaman yang lebih besar pada Memastikan keamanan rollback selama penerapan.

Pertimbangan terakhir untuk cache eksternal adalah bahwa cache eksternal diperbarui oleh masing-masing node di armada layanan. Cache biasanya tidak memiliki fitur seperti tulis dan transaksi kondisional, jadi kami berhati-hati untuk memastikan bahwa kode pembaruan cache benar dan tidak pernah bisa meninggalkan cache dalam keadaan tidak valid atau tidak konsisten.

Keputusan lain yang perlu dibuat ketika kami mengevaluasi bermacam pendekatan caching adalah pilihan antara cache inline dan side. Inline cache, atau cache read-through/write-through, menggabung manajemen cache ke API akses data utama, menjadikan manajemen cache sebagai detail implementasi dari API itu. Contohnya termasuk implementasi spesifik aplikasi seperti Amazon DynamoDB Accelerator (DAX) dan implementasi berbasis standar seperti caching HTTP (baik dengan klien caching lokal atau server cache eksternal seperti Nginx atau Varnish). Cache side, di sisi lain, adalah penyimpanan objek generik seperti yang disediakan oleh Amazon ElastiCache (Memcached dan Redis) atau perpustakaan seperti Ehcache dan Google Guava untuk cache dalam memori. Dengan cache side, kode aplikasi langsung memanipulasi cache sebelum dan sesudah panggilan ke sumber data, memeriksa objek ter-cache sebelum melakukan panggilan hilir, dan meletakkan objek di cache setelah panggilan selesai.

Manfaat utama cache inline adalah model API yang seragam untuk klien. Caching dapat ditambahkan, dihapus, atau diubah tanpa mengubah logika klien. Cache inline juga mengeluarkan logika manajemen cache dari kode aplikasi, sehingga menghilangkan sumber potensi bug. Cache HTTP khususnya sangat menarik karena ada banyak opsi yang tersedia, seperti pustaka dalam-memori, proksi HTTP mandiri seperti yang disebutkan sebelumnya, dan layanan terkelola seperti jaringan pengiriman konten (CDN).

Akan tetapi, transparansi cache inline juga bisa menjadi titik lemah ketersediaan. Cache eksternal kini menjadi bagian dari persamaan ketersediaan untuk dependensi ini. Tidak ada peluang bagi klien untuk mengkompensasi cache yang sementara tidak tersedia. Misalnya, jika Anda memiliki armada Varnish yang meng-cache permintaan dari layanan REST eksternal, maka jika armada cache menurun, dari perspektif layanan Anda hal ini seolah dependensi itu sendirilah yang menurun. Kelemahan lain adalah bahwa cache inline harus dibangun ke dalam protokol atau layanan yang di-cache olehnya. Jika cache inline untuk protokol tidak tersedia, maka cache inline ini bukan pilihan kecuali Anda ingin membangun sendiri klien terintegrasi atau layanan proxy.

Beberapa detail implementasi cache yang paling menantang adalah memilih ukuran cache yang tepat, kebijakan ekspirasi, dan kebijakan eviksi. Kebijakan ekspirasi menentukan berapa lama mempertahankan suatu item di cache. Kebijakan paling umum menggunakan ekspirasi berbasis waktu absolut (yaitu, mengaitkan waktu untuk hidup (TTL) dengan setiap objek saat dimuat). TTL dipilih sesuai kebutuhan klien, seperti seberapa toleran klien terhadap data kedaluwarsa, dan seberapa statis data tersebut, karena perubahan data yang lambat dapat di-cache secara lebih agresif. Ukuran cache ideal didasarkan pada model volume permintaan terantisipasi dan distribusi objek ter-cache di seluruh permintaan itu. Dari situ, kami mengestimasi ukuran cache yang memastikan hit rate cache yang tinggi dengan pola trafik ini. Kebijakan eviksi mengontrol bagaimana item dihapus dari cache ketika mencapai kapasitas. Kebijakan eviksi yang paling umum adalah Least Recent Used (LRU).

Sejauh ini, ini hanyalah senam pikiran. Pola trafik dunia nyata dapat berbeda dari apa yang kami modelkan, jadi kami melacak kinerja aktual cache kami. Cara pilihan kami untuk melakukannya adalah dengan mengeluarkan metrik layanan pada hit dan miss cache, total ukuran cache, dan jumlah permintaan ke layanan hilir.

Kami akhirnya tahu bahwa kami perlu menimbang tentang mengambil ukuran cache dan nilai kebijakan ekspirasi. Kami ingin menghindari situasi di mana pengembang secara sewenang-wenang mengambil beberapa ukuran cache dan nilai TTL selama implementasi awal dan kemudian tidak pernah kembali dan memvalidasi kesesuaiannya di lain waktu. Kami telah melihat contoh nyata dari kurangnya tindak lanjut yang memicu pemutusan layanan sementara dan memperburuk gangguan yang sedang berlangsung

Pola lain yang kami gunakan untuk meningkatkan ketahanan ketika layanan hilir tidak tersedia adalah dengan menggunakan dua TTL: TTL lunak dan TTL keras. Klien akan mencoba untuk menyegarkan item ter-cache berdasarkan soft TTL, tetapi jika layanan hilir tidak tersedia atau pun tidak menanggapi permintaan, maka data cache yang ada akan terus digunakan hingga TTL keras tercapai. Contoh dari pola ini digunakan pada klien AWS Identity and Access Management (IAM).

Kami juga menggunakan pendekatan TTL lunak dan keras dengan tekanan balik untuk mengurangi dampak brownout layanan hilir. Layanan hilir dapat merespons peristiwa tekanan balik bila mengalami brownout, yang menandakan bahwa layanan panggilan harus menggunakan data ter-cache sampai TTL keras dan hanya membuat permintaan untuk data yang tidak ada dalam cache. Kami melanjutkan ini sampai layanan hilir menyingkirkan tekanan balik. Pola ini memungkinkan layanan hilir pulih dari brownout sambil menjaga ketersediaan layanan hulu.

Pertimbangan penting adalah bagaimana perilaku cache ketika kesalahan diterima dari layanan hilir. Salah satu opsi untuk menangani ini adalah membalas klien menggunakan nilai baik ter-cache paling akhir, misalnya meningkatkan pola TTL lunak/TTL keras yang dijelaskan di atas. Opsi lain yang kami gunakan adalah meng-cache respons kesalahan (yaitu, kami menggunakan “cache negatif”) dengan menggunakan TTL yang berbeda dari entri cache positif, dan mempropagandakan kesalahan ke klien. Pendekatan yang kami pilih dalam situasi tertentu tergantung pada rincian layanan dan dengan mengevaluasi waktu yang lebih baik bagi klien untuk melihat data kedaluwarsa versus kesalahan. Terlepas pendekatan yang kami ambil, kami harus memastikan sesuatu berada di cache bila terjadi kesalahan. Jika bukan ini masalahnya dan layanan hilir sementara tidak tersedia atau tidak dapat memenuhi permintaan tertentu (misalnya ketika sumber daya hilir dihapus), layanan hulu akan terus membombardirnya dengan trafik dan berpotensi menimbulkan gangguan atau memperburuk yang sudah ada. Kami telah melihat contoh dunia nyata di mana kegagalan menyimpan respons negatif menyebabkan meningkatnya kegagalan dan kesalahan.

Keamanan adalah aspek penting lainnya pada caching. Saat kami menyertakan cache ke layanan, kami mengevaluasi dan mengurangi risiko keamanan lain apa pun yang ditimbulkan. Sebagai contoh, armada caching eksternal sering kekurangan enkripsi untuk data serial dan keamanan tingkat transportasi. Ini sangat penting jika informasi sensitif milik pengguna disimpan di cache. Masalah ini dapat diatasi dengan menggunakan misalnya Amazon ElastiCache for Redis, yang mendukung enkripsi in-transit dan at-rest. Cache juga rentan terhadap serangan keracunan, di mana kerentanan protokol hilir memungkinkan penyerang mengisi cache dengan nilai menurut keinginan mereka. Ini memperbesar dampak serangan, karena semua permintaan yang dibuat saat nilai ini berada di cache akan melihat nilai yang berbahaya. Untuk satu contoh terakhir, cache juga rentan terhadap serangan timing side-channel. Nilai ter-cache dikembalikan lebih cepat dari nilai tak ter-cache, sehingga penyerang dapat menggunakan waktu respons untuk mendapatkan informasi tentang permintaan yang dibuat klien atau prinsip lain.

Salah satu pertimbangan terakhir adalah situasi “thundering herd”, di mana banyak klien membuat permintaan yang membutuhkan sumber daya hilir tak ter-cache yang sama secara hampir berbarengan. Ini juga dapat terjadi bila suatu server muncul dan bergabung dengan armada yang cache lokalnya kosong. Ini menghasilkan banyaknya permintaan dari masing-masing server yang menuju ke dependensi hilir, dan dapat menyebabkan pelambatan/brownout. Untuk memperbaiki masalah ini, kami menggunakan penggabungan permintaan, di mana server atau cache eksternal memastikan bahwa hanya satu permintaan tertunda yang keluar untuk sumber daya tak ter-cache. Beberapa perpustakaan caching menyediakan dukungan penggabungan permintaan, dan demikian pula beberapa cache inline eksternal (seperti Nginx atau Varnish). Selain itu, penggabungan permintaan dapat dilakukan di atas cache yang ada. 

Artikel ini mengulas beberapa praktik terbaik dan pertukaran Amazon serta risiko yang terkait dengan caching. Berikut ini ringkasan praktik terbaik dan pertimbangan yang digunakan tim kami saat memperkenalkan cache:

• Memastikan ada kebutuhan yang sah akan cache yang dibenarkan dalam hal peningkatan biaya, latensi, dan/atau ketersediaan. Memastikan bahwa data tersebut dapat di-cache, yang berarti bisa digunakan di beberapa permintaan klien. Skeptis-lah terhadap nilai yang akan dihasilkan cache, dan hati-hati mengevaluasi bahwa manfaatnya akan lebih besar dari risiko lainnya yang ditimbulkan cache.
• Rencanakan untuk mengoperasikan cache dengan kekakuan dan proses yang sama untuk armada dan infrastruktur layanan selebihnya. Jangan menganggap remeh upaya ini. Keluarkan metrik pada pemanfaatan cache dan hit rate untuk memastikan cache diselaraskan dengan tepat. Pantau indikator utama (seperti CPU dan memori) untuk memastikan bahwa armada caching eksternal sehat dan diskalakan dengan tepat. Buat alarm pada metrik ini. Pastikan armada cache dapat ditingkatkan tanpa downtime atau pembatalan cache massal (yaitu, validasikan bahwa hashing konsisten berfungsi seperti yang diharapkan.)
• Cermat dan telitilah dalam memilih ukuran cache, kebijakan ekspirasi, dan kebijakan eviksi. Lakukan tes dan gunakan metrik yang disebutkan pada butir di atas untuk memvalidasi dan menyesuaikan pilihan ini.
• Pastikan bahwa layanan Anda tangguh menghadapi ketidaktersediaan cache, yang mencakup berbagai keadaan yang menyebabkan ketidakmampuan melayani permintaan menggunakan data ter-cache. Ini termasuk start dingin, gangguan armada caching, perubahan pola trafik, atau gangguan hilir berkepanjangan. Di banyak kasus, ini bisa berarti melepaskan sebagian dari ketersediaan Anda untuk memastikan bahwa server Anda dan layanan dependen Anda tidak hilang (misalnya dengan membuang beban, membatasi permintaan ke layanan dependen, atau menyajikan data kedaluwarsa). Jalankan uji beban dengan cache dinonaktifkan untuk memvalidasi ini.
• Pertimbangkan aspek keamanan mempertahankan data ter-cache, termasuk enkripsi, keamanan transportasi bila berkomunikasi dengan armada caching eksternal, dan dampak serangan keracunan cache dan serangan side-channel.
• Merancang format penyimpanan untuk perkembangan objek ter-cache dari waktu ke waktu (misalnya, menggunakan nomor versi) dan menulis kode serialisasi yang mampu membaca versi yang lebih lama. Waspadalah terhadap pil racun di logika serialisasi cache Anda.
• Evaluasi bagaimana cache menangani kesalahan hilir, dan pertimbangkan mempertahankan cache negatif dengan TTL berbeda. Jangan menyebabkan atau memperbesar gangguan dengan berulang kali meminta sumber daya hilir yang sama dan membuang respons kesalahan.

Banyak tim layanan di Amazon menggunakan teknik caching. Terlepas dari manfaat teknik-teknik ini, kami tidak mengambil keputusan untuk memasukkan caching begitu saja karena kelemahannya sering kali lebih besar daripada kelebihannya. Kami berharap artikel ini kiranya dapat membantu saat Anda mengevaluasi caching di layanan Anda sendiri.