Spotify altyapısına teknik bir bakış

Bu Pazar günü hem biraz eğlenceli şeyler yapmak, beyin dinlendirmek hem de bir süredir merak ettiğim bir konuyu derinlemesine araştırmak için  aldım kahvemi elime ve Spotify müzik servisinin ardındaki teknolojiyi araştırmak, notlara dökmek için kolları sıvadım. Şimdiden uyarayım, biraz uzun bir yazı olabilir.

Çoğumuzun düzenli olarak kullanığı Spotify müzik servisinin arka tarafındaki (Backend) mimarisi, çalışma şekli, yapıda kullanılan teknolojiler ve bu teknolojileri bir araya getiren yapılar hakkında yaptığım araştırmada kullandığım, çevirisini yaparak derlediğim kaynaklar ve kullanılan teknolojilerin telif hakları sahiplerine aittir. Bu da böyle biline. Araştırmanın büyük çoğunluğu Spotify çalışanlarının çeşitli online mecralarda (Quora, Reddit) yaptıkları altyapı ile ilgili paylaşımlar, sunumlar ve akademik tezlerden yapılan alıntılarla oluşturulmuştur.

Makaleyi yazarken karşılaşacağım ve hakkında bilgi sahibi olmadığım sistemler hakkında kısa bir araştırma yapıp, nedir? ne değildir? ne işe yarar? gibi kısa bilgilendirici notları da eklemeyi ihmal etmeyeceğim. Olur da eksik ve yanlış bir bilgi fark eder ederseniz geri bildirimden çekinmeyin lütfen.

Motivasyon: 

Severek kullandığım bu servisin oluşumunda neler var? Milyonlarca kullanıcının oluşturduğu trafiğin altından nasıl kalkıyorlar?  Kullanılan araçlar, teknikler, yöntemler neler? Bu tür sorulara cevaplar bulmak oldukça eğlenceli görünüyor.

Haydi başlayalım

Müzik formatlarının zaman içinde yaşadığı evrim müziğin dağıtılma ve dinleme biçimini de değiştirdi. Kurşun kalemlerle sardırarak düzeltmeye çalıştığımız vinly teyp kasetlerimiz, temiz tutmaya özen gösterdiğimiz çizilmeye duyarlı CD’lerimiz artık yerlerini Online servislere bırakmış durumda. Günümüzde Spotify bu servislerden en önemlilerinden birisi. Artık insanlar müzik koleksiyonlarına her yerden ulaşabilir durumdalar.  Spotify mevcut müzik servislerinin direkt bir kopyası değil kendine özgü bir çok yeteneği mevcut. Kullanıcılar web üzerinden hizmet veren diğer müzik servislerinin aksine Spotify istemcisini masaüstü veya mobil cihazlarına yükleyerek sistemi kullanırlar.

Sayılarla Spotify

Milyar tane kullanıcı Playlist’i, 24 Milyon aktif kullanıcı, 20 Milyon şarkı ve her gün 20.000 adet bu sayıya yenisi eklenmekte. 6 Milyon Premium kullanıcı.  90 Backend sistem, 23 Site Reliability Engineer, 2 lokasyon, 15’e yakın geliştirme takımı. Her gün kullanıcılar tarafından oluşturulan 1TB sıkıştırılmış veri. Günlük aktif olarak kullanım yapan 8 Milyon kullanıcı.

(2013 yılında, Site Reliability Engineer olarak çalışan David Poblador’un yaptığı sunumdaki veriler ile Machine Learning uzmanı Chris Johnson‘ın verileri kullanılmıştır.)

İşin sırrı p2p Network!

Spotify, milyonlarca son kullanıcıya şarkıları ulaştırabilmek için kendi sunucu ve band genişliğini kullanmak yerine (peer-to-peer) P2P Network kullanır.  Aslında mantık Pirate Bay veya Kazaa gibi sitelerin çalışma yöntemleri ile aynı.

Kullanıcı dinlemek üzere bir şarkı seçtiğinde Spotify sunucuları veriyi anlık olarak kullanıcı bilgisayarına yönlendirir. Aynı zamanda Spotify diğer Spotify kullanıcılarının bilgisayarlarına da bakarak ilgili şarkıyı bulur ve şarkının dosyalarını yeni kullanıcının bilgisayarına yönlendirir. Bu işlem sonrası trafik yükü Spotify merkez sunucularından alınarak p2p bağlantı üzerine aktarılır.

spot-cache

Önbellekleme’nin gücü

