Önbelleğe alma zorlukları ve stratejileri

Yıllar boyunca Amazon’da hizmet oluştururken şu senaryoların çeşitli versiyonlarını yaşadık: Yeni bir hizmet oluştururuz ve bu hizmetin isteklerini gerçekleştirmek için bazı ağ çağrıları yapması gerekir. Bu çağrılar bir ilişkisel veri tabanına, Amazon Dynamodb gibi bir AWS hizmetine veya diğer bir dahili hizmete yapılıyor olabilir. Basit testlerde veya düşük istek oranlarında hizmet sorunsuz çalıştığını, ancak Horizon’da bir sorun olduğunu fark ederiz. Bu sorun, söz konusu diğer hizmete yapılan çağrının yavaş olması veya arama boyutu arttıkça veri tabanının ölçeğini genişletmenin pahalı olması olabilir. Aynı zamanda birçok isteğin aynı aşağı akış kaynağını veya aynı sorgu sonuçlarını kullandığını fark ederiz ve bu nedenle bu verilerin önbelleğe alınmasının sorunlarımızı çözebileceğini düşünürüz. Bir önbellek ekleriz ve hizmetimizin daha da iyileştiğini görürüz. Ayrıca, istek gecikme süresinin düşük olduğunu, maliyetin azaldığını ve aşağı akış erişilebilirliğine ilişkin küçük azalmaların düzeldiğini görürüz. Bir süre sonra hiç kimse ön bellek eklenmeden önceki durumu hatırlayamaz. Bu doğrultuda bağımlılıkların filo boyutu azalır ve veri tabanının ölçeği küçülür. Her şey yolunda gidiyor gibi görünürken hizmet bir felakete hazır olabilir. Trafik modellerinde değişiklikler olabilir, önbellek filosu çalışmayabilir veya önbelleğin seyrek erişilebilir duruma gelmesine veya diğer bir şekilde kullanılamamasına neden olabilen beklenmedik durumlar oluşabilir. Bu da aşağı akış hizmetimizin trafiğinin hem bağımlılıklarımızda hem de hizmetimizde kesintilere neden olabilecek şekilde dalgalanmasına yol açabilir.

Burada ön belleğine bağımlı hale gelmiş bir hizmeti açıkladık. Hizmetin çalışabilmesi için gerekli olan ve kritik bir parçasına yapılan faydalı bir eklemeden önbellek yanlışlıkla çıkarılmıştır. Bu sorunun temelinde önbelleğinin tanıttığı tipik davranışlar vardır. Bu davranışlar belirli bir nesnenin önbelleğe alınıp alınmadığına göre farklılık gösterir. Bu tipik davranışın dağıtımındaki beklenmeyen bir kayma bir felakete neden olabilir.

Amazon’da hizmet oluşturma ve işletme sürecinde önbelleğe alma işleminin hem faydalarını hem de zorluklarını yaşadık. Bu makalenin geri kalanında öğrendiğimiz dersler, en iyi uygulamalar ve önbelleklerin kullanımına ilişkin dikkat edilecek hususlar açıklanmaktadır.

Hizmet önbellekleri, bellekte ya da hizmetin dışında uygulanabilir. Genellikle işlem belleğinde uygulanan on-box önbellekler nispeten hızlıdır ve uygulanmaları kolaydır. Bunlar, minimum çabayla önemli iyileşmeler sağlayabilir. On-box önbellekler, önbellek ihtiyacı tanımlandığında sıklıkla ilk uygulanan ve değerlendirilen yaklaşımlardır. zHarici önbelleklerin aksine, hiçbir ek operasyonel iş yükleri olmaz ve bu yüzden var olan hizmete entegreleri daha düşük risklidir. Sıklıkla uygulama mantığı ile yönetilen (örneğin, hizmet aramaları tamamlandıktan sonra sonuçları açıkça önbelleğe yerleştirerek) veya hizmet istemcisine gömülen (örneğin bir HTTP istemcisini ön belleğe almayı kullanarak) bellek içi komut tablosu olarak bir on-box önbellek uygularız.

