Etiket sistemini ölçeklendirmek: kapasite planlaması nasıl yapılır?

Pilot mağazada her şey mükemmel çalışan bir sistem, otuz mağazaya yayıldığında yavaşlıyor; 500 etiketle sorunsuz güncellenen park 15.000 etikette güncelleme penceresini aşıyor. Ölçeklenme, ESL projelerinin en sık sürprizi. Bu yazı hangi kaynağın nerede tıkandığını ve nasıl planlanacağını anlatıyor.

Dört ayrı kapasite

Ölçeklenmeyi konuşurken dört farklı sınır var ve karıştırılıyorlar.

Radyo kapsaması. Erişim noktasının kapladığı alan. Mağaza büyüdükçe nokta sayısı artıyor; bu en görünür ve en kolay planlanan sınır. Kapsama hesaplayıcı ilk tahmini veriyor.

Erişim noktası kapasitesi. Bir noktanın kaç etiketi kaç dakikada besleyebildiği. Alan yeterli olsa bile etiket yoğunluğu yüksekse ikinci nokta gerekiyor. Bu, teklifte en sık gözden kaçan sınır.

Sunucu ve yazılım kapasitesi. Yönetim yazılımının kaç etiket, kaç mağaza ve kaç eşzamanlı kullanıcıyı taşıdığı. Bazı ürünler mağaza başına ayrı sunucu, bazıları merkezi mimari kullanıyor.

Entegrasyon kapasitesi. ERP'den gelen fiyat değişikliği hacminin işlenme hızı. Kampanya geçişinde 20.000 satırın kaç dakikada kuyruğa girdiği burada belirleniyor.

Yenileme süresi: asıl metrik

Kapasite tartışmasının tek anlamlı çıktısı park yenileme süresi: tüm etiketlerin güncellenmesinin ne kadar sürdüğü. Bu süre, mağazanın güncelleme penceresine sığmalı. Gece 02:00-05:00 arasında güncelleme yapıyorsanız pencere üç saat; yenileme süresi bunun içinde kalmalı ve hata payı bırakmalı.

Şartnameye yazılacak ifade bu: "X etiketlik park, Y dakika içinde tamamen güncellenir." Kabul testinde ölçülen de bu. Kurulum günü akışı yazısı bu ölçümün nerede yapıldığını gösteriyor.

Ölçeklenme nerede kırılıyor?

Sahada en sık görülen üç kırılma noktası var.

Kampanya dalgası. Normal günde saatte birkaç yüz güncelleme yapan sistem, kampanya geçişinde binlerce güncellemeyi aynı anda alıyor. Sistem bunu kuyruğa alıp yayıyorsa sorun yok; hepsini aynı anda yaymaya çalışıyorsa radyo doyuyor. Merkezi kampanya yönetimi yazısı dalga planını anlatıyor.

Mağaza sayısı. Otuz mağazanın hepsi aynı saatte güncelleniyorsa merkezi sunucu ve ağ darboğaz oluyor. Mağaza gruplarını saat dilimlerine yaymak basit ve etkili çözüm.

Şablon karmaşıklığı. Görselli, çok alanlı şablonlar daha çok veri taşıyor ve güncelleme süresini uzatıyor. Ekranda gerçekten gerekli olanı tutmak performans kararı da; bilgi mimarisi yazısı bu dengeyi kuruyor.

Pilotu ölçeklenebilir tasarlamak

Pilotun amacı yalnızca "çalışıyor mu" değil, "büyüdüğünde çalışacak mı" sorusunu yanıtlamak. Bunun için pilot mağaza, en zorlu koşulları içermeli: en yoğun etiket yoğunluğu, en çok metal raf, en yüksek güncelleme sıklığı. Kolay mağazada yapılan pilot yanlış güven veriyor. Pilot mağaza seçimi yazısı bu ölçütleri veriyor.

Büyüme için hangi soruları sormalı?

Teklif aşamasında ölçeklenmeyi kilitleyen dört soru var. Bir erişim noktası kaç etiketi besler ve bu sayı hangi yenileme süresinde geçerli? Yazılım kaç mağaza ve kaç etikete kadar aynı mimariyle çalışır, sınırı aşınca ne değişir? Entegrasyon saniyede kaç fiyat değişikliğini işler? Mağaza sayısı arttığında lisans modeli nasıl değişir?

Teklif alırken sorulacaklar yazısı bu soruları maliyet tarafıyla birleştiriyor.

Ölçek büyüdükçe operasyon da ölçeklenir

Teknik kapasite yetse bile operasyon yetmeyebiliyor. 500 etiketlik parkta ayda birkaç arızalı etiket çıkıyor ve elle yönetiliyor; 15.000 etiketlik parkta aynı oran haftada onlarca etiket demek ve bu, tanımlı bir süreç gerektiriyor. Yedek stok, değişim rutini ve raporlama ölçekle birlikte büyümeli.

Kısa özet

Dört ayrı kapasite var: radyo kapsaması, nokta kapasitesi, yazılım ve entegrasyon. Tek anlamlı metrik park yenileme süresi ve güncelleme penceresine sığmalı. Kırılma noktaları kampanya dalgası, eşzamanlı mağaza güncellemesi ve ağır şablonlar. Pilot en zorlu mağazada yapılmalı. Operasyon da ölçekle büyümeli.

Yaygınlaştırma sırası kapasiteyi test eder

Pilot bittikten sonra mağazaları hangi sırayla devreye alacağınız kapasite planının parçası. En büyük mağazayı ikinci sırada devreye almak, sistemin gerçek yükünü erken gösteriyor ve sorun çıkarsa henüz üç mağazadayken çıkıyor. Kolay mağazalarla başlayıp zoru sona bırakmak, sorunu en pahalı anda keşfetmek demek.

Her dalga sonunda üç sayı ölçülmeli: park yenileme süresi, cevap vermeyen etiket oranı ve entegrasyon kuyruğunun boşalma süresi. Üçünden biri bozulmaya başladıysa sonraki dalgayı beklemek gerekiyor. Pilot kurulumdan yaygınlaştırmaya yazısı dalga planını anlatıyor.

Merkezi mi dağıtık mı mimari?

Zincirler için iki model var. Dağıtık modelde her mağazada yerel sunucu çalışıyor; merkez yalnızca fiyat gönderiyor. İnternet kesildiğinde mağaza çalışmaya devam ediyor ama bakım yükü mağaza sayısıyla çarpılıyor. Merkezi modelde tek sistem tüm mağazaları yönetiyor; bakım kolay ama mağazanın bağlantısı kritik hâle geliyor.

Otuz mağazanın üzerinde merkezi model neredeyse her zaman doğru tercih; yerel dayanıklılık, erişim noktalarının son görüntüyü saklamasıyla sağlanıyor. Bulut mu yerel sunucu mu yazısı bu iki modeli maliyet ve risk açısından karşılaştırıyor.