Spotify, playback hızını ve tutarlılığını korumak için başka bir yöntem daha kullanır; Önbellekleme (Cache). Spotify üzerinden kullanıcı şarkı dinlemeye başladığında şarkı kullanıcı bilgisayarındaki hard disk üzerinde önbelleklenir. Şarkılar direkt olarak Hard disk üzerinden çalar. Varsayılan olarak bu tampon bölge 10GB olarak ayarlanmıştır.  10GB yüzlerce şarkının önbelleklenmesi için yeterlidir. Bu bölge aynı zamanda Premium hesap sahibi kullanıcıların şarkıları Download ettikleri bölgedir.

Spotify kaynaklarından Stream edilen bütün şarkılar Vorbis formatındadır. MP3 formatı gibi bu format da şarkıları sıkıştırır ve transfer edilmesini kolaylaştırır. Çoğu şarkının stream edilmesi 160Kbps (kilobits per second) civarında bir hat trafiği oluşturur. Premium hesap sahibi kullanıcılar için ise daha yüksek kalitede Stream mevcut, 320Kbps.

Spotify’ın sadece bir Web servisi olmadığını ve p2p ağlar ile Scale olup milyonlarca kullanıcının trafik yükünün üstesinden geldiğini daha önce belirtmiştim. Bu trafiği istatiksel olarak betimleyecek olursak, kullanıcı isteklerinin sadece %8.8’i Spotify merkezi sunucuları üzerinden karşılanmakta. Geri kalan bütün trafik p2p ağlar ile kullanıclarda Cache halde duran dosyaların yönlendirilmesi ile oluşmakta. Yani siz de eğer bir Spotify kullanıcı iseniz muhtemelen siz de bu legal p2p ağa hizmet etmektesiniz. 🙂

spot

Spotiy’ın kullandığı p2p network’e biraz daha yakından bakalım; bu network tıpkı bir BitTorrent network gibi kullanıcılar (peer) arasında oluşturulur. Bu kullanıcılar diğer şarkı dinleyen ve dinlemek isteyen kullanıcılardan başkası değildir. Torrent networklerin aksine “Preferred” yani tercih edilen bir SüperNode yoktur. Bağlı olunabilecek Peer sayısı maksimum 60’tır. Bir Spotify Client aynı anda sadece 4 kullanıcıya veri gönderebilir. Spotify merkezi sunucuları üzerindeki Network sorgularının çoğunluğu, dinlenen bir müziği dinleyen diğer kullanıcıların lokasyon olarak nerede olduğu ile ilgilidir. Spotify, UDP protokolü yerine TCP kullanır. Böylece tıkanıklık kontrolü, Monitoring ve kayıp paketlerin tekrar gönderilmesi işlemlerini yönetebilir.

Spotify kullanıcıları Spotify sunucuları üzerinde en yoğun saatlerde saniyede 1.5 milyon event oluşturur. Spotify,  kullanıcıların oluşturduğu bu trafiği Event Delivery System olarak adlandırdığı bir sistem ile yönetir. Bu sistem tamamen “Öngörülebilir bir gecikmeye sahip olmak ve asla veri kaybetmemek üzerine dizayn edilmiştir.” diyor Igor Maravic yaptığı bir sunumda. Event Delivery System, birlikte çalışan birçok mikro servislerden oluşan  karmaşık bir dağıtık sistemdir

Big data? 

Storage yönetimini kolaylaştıran en büyük etken ise kullanıcı tarafında tutulan büyük Cache’lerdir.  Cache dosyaları kullanıcıların dinledikleri müzikleri şifrelenmiş bir şekilde tutarlar. Bu dosyalar nedeni ile kullanıcıların network trafik kullanımını önemli ölçüde düşürür. Defalarca dinlenen parçalar veya listeler bu cache dosyalarından yürütülür.

Spotify’ın merkezi Master Storage alanı 290TB’tır. Buna ilave olarak iki adet Production Storage alanı mevcuttur. Bunlar 90TB Londra ve 90TB Stokholm’de konuşlanmıştır.

Spotify’ın ses formatı olarak Ogg Vorbis kullandığından bahsetmiştik. Ogg Vorbis q5 bitrate yani kabaca 160 kpbs olarak kullanıcıya ulaşır. Premium kullanıcılar ise q9 bitrate ile yaklaşık 320 kbps kalitesi ile şarkılar dinlerler.  Ogg Vorbis saf format olarak kullanılmaz, Spotify kendi özelleştirilmiş Header’larını kullanır. Bu aynı zamanda her şarkı dosyası içinde parçanın belirli bölümünü aramaya yardım eder. Bu ses dosyaları kullanıcı tarafında Crypt edilmiş durumdadır. Yani bu şarkılar lokalde cache durumda bile olsa şarkının çalışabilmesi için Network bağlantısı gerekmektedir. Eğer kullanıcı bir listeyi “Offline Playback” seçeneği ile işaretlemişse şarkılar ancak o zaman Offline çalışabilmektedir.

