Minggu kepungkur aku lunga menyang konferensi DUMP IT (https://dump-ekb.ru/) ing Yekaterinburg lan aku arep menehi pitutur marang kowe apa sing dirembug ing bagean Backend lan Devops, lan apa konferensi IT regional worth manungsa waé.
Nikolay Sverchkov saka Evil Martians babagan Serverless
Ana apa wae?
Secara total, konferensi kasebut duwe 8 bagean: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Aula paling gedhe, kanthi cara, ana ing Ilmu lan Manajemen)) Kanggo ~ 350 wong saben. Backend lan Frontend ora luwih cilik. Kamar Devops minangka sing paling cilik, nanging aktif.
Aku ngrungokake laporan ing bagean Devops lan Backend lan ngobrol sethithik karo speaker. Aku pengin ngomong babagan topik sing dibahas lan mriksa bagean kasebut ing konferensi kasebut.
Perwakilan SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) ngandika ing bagean Devops lan Backend. Topik kalebu CI/CD, nggarap layanan antrian, logging; Topik tanpa server lan nggarap PostgreSQL ing Go wis diliputi kanthi apik.
Ana uga laporan dening Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, nanging aku ora duwe wektu kanggo rawuh kanthi fisik (rekaman video lan slide laporan durung kasedhiya, janji bakal dikirim sajrone 2 minggu. ing dump-ekb.ru).
bagean Devops
Sing nggumunake yaiku bagean kasebut dianakake ing bale paling cilik, sekitar 50 kursi. Wong-wong malah ngadeg ing lorong :) Aku bakal ngandhani babagan laporan sing bisa dakrungokake.
Elastis bobote petabyte
Bagian kasebut diwiwiti kanthi laporan dening Vladimir Lil (SKB-Kontur) babagan Elasticsearch ing Kontur. Dheweke duwe Elastis sing cukup gedhe lan dimuat (~ 800 TB data, ~ 1.3 petabyte kanthi njupuk redundansi). Elasticsearch kanggo kabeh layanan Kontur iku siji, dumadi saka 2 kluster (7 lan 9 server), lan penting banget yen Kontur duwe insinyur Elasticsearch khusus (nyatane, Vladimir dhewe).
Vladimir uga nuduhake pikirane babagan keuntungan saka Elasticsearch lan masalah sing digawa.
keuntungan:
- Kabeh log ana ing sak panggonan, gampang diakses
- Nyimpen log sajrone setahun lan gampang dianalisis
- Kacepetan dhuwur nggarap log
- Visualisasi data keren metu saka kothak
Masalah:
- makelar pesen kudu diduweni (kanggo Kontur perané dimainaké déning Kafka)
- fitur nggarap Kurator Elasticsearch (digawe kanthi berkala beban dhuwur saka tugas biasa ing Kurator)
- ora ana wewenang sing dibangun (mung kanggo dhuwit sing kapisah, cukup gedhe, utawa minangka plugin open source kanthi tingkat kesiapan produksi sing beda-beda)
Mung ana review positif babagan Open Distro kanggo Elasticsearch :) Masalah wewenang sing padha wis dirampungake ing kana.
Saka ngendi asale petabyte?Node kasebut kalebu server kanthi 12 * 8 Tb SATA + 2 * 2 Tb SSD. Panyimpenan kadhemen ing SATA, SSD mung kanggo cache panas (panyimpenan panas).
7+9 server, (7 + 9) * 12 * 8 = 1536 Tb.
Bagéyan saka papan ana ing cadangan, disisihake kanggo redundansi, lsp.
Log saka udakara 90 aplikasi dikirim menyang Elasticsearch, kalebu kabeh layanan laporan Kontur, Elba, lsp.
Fitur pangembangan ing Serverless
Sabanjure laporan dening Ruslan Serkin saka DataArt babagan Serverless.
Ruslan ngedika bab apa pembangunan karo pendekatan Serverless ing umum, lan apa fitur sing.
Serverless minangka pendekatan kanggo pangembangan ing ngendi pangembang ora ndemek infrastruktur kanthi cara apa wae. Conto - AWS Lambda Serverless, Kubeless.io (Serverless nang Kubernetes), Google Cloud Functions.
Aplikasi Tanpa Server sing becik mung minangka fungsi sing ngirim panjalukan menyang panyedhiya Tanpa Server liwat Gateway API khusus. Layanan mikro sing cocog, nalika AWS Lambda uga ndhukung akeh basa pamrograman modern. Biaya kanggo njaga lan nyebarake infrastruktur dadi nol ing kasus panyedhiya maya, ndhukung aplikasi cilik uga bakal murah banget (AWS Lambda - $ 0.2 / 1 yuta panjalukan prasaja).
Skalabilitas sistem kasebut meh becik - panyedhiya awan ngurus iki dhewe, timbangan Kubeless kanthi otomatis ing kluster Kubernetes.
Ana kekurangan:
- ngembangaken aplikasi gedhe dadi luwih angel
- ana kangelan karo aplikasi profiling (sampeyan mung duwe akses menyang log, nanging ora profil ing pangertèn biasanipun)
- ora versi
Jujur, aku krungu babagan Serverless sawetara taun kepungkur, nanging kabeh taun iki aku ora ngerti carane nggunakake kanthi bener. Sawise laporan Ruslan, pangerten muncul, lan sawise laporan Nikolai Sverchkov (Evil Martians) saka bagean Backend, digabungake. Ora sia-sia aku melu konferensi :)
CI kanggo wong miskin, utawa apa worth nulis CI dhewe kanggo studio web?
Mikhail Radionov, kepala studio web Flag saka Yekaterinburg, ngomong babagan CI / CD sing ditulis dhewe.
Studio dheweke wis ilang saka "CI / CD manual" (mlebu menyang server liwat SSH, tarik git, baleni kaping 100 dina) menyang Jenkins lan menyang alat sing ditulis dhewe sing ngidini sampeyan ngawasi kode lan nindakake rilis sing diarani Pullkins. .
Apa Jenkins ora bisa? Ora nyedhiyakake keluwesan sing cukup kanthi standar lan angel banget kanggo ngatur.
"Flag" berkembang ing Laravel (framework PHP). Nalika ngembangake server CI / CD, Mikhail lan kanca-kancane nggunakake mekanisme dibangun ing Laravel sing diarani Teleskop lan Utusan. Asilé yaiku server ing PHP (mangga dicathet) sing ngolah panjalukan webhook sing mlebu, bisa mbangun frontend lan backend, nyebar menyang server sing beda-beda, lan laporan menyang Slack.
Banjur, supaya bisa nindakake penyebaran biru / ijo lan duwe setelan seragam ing lingkungan dev-stage-prod, dheweke pindhah menyang Docker. Kaluwihan tetep padha, kemungkinan homogenisasi lingkungan lan penyebaran lancar ditambahake, lan kabutuhan sinau Docker supaya bisa digunakake kanthi bener ditambahake.
Kepiye cara nyuda jumlah rollback rilis server nganti 99%
Laporan pungkasan ing bagean Devops yaiku saka Viktor Eremchenko, Lead devops engineer ing Miro.com (sadurunge RealTimeBoard).
RealTimeBoard, produk unggulan tim Miro, adhedhasar aplikasi Java monolitik. Nglumpukake, nguji lan nggunakake tanpa downtime minangka tugas sing angel. Ing kasus iki, iku penting kanggo masang versi kode kuwi supaya ora kudu mbalek maneh (iku monolith abot).
Ing dalan kanggo mbangun sistem sing ngidini sampeyan nindakake iki, Miro ngliwati dalan sing kalebu nggarap arsitektur, alat sing digunakake (Atlassian Bamboo, Ansible, etc), lan nggarap struktur tim (saiki wis duwe. tim Devops darmabakti + akeh tim Scrum kapisah saka pangembang saka profil beda).
Dalan kasebut dadi angel lan angel, lan Victor nuduhake rasa lara lan optimisme sing ora mandheg.
Menang buku kanggo takon
Bagian mburi
Aku bisa nekani 2 laporan - saka Nikolay Sverchkov (Evil Martians), uga babagan Serverless, lan saka Grigory Koshelev (perusahaan Kontur) babagan telemetri.
Serverless kanggo manungsa
Yen Ruslan Sirkin ngomong apa Serverless, Nikolay nuduhake aplikasi prasaja nggunakake Serverless, lan ngomong bab rincian sing mengaruhi biaya lan kacepetan aplikasi ing AWS Lambda.
Rincian sing menarik: unsur mbayar minimal yaiku memori 128 Mb lan CPU 100 ms, regane $ 0,000000208. Kajaba iku, 1 yuta panjaluk kasebut saben wulan gratis.
Sawetara fungsi Nikolai asring ngluwihi watesan 100 ms (aplikasi utama ditulis ing Ruby), saéngga nulis ulang ing Go nyedhiyakake tabungan sing apik banget.
Vostok Hercules - nggawe telemetri apik maneh!
Laporan paling anyar saka bagean Backend saka Grigory Koshelev (perusahaan Kontur) babagan telemetri. Telemetri tegese log, metrik, jejak aplikasi.
Kanggo tujuan iki, Contour nggunakake alat sing ditulis dhewe sing dikirim ing Github. Alat saka laporan - Hercules, , digunakake kanggo ngirim data telemetri.
Laporan Vladimir Lila ing bagean Devops mbahas nyimpen lan ngolah log ing Elasticsearch, nanging isih ana tugas ngirim log saka pirang-pirang ewu piranti lan aplikasi, lan alat kaya Vostok Hercules ngatasi.
Sirkuit ngetutake dalan sing dikenal akeh - saka RabbitMQ nganti Apache Kafka, nanging ora kabeh gampang banget)) Dheweke kudu nambah Zookeeper, Cassandra lan Graphite ing sirkuit kasebut. Aku ora bakal mbukak informasi kanthi lengkap babagan laporan iki (dudu profilku), yen sampeyan kasengsem, sampeyan bisa ngenteni slide lan video ing situs web konferensi.
Kepiye dibandhingake karo konferensi liyane?
Aku ora bisa mbandhingake karo konferensi ing Moscow lan St.
DAMP dianakake ing 8 bagean, iki minangka rekor kanggo konferensi Ural. Bagean Ilmu lan Manajemen sing gedhe banget, iki uga ora biasa. Penonton ing Yekaterinburg cukup terstruktur - kutha kasebut duwe departemen pangembangan gedhe kanggo Yandex, Kontur, Tinkoff, lan iki menehi tandha ing laporan kasebut.
Titik liyane sing menarik yaiku akeh perusahaan duwe 3-4 pamicara ing konferensi kasebut bebarengan (iki kedadeyan karo Kontur, Evil Martians, Tinkoff). Akeh sing dadi sponsor, nanging laporan kasebut padha karo liyane, iki dudu laporan pariwara.
Kanggo pindhah utawa ora kanggo pindhah? Yen sampeyan manggon ing Urals utawa toko, sampeyan duwe kesempatan lan kasengsem ing topik - ya, mesthi. Yen sampeyan mikir babagan perjalanan sing dawa, aku bakal ndeleng topik laporan lan laporan video saka taun-taun sadurunge lan nggawe keputusan.
Kauntungan liyane saka konferensi ing wilayah, minangka aturan, iku gampang kanggo komunikasi karo speaker sawise laporan, ana mung kurang pelamar kanggo komunikasi kuwi.
Thanks kanggo Dump lan Ekaterinburg! )
Source: www.habr.com