Bellek içi önbelleklerin avantajları ve çekici basitliğine rağmen bunların birkaç dezavantajı vardır. Bunlardan biri, önbelleğe alınan verilerin filo genelinde sunucular arasında tutarsızlık göstermesi ve bu sebeple bir önbellek tutarlılığı sorununa yol açmasıdır. Bir istemci, hizmete tekrar tekrar çağrı yaparsa hangi sunucunun isteği ele aldığına bağlı olarak ilk çağrıda kullanımdaki daha yeni verileri, ikinci çağrıda ise daha eski verileri alabilir.

Başka bir eksiklikse aşağı akış yükünün artık hizmetin filo boyutu ile orantılı olmasıdır. Yani, sunucu sayısı arttıkça bağlı hizmetlerin yetersiz kalması hala mümkün olabilir. Bunu gözlemlemenin etkili bir yolu önbellek isabetleri/kaçırmalarındaki ölçümleri ve aşağı akış hizmetlerine yapılan istek sayılarını yayınlamaktır.

Bellek içi önbellekler aynı zamanda “hazırlıksız başlangıç” sorunlarına karşı hassastır. Bu sorunlar yeni bir sunucunun tamamen boş bir önbellekle çalıştığı yerde oluşur. Bu da önbelleğini doldurdukça bağımlı hizmete çok fazla istek gönderilmesine sebep olabilir. Bu dağıtımlar veya önbelleğin filo boyutunda boşaltıldığı diğer durumlar sırasında önemli olabilir. Önbellek tutarlılığı ve boş önbellek sorunları, daha sonra bu makalenin ilerleyen kısımlarında detaylı olarak ele alınacak istek birleştirme özelliği kullanarak giderilebilir.

Harici önbellekler yukarıda belirttiğimiz sorunların birçoğunu giderebilir. Bir harici önbellek, önbelleğe alınan verileri Memcached veya Redis gibi bir sistem kullanarak ayrı bir filoda depolar. Harici önbellek filodaki tüm sunucular tarafından kullanılan değeri tuttuğu için, önbellek tutarlılığı sorunları azalır. (Önbellek güncellenirken hata olayları meydana gelebileceğinden bu sorunların tamamen ortadan kalkmadığını unutmayın.) Aşağı akış hizmetlerindeki genel yük bellek içi önbelleklere göre düşüktür ve filo boyutu ile orantılı değildir. Harici önbellek dağıtım süresince dolu olarak kaldığından dağıtım gibi olaylar sırasında ortaya çıkan hazırlıksız başlangıç sorunları görülmez. Son olarak, harici önbellekler bellek içi önbelleklere göre daha fazla kullanılabilir depolama alanı sağlar ve böylece alan kısıtlamaları nedeniyle önbellek çıkarma durumları daha az meydana gelir.

Ancak, harici önbellekler dikkate alınması gereken kendilerine özgü birtakım kusurlara sahiptir. İlk olarak, izlenmesi, yönetilmesi ve ölçeklendirilmesi gereken ek bir filo bulunduğundan genel sistem karmaşıklığı ve operasyonel yük daha fazladır. Önbellek filosunun kullanılabilirliği, önbelleğin kullanıldığı bağımlı hizmetten farklı olacaktır. Örneğin, önbellek sıfır kesinti süresi yükseltmelerine yönelik desteğe sahip değilse ve bakım pencerelerine gereksinim duyuyorsa önbellek filosunun kullanılabilirlik oranı genellikle daha düşüktür.