TCP’nin gücü adına!

Adım adım Spotify altyapısının çalışma mantığı:

  1. Kullanıcı Spotify Client kullanarak bir şarkıyı dinlemek üzere tıklar
  2. Eğer şarkı Cache üzerinde kayıtlı ise Spotify şarkıyı lokal dosyaları kullanarak çalmaya başlar.
  3. Şarkı Cache’de değilse Spofity Client şarkının ilk 15 saniyesini Spotify merkez sunucularından talep eder. Şarkı mümkün olan en kısa sürede çalmaya başlar.
  4. Bütün bu işlemler olurken Client aynı zamanda p2p Network aracılığı ile şarkıyı diğer Spotify kullanıcılarında aramaya başlar.
  5. Şarkının geri kalan kısmı çeşitli kaynaklardan toplanarak stream edilir. Cache, Multiple Peers, Spotify Servers gibi. Eğer şarkı çok fazla popüler bir şarkı ise merkezi Spotify sunucuları yerine muhtemelen p2p ağlar üzerinden çekilir.
  6. Şarkı çalmaya devam ederken şarkının bitmesine son 30 saniye kala Spotify Client p2p ağlar üzerinde bir sonraki şarkıyı aramaya başlar.
  7. Şarkı bitimine son 10 saniye kalasıya, bir sonraki şarkı p2p Network üzerinde bulunmamışsa Client tekrar yeni şarkıyı Spotify Server’ları üzerinden fetch ederek çalmaya başlar.

Yetmedi mi? Haydi biraz daha derinlere inelim.

Spotify’ın Infrastructure mimarisine biraz daha yakından bakalım. Konu ile ilgili yaptığım araştırmalarda Spotify’da Backend Developer olarak çalışan Niklas Gustavsson’un mimari ile ilgili birkaç açıklamasına rastladım.

Servis odaklı mimari

Spotify’ın Backend mimarisi oldukça “service oriented” şeklinde. Backend, yüzlerce servisin -ki çoğunlukla ufak ve basit parçalardan oluşan- bir araya gelmesi ile oluşuyor. Servislerin çoğu, birkaç tanesi dışında Python ve Java ile yazılmıştır. Servislerin birbirleri ile olan iletişimi, mesaj bazlı ve ZeroMQ ve Protobuf üzeirine inşa edilmiş Hermes protokolü ile sağlanmıştır. Bunlarla birlikte eski servisler halen HTTP ve XML/JSON kullanmakta. Storage için öncelik  PostgreSQL, Cassandra ve çeşitli statik indekslerde. Yeri gelmişken, PostgreSQL açık kaynak, nesne-ilişkisel (object-relational) bir veritabanı. Cassandra ise scalability yani ölçeklenebilirdiğin ön planda olduğu ve High Availability yani yüksek erişilebilirlik, servisin her durumda ayakta olması gereken durumlarda tercih edilen bir veritabanı sistemidir. Bulut yetenekleri ve lineer ölçeklenebilirlik, hata giderme yetenekleri ile Mission-Critical servislerde tercih edilmektedir. Farklı lokasyonlardaki Data center’lar aracılığı ile replikasyonu desteklemesinden dolayı sınıfının en iyisi konumundadır.

Spotify iş kritik ve tutarlılığın ön planda olduğu işler için PostgreSQL kullanmakta. Çok hızlı büyüyen datalar ön planda ise Cassandra kullanmakta.

Bu kadar Cassandra reklamı yaptıktan sonra tekrar Spotify Backend mimarisine geri dönelim. 🙂

Bu yapıların diğer kullanım alanı ise içerik servisleri (Content Services), arama veya metaveri‘lerin kayıtları için kullanılmakta. Ses dosyalarının çoğunluğu (2012 yılı için konuşursak) Amazon S3 servisi üzerinde konuşluydu, şimdilerde ise Google Cloud Platform üzerine taşınıyor olduğu bilgisi mevcut.

Client tarafına bir bakış

Spotify masaüstü, mobil istemci ve Embedded Library, libspotify’ın hepsi ortak bir code base kullanır. Daha sonra her istemci için bu çekirdek üzerine özelleştirilmiş kullanıcı arabirimlerini ve diğer platform  gereksinimlerini eklenir. Code Base C++ dili ile yazılmıştır. Platformlar için ise o platformun native dili kullanılmıştır. Örneğin iOS için ObJC gibi.

Veriler daha önce de bahsedildiği gibi Local Cache’den, peer-to-peer bağlantılardan ve merkezi storage sunucularından gelir. Bu konu ile detaylı bilgi şu paper dosyasından alınabilir.

Open Source krallığı

