Giriş

Bulut faturanız her ay artıyor ve neden olduğunu anlayamıyor musunuz? Snap! Raise tam da bu durumla geldi: aylık 16.000 dolarlık bir OpenSearch faturası, 18 data node, 15.786 shard — ama diskte duran gerçek veri yalnızca 14 GB. Beş ay içinde aynı cluster’ın aylık maliyetini 2.300$ seviyesine indirdik; toplam platform kapasitesini ise 6.000 mağazadan 30.000 mağazaya çıkardık.

Sorun

Snap! Raise, ABD genelinde 150.000’den fazla okul ve takıma dijital bağış toplama hizmeti sunan bir platform. Magento e-ticaret altyapısını kullanıyorlar ve her mağazanın ürün araması için ayrı bir AWS OpenSearch index’i bulunuyor.

Aylık maliyet: 16.000$
Cluster yapısı: 18 data node (r6g.xlarge, 32 GiB RAM) + 5 master node
Toplam bellek: 318 GiB, toplam disk: 1.75 TB
Shard sayısı: 15.786 (7.884 index)
Gerçek disk kullanımı: 14 GB

1.75 TB ayrılmış disk alanına karşılık yalnızca 14 GB veri vardı. Cluster, ayrılan kapasitesinin %1’inden azını kullanırken fatura provision edilen kapasiteye göre oluşuyordu.

Teşhis

İlk adım olarak _cat/indices çıktısını boyuta göre sıraladım. Pattern hızla ortaya çıktı: Snap! Raise, mağaza-başına-index mimarisi kullanıyordu. Her katalog güncellemesinde yeni bir versiyonlu index oluşturuluyor, alias yeni index’e taşınıyor; ancak eski versiyonlar silinmiyordu.

Bu nedenle zamanla index sayısı katlandı. Sistemde 7.884 index vardı ama aktif olarak gereken sayı yaklaşık 1.740’tı. Her sahipsiz index iki shard (primary + replica) taşıyarak shard sayısını sessizce şişiriyordu.

AWS OpenSearch’te önerilen üst sınır yaklaşık 25 shard/GB RAM iken bu cluster yaklaşık 50 shard/GB seviyesindeydi. Sonuç: daha fazla node, daha yüksek maliyet, tekrar eden döngü.

Çözüm

Optimizasyonu beş ay boyunca üç aşamada uyguladım.

Aşama 1 — Doğru Boyutlandırma (Ağustos 2022)

1.740 aktif index ve 1 primary + 1 replica ile toplam shard ihtiyacı 3.480’di. 25 shard/GB kuralına göre minimum 139 GB RAM gerekiyordu. İki erişilebilirlik bölgesinde 3 adet r6g.xlarge node ile 192 GB RAM sağlandı.

Bu adımla maliyet 16.000$’dan 1.700$’a düştü (yaklaşık %89).

Aşama 2 — Kontrollü Büyüme (Eylül–Kasım 2022)

Eylül: Maksimum mağaza sayısı 6.000’den 14.000’e çıktı, maliyet 3.900$/ay.
Kasım: Maksimum mağaza sayısı 18.000’e çıktı, maliyet 4.900$/ay.

Bu aşamada zamanlanmış bir temizlik script’i devreye alındı. Script; alias’ı olmayan index’leri, sıfır dokümanlı index’leri ve aynı mağaza için duplike versiyonları tespit edip siliyordu.

Aşama 3 — Son Optimizasyon (Kasım–Aralık 2022)

Index yaşam döngüsü kontrol altına alındıktan sonra yük testleri yapıldı: tam reindex döngüsü, production hacminde sorgu trafiği, CPU/bellek/gecikme takibi.

Sonuç: aynı iş yükü daha az data node ile güvenle taşınabildi. Ek olarak her 10 dakikada shard sayısını kontrol eden ve eşik yaklaşınca Slack’e bildirim gönderen uyarılar kuruldu.

Sonuçlar

Metrik	Önce	Sonra
prod1 aylık maliyet	16.000$	2.300$
Data node sayısı (prod1)	18	8
prod1 mağaza kapasitesi	6.000	16.000
Toplam platform kapasitesi	6.000	30.000
Maliyet düşüşü	—	%86
Index yönetimi	Manuel	Otomatik temizlik + uyarı

Üç cluster için toplam aylık maliyet yaklaşık 4.150$ seviyesine inerken toplam kapasite 30.000 mağazaya ulaştı.

Öğrendiklerimiz

Index şişkinliği sessiz maliyet katilidir. Veri büyümesinden çok, sahipsiz index birikimi fatura patlatır.
Shard/GB oranı kritik bir sınırdır. 25 shard/GB kuralı pratikte maliyet ve stabilite dengesini belirler.
Otomatik oluşturulan index’ler otomatik silinmelidir. Lifecycle yönetimi yoksa maliyetler tekrar büyür.
Node sayısını ölçümle doğrulayın. Varsayımla değil, yük testiyle karar verin.
Proaktif izleme ciddi tasarruf sağlar. Basit shard uyarıları gereksiz provisioning’i önler.

Elasticsearch veya OpenSearch cluster optimizasyonu konusunda destek almak için searchali.com’u ziyaret edebilirsiniz.

Snap! Raise: 86% OpenSearch Cost Reduction

Let's push your search infrastructure beyond its limits.