Harici önbellek nedeniyle hizmetin erişilebilirliğinin azalmasını önlemek adına önbellek filosunun kullanılamaması, önbellek düğüm hatası veya önbellek koy/al hataları ile ilgilenmek için hizmet kodu eklememiz gerektiğini keşfettik. Seçeneklerden biri bağımlı hizmetin çağrılmasına geri dönüştür. Ancak, bu yaklaşımı benimsediğimizde dikkatli olmamız gerektiğini öğrendik. Bu, uzun süreli bir önbellek kesintisi sırasında aşağı akış hizmetine yönelik trafikte alışılmamış bir artışa sebep olur. Bu da, söz konusu bağımlı hizmette kısıtlamaya veya karartmaya ve sonuç olarak erişilebilirliğin azalmasına neden olur. Harici önbelleği, bu belleğin erişilemez duruma gelmesi halinde geri dönebileceğimiz bir bellek içi önbellek ile birlikte kullanmayı veya yük atma işlemini kullanıp aşağı akış hizmetine gönderilen maksimum istek oranını sınırlamayı tercih ederiz. Bağımlılıklarda kesinti olmasını önlemek için kullandığımız koruma araçlarının beklenen şekilde çalıştığını doğrulamak için, önbelleğe almayı devre dışı bırakarak hizmet davranışını test ederiz.

Dikkate alınacak bir diğer husus önbellek filosunun ölçeklendirilmesi ve esnekliğidir. Önbellek filosu talep oranına veya bellek sınırlarına ulaşmaya başladığında düğümler eklenmesi gerekir. Uygun monitörler ve alarmlar kurabilmek için bu sınırlara yönelik başlıca göstergelerin hangileri olduğunu belirleriz. Örneğin, ekibimiz şu anda üzerinde çalışmakta olduğum hizmette Redis istek oranı sınıra ulaştıkça CPU kullanımının oldukça yükseldiğini keşfetti. Sınırı belirlemek ve doğru alarm eşiğini bulmak için gerçekçi trafik modelleri kullanarak yük testi yaptık.

Önbellek filosuna kapasite eklediğimizde, bunu herhangi bir kesintiye veya önbellekte büyük bir veri kaybına neden olmayacak şekilde yapmaya özen gösteririz. Farklı önbelleğe alma teknolojileri için dikkate alınması gereken farklı noktalar söz konusudur. Örneğin bazı önbellek sunucuları bir kümeye kesinti süresi olmadan düğümler eklenmesini desteklemez ve önbellek filosuna düğüm eklemek ve önbelleğe alınan verileri yeniden dağıtmak için gerekli olan tutarlı karma işlemi tüm önbellek istemci kitaplıkları tarafından sunulmaz. Tutarlı karma işlemine yönelik istemci uygulamalarının çeşitliliği ve önbellek filosunda düğümler bulunması nedeniyle üretime geçmeden önce önbellek sunucularının eklenmesini veya kaldırılmasını kapsamlı olarak test ederiz.

Harici önbellekler için depolama biçimi değiştirildiğinde dayanıklılığın korunduğundan emin olmak için daha fazla özen gösteririz. Önbelleğe alınan veriler kalıcı olarak depolanıyormuş gibi işlenir. Güncellenen yazılımın her zaman bir önceki yazılım tarafından yazılan verileri okuyabileceğinden ve daha eski sürümlerin yeni formatları/alanları düzgün bir şekilde görebileceğinden (örneğin filonun eski ve yeni kodların bir karışımını içerdiği dağıtımlar sırasında) emin oluruz. Beklenmeyen formatlar ile karşılaşıldığında yakalanmayan istisnalar olmasının önlenmesi zehirli iletilerin engellenmesi için önemlidir. Ancak bu, format ile ilgili tüm sorunların önlenmesi için yeterli değildir. Sürüm formatı uyumsuzluğunun tespit edilmesi ve önbelleğe alınan verilerin çıkarılması, önbelleklerin toplu olarak yenilenmesine neden olabilir; bu da bağımlı hizmette kısıtlamaya veya karartmalara yol açabilir. Serileştirme format sorunları, Dağıtım sırasında geri alma güvenliğini sağlama başlıklı makalede daha ayrıntılı bir şekilde ele alınmıştır.