Spotify altyapısında kullanılan diğer tüm Open Source araçlar gibi işletim sistemlerinin de Open Source olduğunu ve ağırlıklı olarak Debian işletim sistemi kullanıldığını söylüyor yazısında Niklas Gustavsson.

Genel olarak kullanılan teknolojiler ile ilgili şöyle bir liste verilmiş;

Amazon (CloudSearch, CloudFront, S3) Android Wear SDK, Apache (Cassandra, Kafka, CloudStack, Web Server), Babel, Bootstrap, DbVisualizer, Fabric, Genymotion, Java, jQuery, Mashape, Modernizr, Objective-C, PostgreSQL, PyCharm, Python, Raml, Reveal, SQLite, Testflight, Underscore.js, UpSource, Bynder, Carpathia by QTS, Crashlytics, Datadog, DigiCert, Disqus, Docker, Domaininfo Domain Registration, eNom Hosting, Fastly, GoDaddy SSL, Kount, New Relic, nginx, Pingdom, PractiTest, TeamCity, Tumblr, and WordPress.

Kullanılan teknolojiler Spotify çalışanları tarafından da doğrulanmış.

spot-arch

Biraz daha derinlere inelim

Servislerin çoğunun Python ile yazıldığından bahsetmiştik. Birkaçının da C ve Java ile ilgili olduğu ve Storage’lar her servis için ayrıca optimize edildiğinden bahsedilmekte. Çoğunlukla Cassandra ve Tokyo Cabinet ile altyapı sağlanmakta.

Tamam da nedir bu Tokyo Cabinet? Tokyo Cabinet bir library, veritabanı yönetimini kolaylaştıran bir rutinler kütüphanesi. Database’in kayıtları tutan basit bir data dosyası olduğunu düşünürsek ve her kaydın bir key ve value olduğunu, her key ve value’nun da bir değişken uzunluğundaki byte boyutu olduğunu biliriz. Bu değerlede Binary data ve karakter Stringler’in kullanıldığını biliyoruz. Kayıtların da bir hash tablosunda organize edildiğini biliyoruz. Tokyo Kabinet GDBM ve QDBM‘in bir halefi olarak aşağıdaki amaçlarla geliştirilmiş. Tokyo Kabinet zamanla geleneksel DBM araçlarının yerini almış.

  • improves space efficiency :  Database dosyasının daha ufak boyutlu olmasını sağlar.
  • improves time efficiency : İşlem hızını arttırır.
  • improves parallelism : multi-thread ortamlarda yüksek işlem hızı
  • improves usability : Basitleştirilmiş API
  • improves robustness : Felaket durumunda bile Database dosyası tutatlı ve sağlam.
  • supports 64-bit architecture : Muazzam bellek miktarlarının kullanımına olanak sağlar ve Database boyutları oldukça büyük olabilir.

Arada Tokyo Kabinet bilgisi de verdikten sonra mimariye devam edelim;

Çoğu servis,  in-memory caching yani RAM üzerinde önbelleklenmesine olanak sağlayan Memcached kullanır.  Memcached bir in-memory key-value sistemdir. Uygulamaların Database erişimini minimize eder. Belirli keyleri belirli sürelerde önbellekte tutarak aşırı io’yu engeller. Böylece ağır trafik yüklerinde Database’in tutarlı ve hızlı çalışması sağlanır.

Servilerin Memcached ile birlikte /dev/shm ‘in de kullanıldığı görülmekte. SHM Linux Shared Memory System’dir.  Geleneksel paylaşımlı hafıza konseptinin iplemente edilmesinden başka bir şey değildir.  Örneğin bir program bir bellek bölümü oluşturur. Bu bölüme eğer izin verilmişse diğer prosesler erişebilir. Bu şekilde bir bellek kullanımı Lİnux üzerinde bütün işleri hızlandırır.  Özellikle de Database uygulamaları için kullanılmaktadır. Genel konuşmak gerekirse IO yoğun işlemler için /dev/shm kullanmak oldukça faydalıdır.  /dev/shm’in çok da fazla fayda getirmediği uygulamalar genellikle IO gerektirmeyen uygulamlardır. Örneğin video dönüştürme, gaming vs.

Yine konuyu toparlayacak olursak, Spotify onlarca minik servisten oluşmakta ve bu servisler HTTP veya HERMES üzerinden konuşmakta. Kendi ürünleri olan supervisor ile bu servisler ayakta durmakta ve birbirleri ile etkileşim içinde çalışmaktadır.

Hermes’e biraz yakından bakacak olursak, Hermes transport için ZeroMQ kullanmakta. Zarflama ve payload işlemleri için Protobuf kullanılmakta. HTTP veya REST tarzı gösterime sahip. Request-Reply ve Publish/Subscribe mimarisi ile çalışmakta. Çok performanslı ve yüksek izlenebilir yapıda olduğu belirtilmekte.

