Merhabalar,
Ramazan ayı boyunca Cloud and Serverless Turkey meetup ekibi haftada bir yada iki olmak üzere, ben gibi Cloud’a yeni başlayacaklar için çok yararlı olacak online etkinlikler düzenledi. Ben de dinlerken bazı önemli gördüğüm noktaları not aldım ve blog’uma aktarmak için şu an zaman bulabildim.
- 6 Mayıs Çarşamba - AWS Global infrastructure: Uygulamamı us-east-1’a deploy ettim patladı, orucum kabul olur mu?
- 12 Mayıs Salı - DevOps vs SRE: hangisi daha çok sevap point kazandırır?
- 15 Mayıs Cuma - Cold Start ve diğer Serverless problemleri: İstemeden Cold Start’a yakalandım, orucum bozulmuş olur mu?
- 18 Mayıs Pazartesi - Container vs Serverless: Containerlar ile Serverless fonksiyonları beraber kullanmak caiz midir?
- 21 Mayıs Perşembe - Cloud’a nasıl başlarım: Cloud korkularımı yenmek için ne yapmayalım?
AWS Bulut Altyapısı Bileşenler: Zone, Region, CDN ve daha fazlası
AWS altyapısı ile ilgili kavramları (Regions, AZ-Availability Zones, Local Zones, Point of Presence, Network) görsel olarak anlatan bir site.
Region seçimindeki en büyük fark lateny. Türkiye için genelde Frankfurt tercih ediliyor. (60-80ms round trip latency) Mesela Dublin için 130ms. Rakamların anlam kazanması için; insanın gözünü açıp kapatması 300ms sürüyor.
Bulunduğunuz bölgeden region’lara olan latency’i hesaplayan bir site. Region seçiminde faydalı olabilir.
Peki region, latency harici neye göre seçilmeli? Yeni servis ya da yeni eklenen özellik hemen tüm region’lara gelmiyor. Genelde avrupa için ilk region olan Dublin’e geliyor. Tabii, müşteri profiline göre de bir etkisi var. IoT sektörü oralarda daha gelişmiş olduğu için IoT özellikleri genelde Frankfurt’a geliyor.
Her servisin fiyatı her region’da aynı değil, maliyete göre fiyatlandırma yapılıyor; enerji maliyeti, insan gücü maliyeti vs. Mesela Amerika’da enerji, Amazon’un kendi güneş panellerinden üretildiği için oradaki servisler daha ucuz.
AZ-Availability Zones = Datacenter Cluster
Az to AZ latency: 2-4 ms
Veriyi region’a yükleyince, arka planda birden cok AZ’ye replica ediyor. Yüzde 99,9…(9 tane 9) availability sağlıyor. Veri sadece o region’da, regionlar arası kopyalama yok. Böylece Türkiye bir gün region olursa, veri Türkiye dışına çıkmıyor, yani KVKK’ya uyuyor.
Local Zone= Tek datacenter ve bir region’a bağlı. Altyapıyı hızlı şekilde kurmak için, tüm servisler yok, amaç ihtiyaca göre hızlı cevap verecek şekilde tasarlamak, diğer türlü AZ tasarlamak zor.
Point of Presence ile latency’i azaltmaya yönelik region’a giden yolda cache noktaları var.
Spot instance: Çok kullanılmayan makinelerde (mesela milanda daha az kullanıcı varsa) daha ucuz maliyetle servisleri kullanabilme imkanı var, açık artırma gibi. Diğer kullanım yöntemleri on-demand ve reserved instances.
Ya region fail olursa? O zaman region bazında high availability seçeceksin. Uygulamayı iki regiona dağıtacaksın. Bu da x2 maliyet demek. Ortada bir trade-off var: risk mi maliyet mi? Ama zoned-based architecture yeterince güvenli.
AWS neye göre region kuruyor? return of invesment: yatırımı kaç senede cıkarabilirim?
AWS re:Invent 2016: Amazon Global Network Overview with James Hamilton
DevOps ve SRE farkı nedir?
Farklarında önce bir benzerliği, ikisi de cross-functional team.
DevOps, developerlar işini yapabilsin diye kod hariç herşeyi yapan kesim. Yazılım sektörüyle ilgili teknik pratikleri içerir.
SRE-Site Reliability Engineer, ilk olarak Google tarafından uygulanmıştır. google’ın tanımına göre yazılımcıya SysAdmin işlerini vermeye deniyor.
SRE implements DevOps.
SRE’in ana görevi reliability, yani üründe çıkan soruları çözerek ürünün ayakta sağlam şekilde olmasında sorumlu, bunu da Scalability, Security, Monitoring, Automation gibi DevOps süreçleriyle sağlıyor. Burası işinin %50’si. Kalan %50’si ile yazılım yaparak ürün geliştirme. Ama bu geliştirme domain’e yönelik değil, developer’ların kullanacağı ürünler. Yani infrastructure development.
SRE, şirket içindeki en güçlü yazılım mühendisleridir,koçluk yaparlar, best practice’leri anlatırlar, 2-3 ay bir takıma giderler ve reliability olmayı öğretirler.
Altyapıdaki know-how’ı almak, kişileri bu altyapıya entegre etmek aylar sürebilir. SRE’in altyapıda kullanılan herşey hakkında, normalin ilerisinde bilgisi olmalıdır.
Altyapı çok sancılı bir süreç. Herşeyi tasarladın yaptın ettin ama buna adapte olacak kimse yoksa, yine reliability’in kırılıyor.
Developer’ların kafkayı nasıl scale edeceğini bilmesi gerekmiyor, ama oraya nasıl mesaj atacak bilebilmeli. Buradaki ownership, takımlarda değil SRE’de. Developer nasıl kullanacağını biliyor ama nasıl çalışıyor bilmiyor. Serverless’a yakın bir sistem sunuluyor aslında. Shared-Responsibility.
https://jbd.dev/prod-readiness/
https://medium.com/google-cloud/production-guideline-9d5d10c8f1e
FaaS - Serverless (AWS Lambda) Problemleri ve Çözümleri
AWS Lambda, tam karşılığı FaaS, büyük uygulamaları input ve output olacak şekilde küçük function’lara bölüyoruz. Nerede nasıl hangi serviste çalışacak, scalabilty’si bizi ilgilendirmiyor, bunlarla serverless ilgileniyor. Aslında adı da buradan geliyor, server’ları bizden soyutladığı için serverless deniliyor, yoksa arka planda yine server’larda çalışıyor. AWS Lambda, stateless bir servis. Ayrıca event-driven. Mesela S3’e dosya eklendi, bu create event yaratır, lambda bunu yakalayarak trigger’lanabilir. Event nasıl gelecek, nasıl işleyeceğim diye endişelenmiyorsun, geldiği an işliyorsun ne güzel.
Lambda Problemleri
Cold Start; Initialize olma süresine cold start deniyor. Lambda container’lar üzerinde çalışıyor. Uygulamaya request geldiğinde, lambda önce hazırda varsa ona yonlendiriyor, yoksa yeni container ayağa kaldırıyor. Container’lar hızlı ayağa kalkıyor ama buradaki asıl sorun uygulamanın ayağa kalkması. Mesela spring saniyelerce sürüyor. Bu genelde Java sorunu, Spring’i lambda’ya olduğu gibi taşırsan oooooppppsssss.
Lambda işi bitince, container’ı freeze ediyor, request gelince tekrar unfreeze ediyor. Belli süre request gelmezse, buna zaten istek gelmiyor deyip kendini kapatıyor. Bu yüzden stateless olsun deniyor lambda’larınız.
Bazı çözüm yolları;
- İstenilirse istenen sayıda container ayakta tutulur. Negative effect: pricing. Zaten EC2 yerine kullanma nedeni ucuza getirmek, sadece function’ın çalıştığı süredeki kaynaklar için ödeme yapılıyor.
- Boş/dummy mesajlar gönderilerek kapanması önlenebilir, warmup.
At Least One Delivery Problem. Tek bir request için bir kez çalışması beklenen function’da, iki kere calısma yaşabiliyor. Çünkü exactly once maliyetli, bunu sunars throughput’u düşüyor. Idempodent işlemler sorun olmaz ama ödeme gibi önemli islemlerde birden fazla olamaz. Distributed, genelde at-least-one sunuluyor, aynı durum standart SQS’te de var.
Step functions bunu cozuyor.
Lambda, çok fazla scale edilirse concurrent calışarak, on-demand servisere mesela RDS’e birçok connection açılabiliyor. Lambda’da bu, concurrent execution limit ile sınırlanabiliyor, peki ama gercekten scale etmesi gerekirse o zaman edemez. RDS özelinde bu, RDS proxy ile direkt DB’ye connection açmak yerine proxy’e açılarak çözülüyor. Proxy, fiziksel connectionları yönetiyor, bu sayede yükün çoğu proxy’e biniyor.
OpsGenie 40.000 $’lık fail hikayesi. Cloudwatch’a log geldikçe lambda yakalıyor ve graylog’a gönderiyor. Graylog down oluyor. buraya gönderilemeyen mesajlar dead letter queue’da birikiyor. Lambda DLQ’dan tekrar tekrar trigger oluyor. 2 hafta boyunca queue büyüdükçe lambda sürekli scale oluyor. Sonuç 40bin dolar fatura.
Monitoring ve Debugging
Lambda dışarıdan connection kabul etmiyor. Nedeni VPC, ona adres atamıyor. Ancak API Gateway ile dışarıdan erişilebilir.
Lambda yalnızca request’i işlerken aktif, o yüzden iş bitince arkada logu gonderecek bir şey yok. Her an ölebilir, donabilir, loglar da gönderilmeden kalabilir. mesela Elasticsearch API ile göndermek uygulamayı ağırlaştırır, o yüzden bir seçenek değil.
Uygulamada debugging nasıl oluyorr? IDE, uygulamaya network connection açıyor. Debug ile alakalı komutlar, bu TCP connection üzerinden gidiyor. Lambda da dışarıdan bağlanamıyosun, ee? Thundra, bu workaround’da çalışıyor. IDE ve lambda ortada broker’da buluşuyor. Kullanıcılar local IDE’sinden debug edebiliyor.
How AWS Lambda team made my two years old talk completely irrelevant by Serhat Can
Bulutta Yüksek Performanslı ve Verimli Sistem Tasarlama
- Metrics
İşler iyi gitmiyorsa problemin nerede olduğu metric’lerden anlaşılır. O yüzden iyi bir sistem tasarlarken metric toplamak, özellikle hangi metric’ler toplanacak önemli. Mesela dışarıya API sunuluyorsa bu metricler latency, erros, CPU/memory/IO olabilir. Latency yüksekse client, sistem performansından memnun olmaz demektir, bu anlaşılır. Avg latency’e bakmak outlier’ları gizler, bunun için performansa bakılırken avg latency yerine p90, p99, max latency ile ilgilenilmeli. (p90=percentile 90. x latency ile alakalı metric’lerin yüzde90’ı x altında.) Max latency, sistem en kötü durumda ne kadar cevap veriyor demek, bu yüzden max’a başvurmak en iyisi.
Client Error (HTTP 4xx) ignore edilebilir, ama sık sık gelirse incelenmesi gerekebilir. Server Error (5xx) aslında önemli, bu error’lara alarm kurmak iyi bir pratik.
Sunucu üzerinde calısan uygulamalar icin CPU/memory/IO. Eğer memory, sınırlarda dolaşıyorsa out-of-memory yemesi işten bile değil. IO, sürekli diske yazan okuyan işlemler, belki bir kere okuyup cacheleyerek disk üzerindeki baskıyı azaltmak yerine sürekli diskten okuma, sistem yavaşlığına sebep olabilir. Bu metric ile anlaşılabilir.
Servislere özel metricler; redis, lambda, sqs, knesis, dynamodb’a özel metricler. mesela sqs’de # msg visible, bir anda artarsa kuyrukta consume hızı yavaş, ileride sorun yaratabilir uyarı demek. Redis icin eviction (cache belli bir memory sınırına ulaşınca, kendisini sağlıklı tutabilmek için cache’deki varolan itemlar’den evict etme). Eviction’ların çok olması, memory’nin yetersiz olduğuna ya da gereksiz yere çoğu şeyi cache’de tuttugumuz anlamına gelebilir.
- Caching
Amaç, optimizasyon ve daha iyi performans. Ne tür cache’lemeler yapılabilir?
Read’ler icin diske gitmeden de sonuç dönebilme için cache-layer. Cache layer = Local Cache (remote cache’e network call atmasına gerek kalmadan) + Remote Cache(Redis, ElastiCache vb.)
negative cache , positive cache. cache hata bulunursa kullanıcıya hata mı dönülsün?
inline cache
side cache= cache ve db aynı yerdeyse side cache mesela dax, dynamodb önündeki cache. tek bir layer gibi geliyor.
Thundering herd problem: Cachede data yok, 100 request aynı anda geldi, 100’ü de aynı anda DB’ye gidecek demek. Bunun yerine cache kısmında, cache’den arka servise erişilirken lock tutulup sadece birisi DB’ye erişebilir. Böylece arkadaki servis boğulmamış olur.
- IO
Async IO ve Non-blocking IO benzer ama detayda farklı. Async için, o thread o işi yapmak i.in baska thread’e paslıyor. Arkadaki işi paylaştığı thread’ler birbirini bekleyeebilir thread pool’da. Mesela 100 thread’lik bir pool. 101. thread pool’u bekleyecek.
Non-blocking’de, beklemeden ziyade OS seviyesinde select/pool, epoll ile işlemler.
Connection, elden geldiğince reuse edilmeli. keep-alive. Https için, birden fazla round trip oluyor, mesela sertikayı al gibi bir overhead. http/2, http/1 üzerine avantajlı, client’ın istemesine gerek olmadan server-push mantığı sağlıyor.
İletişim protokolü uygunsa REST değil de gRPC. gRPC, default http/2 üzerinde. REST, genelde json ve xml formatında ama çok sıkıştırılmış data değil. gRPC’de data size’ı çok küçük, boylece daha az data gidip geldiği icin performanstan kazanılır.
CDN kullanılmalı. DNS resolution aşamasında, CDN edge seçimi gerceklesiyor. Web sayfası icin ciddi performans sergiliyor, aksi takdirde dünyanın öbür ucuna gidip gelmesi bayağı bir network delay olur.
- Redis
Redis Pipelining: redis’e tek tek gitmek yerine batch ile gitmek. Böylece tek seferde gönderilir, rediste internal olarak tek tek işlenir.
Persistent olması istenmiyorsa kapatılmalı. RDB snapshot ile, periyodik aralıklarda redisin snapshot’ı diske yazılıyor, default bu var.
Disk Swap; memorydeki data diske transfer edilirse yavaslık olur, disk swap kapatılması iyi olur.
Komutun complexity’sinin farkında olunmalı. O(n) gibi bir komut için milyonlara item varsa, bu komut sn’ler sürebilir. Redis’in sitesinde hangi komutun ne kadar karmaşıklıkta olduğu yazıyor.
- ElasticSearch
Reindex’lemek. Eğer çok fazla update/delete varsa index’i yenilemek icin önemli. Yine disk swap edilmeli. Profiling api ile, query planı görülebilir. Query hakkında nasıl çalıştığı hakkında bilgi sağlayarak bir inside verir, yani profiling ile monitoring.
- Event-Driven Architecture
Böyle tasarlanmasının faydası? API, gelen istekle datayı yazmak icin beklememiş olacak. Baska servise delege edecek. Hatta servis, batch olarak yazarak yazdığı servisi daha fazla yormamış olur. Hem de hata durumlarında daha kolay çıkılır.
- Replicate
Kendisine daha yakın storage’den alması. Data locality ve failover mekanizması.
- Recover
Sistemin dayanıklı olmasını sağlıyor. Periyodik olarak sistem snapshot’ı alınabilir.