AWS DynamoDB Notlarım
DynamoDB kullanma ihtiyacımdan dolayı üzerine kafa yorup, AWS’in DynamoDB kitabı ve üzerine 121 bölümlü Udemy kursunu bitirmişken önemli olduğunu düşünerek aldığım notlarımı burada Türkçe olarak paylaşmak istedim.
Önce ilk soruyu soralım neden DynamoDB kullanmaya ihtiyaç duyarsınız?
Relational database yapısı 1970'lerde bulunan bir teknoloji. Yani bugünden 50 sene önce. Bu kadar eski bir teknoloji olsa da bizler mimarilerimizde hala relational database’leri sıklıkla kullanıyoruz. Bu teknoloji karmaşık query’ler yazma ve veriye ulaşma konusunda muazzam olsada yüksek trafikte çalışmaya o kadar müsait değil. Bu da normal aslında. Yapıldıkları dönemin ihtiyaçları ile bu dönemin ihtiyaçları farklı. O dönem trafik bu dönemki gibi dikkate değer bir konu değildi, öncelikler farklıydı.
Trafik alan bir sistem yaptığınızda sizi sıklıkla yarı yolda bırakacak olan bu sebeple DB’ler oluyor. Sadece DB’yi korumak için önüne cache(redis gibi) sistemleri koysanızda, sorumlulukları farklı noktalara dağıtsanızda bazı durumlar varki DB’nin gücüne muhtaç olduğunuz ve ondan cevap almak zorunda kaldığınız durumlar. İşte bu durumlarda DB’niz yükü kaldıramayacağını ilan ettiği noktada mimariyi tekrar yapılandırmanın zamanı geldi demektir.
Yüksek trafik yönetme konusunda noSQL tipinde veritabanları iyi bir alternatif. Çeşit çeşit noSQL veritabanı var. Bunlardan birisi de AWS’in DynamoDB’si. AWS’in her zaman yaptığı gibi DB’nin yanında DB’nin servis ve operasyon işini de üstüne alması sebebi ile tercih edilebilir bir ürün haline dönüşüyor. Ayrıca AWS üzerine konumlanmış bir mimariniz varsa size bir çok noktada kolaylık sağlıyor.
Notlarımı paylaşmadan önce burada hedeflediğim şeyin altını tekrar çizmek istiyorum: DynamoDB’yi uçtan uca anlatmak gibi bir içerik içermiyor bu yazı. Sadece önemli olan noktaları ve tavsiyeleri barındırıyor.
Not 1: Bir relational database kullanıyorsanız, derdiniz başka parametrelere bağlı olsada temelde işlem gücünüz ve iOPS’unuzdur. Bu iki değeri koruduğunuz sürece genel olarak sisteminiz sağlıklı çalışacaktır. İşlem gücü konusunda makineniz yetersiz kaldığında, genellikle dikey olarak makineyi güçlendirmek zorunda kalırsınız. Maaelsef RDS’in doğası gereği bu sisteme downtime yaşatır. Bu çok sıkıntılı bir durumdur. Hele ciddi yük aldığınız, alarmlar ile boğuştuğunuz sırada makineyi yükseltmek için makineyi kapatmak işletmeler için ciddi problem, gelir kaybıdır.
Diğer yandan açacağınız RDS boyutunu da tahmin etmek pek olası değildir. Arama motorlarında “şöyle bir sistem yapacağım bana hangi boy RDS makinesi lazım” diye aratırsanız genel tavsiye gelen yükü gözlemleyip artış ve azalış yap yönündedir. Ancak scale up/down yetisi maalesef RDS tarafında down-time yaşattığı için sizin kapasite üzerinde oynamanıza engel olur.
RDS’i bir noktadan sonra genişlemek mümkün değilken, DynamoDB’i Provisioned Capacity hesabı yaparak down-time yaşatmadan sınırsız scale up/down yapabiliyorsunuz.
Not 2: İki tip sorgu çeşidi var. Bunlardan birisi strong consistency diğeri eventual consistency. Bunu anlamak için önce DynamoDB veriyi nasıl tutuyor anlamak lazım. DynamoDB 3 farklı A-Z üzerinde replicalar tutuyor. Bunlardan bir tanesi primary oluyor. Eğer primary olandan veri okumak istenirse bu strong consistency oluyor. Eğer primary dışındaki replica’lardan veri okunmak istenirse bu eventual consistency oluyor. Çünkü primary üzerinde write işlemleri olması sebebi ile verinin doğruluğu kesin. Diğerleri henüz güncellemeyi almamış olabileceği için verinin kesinliği söz konusu değil. Ancak diğer taraftan maliyeti de 2 katı pahalı. Çünkü strong olan eventual’a göre iki katı kapasite ihtiyaçı duyuyor. Dolayısı ile yapılacak sorgularda ciddi bir netlik ihtiyacı yoksa, milisaniyelik gecikmeler problem değilse eventual consistency tercih etmek cost-saving sağlayacaktır. Bir diğer not: Sorguların default değeri eventual consistency olarak atanmıştır.
Not 3: Kapasite belirleme işi biraz karışık. Hatalı ya da düzenli yapılmazsa maliyetli bir konu. Bu problemden kaçınmak için AWS DynamoDB auto-scaling özelliği belirli bir süre tanımlanmış değerin üstünde kapasite kullanımı olursa sizin adınıza otomatik scale-up/down yapmanıza imkan veriyor. Maliyet azaltmak için oldukça mantıklı bir tercih. Aktif edilmesinde fayda var. Örneğin alttaki gereksiz kapasite boşluklarını auto-scale özelliği ile AWS sizin adınıza nasıl yönettiğini görebiliyoruz.
Not 4: DynamoDB’in tabloları tanımlarken index’ler iyice düşünülmeli. Özellikle local secondary index. Çünkü local secondary index tablo yaratılırken yaratılması gereken bir index. Diğer taraftan Global Secondary Index daha sonradan da eklenebiliyor ancak şuna dikkat etmek lazım: Global Secondary Index tablonun base kapasitesi yerine yeni bir kapasiteye ihtiyac duyuyor. Bu sebeple maliyeti artırıcı bir unsur. Eğer gerek duyulmuyorsa tanımlanmaması gerekir.
Not 5: DynamoDb verileri partition’lara bölümleyip tutuyor. Bazı partition’larda tutulan veriler sıklıkla kullanılmasından dolayı hot partition olarak değerlendiriliyorlar. Yani çok sıklıkla kullanılan. Genel kapasite her partition’ına aynı seviyede bölümlenip veriliyor. Ancak bazıları çok sık çağırılırken bazıları daha az çağırılıyor. Bu bazılarının kapasitesini tüketmesine, diğerlerinin ise kullanmadığı bir kapasitenin oluşmasına sebep oluyor. Eskiden özellikle bu ciddi bir problem iken mayıs 2019 da tanıttıkları Adaptive Capacity ile bu sorunu aşmışlar ve partition’lar arasında kapasite yönetimini yapmayı sağlamışlar. Yine de şuna dikkat etmek lazım. Belirli bir noktadan sonra partition’ların kendi hard limitleri var. 3000 read capacity unit ve 1000 write capacity unit. Eğer bir partition üzerinde bu rakamları aşarsanız adaptive capacity de kurtaramıyor sizi. Dolayısı ile farklı çözümlere yönelmeniz lazım.
Not 6: “Scan” operatör yerine “Query” operatörü kullanılmalı. Scan partition’lar arasında gezerken, query sadece bir partition içinde geziyor. Dolayısı ile olabildiğinde query operatörü kullanmakta fayda var. Bu şekilde hem hız kazanımı hem capacity unit kazanımı elde etmiş oluyorsunuz.
Not 7: Kısıtlardan bir diğeri attribute olarak tutulacak bir verinin boyutunun maksimum 400KB olması. 400KB üstü attribute saklama ihtiyacı için 3 öneri var. İlki GZIP ile küçült, ikinci S3 koy linkini DynamoDB ye bırak, son olarak attribute farklı partition ve sort key ile bölümle. Mesela partition key 1-sort 1, partition key 1-sort 2 vs. şeklinde bölümle.
Not 8: DAX kullanılarak DynamoDB kendi önüne kendi cache sistemini koyarak hot partition problemlemi çözümüne destek oluyor. Yani partition’ın kendi kapasitesini tüketmeden DAX üzerinden verinin alımı sağlanıyor. DAX kullanacakların şunu bilmesinde fayda var: DAX sadece eventual consistency şeklinde hizmet vermekte.
Not 9: DynamoDB streams güzel bir özellik. Herhangi bir değişiklikte otomatik lambda trigger edilebiliyor. Lambda ile istediğiniz her şeyi yapabilirsiniz. Mesela yeni bir müşteri kayıt oluşturdu. Ona otomatik welcome maili atabilirsiniz.
Not 10: TTL özelliği ile belirlenen bir süre sonra verinin expire etmesi sağlanabiliyor. Bu şekilde o verinin silinmesi ya da arşivlenmesi sağlanabilir. Örneğin alışveriş sepetine atılan nesnelerin verisi ya da session verisinin kalıcı bir şekilde saklanmasına gerek yok. Bu sebeple tutulan bu tip verilerin bir süre sonra silinmesi mantıklı olacaktır. İşte bu noktada TTL kullanılabilir.
Bir diğer yandan sistem kapasitesinin daha verimli kullanılmasında faydalı. DynamoDB’nin doğası gereği elindeki kapasiteyi tüm partition’lara bölümlüyor. Eğer elinde çok partition varsa partition başına düşecek kapasite azalacaktır. Örneğin müşterilerinize verdiğiniz servis için sağladığınız veriler bir tabloda tuttuğunuzu düşünelim. Diğer yandan aynı tabloda kulanıcı log’larını da tutuyorsunuz diyelim. Zamanla ne olacak: Devamlı büyüyen bir tablo değil mi? Kullanıcılar kullandıkça onların logları ile veriniz genişleyecek. Bu durumda her gecen gün partition’ların kapasitesi daha fazla sayıya bölümlendiği için partition başına kapasite düşecek. Log verisi daha az kullanılıyor olsada sisteminizin ihtiyacı olan asıl verileri barındıran partition’lar kadar kapasite allocate edecek. Siz de sık kullanılan yani kapasitesi her seferinde düşen bu partitionların ihtiyacını karşılayabilmek için her seferinde kapasite artışı yapmak zorunda kalacaksınız. İşte TTL bu noktada size ciddi fayda sağlayıp az kullanılan partitionları farklı tabloya taşımanıza imkan veriyor. Sizde sık kullanılanlar için yüksek kapasiteli bir tablo sunabilir, az kullanılanlar için düşük kapasiteli bir tablo sunabilirsiniz. Bu sizi sonsuz kapasite artışı maliyetinden kurtaracaktır.
Not 11: Global table özelliğini kullanarak birden çok region üzerinde aynı anda çalışma imkanı sunabilirsiniz. Yani A-Z değil, region bazlı yedekleme. Örneğin Amerika’da bulunan bir region’da olduğunuzu düşünelim. Bu çöktüğünde Avrupa’da bulunan bir diğer replica’nız üzerinden hizmet vermeye devam edebiliyorsunuz.
Not 12: DAX üzerinde işlem yapan(Örnek: Lambda) ile DAX aynı VPC üzerinde olmak zorunda. DAX yaratıldığında default cache tutma süresi 5dk. Değiştirilmezse 5dk içinde expire oluyor ve siliniyor.
Not 13: Manuel ya da Lamabda ile düzenli alınabilecek backupların dışında “Point in Time Recovery” adlı feature 35 güne kadar DynamoDB’yi istenen zamana döndürebiliyor. Sadece enable ediyorsunuz ve otomatik bunun yönetimini yapıyor. Hatalı silmelere ve diğer kazalara karşı kullanmakta fayda var.
Not 14: “AWS Data Pipeline” kullanılarak S3'e DynamoDB dump bırakabiliyorsunuz. Benzer şekilde import edip S3'den dump alınıp kolaylıkla yeni tablo oluşturabiliyorsunuz.
Not 15: DynamoDB’nin noSQL yapısından dolayı kompleks query yazılamamasının önüne Redshift kullanılarak geçilebiliyor. Özellikle raporlama tarafımızda kullanmak için belirli bir andaki DynamoDB datası DynamoDB’den çekilip Redshift’e alınabiliyor. Alınan o data üzerinde SQL query’ler yazıp, rapor çıkarabilirsiniz.
Not 16: Redshift ile sadece kopyalanan veri üzerinde SQL koştururken, AWS EMR ile real-time DynamoDB datası üzerinde SQL koşabiliyorsun. EMR alttında Apache Hadoop Cluster’ı yönetiyor. Hadoop üzerinde çalışan Apache Hive Data warehouse’ı kullanıyor. Bu şekilde gerçek zamanlı data üzerinde SQL ile sorgu yapabilir hale gelebiliyorsunuz.
Not 17: DynamoDB’nin text search yetisi oldukça zayıf. Case-sensitive search, sort, ranking vs. yok. Dolayısı ile bunu için CloudSearch öneriliyor. Belirli bir andaki datayı DynamoDB’den alıp CloudSearch’e verebiliyorsunuz sonrasında search işlemleri yapılabiliyor.
Not 18: CloudSearch belirli bir andaki kopyalanan data üzerinde text search yapıyor. Peki bunu gerçek zamanlı veri üzerinde yapmak isterseniz? Onun için önerilen DynamoDB’nin stream özelliği ile bir Lambda tetikleme ve Cloud Search’i güncel veri ile beslemek. Bu şekilde CloudSearch üzerinde real-time data saklamış oluyorsunuz ve işlemler bu data üzerinde yapıldığı için real-time denebilir.
Not 19: DynamoDB’den bağımsız ama yine de atlamadan hatırlatmakta fayda var. İşem yapan user’ın IAM policy’sine sadece write, read ve query gibi kısıtlı işlem yetkisi vermekte fayda var. FullAccess olmamalı. Ayrıca sadece ilgili table’ın ARN’i üzerinde yetki tanımlarsanız daha doğru olacaktır.
Notlarım bu şekilde. Umarım faydalı olacak bir kaç nokta bulmuşsunuzdur.
Eklemek isterseniz linkedin ve twitter hesaplarım aşağıdadır.
Saygılarımla,
Doğan Aydın
Referanslar
- https://www.amazon.com/Amazon-DynamoDB-Developer-Web-Services-ebook/dp/B0763ZV7JG
- https://www.youtube.com/watch?v=-um_HJWcHtA&list=PL9nWRykSBSFi5QD8ssI0W5odL9S0309E2&index=4
- https://www.youtube.com/watch?v=6yqfmXiZTlM
- https://www.udemy.com/course/dynamodb/
- https://www.reddit.com/r/aws/comments/6n2uuf/dynamodb_ttl_use_case/