Spotif mimarisinde her şey bir SRV DNS kaydına sahip. Her kayıt aynı isimli bir servis instance içindir. Client’lar servis sağlayan sunucuları bu kayıtlarla çözerler. Tıpkı DNS çözümlemesi gibi. İstemciler eğer bir failure durumu varsa bu kayıtlar aracılığı ile diğer servis sunan instance’lara yönlendirilir.

Aslıda DNS kayıtlarının en önemli amacı Spotify istemcilerinin servisler üzerine dağıtılmasıdır. Service Discovery yani hangi servisin hangi sunucu üzerinde çalıştığı bilgisinin yönetim DNS kontrolü ile yapılır. Birazdan bahsedeceğim DHT yani Distributed Hash Table (Dağıtık Hash Tabloları) dosyalarının Ring konfigürasyonları da bu kayıtlar ile yönetilir.

DNS her şeyin merkezi

Örnek bir DNS kaydını inceleyelim.

_playlist._http.spotify.net 3600 SRV 10 50 8081 host1.spotify.net

Bu kayıt içinde geçen tanımlamalar şu şekilde;

  • ._playlist: Servis adı
  • _http: protocol
  • 3600: TTL değeri / Yaşam süresi
  • 10: Priority yani öncelik
  • 8081:port
  • host1.spotify.net: host adı

Servislere biraz daha yaklaşalım. Servisler ufak ve ölçeklemeye (Scale) müsait bir yapıda olduğundan sadece ihtiyaç halinde bir kaç server ekleme ile genişleyebilmektedir. Bu servisler ihtiyaç halinde yeniden başlatılabilirler.  Canlı sunucular üzerinde dağıtılabilirler. Stateless bir yapıda çalışmaktalar.  Bazı servisler Read/Write durumdadır. Bu servisler daha çok kullanıcıların olşturduğu içeriklerde kullanılırlar. Örneğin, özel oluşturulan Playlist’ler gibi. Instance’ler boyunca dataların bütünlüğünden emin olmak bu servislerde zor bir işlemdir. Peki bu durumun altından kalkabilmek için yapılan işlemler nelerdir? Eventual Consistency, yani muhtemel tutarlılık diyebiliriz.  Kilitleme ve atomik işlemlerle bu sorunların önüne geçilir. Global unik keylerin oluşturulması bu sorunu çözmeye yardımcı olur. Örneğin; kullanıcı adları. Transaction’lar; örneğin faturalama.

Devam edelim

Bütyük verileri yönetmek için kullanılan yöntemlerden birisi de Sharding.  Bazı servisler Dynamo ‘dan esinlenerek oluşturulan DHT”leri yani Distributed Hash Table (Dağıtık Hash Tabloları) kullanır. Bu mimaride her request bir key’e sahiptir. Her servis nodu bu hash keylerin aralığından sorumludur. Data ise bu servis nodlarının arasındada dağıtık durumdadır. Yedeklililk durumu ise replika nodlara yazılarak sağlanır.

Distributed Hash Table durumunu biraz açalım; DHT ilk zamanlar p2p network sistemlerden esinlerek ortaya çıkmıştır. Bu sistemler Freenet, gnutella veya hepimizin bildiği BitTorrent ağı. Dağıtık olarak kaynakların intenet yolu ile noktadan noktaya dağıltılması ve böylece harddisk ve network kullanım kapasitesinde önemli ölçüde verim sağlanması amaçlanmıştır. DHT bir çeşit dağıtık sistemdir. Benzer hash tablolarını (key, value) katılımcı nodlar arasıda paylaştırır.

Sharding kavramına değinelim; Sharding, büyük miktarda veriyi yönetebilmek için onu parçalara ayırmak ve bu parçalar üzerinden işlem yapmak anlamına gelir.

Playlist mimarisine bir göz atalım

Sunumlardan her Playlist’in versiyon kontrollü bir obje olduğunu ve tüm Playlist’lerin login aşamasında Sync edildiğini, yeni bir değişiklik varsa bu değişikliğin bu aşamada Fetch edildiği görülmekte. Anladığım kadarı ile kullanıcı playlist sıra değişikliği yaptığında Client üzerinde değişiklikler anlık gösteriliyor. Offline değişiklikler ve hata düzeltmeleri ise Server uygun durumda olduğunda online ortama aktarılıyor. Playlist’in Backend tarafındaki versiyon kontrolü aşağıdaki gibi görülmekte.

playlist

Bu noktada Cassandra karşımıza çıkıyor. Cassandra Spotify altyapısında ilk Playlist’ler için kullanılmış ve daha sonra şöyle bir cümle var “Now we use it a lot…” Cassandra’nın ilk olarak 0.7 versiyonu ile başlanmış. Şu an sanırım 3.3 versiyonunda.  Playlistlerin 3 farklı sorguları bulunmakta. SYNC, GET, APPEND.

