Ölçeklenebilirliği düşünmeye ne zaman başlamalı? [kapalı]

Komik ama aynı zamanda korkunç bir sorun yaşıyorum. Yeni bir (iPhone) uygulama başlatmak üzereyim. Kendi özel arka ucumda çalışan sıra tabanlı çok oyunculu bir oyun. Ama başlatmaktan korkuyorum.

Bazı nedenlerden dolayı, büyük bir şey haline gelebileceğini ve popülaritesinin zayıf yalnız tek sunucum + MySQL veritabanımı öldüreceğini düşünüyorum.

Bir yandan, eğer büyürse, hazırlıklı olsam ve halihazırda ölçeklenebilir bir altyapıya sahip olsam iyi olur.

Öte yandan, onu dünyaya çıkarmak ve ne olduğunu görmek istiyorum.

Sıklıkla "erken optimizasyon tüm kötülüğün kökü" ya da katil oyununuzu şimdi, eldeki araçlarla inşa etmeniz ve daha sonra ölçeklenebilirlik gibi diğer şeyler hakkında endişelenmeniz gerektiğini söyleyen insanlar okuyorum.

Konuyla ilgili bazı uzmanlardan veya tecrübesi olan kişilerden bazı görüşler duymak isterim. Teşekkürler!

Aslında oldukça kolay bir seçim.

Şu anda sıfır kullanıcınız var ve ölçeklenebilirlik sorun değil.

İdeal olarak, milyonlarca kullanıcınızın bulunduğu noktaya ulaşmak istersiniz ve ölçeklenebilirlik sorun haline gelir.

Şu anda bir ölçeklenebilirlik sorununuz yok; kullanıcı sayısı probleminiz var. Ölçeklenebilirlik sorunu üzerinde çalışırsanız, kullanıcı sayısı sorununu düzeltmezsiniz, yani henüz sahip olmadığınız bir sorunu çözmiş olacaksınız ve sahip olduğunuz sorunu çözmeyeceksiniz demektir. En olası sonuç, ürününüzün bunu yapmayacağı ve tüm çalışmalarınızın hiçbir şey için yapılmayacağıdır.

Kullanıcı sayısı sorunu üzerinde çalışıyorsanız, şu anda sahip olduğunuz bir sorunu çözeceksiniz ve ardından ölçeklenebilirlik olabilecek bir sonraki soruna odaklanabilirsiniz.

Ölçeklenebilirlik sorunları ile ilgili güzel bir şey, tanım gereği, genellikle işin oldukça iyi olduğu anlamına gelir ve bu da ölçeklenebilirliği optimize etmek için para harcayabileceğiniz anlamına gelir. Gece boyunca sıfır kullanıcıdan on milyona geçmezsiniz ve sistemin performansına dikkat ederseniz, zamanı geldiğinde optimize etmek için bolca zamanınız olacaktır.

Elbette, şu anda ihtiyacınız olan kodu yazarken ölçeklenebilirliği akılda tutmaya yardımcı olur, ancak eğer bilmediğiniz bir özellik üzerinde düzinelerce, hatta yüzlerce adam-saat harcamak mantıklı değildir. Buna ihtiyacın olacak ve en olası senaryo senin olmayacak. Şu anda ana endişeniz gemi. Bundan sonra ne olur; bunun hakkında daha sonra endişelenebilirsiniz.

Optimizasyonun gerekli olduğunu bilinceye kadar optimizasyon yapmak için hiçbir neden yoktur. Optimizasyonun gerekli olduğunu nasıl anlarsınız? Ölçüyorsun.

Sunucunuzun bir tür web tabanlı arayüzü olduğunu varsayarsak, Apache JMeter gibi araçları kullanarak birçok kullanıcıyı simüle edebilirsiniz . Aracı nasıl kullanacağınızı öğrenin, ardından arka ucunuzu stres testi yapmaya başlayın. Sisteminiz için sınırların ne olduğunu bilmek için yeterince öğrenebilmelisiniz. Daha sonra, ne zaman ölçekleneceğine karar vermek için bu bilgileri sahip olduğunuz kullanıcı sayısı ve bir seferde çalışan ortalama sayı ile birleştirebilirsiniz.

TL; DR İlk kod satırı yazılmadan önce ölçeklenebilirliği düşünmelisiniz.

Her şey sırayla. Scalabilty! = Optimizasyon

İlk kod satırı yazılmadan önce ölçeklenebilirliği düşünmelisiniz. Bu, oyununuzun bir hit olabileceği ihtimaline karşı muazzam bir altyapı inşa ettiğiniz anlamına gelmez. Ölçeklenebilirlik hakkında düşünmek:

• Kodun ölçeklenecek şekilde yazıldığından emin olun. Ölçeklendirmeye gerek olmadığı düşünülen pek çok proje gördüm. Sonuçlar, ona attığınız donanıma bakılmaksızın ölçeklenmeyen veya ölçeklenmesi oldukça pahalı olan bir kod tabanıdır.
• Ölçekleme stratejinizi belirleyin. Tüm kullanıcıları nasıl destekleyeceğiniz konusunda bir plan yapın. Bir MySQL db'niz var, onu parçalayacak mısınız yoksa küme mi, yoksa başka bir şey mi? Parçalama gibi stratejiler biraz düşünülmeyi gerektirir çünkü mimariye gereksinimleri koyar. Kümeleme, daha az. Oturumları destekliyor musunuz ve oturumlar birden çok ön uç sunucuyla nasıl tepki verecek. Yük dengeleyicinizde yapışkan oturumlara ihtiyacınız olacak mı?
• Uygulama stratejisini belirleyin. Ölçekleme için AWS mi kullanacaksınız? Kutusundan çıkar çıkmaz dinamik ölçeklendirme sağlayan herhangi bir ürün veya hizmetten yararlanabilir misiniz? Bu, maliyetlerinizin anlaşılmasını da içerir.

AMA zaten bir kod tabanınız var gibi görünüyor. Şimdi soru, ölçeklendirmeye ne zaman başlanacağıdır. Bu tamamen kodunuza bağlıdır.

Kodunuz ölçeklendirmeye uygunsa , zor kısmı tamamlamış olursunuz. Bir AWS hesabı alabilir, sunucuları gerektiği gibi büyütebilir ve gidebilirsiniz.

Kodunuz ölçeklenmiyorsa veya tıkanıklıkları varsa, yapacak işiniz vardır. Darboğazlarınızın ne olduğunu tanımlamanız ve düzeltmeniz gerekir. "Ne zaman" bilmek gerçekten zor. Bazı hizmetler platosu, bazıları sürekli yükseliyor, bazıları patlıyor. Kaynakların ölçekleme gibi bir şeye ne zaman atılacağına karar vermek genellikle işin bir işlevidir ve riskleri değerlendirir.

Senin pozisyonunda , bir "beta" olarak yayınlayabilir ve kullanıcı beklentilerini yönetebilirim. Bu şekilde ürünü çıkarabilirim ve nasıl açıldığını görebilirim.

Yani, ölçeklenebilirlik hakkında iki kez düşünmelisiniz.

İlk olarak, tek bir kod satırı yazmadan önce hafifçe düşünülmelidir. Bu, kendinizi bir ölçeklenebilirlik deliğine yazmamanızı ve kodunuzun ikinci kez ihtiyacınız olan ölçümleri verecek şekilde kullanıldığından emin olmak içindir.

Ölçeklenebilirliği düşünmek için ikinci kez, kabul edilemez derecede yavaş hale gelen şeylerin ilerlemesinde yeterli olacaktır. Bu, "çok yavaş" ın ne anlama geldiğini ve işinizin yük altında nasıl tepki verdiğini bilmeniz gerektiği anlamına gelir. Sürücüsü (muhtemelen qps) ayda% N artan bir hizmetiniz varsa, kaynak kullanımınız yük kare veya yükte doğrusal ise "tüketilen makine kaynaklarının% 95'i" nden oldukça farklı zamanlarınız olur.