Harici önbellekler için dikkate alınması gereken son nokta, bu önbelleklerin hizmet filosunda bulunan ayrı düğümler tarafından güncellendiğidir. Önbellekler genellikle koşullu koyma veya işlemler gibi özelliklere sahip değildir. Bu nedenle önbellek güncelleme kodunun doğru olduğundan ve asla önbelleğin geçersiz veya tutarsız olmasına neden olmayacağından emin oluruz.

Farklı önbellek yaklaşımlarını değerlendirirken almamız gereken bir diğer karar, satır içi önbellekler ile taraf önbellekleri arasında bir seçim yapmaktır. Satır içi önbellekler (veya okuma/yazma önbellekleri) önbellek yönetimini temel veri erişim API’sine ekler ve böylece önbellek yönetimini söz konusu API’nin bir uygulama detayı haline getirir. Örnekler arasında Amazon DynamoDB Accelerator (DAX) gibi uygulamaya özgü ve HTTP önbelleğe alma işlemi (yerel bir önbelleğe alma istemcisi ya da Nginx veya Varnish gibi harici bir önbellek sunucusu aracılığıyla) gibi standarda dayalı uygulamalar sayılabilir. Bunun aksine, taraf önbellekleri Amazon ElastiCache (Memcached ve Redis) veya bellek içi önbelleklere yönelik Ehcache ve Google Guava gibi kitaplıklar tarafından sağlanan depolar gibi genel nesne depolarıdır. Taraf önbellekleri kullanıldığında uygulama kodu, veri kaynağına yapılan çağrılardan önce ve sonra önbelleği doğrudan işleyerek, aşağı akış çağrıları gerçekleştirilmeden önce önbelleğe alınan nesneleri kontrol eder ve çağrılar tamamlandıktan sonra da nesneleri önbelleğe yerleştirir.

Satır içi önbelleklerin temel faydası istemcilere yönelik tek biçimli bir API modelidir. Önbelleğe alma işlemi istemci mantığında hiçbir değişiklik yapılmaksızın eklenebilir, kaldırılabilir veya ayarlanabilir. Satır içi önbellekler aynı zamanda önbellek yönetim mantığını uygulama kodundan çıkarır ve böylece potansiyel bir hata kaynağını ortadan kaldırır. HTTP önbellekleri, bellek içi kitaplıklar, daha önce bahsedilenlere benzer tek başına HTTP proxy’leri ve içerik teslimi ağları benzeri yönetilen hizmetler gibi birçok kullanıma hazır seçeneği barındırdığından özellikle ilgi çekicidir.

Ancak, bellek içi önbelleklerin şeffaflığı kullanılabilirlik açısından bir dezavantaj olabilir. Harici önbellekler artık bu bağımlılığa yönelik kullanılabilirlik denkleminin bir parçasıdır. İstemcinin geçici olarak kullanılamayan bir önbelleği düzeltme fırsatı yoktur. Örneğin, önbelleğin harici bir REST hizmetinden istediği bir Varnish filosuna sahipseniz ve bu önbelleğe alma filosu bozulursa hizmetiniz açısından bu bağımlılığın kendisinin bozulmasına benzer bir durumdur. Satır içi önbelleklere yönelik diğer bir dezavantaj, bu önbelleklerin kullanıldığı protokol veya hizmete eklenmesine yönelik gerekliliktir. Söz konusu protokol için bir satır içi önbellek mevcut değilse bu durumda kendiniz bütünleşik bir istemci veya proxy hizmeti oluşturmak istemediğiniz sürece satır içi önbelleğe alma işlemi seçenekler arasında değildir.