Playlist Query çeşitleri:

  • SYNC – Belirli bir revizyona kadar olan bütün değişiklikleri çağırır.
  • GET – Son alınan snapshot’ı çağırır.
  • APPEND – Şarkı ekleme / Şarkı Silme / Listedeki sıralama değişimler.

Cassandra data modeli ile ilgili iseniz şu sunumdan devam edebilirsiniz. Zira bu konu beni epey aşıyor.

Toplu olarak sunucuların yönetimi

Servislerin üzerinde çalıştığı sistemlerin toplu halde yönetimi için Puppet kullanılmakta. Puppet recipe’ları ile Debian paketleri toplu halde kurulabilmekte. DevOps takımları Puppet’ı yönetmekte. Servis parametrelerinin yönetimi için Hiera kullanılmakta. Hiera, konfigürasyon dataları için bir key/value yönetim aracı. Hieara ile Puppet daha verimli çalışmakta. Kullanıcının önceden tanımladığı datalar ile sistem yönetimi daha rahat olmakta.

Hiera’ya biraz daha yakından bakalım;

  • Node’ların daha kolay konfigüre edilmesini sağlar.
  • Puppet modüllerinin tekrar tekrar kullanımını kolaylaştırır.

Arama işleminin yönetimi

Arama altyapısı bir Java servisinden oluşur. Apache Lucene kullanılmaktadır. Yeni index günlük olarak publish edilir. Arama önerileri ise ayrı bir servis ile yönetilir. Bu servis hız için optimize edilmiştir.  Hemen Lucene’den de biraz bahsedelim. Lucene yüksek performanslı bir metin arama motorudur. Tamamen Java ile yazılmıştır. Full-text arama ihtiyacının olduğu her programda kolaylıkla iplemente edilebilir. Platform bağımsız çalışabilmektedir.

Analiz?

Büyük data setlerinin analizi için Apache Hadoop kullanılmakta.  İstemcilerin eriştiği Access Point logları, içerik tüketim logları, arama ve gezinme detayları Hadoop’a yönlenmekte ve analiz burada yapılmakta. Spotify üzerinde yaklaşık 700 Node Hadoop Cluster olduğu belirtilmekte.

spot-hadoop

Hadoop’a kısaca bir göz atalım; Hadoop, güvenilir, ölçeklenebilir ve dağıtık bir computing altyapısı ile normal bilgisayarları kümeleyerek (clustering) büyük verilerin bu kümeler üzerinde işlenmesine olanak sağlar.

Development ortamı

Yine,  Niklas Gustavsson’un sunumundan elde edilen verilere göre, Spotify’da kullanılan geliştirme araçları Infrastructure’da olduğu gibi Open Source odaklı. Git, Debian, Munin, Zabbix, Puppet ve TeamCity bunlardan birkaçı. Şöyle de bir not var; “Developers use whatever development tools they are comfortable with” Yani, geliştiriciler hangi araçlarda rahatsa onu kullanıyorlar. 3 haftalık iterasyonlar şeklinde Scrum veya Kanban kullanım mevcut. Bütün her şey monitör edilmekte ve ölçülmekte. Devops olmazsa olmaz durumda.

Data center kapasiteleri

Spotify servisleri 5000’den fazla sunucunun bulunduğu 4 veri merkezinde çalışıyor.  Toplam internet kapasitesi 140Gbps. Datacenter içindeki sunucuların bilgileri bir varitabanında tutulmakta. Bu bilgiler MAC adresler, donanım konfigürasyonları, lokasyon, network, hostname ve durum (Kullanımda, beklemede) şeklinde. DNS, DHCP ve PXE kayıtları bu veri tabanından otomatik olarak üretilmekte. Kurulum yönetimi Cobbler ile yapılmakta.

Cobbler‘a biraz değinelim; Cobbler bir Linux kurulum yönetisi ya da Deployment Server.  Network üzerinden çok hızlı bir şekilde Linux Provisioning yapabilir. DNS, DHCP konfigürasyonları, güç yönetimi, orkestrasyon yani toplu halde sunucu yönetimlerine izin verir.  Tek komut ile çoklu sunucu sistemleri farklı lokasyonlardaki data center’lar içerisinde ayağa kaldırabilir. Bakın bu çok önemli.

Önceden eski yöntemlerle SSH yapılan sunucular üzerinde çalıştırılan klasik apt-get install && upgrade komutları zamanla yerini Fabric komutlarına bırakmış.