Sıra tabanlı bir oyunla, iyi bir güvenlik marjına sahip olmalısınız (muhtemelen tek bir oyun dünyasına sahip değilsiniz ve eğer yaparsanız, muhtemelen dahili bir geometri vardır, yani "herkesin herkesle etkileşime girmediği" sorunları "çevirin).

Ayrıntıları bilmeden, ölçekleme sorunlarının nerede bulunduğunu ve bunları çözmek için hangi olası stratejileriniz olduğunu düşünmek için bir veya iki gün sürerim. Ama bu önemlidir, düşünün. Yapmayın, sadece düşünün (ve belgeleyin). Birkaç yüz kullanıcıyla tezahür etmeye başlayan ölçeklenebilirlik sorunlarınız olmadığı sürece, yükü kontrol etmek ve daha fazla arka uç kaynağı döndürmek için zamanınız olmalıdır.

Açıklamanızdan, iki olası sonuç olduğu anlaşılıyor:

• Oyun bir başarısızlıktır ve o zaman umursamazsınız.
• Oyun başarılı ve arka ucunuz yük ile başa çıkamayacak ve sonuç bir başarısızlık olacaktır.

Hmmm.

İşte kendinize sormanız gereken bazı sorular:

• Mevcut arka ucunuz kabul edilebilir performansla kaç kullanıcıyla başa çıkabilir?
• Bir çeşit hızlı büyüme görüyorsanız, mevcut kullanıcılarla etkisini sınırlamak için bir tür planınız var mı (örneğin, oyunu geçici olarak uygulama mağazasından çekin)
• Başarılı olursanız ne kadar hızlı bir şekilde daha iyi bir arka uç oluşturabilirsiniz?
• Beklemenin ticari sonuçları nelerdir? Kendinizi besleyebilir misiniz? Riskler nelerdir?
• Yukarıdaki sorunun yanıtları verildiğinde, şimdi salıvermenin ticari sonuçları nelerdir?

Bunları düşündüğünüzde sorunuzun cevabı belirginleşmelidir. Her sistem farklı ve her işletme farklı olduğu için hiçbir uzman daha fazla bilgi olmadan ne yapacağınızı söyleyemez.

Sunucunuz kullanıcılar tarafından etkileşimli olarak kullanılacaktır. Bu, gecikmenin kullanıcı deneyimini çok derinden etkilediği anlamına gelir. Kötü gecikme her zaman kötü kullanıcı deneyimine neden olur.

En azından Bryan tarafından tarif edildiği gibi bazı geçici yük testleri yapın.

Daha ciddi bir yaklaşım

Bazı simülasyon çalışmaları yapın ve kullanıcı deneyiminizde gecikmenin ne olduğunu öğrenin (bir ağ gecikme simülasyonu kullanarak veya uygulamanızın içinde sadece uyku ()). Hangi gecikmenin fark edilir hale geldiğini, sinir bozucu ve kullanılamaz hale geldiğini öğrenin.

Ardından optimizasyon yönünde ilk adım geliyor. Sunucunuz için bir SLA'ya karar verin: örn. Can sıkıcı gecikme ile en kötü% 10 çağrılarda ve kullanılamayan gecikme ile% 1 çağrılarda. Bu sınırlarla, sunucunuzun kaç kullanıcıyı destekleyebileceğini bulmak için yük testini kullanabilirsiniz.

Ölçüm gecikmesi olmadan saf verim testi (veya en azından yük testi sırasında sunucuyu manuel olarak kullanarak) o kadar kullanışlı değildir, çünkü ölçülen verim numaralarının katlanılabilir kullanıcı deneyimi ile sonuçlanıp sonuçlanmadığını söylemez.

Gil Tene tarafından gecikmenin ölçülmesi hakkında çok güzel bir sunum: http://www.infoq.com/presentations/latency-pitfalls

Daha sonra, mimari, ops, geliştirme, kalite güvencesi ve ürün izleme gibi tüm öğeler için performans için ortak bir anlayış oluşturmak amacıyla kullanılan iş gereksinimleri aşamasında. Önünüzde neyin gerekli olduğu konusunda ortak bir anlayış oluşturmazsanız, kuruluşun her bir kısmının, yaşam döngüsü boyunca belirli görevlerde bulunurken performans hakkında (ya da hiç düşünmüyorsa) varsayımlarda bulunmasını sağlayabilirsiniz. uygulama. Şelale, kısa şelale, çevik veya özgeçmiş anahtar kelime listesinde o anın geliştirme metodolojisi ne olursa olsun bu geçerlidir.

Performans ve ölçeklenebilirlik zordur. İşlevsellik kolaydır. Kötü ölçekleme kodu, sağladığınız kaynak havuzunu doldurmak için büyüyecektir, bu nedenle daha büyük bir donanım satın alarak maliyet baloncuğunu değiştirmek, verimsiz kodu düzeltmeniz veya daha fazla donanım satın almanız gerekmeden önce sizi o kadar ileri götürür. Bunu öncelikli olarak sürecek şekilde bırakmak da çok maliyetlidir. Performansla ilgili geç gelen bir gereksinimi karşılamak için uygulamanın yaşam döngüsünün erken aşamalarında alınan ve tamamen tersine çevrilmesi gereken mimari ve tasarım kararları vardır - Alüminyumdan alete geçiş yapmak zorunda olan yüksek performanslı bir spor otomobil üreticisi düşünün performansla ilgili bir güç / ağırlık oranına ulaşmak için karbon fiber ve bunun takımları, eğitimi, otomobilin yapısını vb.

Kuruluşunuzdaki mimarlara, geliştiricilere ve operasyon uzmanlarına uygulama için performans gereksinimlerinin neler olduğunu sorun. Bunlar işten alınmazsa, aynı grup içinde bile farklı kişilerden farklı yanıtlar alırsanız (veya yanıtlar almazsanız) şaşırmayın. Bu "varsayımlar" her zaman kuruluşta konuşlandırma yapmak için geri gelir.