E-ticaret domaininde nasıl başladık ?- Redis ile ziyaretçi sayacının geliştirilmesi
E-ticaret dönüşümüne başlayabilmek için öncelikle yapmamız gereken, o ilk servisi production ortamına alabilmek idi. Uygulaması basit, hata alsa dahi sorun olmayacak eski yapıya hızlıca geçiş yapabilecegimiz bir servis seçtik. Öncelikle Mimari Yönetim ekibimiz ile oturup mevcut datacenterdaki kurulumun üzerinden geçip, eticaret datacenterda yapmamız gereken işlemleri aşağıdaki gibi belirledik.
Kurulacak bayağı bir middleware ve servis çıktı. Bunların hepsini kurup çalışır hale getirdik. Ortama göre konfigurasyonları dışında çok birşey çıkmasa da CI/CD nin ayaklandırılması gibi işler biraz el yordu. Burada sistem ve devops ekibimizin büyük katkıları oldu.
İlk servisimiz ürün detay ekranında ürünün son bir dakika içinde kaç farklı ziyaretçi tarafından görüntülendiğinin hesaplanması işi oldu. Eski servisin aksine Redis’in özelliklerini kullanarak ilerledik. Redis üzerinde direkt bir çözüm yok ancak SortedSet üzerinde her bir ürün için tanımlanan anahtar (key) ile visitorId ve timeout olacağı milisaniyeyi tuttuk. SortedSetRangeByScore methoduyla, şu an ile sayacın timeout olacağı zaman arasında olan kayıtların listesini aldık. Bu listenin uzunluğu bize ilgili ürünü kaç kişinin son bir dakika içinde listediğini verdi.
Redis’ teki eksiklik SortedSet üzerinde normal anahtarlardaki gibi bir TTL (time to live) değeri girilemiyor olması. Bu sebeple, hesaplarken zaman bazlı kontrol ile listeyi süzüyor olsak dahi sayfalar özelindeki listeler giderek uzayacak ve memory ihtiyacımız giderek artacak idi. Bu duruma engel olabilmek için .Net Core da hosted service yazıp expire olan değerleri manuel olarak silmek durumunda kaldık. Hosted service, productionda minimum iki instance olarak çalışacağı için, performans açısından ve Redis’i yormamak için temizlik işinin aynı anda sadece bir instanceda yapılması gerekiyordu. N hosted serviceten sadece birinin çalışmasını sağlayabilemek için Redis üzerindeki lock mekanizmasını kullandık. Lock için de uygun bir TTL belirledik. Eğer lock koyan process işini bitiremez ve unlock edemez ise lock expire olacağından, süreç bir şekilde tekrar yoluna girecek kurguda oldu.
Günün sonunda Pars.Core üzerinde basit bir servis geliştirmiş olduk. Bunu yaparken Redis’in iki farklı özelliğini kullandık ve aynı zamanda ilk servisimizi üretim ortamına alarak, üretim ortamında Kubernetes ortamını çalışır hale getirmiş, Mimari Yönetim Müdürlüğünün artifactlerini ayrı bir datacenter da ayağa kaldırmış, eticaret için tüm CI/CD pipeline’ı kurmuş ve Kubernetes üzerindeki bir servisimizi dışarı açmış olduk. Ayrıca, şifreler için Vault, monitoring için Prometheus Grafana ve loglama için de Elastic Search Clusterlarımız ayağa kalkmış oldu.
Her dönüşüm projesinde hızlı kazanımlar ile ekibin bu işin sonunda neye benzeyeceğini ve sonunda ışık olup olmadığını görmesi gerekir. Kolay kolay kimseyi sonunu göremediği bir yola çıkaramazsınız. Tüm ekip yenilik istediğini belirtiyor olsa da zaman baskısı olan bir proje geldiğinde yine bilinen eski yoldan gidilmesi olası ve normaldir. Hızlı kazanımların en büyük kazancı yeni başlayacak projelerin önünü açması ve arkadan gelecek taleplerin yeni mimari ile ilerlemesinin sağlanabilmesidir. Nitekim bu servis sonrasında gelen ilk orta ölçekli projenin servis katmanı sıfırdan yazılacağı için direkt Pars.Core ile geliştirmeye başladık. Bu da başka bir yazar ve başka bir yazıya kalsın :)