Server’lar üzerine konuşmuşken, ilginç bir de gönderi buldum. Biliyorsunuz, Linux caminası Init mi? Systemd mi? sorunsalı ile saç baş yola dursun, Spotify bu konuda seçimini yaparak  Systemd’nin her zaman arkasında olduğunu belirtmiş. Ayrıca bu gönderi ile Infrastructure hakkında da özet bir bilgi görülüyor.

Tabii ki Container’lar

Container’lar işletim sistemi seviyesinin en üstünde çalışmakta. test, production, public cloud, geliştirme ortamları gibi farklı ortamların ortaya çıkaracağı tutarlılık sorunlarını ortadan kaldırır.

Bu ne demek? Eğer kod development ortamında sağlam çalışıyorsa container’lar yardımı ile production ortamda da doğruca çalışması sağlanır.

Container’lar sayesinde kodun test edilme süreci daha verimli geçer.  Container ortamında deployment çok çok hızlıdır.  Herhangi bir hata durumunda Rollback işlemi kolaydır.  Spotify yapısında Docker yoğun olarak kullanılmakta.  Container yönetimi Helios ile yapılmakta.

Helios, Docker container’ların orkestrasyon edilmesinde kullanılan bir platform. Tıpkı Kubernetes gibi.  Helios ile container’lar toplu halde deploy edilebilir, bütün sunucu filoları üzerinde yönetilebilir. Helios sunduğu HTTP API ile aynı zamanda komut satırından da (CLI) yönetilebilmektedir.

Docker, Spotify infrasında vazgeçilmez bir oyuncu gibi görünüyor. Sunumlardan birinde Docker yönetiminde “Image inheritance mechanism for sharing infrastructure” cümlesi çok dikkatimi çekti. Çok bilmediğim bir yöntem ama ismi gerçekten ilginç geldi. Hemen araştırdım; şurada durum ile ilgili özet geçilmiş.  Belki başka bir yazının konusu olabilir.

Yapıda 2000+ üzeri container, binlerce host üzerinde çalışmakta.   Container yönetiminde  karşılaşılan en önemli 3 sorun şöyle;

Bu arada bu sorunları derinlemesine inceleyen kişi David Xia, kendisi Spotify’da Yazılım Mühendisi olarak çalışmakta.

  • Yanlış konfigüre edilmiş container yapılandırmaları.  Bu hata genelde Developer’lardan şu şekilde dönüş olarak gelmekte: “Neden benim servisim, Integration Test’ten geçtiği halde onu bir Container olarak Deploy ettiğimde patlıyor?”

Bu sorunun kaynağı, sunumdan anladığım kadarı ile test anında güzelce çalışan ve direkt ulaşılan portlar sorun çıkarmazken, Deploy aşamasında servisin Container içine alındığında  Expose edilmemiş portların olduğu şeklinde. Bence de mantıklı. Portları map edilmemiş bir servis elbette patlayacaktır. Ama bu tür sorunları Production ortamında çözebilmek ayrı bir meziyet.

container1.JPG

Görüldüğü gibi sorunun üstesinden iç ve dış portların Map edilmesi ile gelinmekte.

container1

Bir diğer sorun ise;

  • Önemli Dependency’ler. Docker Container’ların ihtiyaç duyduğu Dependency”ler ve sorun genelde şu şekilde ortaya çıkmakta. “Projemin Integration Testini kendi lokalimde çalıştırmak istiyorum. Test için yine lokal bir Cassandra veya farklı bir Database’e ihtiyacım var. Bu ortamı nasıl ayarlarım?”

container3.JPG

Sorunun çözümü basit.  Tek bir komut ile Cassandra ayakta!

docker run –name cassandra_container -d cassandra_image

Yapılması gereken Developer’ın lokalinde bir Container daha çalıştırılarak Database ihtiyacının giderilmesi. Pratik ve hızlı bir şekilde Developer’ın projesinin ihtiyaç duyduğu lokal Database ihtiyacının Container’lar yardımı ile sağlanması ve servise bağlanması yeterli.

container5.JPG

Spotify altyapısını incelerken, altyapı içerisinde yaşanan sorunları da incelemeden olmaz diyerek bu şekilde bir kaç örnek vermek istedim. Sizleri sıkmadan son örneği de vererek Container Infrası hakkında detay vermeye devam edeyim. 🙂

  • Tekrarlanabilir (Reproducible) testler. Container’ların bu kadar yaygınlaşmasının en önemli nedenlerinden biridir tekrarlanabilir işlerin Container’lar yardımı kolaylaşması. Hemen soruna geçelim. Bir Developer talebi “Tekra test yapmak için test ortamının bağımlı olduğu araçları eski ve temiz hallerine nasıl döndürebilirim?” Bu oldukça önemli ve sık karşılaşılan bir durumdur.  Yine sadece 2 komut ile  az önceki Cassandra örneğinde olduğu gibi temiz bir State ile Container’larıın ayağa kalması sağlanır.

