Örnek sorular
Cloud Architecture ScalingZorluk 1
IaaS, PaaS ve SaaS bulut hizmet modelleri arasındaki temel fark nedir?
- aIaaS ile PaaS aynı soyutlama seviyesini sağlar; aralarındaki tek gerçek fark, sizin için neyin yönetildiği değil fiyatlandırma modelidir
- bPaaS kullanan bir ekip, tıpkı IaaS'ta olduğu gibi işletim sistemi yamalarını ve sunucu kapasite planlamasını hâlâ kendisi yapmak zorundadır
- cSıfırdan yeni bir uygulama inşa etmek isteyen bir ekip için SaaS en uygun modeldir, çünkü altyapı yığınının her katmanı üzerinde tam ve doğrudan düşük seviye kontrol sağlar
- dIaaS ham altyapıyı (VM, ağ, depolama) sağlar; PaaS yönetilen bir runtime ve ölçekleme ekler; SaaS ise bitmiş uygulamayı hazır servis olarak sunar✓
Açıklama:Üç model, sağlayıcının ne kadar operasyonel sorumluluk üstlendiğine göre ayrışır: IaaS ham compute/network/storage verir, OS ve runtime'ı siz yönetirsiniz; PaaS ek olarak runtime, patching ve ölçeklemeyi de yönetir, siz yalnızca kod gönderirsiniz; SaaS ise hiçbir altyapı yönetimi olmadan bitmiş bir uygulama sunar. b yanlıştır çünkü PaaS'ın tüm amacı OS patching'i ekibin üzerinden almaktır. c yanlıştır çünkü SaaS hiçbir altyapı kontrolü sağlamaz; özel bir uygulama inşa eden ekibin IaaS veya PaaS'a ihtiyacı vardır, SaaS'a değil.
Cloud Architecture ScalingZorluk 2
Küçük bir startup ekibi, dahili bir admin aracı geliştiriyor ve sunucu, işletim sistemi veya runtime yönetmeden yalnızca uygulama koduna odaklanmak istiyor. Bu ihtiyaca en uygun hizmet modeli hangisidir?
- aIaaS, çünkü ham sanal makineler basit bir dahili araç için her zaman en hızlı yoldur
- bSaaS, çünkü kendi bir şey inşa etmek yerine hazır bir CRM ürünü satın almalılar
- cPaaS, çünkü platform runtime, OS patching ve ölçeklemeyi onlar adına yönetir; ekip yalnızca uygulama koduna odaklanabilir✓
- dOn-premises barındırma, çünkü dahili araçlar ekibin hedefinden bağımsız olarak her zaman kendi altyapılarında barındırılmalıdır
Açıklama:PaaS tam olarak bu senaryo için tasarlanmıştır: kod push edersiniz, platform runtime kurulumu, OS seviyesi bakım ve ölçeklemeyi yönetir. a yanlıştır çünkü IaaS'ta OS ve runtime'ı hâlâ ekip yönetmek zorundadır. d yaygın ama hatalı bir genellemedir — güvenlik kaygısı otomatik olarak on-premises gerektirmez, senaryoda böyle bir gereksinim de belirtilmemiştir.
Cloud Architecture ScalingZorluk 1
Bir cloud region ile availability zone (AZ) arasındaki temel ilişki nedir?
- aRegion, birden fazla availability zone içeren geniş bir alandır; bu AZ'ler genelde fiziksel izole olsa da düşük gecikmeli bağlantılarla yakındır✓
- bAvailability zone, region için kullanılan başka bir pazarlama terimidir; sağlayıcılar iki terimi gerçek bir ayrım olmadan birbirinin yerine kullanır
- cRegion tek bir veri merkezi binasını ifade eder; availability zone ise birden fazla ayrı region'ı kapsayan çok daha geniş coğrafi gruplamadır
- dAvailability zone ve region tamamen aynı altyapı sınırını tanımlar; terim seçimi yalnızca hangi sağlayıcıyı kullandığınıza bağlıdır
Açıklama:Bir region birden fazla availability zone'u bir araya getirir; her AZ bağımsız bir arıza alanı (kendi güç, soğutma, çoğu zaman kendi binası) olacak şekilde tasarlanırken, aynı region içindeki diğer AZ'lere düşük gecikmeli iletişim kuracak kadar da yakındır. c ve d şıkları bu hiyerarşiyi tersine çevirir veya birleştirir; bu, cloud mimari diyagramlarını ilk okuyan junior mühendislerde sık görülen bir yanılgıdır.
Cloud Architecture ScalingZorluk 2
Bir ekip, uygulamasının tamamını tek bir availability zone'da çalıştırıyor. Bir olay sırasında, elektrik kesintisi nedeniyle o AZ tamamen erişilemez hale geliyor ve tam kesinti yaşanıyor. İleriye dönük en doğru mimari düzeltme hangisidir?
- aAynı AZ içinde instance boyutunu büyütmek, çünkü daha büyük bir instance elektrik kesintisinden daha hızlı toparlanır
- bDaha fazla replica eklemek ama hepsini ağ ve konfigürasyonu basitleştirmek için aynı tek AZ içinde tutmak
- cTamamen farklı bir bulut sağlayıcısına geçmek, çünkü aynı sağlayıcıda kalmak aynı kesintinin tekrar yaşanacağını garanti eder
- dUygulamayı region içindeki birden fazla availability zone'a dağıtmak; böylece bir AZ arızalanırsa trafik sağlıklı bir AZ üzerinden karşılanmaya devam edebilir✓
Açıklama:Tek-AZ dağıtım, tüm AZ'nin tek bir arıza noktası (single point of failure) olduğu anlamına gelir — aynı AZ içinde boyut büyütmek veya replica eklemek, AZ'nin kendisinin devre dışı kalmasına karşı hiçbir koruma sağlamaz. Instance'ları birden fazla AZ'ye yaymak ve sağlıksız zone'ları atlayan bir load balancer kullanmak, altyapı seviyesinde high availability sağlamanın standart yoludur. a şıkkı kapasiteyi ele alır, erişilebilirliği değil; anlatılan gerçek arıza modeliyle ilgisizdir.
Cloud Architecture ScalingZorluk 1
Horizontal scaling ile vertical scaling arasındaki fark nedir?
- aHorizontal scaling, tek bir sunucunun CPU ve RAM'ini artırmaktır; vertical scaling ise tamamen yeni sunucular eklemektir
- bHorizontal scaling, aynı iş yükünü paylaşan daha fazla sunucu/instance eklemektir (scale out); vertical scaling ise mevcut sunucunun kaynaklarını artırmaktır (scale up)✓
- cİki terim cloud mimarisinde tamamen aynı kavramı ifade eder; farklı sağlayıcılar aynı davranış için yalnızca farklı pazarlama isimleri kullanır
- dVertical scaling yalnızca veritabanı ve depolama sistemleri için, horizontal scaling ise yalnızca stateless web/uygulama sunucuları için geçerlidir
Açıklama:Horizontal scaling (scale out/in), yükü daha fazla makineye dağıtmak için instance ekler veya çıkarır; vertical scaling (scale up/down) ise tek bir makinenin kaynaklarını büyütür veya küçültür. a şıkkı tanımları yer değiştirir, d şıkkı ise gerçek kullanımı yansıtmayan yapay bir kısıtlama getirir — her iki yaklaşım da compute ve veri iş yüklerinde geniş çapta uygulanır.
Cloud Architecture ScalingZorluk 2
Stateless bir web uygulaması artan trafik altında yavaşlamaya başlıyor. Bu uygulamayı ölçeklendirmek için en uygun ilk adım hangisidir?
- aTrafiği azaltmak için rate limiting uygulamak, çünkü kullanıcı sayısını sınırlamak her yavaşlamaya karşı standart ilk tepkidir
- bTek instance'ın CPU ve RAM'ini artırmaya devam etmek, çünkü stateless uygulamalar yalnızca vertical scaling ile ölçeklenebilir
- cUygulamayı stateless'ten stateful'a çevirip oturum verisini her instance içinde tutarak istek işleme yükünü azaltmak
- dAynı uygulamadan birden fazla instance/replica çalıştırıp trafiği bir load balancer arkasında bu instance'lar arasında dağıtmak (horizontal scaling)✓
Açıklama:Stateless bir uygulama oturum verisini belirli bir instance'a bağlı tutmadığı için, herhangi bir instance herhangi bir isteği işleyebilir; bu da onu load balancer arkasında horizontal scaling için doğal bir aday yapar. b yaygın bir yanılgıdır — stateless uygulamalar aslında yatayda ölçeklemesi en kolay olanlardır, vertical scaling'e sınırlı değildir. c ise yanlış yöne gider: state eklemek horizontal scaling'i kolaylaştırmaz, zorlaştırır.