Ankara TechTalks #1

Onedio Ölçeklenebilir Mimarisi
Enis Bayramoğlu & Hasan Tayyar BESIK

http://www.meetup.com/Ankara-Tech-Talks/events/231360785/

Transcript

1. Onedio Platformunun Ölçeklenebilir Mimarisi Enis Bayramoğlu enis@onedio.com Hasan Tayyar Beşik tayyar@onedio.com
2. Ölçeklendirilebilirlik Sistemin artan yük/iş karşısınsında genişleyebilme yeteneği.
3. Onedio Mimarisi
5. ElasticBeanstalk
6. ElasticBeanstalk • Altyapı bağımsız • Kolay ◦ Deployment ▪ Zero downtime ◦ Scaling ◦ Capacity provisioning ◦ Load balancing ◦ Application health monitoring
7. ELB & EC2
8. ELB Elastic Load Balancing Gelen trafiği EC2 makinelerine otomatik olarak dağıtır
9. ELB • Round Robin • Health Check ◦ Tcp veya http check ◦ Custom freq. ve failure threshold • Idle timeouts ◦ Default 60 sec • ELB with Multi-zone + Route53 = ⚡ • Cross Zone Balancing = ⚡ • Cloudwatch ile detaylı gözlem • Cloudwatch metriklerine göre autoscale ayarlayabilme
10. ElastiCache
11. ElastiCache • In-Memory Cache Service • Supports ◦ Memcached ◦ Redis
12. DynamoDb
13. DynamoDb • Nosql • Ölçeklenebilir • Hızlı ve öngörülebilir performans • 3 way replicated default • Automatic distribution ◦ Amazon DynamoDB stores three geographically distributed replicas of each table to enable high availability and data durability. • SSD • In-place Atomic Updates • Tahmini maliyet hesaplama https://aws.amazon.com/dynamodb/faqs/
14. DynamoDb - Table & Keys • Partition/Hash key * ◦ Bu key ile DynamoDb unordered hash index olusturur. ◦ Bu hash index tablonun bölüntülenmesini saglar. • Sort/Range Key ◦ (HashKey + RangeKey) = Composite Key
15. DynamoDb - Indexes • Global Secondary Index • Local Secondary Index - bir çesit Sparse index • Sparse Global Index
16. DynamoDb - Scaling - Partitioning Otomatik Partition ( readCapacityUnits / 3,000 ) + ( writeCapacityUnits / 1,000 ) = initialPartitions ( 1,000 / 3,000 ) + ( 500 / 1,000 ) = 0.8333 --> 1 ( 1,000 / 3,000 ) + ( 1,000 / 1,000 ) = 1.333 --> 2
17. DynamoDb - Scaling - Throughput • Throughput “To get the most out of DynamoDB throughput, create tables where the partition key has a large number of distinct values, and values are requested fairly uniformly, as randomly as possible.” http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html
18. DynamoDb - Scaling - Throughput • Throughput Hot Data ve Cold Data birlikte olmamalı Her zaman dilimi için farklı tablo kullanın Analytics201603 Analytics201604 Analytics201605
19. DynamoDb - Scaling - Size Item sayısı sınırı yok Tablo büyüklügü sınırı yok ama dönemlsel olarak bölmeniz tavsiye edilir En büyük Item 400KB olabilir LSI en fazla 10GB olabilir
20. DynamoDb - Para Ortalama maliyeti öngörebilirsiniz.
21. DynamoDb vs SimpleDb SimpleDb • Limited storage ☠ • Limited write/read capacity ☠ • Limited Scalability features ☠ • Tüm degerler indexlenir ☠ • Küçük projeler için ideal ✔
22. MongoDb
23. MongoDb - Replication • MongoDB Replicaset ◦ Tek sayıda üye ▪ Primary seçim sorunu. 2 üye kalırsa primary seçilmez. ◦ “Delayed” üye ◦ http://cloud.mongodb.com
24. CDN & Firewall
25. Güvenlik • Çok sayıda AWS kullanıcı rolü • AWS CloudTrail ile tüm işlemler takip ediliyor • AWS CloudWatch alarmları • ThirdParty monitoring araçları
26. Felaket Kurtarma • Offline ve Online yedekler. • CloudFormation
27. Case Study: Hangi Ünlüye Benziyorsun? http://oned.io/h/674564
28. Görüntü İşleme altyapısı: Caffe + OpenCV • Resimde yüzün varlığını doğrulama: OpenCV Haar Cascade Classifier ◦ Python ◦ CPU üzerinde ~30 ms • Doğrulanan resmi önceden verilen ünlülerden birine benzetme: Caffe ◦ Python ◦ Önceden eğitilmiş bir ağı kendi ünlü setimize adapte ettik. ◦ CPU üzerinde ~20s ◦ GPU üzerinde ~500ms
29. Klasik Sunucu - İstemci Etkileşimi • İstemci sunucuya istek atar. • Sunucu ilgili veritabanlarına sorgular atar ve cevabı hazırlar. • Sunucu istemciye cevabı döner ve etkileşim tamamlanır. 1. İstekler yığıldığında cevabın hesaplanması onlarca saniye sürebilir 2. Caffe modelinin GPU üzerinde işlenmesi gerekiyor!
30. Çözüm: Mesaj Kuyruğu • İstemci sunucuya istek atarak işlemi başlatır • Sunucu yapılacak işi mesaj kuyruğuna koyar • İşçilerden biri işi alır • Sonucu istemcinin erişebileceği bir yere koyar • İstemci “poll” yaparak sonuca ulaşır
31. Sistem Bileşenleri • Sunucu: Node.js üzerinde Onedio Back-end Beanstalk Node.js Autoscaling Group(AWS) Onedio KV Store • Mesaj kuyruğu: Beanstalk • İşçiler: AWS Autoscaling Group içerisinde G2 (GPU) instance’ları • Sonuç tablosu: Onedio’nun özel key - value sunucusu
32. Mimari Sorun • Sorun: Autoscaling Group içinde yazılım güncellemesi yapmak çok zahmetli Autoscaling Group(AWS) • Sorun: Geliştirme bilgisayarında altyapıyı kurmak çok zahmetli ve işlem çok uzun sürüyor • Çözüm: Yeniden kullanılabilir temel işlemleri “mikroservis” yapmak. • Sorun: Mesaj kuyruğu geleneksel istek-cevap çalışma şekline yabancı! (Cevaplar da kuyruğa koyulmalı)
33. Hangi Ünlü Basamakları 1. Resmi OpenCV ile incele, resimde yüz olduğunu doğrula. 2. Yüz bulunamazsa KV store’a hatayı bildir, işlemi bitir. 3. Resmi Caffe modeliyle işle, ünlülere benzerliğini puanla. 4. Caffe’den gelen puanlara göre, kullanıcıya gösterilecek alternatifleri seç ve KV stora’a yaz. Yeniden Kullanılabilir Uygulamaya Özel
34. Mesaj Kuyruğu Merkezli Akış OpenCV yüz tespit kuyruğu Lineer cebir kuyruğu Caffe model kuyruğu İşçiler hangiunlu_app_v1 kuyruğu Uygulama Yürütücüsü Onedio Back-End
35. • İstek - cevap iletişim modelinde, istemci uygulamanın durumunu (state) tutar, sunucu sadece isteği işler, sunucunun durumunda değişiklik olmaz. • İstemci isteği atar ve cevabı bekler, cevap geldiğinde ne yapacağını bilir. • Kuyruk merkezli akışta istemci sorguyu atar ama cevabı beklemez. Cevabın aynı işlem’e (process) hatta aynı bilgisayara döneceği bile garanti değildir! • Uygulamanın bütün durum verisi istekle birlikte mesaja eklenir, sunucu isteği işler, yerine mesajı koyar ve durum bilgisiyle birlikte cevabı döner. • Yani istemcinin durumunda da değişiklik olmaz! • Bütün global durum mesaj kuyruğunda tutulur! Mesaj Kuyruğu Merkezli Akış - Tartışma
36. • İstekte bulunmak için, isteğin kuyruğuna şu veriler yollanır: ◦ İstek argümanları (resmin URL’i, caffe modelinin adı vs.) ◦ Uygulamanın durumu (uygulama sonunda cevabın nereye yazılacağı vs.) ▪ Not: cevabı işleyecek “handler”ın kodu durumun bir parçasıdır (Program counter). ◦ İsteği yapan uygulamanın mesaj kuyruk kodu. • İstekleri cevaplamak için şu prosedür takip edilir: ◦ İstek kuyruğundan bir mesaj alınır, cevap kuyruğu, argümanlar ve kalanı ayrıştırılır. ◦ Argümanlar işlenerek isteğin cevabı oluşturulur. ◦ İstekle bildirilen uygulama kuyruğuna cevap ve uygulama durumunu içeren mesaj eklenir. • Uygulamayı yürütmek için şu prosdür takip edilir: ◦ Uygulamanın kuyruğundan bir mesaj alınır ve bir sonraki handler tespit edilir. ◦ Bu handler, uygulama durumu ve mesaj cevabıyla çağırılır. Protokol Özeti
37. seksek.py Protokolün Python kütüphanesi olarak gerçeklenmesi: seksek (200 satır!)
38. • Protokolün uygulanmasıyla ilgili bütün sıkıcı ve hataya yatkın detayları seksek düzenliyor. • Uygulama basamaklarında ya da sunuculardan birinde bir hata oluştuğunda, seksek hataya sebep olan mesajı “bury” ediyor. Bu mesajlar kaybolmuyor, kodda hatalar ayıklanırken kullanılabiliyorlar. • Uygulamayı ya da servisleri yürüten işlemlerden biri ölse bile işler kaybolmuyor. • Seksek protokolü her dilde gerçeklenebilir ve farklı dillerin uygulamaları ve sunucuları şeffaf bir şekilde konuşabilirler. Faydaları
39. queue_manager.py • AWS konsolundan autoscale group instance’ları sistem metriklerine göre otomatik olarak açılıp kapatılabiliyor. • Kullanılabilen metrikler: CPU kullanımı, RAM, Trafik etc. • İşçiler isteklere cevap verirken %100 kapasitede çalışıyorlar, ama bu sistemin ne kadar yoğun olduğunu temsil etmiyor. • İstek kuyruklarında biriken mesaj sayısı yoğunluğu çok isabetli temsil ediyor! • queue_manager.py: Kuyrukları takip edip AWS API’si üzerinden işçi sayısını artırıp azaltıyor.
40. Sorular