$docker stop container_ismi

$docker run –name cassandra_container -d cassandra_image

Sonuç: Happy Developer!

Machine Learning / Big data?

Spotify’da  aktif olarak Machine Learning kullanılmakta. Örneğin kullanıcının dinlediği müzik tarzlarına göre yapılan öneriler, Radio, Keşfet, İlişkili Sanatçılar gibi birçok yapay zeka ürünü kullanıcılar tarafından aktif olarak kullanılmakta. Özellikle “Haftalık Keşfet” özelliğinin efsane olduğunu belirtmeliyim. 🙂

Spotify’da kullanıcıların stream davranışlarını incelenmekte ve analiz edilmekte.  Analiz yaklaşık 700 Hadoop cluster üzerinde yapılmakta.

Spotify’da Big Data analistleri bir çok soruya yanıt ararlar. Örneğin;

  • 2013 yılı içerisinde hangi kadın sanatçı en sık stream edilendi?
  • En popüler Erkek sanatçı, müzik grubu, en çok dinlenen şarkı?
  • Hangi ülkede hangi sanatçılar çok seviliyor?
  • 2013 yılında en “viral” şarkı hangisiydi?

Bu soruların bir de yatırımcı ve yönetici gözüyle sorulanları var? Bunlara da yanıt aramak gerekli;

  • Günlük aktif kullanıcı sayısı (DAU) nedir?
  • Dün bu durum ne idi?
  • Spotify’ın resmi olarak kullanıma açılacağı bir sonraki ülke hangisi? Analizler?

Bir de iş analizi amaçlı sorunları var tabii ki;

  • Potansiyel büyümenin değeri?
  • Aktif kullanıcı, stream edilen şarkı sayısı, sign-up sayıları
  • Şifketin KPI durumları

Spotify’da çalışan Veri Bilimci’lerin yanıt aradığı bir diğer sorular ise şunlar;

  • Jay-Z uyandığında hangi şarkı ona stream edilir?
  • Adam Kawa Timbuktu’dan bugün sıkıldı mı? 🙂  (Sunumun sahibi, Spotify Big Data danışmanlarından)
  • Jeff’i Premium Account kullanmaya nasıl teşvik ederiz? Gibi..

Veri Bilimcilerin bir diğer uğraşı ise ürün özellikleri. Örneğin “Öneriler” kısmı veya “Keşfet” ya da “Radio” özelliği. Bütün bu soruların cevapları kullanıcılara her an harika müzikleri sunmak için bir çok analizin sonucu. Şarkıların, sanatçıların ve Playlist’lerin  Classification dediğimiz sınıflandırma işlemi.  Ve Tabii ki Mood özelliği. Her ülkede en çok dinlenen şarkıların bulunduğu gerçek zamanlı Playlist’ler.

Hatta, Veri Bilimciler bir taraftan Tasarımcılar ve Developer’lar için de cevap aramakta. “Bu buton öncekinden daha mı etkili?”, “Kullanıcıya gösterilen mesajları nasıl kişiselleştirelim?”, “Arama sonuçları ekranda nasıl görüntülenmeli” gibi.

Spotify’da Big Data kullanım detaylarına şu sunum aracılığı ile ulaşabilirsiniz.

 

 

 

Teşekkürler.

Hakan ORCAN

 

Derlediğim kaynaklar:

https://labs.spotify.com/

https://www.infoq.com

http://www.csc.kth.se/~gkreitz/spotify-p2p10/

Slideshare

Edit:03.04.2017 / Typo hataları ve birkaç ufak düzeltme, birkaç da ekleme.

Advertisements

26 thoughts on “Spotify altyapısına teknik bir bakış

  1. Mcan says:

    Böyle teknik yazıları türkçe okumak gurur verici,emeğine sağlık hiç sıkılmadan okudum.
    İstek yapabiliyorsak DOCKER’ı da kaleme alsan bir de senden dinlesek güzel olur.
    İyi günler.

    Liked by 1 person

  2. Hakan Orcan says:

    Yorumlar için ayrı ayrı teşekkür ediyorum. Çok az meslek var sanırım, yeni şeyler öğrendikçe insanın heyecan duyduğu, kendini daha iyiye motive ettiği. Yorumlarda da bu heyecanını dışarı taşıran birçok meslektaşı görmek, beğenilerini okumak çok değerli. Herkese keyifli çalışmalar.

    Like

  3. EKIN says:

    Çok güzel bir yazı olmuş. Gerçekten faydalı. Ayrıca yazı yazma stiliniz çok iyi, sıkılmadan bir solukta okudum yazınızı. Ellerinize, emeğinize sağlık.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s