Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Ankara TechTalks #1

Ankara TechTalks #1

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

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

E80bb03522c1606b401d0a87266e8910?s=128

Hasan Tayyar BEŞİK

June 03, 2016
Tweet

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

  4. None
  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