En zorlu önbellek uygulama detaylarından bazıları şunlardır: doğru önbellek boyutunu seçme, süre sonu politikası ve çıkarma politikası. Süre sonu politikası bir ögenin önbellekte ne kadar süreyle tutulacağını belirler. En yaygın politika kapsamında kesin zamana bağlı süre sonu uygulanmaktadır (diğer bir deyişle, yüklendiğinde her bir nesne için bir yaşam süresi (TTL) belirlenmektedir). TTL, istemcinin eski verilere karşı ne ölçüde tolerans gösterdiği ve verilerin ne kadar statik olduğu gibi istemci gerekliliklerine göre seçilir, çünkü yavaş bir şekilde değişen veriler daha agresif bir şekilde önbelleğe alınabilir. İdeal önbellek boyutu öngörülen istek hacmine yönelik modele ve bu istekler kapsamında önbelleğe alınan nesnelerin dağıtımına bağlıdır. Buna dayalı olarak bir önbellek boyutunun bu trafik modelleri ile yüksek bir önbellek isabet oranını temin edebileceğini tahmin ediyoruz. Çıkarma politikası önbellek kapasitesine ulaşıldığında ögelerin önbellekten nasıl kaldırıldığını kontrol eder. En yaygın çıkarma politikası En Önce Kullanılan (LRU) politikasıdır.

Bu şimdiye kadar yalnızca bir düşünce alıştırması olmuştur. Gerçek dünyadaki trafik modelleri bizim modellediğimizden farklıdır. Bu nedenle önbelleğimizin gerçek performansını izleriz. Bunun için önbellek isabet ve kaçırmaya yönelik hizmet ölçümleri, toplam önbellek boyutu ve aşağı akış hizmetlerine yönelik istek sayısını yayınlamayı tercih ediyoruz.

Önbellek boyutu ve süre sonu politika değerlerini belirleme konusunda özenli olmamız gerektiğini öğrendik. Bir geliştiricinin ilk uygulama sırasında önbellek boyutu ve TTL değerlerini rastgele olarak seçtiği ve daha sonra bir daha geri dönüp bunların uygunluğunu doğrulamadığı durumlardan kaçınmak istiyoruz. Bu takip eksikliğinin gerçek dünyada geçici hizmet kesintilerine ve devam eden kesintilerin şiddetlenmesine yol açtığı örneklere şahit olduk.

Aşağı akış hizmetlerinin kullanılamadığı durumlarda dayanıklılığı yükseltmek için kullandığımız diğer bir model de, bir soft TTL ve bir hard TTL olmak üzere iki TTL kullanmaktır. İstemci önbelleğe alınan ögeleri soft TTL’ye göre yenilemeye çalışır. Ancak aşağı akış hizmeti kullanılamıyorsa veya diğer bir şekilde isteğe yanıt vermiyorsa hard TTL’ye ulaşılana kadar mevcut önbellek verileri kullanılacaktır. Bu modelin bir örneği AWS Identity and Access Management (IAM) istemcisinde kullanılır.

Ayrıca, aşağı akış hizmeti karartmalarının etkisini azaltmak için soft ve hard TTL yaklaşımını ters yönde baskı ile kullanırız. Aşağı akış hizmeti karartma durumunda bile ters yönde bir baskı ile yanıt verebilir. Bu yanıt, çağrı yapan hizmetin hard TTL’ye ulaşılana kadar önbelleğe alınan verileri kullanması ve yalnızca önbellekte olmayan veriler için istek göndermesi gerektiğini işaret eder. Aşağı akış hizmeti ters yönde baskıyı kaldırana kadar buna devam ederiz. Bu model, yukarı akış hizmetlerinin kullanılabilirliğini sürdürürken aşağı akış hizmetinin bir karartma durumundan kurtulmasına olanak tanır.

