Geçen hafta Yekaterinburg'daki DUMP IT konferansına (https://dump-ekb.ru/) gittim ve size Backend ve Devops bölümlerinde nelerin tartışıldığını ve bölgesel BT konferanslarının dikkate değer olup olmadığını anlatmak istiyorum.
Evil Martians'tan Nikolay Sverchkov Sunucusuz hakkında
Zaten orada ne vardı?
Konferansta toplamda 8 bölüm vardı: Arka Uç, Ön Uç, Mobil, Test ve QA, Devops, Tasarım, Bilim ve Yönetim.
Bu arada en büyük salonlar Bilim ve Yönetim'dedir)) Her biri ~350 kişiliktir. Arka uç ve Ön uç çok daha küçük değildir. Devops odası en küçük ama aktif odaydı.
Devops ve Backend bölümlerindeki raporları dinledim ve konuşmacılarla biraz konuştum. Konferansta ele alınan konular hakkında konuşmak ve bu bölümleri değerlendirmek istiyorum.
Devops ve Backend bölümlerinde SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web stüdyosu Flag, Miro (RealTimeBoard) temsilcileri konuştu. CI/CD ile ilgili konular, kuyruk hizmetleriyle çalışma, günlüğe kaydetme; Sunucusuz konular ve Go'da PostgreSQL ile çalışma iyi bir şekilde ele alındı.
Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank'tan da raporlar vardı ama fiziki olarak katılmaya vaktim olmadı (raporların video kayıtları ve slaytları henüz mevcut değil, 2 hafta içinde yayınlayacaklarına söz veriyorlar) dump-ekb.ru'da).
Devops bölümü
Şaşırtıcı olan ise bölümün yaklaşık 50 koltuklu en küçük salonda düzenlenmesiydi. Hatta koridorlarda bile insanlar ayakta duruyordu :) Sizlere dinlediğim raporları anlatacağım.
Bir petabayt ağırlığında elastik
Bu bölüm Vladimir Lil'in (SKB-Kontur) Kontur'daki Elasticsearch hakkındaki raporuyla başladı. Oldukça büyük ve yüklü bir Esnekliğe sahipler (~800 TB veri, artıklık dikkate alınarak ~1.3 petabayt). Tüm Kontur hizmetleri için Elasticsearch tektir, 2 kümeden oluşur (7 ve 9 sunucudan oluşur) ve o kadar önemlidir ki Kontur'un özel bir Elasticsearch mühendisi (aslında Vladimir'in kendisi) vardır.
Vladimir ayrıca Elasticsearch'ün faydaları ve getirdiği sorunlara ilişkin düşüncelerini de paylaştı.
Şunun için iyi:
- Tüm günlükler tek bir yerde, onlara kolay erişim
- Logların bir yıl boyunca saklanması ve kolayca analiz edilmesi
- Günlüklerle yüksek çalışma hızı
- Kutudan çıktığı haliyle harika veri görselleştirmesi
Sorunları:
- mesaj komisyoncusu mutlaka sahip olunması gereken bir şeydir (Kontur için rolü Kafka tarafından oynanır)
- Elasticsearch Küratörü ile çalışmanın özellikleri (Küratördeki düzenli görevlerden periyodik olarak oluşturulan yüksek yük)
- yerleşik yetkilendirme yok (yalnızca ayrı, oldukça büyük para için veya üretime farklı derecelerde hazır olma derecesine sahip açık kaynaklı eklentiler olarak)
Open Distro for Elasticsearch hakkında sadece olumlu yorumlar vardı :) Aynı yetkilendirme sorunu orada da çözüldü.
Petabayt nereden geliyor?Düğümleri 12*8 Tb SATA + 2*2 Tb SSD'li sunuculardan oluşmaktadır. SATA'da soğuk depolama, yalnızca sıcak önbellek (sıcak depolama) için SSD.
7+9 sunucu, (7 + 9) * 12 * 8 = 1536 Tb.
Alanın bir kısmı yedekte, fazlalık olarak ayrılmış vb.
Kontur, Elba vb. şirketlerin tüm raporlama hizmetleri de dahil olmak üzere yaklaşık 90 uygulamanın logları Elasticsearch'e gönderiliyor.
Sunucusuz geliştirmenin özellikleri
Sırada DataArt'tan Ruslan Serkin'in Sunucusuz hakkındaki raporu var.
Ruslan genel olarak Serverless yaklaşımıyla geliştirmenin ne olduğundan ve özelliklerinin neler olduğundan bahsetti.
Sunucusuz, geliştiricilerin altyapıya hiçbir şekilde dokunmadığı bir geliştirme yaklaşımıdır. Örnek - AWS Lambda Sunucusuz, Kubeless.io (Kubernetes içinde Sunucusuz), Google Cloud Functions.
İdeal bir Sunucusuz uygulama, özel bir API Ağ Geçidi aracılığıyla Sunucusuz sağlayıcıya istek gönderen bir işlevdir. İdeal bir mikro hizmettir; AWS Lambda ayrıca çok sayıda modern programlama dilini de destekler. Bulut sağlayıcıları söz konusu olduğunda altyapının bakımı ve dağıtımının maliyeti sıfır olur, küçük uygulamaları desteklemek de çok ucuz olacaktır (AWS Lambda - 0.2 ABD doları / 1 milyon basit istek).
Böyle bir sistemin ölçeklenebilirliği neredeyse idealdir; bulut sağlayıcı bunu kendisi halleder, Kubeless, Kubernetes kümesi içinde otomatik olarak ölçeklenir.
Dezavantajları var:
- Büyük uygulamalar geliştirmek giderek zorlaşıyor
- profil oluşturma uygulamalarında zorluk var (yalnızca günlüklere erişebilirsiniz, ancak genel anlamda profil oluşturma mümkün değildir)
- versiyonlama yok
Dürüst olmak gerekirse, birkaç yıl önce Sunucusuz'u duymuştum ancak bunca yıl boyunca onu nasıl doğru kullanacağımı bilmiyordum. Ruslan'ın raporunun ardından anlayış ortaya çıktı ve Arka Uç bölümünden Nikolai Sverchkov'un (Kötü Marslılar) raporunun ardından konsolidasyon sağlandı. Konferansa gitmem boşuna değildi :)
CI yoksullar içindir, yoksa bir web stüdyosu için kendi CI'nızı yazmaya değer mi?
Yekaterinburg'daki Flag web stüdyosunun başkanı Mikhail Radionov, kendi yazdığı CI/CD hakkında konuştu.
Stüdyosu "manuel CI/CD"den (sunucuya SSH yoluyla giriş yapıldı, git pull yapıldı, günde 100 kez tekrarlandı) Jenkins'e ve kodu kontrol etmenize ve Pullkins adı verilen sürümleri gerçekleştirmenize olanak tanıyan, evde yazılmış bir araca geçti.
Jenkins neden işe yaramadı? Varsayılan olarak yeterli esneklik sağlamıyordu ve özelleştirilmesi çok zordu.
“Bayrak” Laravel'de (PHP çerçevesi) gelişir. Bir CI/CD sunucusu geliştirirken Mikhail ve meslektaşları Laravel'in Telescope ve Envoy adı verilen yerleşik mekanizmalarını kullandılar. Sonuç, PHP'de, gelen webhook isteklerini işleyen, ön uç ve arka uç oluşturabilen, farklı sunuculara konuşlandırabilen ve Slack'e rapor verebilen bir sunucudur (lütfen unutmayın).
Daha sonra mavi/yeşil dağıtım gerçekleştirebilmek ve geliştirme-sahne-üretim ortamlarında tek tip ayarlara sahip olmak için Docker'a geçtiler. Avantajlar aynı kaldı, ortamı homojenleştirme ve kusursuz dağıtım olanakları eklendi ve onunla doğru şekilde çalışmak için Docker'ı öğrenme ihtiyacı eklendi.
Sunucu sürümü geri alma sayısını nasıl %99 oranında azalttık?
Devops bölümündeki son rapor Miro.com'un (eski adıyla RealTimeBoard) Devops Mühendisi Viktor Eremchenko'dan geldi.
Miro ekibinin amiral gemisi ürünü olan RealTimeBoard, yekpare bir Java uygulamasına dayanmaktadır. Kesinti olmadan toplanması, test edilmesi ve dağıtılması zor bir iştir. Bu durumda, geri alınmasına gerek kalmaması için kodun böyle bir sürümünü dağıtmak önemlidir (bu ağır bir monolittir).
Bunu yapmanıza olanak tanıyan bir sistem oluşturma yolunda Miro, mimari, kullanılan araçlar (Atlassian Bamboo, Ansible, vb.) ve ekiplerin yapısı (artık sahipler) üzerinde çalışmayı içeren bir yoldan geçti. özel bir Devops ekibi + farklı profillerdeki geliştiricilerden birçok ayrı Scrum takımı).
Yolun zor ve dikenli olduğu ortaya çıktı ve Victor, burada bitmeyen birikmiş acıyı ve iyimserliği paylaştı.
Soru sorma kitabı kazandım
Arka uç bölümü
Yine Sunucusuz hakkında Nikolay Sverchkov'dan (Kötü Marslılar) ve Grigory Koshelev'den (Kontur şirketi) telemetri hakkında 2 rapora katılmayı başardım.
Sıradan ölümlüler için sunucusuz
Ruslan Sirkin Sunucusuzun ne olduğundan bahsederken Nikolay, Sunucusuz kullanan basit uygulamaları göstererek AWS Lambda'da uygulamaların maliyetine ve hızına etki eden detaylardan bahsetti.
İlginç bir ayrıntı: Minimum ücretli öğe 128 Mb bellek ve 100 ms CPU'dur, maliyeti 0,000000208 ABD dolarıdır. Üstelik bu tür taleplerin ayda 1 milyonu ücretsiz.
Nikolai'nin bazı işlevleri genellikle 100 ms sınırını aşıyordu (ana uygulama Ruby'de yazılmıştı), bu nedenle bunları Go'da yeniden yazmak mükemmel tasarruf sağladı.
Vostok Hercules — telemetriyi yeniden harika hale getirin!
Grigory Koshelev'in (Kontur şirketi) telemetri ile ilgili Arka Uç bölümünün en son raporu. Telemetri, günlükler, ölçümler, uygulama izleri anlamına gelir.
Bu amaçla Contour, Github'da yayınlanan, kendi yazdığı araçları kullanır. Rapordaki araç - Herkül, , telemetri verilerini iletmek için kullanılır.
Vladimir Lila'nın Devops bölümündeki raporu, günlüklerin Elasticsearch'te saklanması ve işlenmesini ele alıyordu ancak binlerce cihaz ve uygulamadan günlüklerin teslim edilmesi görevi hâlâ mevcut ve Vostok Hercules gibi araçlar bunları çözüyor.
Devre, RabbitMQ'dan Apache Kafka'ya kadar birçok kişi tarafından bilinen bir yol izledi, ancak her şey o kadar basit değil)) Devreye Zookeeper, Cassandra ve Graphite'i eklemek zorunda kaldılar. Bu rapordaki bilgileri (profilimi değil) tam olarak açıklamayacağım, eğer ilgileniyorsanız konferans web sitesindeki slaytları ve videoları bekleyebilirsiniz.
Diğer konferanslarla karşılaştırıldığında nasıldır?
Bunu Moskova ve St. Petersburg'daki konferanslarla kıyaslayamam, Urallar'daki diğer etkinliklerle ve Samara'daki 404fest ile karşılaştırabilirim.
DAMP 8 bölümde düzenleniyor, bu Ural konferansları için bir rekor. Çok büyük Bilim ve Yönetim bölümleri, bu da alışılmadık bir durum. Yekaterinburg'daki izleyici kitlesi oldukça yapılandırılmış - şehirde Yandex, Kontur, Tinkoff için büyük geliştirme departmanları var ve bu da raporlara damgasını vuruyor.
Bir diğer ilginç nokta ise birçok firmanın konferansta aynı anda 3-4 konuşmacıya sahip olması (Kontur, Evil Martians, Tinkoff'ta da durum aynıydı). Birçoğu sponsordu ama raporlar diğerleriyle oldukça aynı, bunlar reklam raporları değil.
Gitmek mi gitmemek mi? Urallarda veya yakınlarda yaşıyorsanız, fırsatınız var ve konulara ilgi duyuyorsunuz - evet, elbette. Uzun bir yolculuk düşünüyorsanız geçmiş yıllara ait rapor ve video rapor konularına bakarım ve bir karar verdi.
Bölgelerdeki konferansların bir diğer avantajı da kural olarak raporlardan sonra konuşmacıyla iletişim kurmanın kolay olmasıdır; bu tür iletişim için başvuranların sayısı daha azdır.
Dump ve Ekaterinburg'a teşekkürler! )
Kaynak: habr.com