Minggu lepas saya pergi ke persidangan DUMP IT (https://dump-ekb.ru/) di Yekaterinburg dan saya ingin memberitahu anda perkara yang dibincangkan dalam bahagian Backend dan Devops, dan sama ada persidangan IT serantau patut diberi perhatian.
Nikolay Sverchkov dari Evil Martians tentang Tanpa Pelayan
Apa yang ada di sana?
Secara keseluruhan, persidangan itu mempunyai 8 bahagian: Bahagian Belakang, Bahagian Depan, Mudah Alih, Pengujian dan QA, Devops, Reka Bentuk, Sains dan Pengurusan.
Dewan terbesar, dengan cara itu, adalah di Sains dan Pengurusan)) Untuk ~350 orang setiap satu. Bahagian Belakang dan Bahagian Depan tidak jauh lebih kecil. Bilik Devops adalah yang terkecil, tetapi aktif.
Saya mendengar laporan di bahagian Devops dan Backend dan bercakap sedikit dengan pembesar suara. Saya ingin bercakap tentang topik yang diliputi dan menyemak bahagian ini pada persidangan itu.
Wakil SKB-Kontur, DataArt, Evil Martians, studio web Ekaterinburg Flag, Miro (RealTimeBoard) bercakap dalam bahagian Devops dan Backend. Topik merangkumi CI/CD, bekerja dengan perkhidmatan baris gilir, pengelogan; Topik tanpa pelayan dan bekerja dengan PostgreSQL dalam Go telah diliputi dengan baik.
Terdapat juga laporan oleh Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, tetapi saya tidak mempunyai masa untuk menghadirinya secara fizikal (rakaman video dan slaid laporan belum tersedia, mereka berjanji untuk menyiarkannya dalam masa 2 minggu di dump-ekb.ru).
Bahagian Devops
Apa yang mengejutkan ialah bahagian itu diadakan di dewan terkecil, kira-kira 50 kerusi. Orang ramai juga berdiri di lorong :) Saya akan memberitahu anda tentang laporan yang saya berjaya dengar.
Anjal seberat petabait
Bahagian itu bermula dengan laporan oleh Vladimir Lil (SKB-Kontur) tentang Elasticsearch di Kontur. Mereka mempunyai Elastik yang agak besar dan dimuatkan (~800 TB data, ~1.3 petabait dengan mengambil kira lebihan). Elasticsearch untuk semua perkhidmatan Kontur adalah tunggal, terdiri daripada 2 kelompok (daripada 7 dan 9 pelayan), dan sangat penting sehingga Kontur mempunyai jurutera Elasticsearch khas (sebenarnya, Vladimir sendiri).
Vladimir juga berkongsi pendapatnya tentang faedah Elasticsearch dan masalah yang dibawanya.
Manfaat:
- Semua log berada di satu tempat, akses mudah kepada mereka
- Menyimpan log selama setahun dan menganalisisnya dengan mudah
- Kelajuan tinggi bekerja dengan balak
- Visualisasi data yang menarik di luar kotak
Masalah:
- broker mesej mesti ada (untuk Kontur peranannya dimainkan oleh Kafka)
- ciri bekerja dengan Kurator Elasticsearch (beban tinggi yang dibuat secara berkala daripada tugas biasa dalam Kurator)
- tiada kebenaran terbina dalam (hanya untuk wang yang berasingan, agak besar, atau sebagai pemalam sumber terbuka dengan pelbagai tahap kesediaan untuk pengeluaran)
Terdapat hanya ulasan positif tentang Open Distro untuk Elasticsearch :) Isu kebenaran yang sama telah diselesaikan di sana.
Dari mana datangnya petabyte?Nod mereka terdiri daripada pelayan dengan 12*8 Tb SATA + 2*2 Tb SSD. Storan sejuk pada SATA, SSD hanya untuk cache panas (storan panas).
7+9 pelayan, (7 + 9) * 12 * 8 = 1536 Tb.
Sebahagian daripada ruang adalah dalam simpanan, diketepikan untuk lebihan, dsb.
Log daripada kira-kira 90 aplikasi dihantar ke Elasticsearch, termasuk semua perkhidmatan pelaporan Kontur, Elba, dsb.
Ciri pembangunan pada Tanpa Pelayan
Seterusnya ialah laporan oleh Ruslan Serkin dari DataArt tentang Tanpa Pelayan.
Ruslan bercakap tentang pembangunan dengan pendekatan Tanpa Pelayan secara umum, dan apakah ciri-cirinya.
Tanpa pelayan ialah pendekatan kepada pembangunan di mana pembangun tidak menyentuh infrastruktur dalam apa jua cara. Contoh - Tanpa Pelayan AWS Lambda, Kubeless.io (Tanpa Pelayan di dalam Kubernetes), Fungsi Awan Google.
Aplikasi Tanpa Pelayan yang ideal hanyalah fungsi yang menghantar permintaan kepada pembekal Tanpa Pelayan melalui Gateway API khas. Perkhidmatan mikro yang ideal, manakala AWS Lambda juga menyokong sejumlah besar bahasa pengaturcaraan moden. Kos penyelenggaraan dan penggunaan infrastruktur menjadi sifar dalam kes penyedia awan, menyokong aplikasi kecil juga akan menjadi sangat murah (AWS Lambda - $0.2 / 1 juta permintaan mudah).
Kebolehskalaan sistem sedemikian hampir ideal - pembekal awan menguruskan ini sendiri, skala Kubeless secara automatik dalam kelompok Kubernetes.
Terdapat keburukan:
- membangunkan aplikasi besar menjadi lebih sukar
- terdapat kesukaran dengan aplikasi pemprofilan (hanya log tersedia untuk anda, tetapi bukan pemprofilan dalam erti kata biasa)
- tiada versi
Sejujurnya, saya mendengar tentang Tanpa Pelayan beberapa tahun yang lalu, tetapi selama ini saya tidak jelas cara menggunakannya dengan betul. Selepas laporan Ruslan, pemahaman muncul, dan selepas laporan Nikolai Sverchkov (Evil Martians) dari bahagian Backend, ia disatukan. Tidak sia-sia saya pergi ke persidangan itu :)
CI adalah untuk golongan miskin, atau adakah patut menulis CI anda sendiri untuk studio web?
Mikhail Radionov, ketua studio web Flag dari Yekaterinburg, bercakap tentang CI/CD yang ditulis sendiri.
Studionya telah beralih daripada "CI/CD manual" (log masuk ke pelayan melalui SSH, lakukan tarikan git, ulangi 100 kali sehari) kepada Jenkins dan kepada alat tulisan sendiri yang membolehkan anda memantau kod dan melaksanakan keluaran yang dipanggil Pullkins .
Mengapa Jenkins tidak bekerja? Ia tidak memberikan fleksibiliti yang mencukupi secara lalai dan terlalu sukar untuk disesuaikan.
"Bendera" berkembang dalam Laravel (rangka kerja PHP). Semasa membangunkan pelayan CI/CD, Mikhail dan rakan-rakannya menggunakan mekanisme terbina dalam Laravel yang dipanggil Teleskop dan Utusan. Hasilnya ialah pelayan dalam PHP (sila ambil perhatian) yang memproses permintaan webhook masuk, boleh membina bahagian hadapan dan bahagian belakang, menggunakan pelayan yang berbeza dan melaporkan kepada Slack.
Kemudian, untuk dapat melaksanakan penggunaan biru/hijau dan mempunyai tetapan seragam dalam persekitaran dev-stage-prod, mereka beralih kepada Docker. Kelebihannya tetap sama, kemungkinan menyeragamkan persekitaran dan penggunaan yang lancar telah ditambah, dan keperluan untuk mempelajari Docker untuk bekerja dengannya dengan betul telah ditambah.
Cara kami mengurangkan bilangan rollback keluaran pelayan sebanyak 99%
Laporan terakhir dalam bahagian Devops adalah daripada Viktor Eremchenko, jurutera utama devops di Miro.com (dahulunya RealTimeBoard).
RealTimeBoard, produk utama pasukan Miro, adalah berdasarkan aplikasi Java monolitik. Mengumpul, menguji dan melaksanakannya tanpa masa henti adalah tugas yang sukar. Dalam kes ini, adalah penting untuk menggunakan versi kod sedemikian supaya ia tidak perlu digulung semula (ia adalah monolit yang berat).
Dalam perjalanan untuk membina sistem yang membolehkan anda melakukan ini, Miro melalui laluan yang termasuk bekerja pada seni bina, alat yang digunakan (Atlassian Bamboo, Ansible, dll), dan bekerja pada struktur pasukan (mereka kini mempunyai pasukan Devops yang berdedikasi + banyak pasukan Scrum yang berasingan daripada pembangun profil yang berbeza).
Laluan itu ternyata sukar dan berduri, dan Victor berkongsi kesakitan dan keyakinan yang terkumpul yang tidak berakhir di situ.
Menang buku kerana bertanya soalan
Bahagian belakang
Saya berjaya menghadiri 2 laporan - dari Nikolay Sverchkov (Evil Martians), juga tentang Serverless, dan dari Grigory Koshelev (syarikat Kontur) tentang telemetri.
Tanpa pelayan untuk manusia biasa
Jika Ruslan Sirkin bercakap tentang apa itu Tanpa Pelayan, Nikolay menunjukkan aplikasi mudah menggunakan Tanpa Pelayan, dan bercakap tentang butiran yang mempengaruhi kos dan kelajuan aplikasi dalam AWS Lambda.
Perincian yang menarik: elemen berbayar minimum ialah 128 Mb memori dan 100 ms CPU, ia berharga $0,000000208. Lebih-lebih lagi, 1 juta permintaan sedemikian setiap bulan adalah percuma.
Sesetengah fungsi Nikolai sering melebihi had 100 ms (aplikasi utama ditulis dalam Ruby), jadi menulis semulanya dalam Go memberikan penjimatan yang sangat baik.
Vostok Hercules — jadikan telemetri hebat sekali lagi!
Laporan terkini bahagian Backend dari Grigory Koshelev (syarikat Kontur) mengenai telemetri. Telemetri bermaksud log, metrik, jejak aplikasi.
Untuk tujuan ini, Contour menggunakan alat tulisan sendiri yang disiarkan pada Github. Alat dari laporan - Hercules, , digunakan untuk menghantar data telemetri.
Laporan Vladimir Lila dalam bahagian Devops membincangkan menyimpan dan memproses log dalam Elasticsearch, tetapi masih terdapat tugas untuk menghantar log daripada beribu-ribu peranti dan aplikasi, dan alatan seperti Vostok Hercules menyelesaikannya.
Litar ini mengikuti laluan yang diketahui ramai - dari RabbitMQ ke Apache Kafka, tetapi tidak semuanya begitu mudah)) Mereka terpaksa menambah Zookeeper, Cassandra dan Graphite ke litar. Saya tidak akan mendedahkan sepenuhnya maklumat mengenai laporan ini (bukan profil saya), jika anda berminat, anda boleh menunggu slaid dan video di laman web persidangan.
Bagaimanakah ia dibandingkan dengan persidangan lain?
Saya tidak boleh membandingkannya dengan persidangan di Moscow dan St. Petersburg, saya boleh membandingkannya dengan acara lain di Ural dan dengan 404fest di Samara.
DAMP diadakan dalam 8 bahagian, ini adalah rekod untuk persidangan Ural. Bahagian Sains dan Pengurusan yang sangat besar, ini juga luar biasa. Penonton di Yekaterinburg agak tersusun - bandar ini mempunyai jabatan pembangunan yang besar untuk Yandex, Kontur, Tinkoff, dan ini meninggalkan kesan pada laporan.
Satu lagi perkara yang menarik ialah banyak syarikat mempunyai 3-4 penceramah pada persidangan itu sekaligus (ini adalah kes dengan Kontur, Evil Martians, Tinkoff). Ramai daripada mereka adalah penaja, tetapi laporannya agak setanding dengan yang lain, ini bukan laporan pengiklanan.
Pergi atau tidak pergi? Jika anda tinggal di Ural atau berdekatan, anda mempunyai peluang dan berminat dengan topik - ya, sudah tentu. Jika anda memikirkan tentang perjalanan yang jauh, saya akan melihat topik laporan dan laporan video dari tahun-tahun sebelumnya dan membuat keputusan.
Satu lagi kelebihan persidangan di wilayah, sebagai peraturan, adalah mudah untuk berkomunikasi dengan penceramah selepas laporan; terdapat lebih sedikit pemohon untuk komunikasi sedemikian.
Terima kasih kepada Dump dan Ekaterinburg! )
Sumber: www.habr.com