Dikkat edilmesi gereken önemli bir husus, aşağı akış hizmetinden hatalar alınması durumunda görülen önbellek davranışıdır. Bu durumun çözümlenmesine yönelik seçeneklerden biri istemciye en son ön belleğe alınan iyi değeri kullanarak (örneğin yukarıda açıklanan soft TTL / hard TTL modelinden yararlanarak) yanıt vermektir. Diğer bir seçenek ise olumlu önbellek girişlerinden farklı bir TTL kullanan hata yanıtını önbelleğe almak (diğer bir deyişle “olumsuz bir önbellek” kullanmak) ve hatayı istemciye aktarmaktır. Belirli bir durumda seçtiğimiz yaklaşım, hizmetin özelliklerine ve istemcilerin hatalara karşı eski verileri görmesi için uygun zamanın değerlendirilmesine göre değişmektedir. Hangi yaklaşımı benimsersek benimseyelim, hata durumlarında önbellekte bir şey olduğundan emin olmamız gerekmektedir. Böyle bir durum yoksa ve aşağı akış hizmeti geçici olarak kullanılamıyorsa ya da diğer bir şekilde belirli istekleri yerine getiremiyorsa (örneğin bir aşağı akış kaynağının silinmesi) yukarı akış hizmeti trafiğini göndermeye devam edecek ve muhtemelen bir kesintiye veya mevcut bir kesintinin şiddetlenmesine neden olacaktır. Daha fazla hata oranına ve hataya neden olan olumsuz yanıtların önbelleğe alınamadığı durumlara yönelik gerçek dünyadan örnekler gördük.

Önbelleğe alma işleminin diğer bir önemli unsuru güvenliktir. Bir hizmete bir önbellek tanıttığımızda bunun getirdiği güvenlik risklerini değerlendirir ve hafifletiriz. Örneğin, harici önbelleğe alma filolarında genellikle serileştirilmiş verilere yönelik şifreleme ve aktarım düzeyinde güvenlik bulunmamaktadır. Bu durum, özellikle önbellekte hassas kullanıcı bilgilerinin tutulması durumunda önemlidir. Bu sorun, iletim ve bekleme sırasında şifrelemeyi destekleyen Amazon ElastiCache for Redis gibi bir unsur kullanılarak hafifletilebilir. Önbellekler de aşağı akış protokolündeki bir güvenlik açığının saldırganın önbelleği kendi kontrolündeki bir değer ile doldurmasına izin verdiği zehirleme saldırılarına açıktır. Bu da, söz konusu değerin önbellekte bulunduğu süre içerisinde gönderilen tüm istekler kötü amaçlı değeri göreceğinden saldırının etkisini artırır. Son bir örnek vermek gerekirse önbellekler yan kanal zamanlama saldırılarına da açıktır. Önbelleğe alınan değerler alınmayan değerlere göre daha hızlı döndürülür, bu nedenle bir saldırgan diğer istemcilerin veya ilkelerin gönderdiği isteklere ilişkin bilgi alabilmek için yanıt zamanını kullanabilir.

Dikkate alınması gereken son husus, birçok istemcinin hemen hemen aynı anda aynı önbelleğe alınmamış aşağı akış kaynağına ihtiyaç duyan istekler gönderdiği “gürültülü kalabalık” durumudur. Bu durum ayrıca bir sunucu ortaya çıktığında ve boş bir yerel önbelleğe sahip filoya katıldığında da gerçekleşir. Bunun sonucunda her bir sunucudan aşağı akış bağımlılığına çok sayıda istek gönderilir ve bu da kısıtlamaya veya karartmaya neden olabilir. Bu sorunu çözmek için istek birleştirme yöntemini kullanırız. Bu durumda, sunucular veya harici önbellek, önbelleğe alınmamış kaynaklar için yalnızca tek bir bekleyen istek olmasını sağlar. Bazı önbellek kitaplıkları ve bazı harici satır içi önbellekler (örneğin Nginx veya Varnish) istek birleştirmeyi destekler. Ayrıca, istek birleştirme yöntemi mevcut önbelleklere ek olarak uygulanabilir. 

Bu makalede bazı en iyi Amazon uygulamalarına ve önbelleğe almaya ilişkin ödünler ve risklere değinilmiştir. Amazon en iyi uygulamalarının ve ekiplerimizin bir önbellek tanıtırken dikkat ettiği hususların bir özeti aşağıda verilmiştir:

• Bir önbellek için maliyet, gecikme ve/veya kullanılabilirliğin artırılması açısından gerekçelendirilmiş meşru bir gereksinim olduğundan emin oluruz. Verilerin önbelleğe alınabilir olduğundan, diğer bir deyişle birden fazla istemci isteğinde kullanılabildiğinden emin oluruz. Bir önbelleğin getirdiği değere şüpheyle yaklaşma ve faydaların önbelleğin getirdiği ek risklerden daha fazla olup olmadığını dikkatli bir şekilde değerlendiririz.
• Önbelleğin hizmet filosunun geri kalanı ve altyapı için kullanılan süreçler ve gösterilen titizlikle çalıştırılmasını planlarız. Bu çabayı hafife almayız. Önbelleğin uygun şekilde ayarlandığından emin olmak için önbellek kullanımına ve isabet oranına yönelik ölçümleri yayınlarız. Harici önbelleğe alma filosunun iyi durumda olduğundan ve uygun şekilde ölçeklendirildiğinden emin olmak için temel göstergeleri (örneğin CPU ve bellek) izleriz. Bu ölçümlere yönelik alarmlar kurarız. Önbelleğe alma filosunun kesinti veya önbelleklerin toplu olarak geçersiz kılınması durumları olmaksızın ölçeklendirilebildiğinden emin oluruz (diğer bir deyişle, tutarlı karma işleminin beklenen şekilde çalıştığını doğrularız).
• Önbellek boyutu, süre sonu politikası ve çıkarma politikası seçiminde özenli ve deneyime dayalı davranırız. Bu seçimleri doğrulamak ve ayarlamak için bir önceki maddede belirtilen testleri ve ölçümleri uygularız.
• Önbelleğe alınan veriler kullanılarak isteklerin yerine getirilememesine sebep olan birçok durum dahil olmak üzere önbelleğin kullanılamamasına karşı hizmetinizin dayanıklı olduğundan emin oluruz. Söz konusu durumlar arasında hazırlıksız başlangıçlar, önbelleğe alma filosu kesintileri, trafik modellerinin değişmesi veya uzun süreli aşağı akış kesintileri sayılabilir. Birçok durumda bu, sunucularınızda ve bağımlı hizmetlerinizde karartma (örneğin yük atma, bağımlı hizmetlere gönderilen istekleri sınırlama veya eski veriler sunma) olmadığından emin olmak için erişilebilirlik durumunuzun bir kısmının ticareti anlamına gelir. Bunu doğrulamak için devre dışı bırakılan önbellekler ile yük testleri yaparız.
• Şifreleme, harici bir önbelleğe alma filosu ile iletişim kurulması sırasında aktarım güvenliği ve önbellek zehirleme saldırıları ile yan kanal saldırılarının etkisi dahil olmak üzere önbelleğe alınan verilerin korunmasına yönelik hususları dikkate alırız.
• Önbelleğe alınan nesnelere yönelik depolama formatını zaman içerisinde değişecek (örneğin bir sürüm numarası kullanacak) ve daha eski sürümleri okuyabilen bir serileştirme kodu yazacak şekilde tasarlarız. Önbellek serileştirme mantığınızdaki zehirli iletilere dikkat ederiz.
• Önbelleğin aşağı akış hataları ile nasıl ilgilendiğini değerlendirir ve ayrı bir TTL ile olumsuz bir önbelleği sürdürmeyi düşünürüz. Aynı aşağı akış kaynağını tekrar tekrar isteyerek ve hata yanıtlarını çıkararak bir kesintiye neden olmayız veya kesintiyi şiddetlendirmeyiz.

Amazon içerisindeki birçok hizmet ekibi önbelleğe alma teknikleri kullanmaktadır. Bu tekniklerin faydalarına rağmen dezavantajlar avantajlardan fazla olabileceğinden önbelleğe almayı eklemeye karar vermeyiz. Bu makalenin kendi hizmetlerinizde önbelleğe alma işlemini değerlendirirken size yardımcı olacağını umuyoruz.