Minggu lalu saya menghadiri konferensi DUMP IT (https://dump-ekb.ru/) di Yekaterinburg dan saya ingin memberi tahu Anda apa yang dibahas di bagian Backend dan Devops, dan apakah konferensi TI regional patut diperhatikan.
Nikolay Sverchkov dari Evil Martians tentang Tanpa Server
Apa yang ada di sana?
Secara total, konferensi ini memiliki 8 bagian: Backend, Frontend, Mobile, Testing dan QA, Devops, Design, Science dan Management.
Omong-omong, aula terbesar ada di Sains dan Manajemen)) Masing-masing dapat menampung ~350 orang. Backend dan Frontend tidak jauh lebih kecil. Ruang Devops adalah yang terkecil, namun aktif.
Saya mendengarkan laporan di bagian Devops dan Backend dan berbicara sedikit dengan para pembicara. Saya ingin berbicara tentang topik yang dibahas dan mengulas bagian-bagian ini di konferensi.
Perwakilan dari SKB-Kontur, DataArt, Evil Martians, studio web Ekaterinburg Flag, Miro (RealTimeBoard) berbicara di bagian Devops dan Backend. Topik-topiknya mencakup CI/CD, bekerja dengan layanan antrean, logging; Topik tanpa server dan bekerja dengan PostgreSQL di Go dibahas dengan baik.
Ada juga laporan dari Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, tetapi saya tidak punya waktu untuk menghadirinya secara fisik (rekaman video dan slide laporan belum tersedia, mereka berjanji akan mempostingnya dalam waktu 2 minggu di dump-ekb.ru).
Bagian pengembang
Yang mengejutkan, bagian tersebut diadakan di aula terkecil, sekitar 50 kursi. Orang-orang bahkan berdiri di gang :) Saya akan bercerita tentang laporan yang berhasil saya dengarkan.
Elastis seberat satu petabyte
Bagian ini diawali dengan laporan oleh Vladimir Lil (SKB-Kontur) tentang Elasticsearch di Kontur. Mereka memiliki Elastic yang cukup besar dan dimuat (~800 TB data, ~1.3 petabyte dengan memperhitungkan redundansi). Elasticsearch untuk semua layanan Kontur bersifat tunggal, terdiri dari 2 cluster (dari 7 dan 9 server), dan sangat penting sehingga Kontur memiliki insinyur Elasticsearch khusus (sebenarnya, Vladimir sendiri).
Vladimir juga berbagi pemikirannya tentang manfaat Elasticsearch dan masalah yang ditimbulkannya.
Manfaat:
- Semua log ada di satu tempat, akses mudah ke sana
- Menyimpan log selama satu tahun dan menganalisisnya dengan mudah
- Kecepatan tinggi bekerja dengan log
- Visualisasi data yang keren dan unik
Masalahnya adalah:
- perantara pesan harus dimiliki (untuk Kontur perannya dimainkan oleh Kafka)
- fitur bekerja dengan Elasticsearch Curator (beban tinggi dibuat secara berkala dari tugas reguler di Curator)
- tidak ada otorisasi bawaan (hanya untuk uang terpisah, cukup besar, atau sebagai plugin sumber terbuka dengan berbagai tingkat kesiapan untuk produksi)
Hanya ada ulasan positif tentang Open Distro untuk Elasticsearch :) Masalah otorisasi yang sama telah diselesaikan di sana.
Petabytenya dari mana?Node mereka terdiri dari server dengan 12*8 Tb SATA + 2*2 Tb SSD. Penyimpanan dingin pada SATA, SSD hanya untuk cache panas (hot storage).
7+9 server, (7 + 9) * 12 * 8 = 1536 Tb.
Sebagian ruang dicadangkan, disisihkan untuk redundansi, dll.
Log dari sekitar 90 aplikasi dikirim ke Elasticsearch, termasuk semua layanan pelaporan Kontur, Elba, dll.
Fitur pengembangan di Tanpa Server
Berikut laporan Ruslan Serkin dari DataArt tentang Serverless.
Ruslan bercerita tentang apa itu pengembangan dengan pendekatan Serverless secara umum, dan apa saja fitur-fiturnya.
Tanpa server adalah pendekatan pengembangan di mana pengembang tidak menyentuh infrastruktur dengan cara apa pun. Contoh - AWS Lambda Tanpa Server, Kubeless.io (Tanpa Server di dalam Kubernetes), Google Cloud Functions.
Aplikasi Tanpa Server yang ideal hanyalah sebuah fungsi yang mengirimkan permintaan ke penyedia Tanpa Server melalui API Gateway khusus. Layanan mikro yang ideal, sementara AWS Lambda juga mendukung sejumlah besar bahasa pemrograman modern. Biaya pemeliharaan dan penerapan infrastruktur menjadi nol bagi penyedia cloud, mendukung aplikasi kecil juga akan sangat murah (AWS Lambda - $0.2 / 1 juta permintaan sederhana).
Skalabilitas sistem seperti itu hampir ideal - penyedia cloud menangani hal ini sendiri, Kubeless melakukan penskalaan secara otomatis dalam cluster Kubernetes.
Ada kelemahannya:
- mengembangkan aplikasi besar menjadi lebih sulit
- ada kesulitan dengan aplikasi pembuatan profil (hanya log yang tersedia untuk Anda, tetapi tidak membuat profil seperti biasanya)
- tidak ada versi
Sejujurnya, saya mendengar tentang Tanpa Server beberapa tahun yang lalu, namun selama ini tidak jelas bagi saya bagaimana cara menggunakannya dengan benar. Setelah laporan Ruslan, pemahaman muncul, dan setelah laporan Nikolai Sverchkov (Evil Martians) dari bagian Backend, hal itu dikonsolidasikan. Tidak sia-sia saya pergi ke konferensi tersebut :)
CI diperuntukkan bagi masyarakat miskin, atau apakah layak menulis CI Anda sendiri untuk studio web?
Mikhail Radionov, kepala studio web Flag dari Yekaterinburg, berbicara tentang CI/CD yang ditulis sendiri.
Studionya telah berubah dari “CI/CD manual” (masuk ke server melalui SSH, lakukan git pull, ulangi 100 kali sehari) ke Jenkins dan ke alat yang ditulis sendiri yang memungkinkan Anda memantau kode dan melakukan rilis yang disebut Pullkins .
Mengapa Jenkins tidak berhasil? Secara default, ini tidak memberikan fleksibilitas yang cukup dan terlalu sulit untuk disesuaikan.
“Flag” berkembang di Laravel (kerangka PHP). Saat mengembangkan server CI/CD, Mikhail dan rekan-rekannya menggunakan mekanisme bawaan Laravel yang disebut Telescope dan Envoy. Hasilnya adalah server di PHP (harap diperhatikan) yang memproses permintaan webhook yang masuk, dapat membangun frontend dan backend, menyebarkan ke server yang berbeda, dan melaporkan ke Slack.
Kemudian, untuk dapat melakukan penerapan biru/hijau dan memiliki pengaturan yang seragam di lingkungan dev-stage-prod, mereka beralih ke Docker. Keuntungannya tetap sama, kemungkinan untuk menyeragamkan lingkungan dan penerapan yang lancar telah ditambahkan, dan kebutuhan untuk mempelajari Docker untuk bekerja dengannya dengan benar juga ditambahkan.
Bagaimana kami mengurangi jumlah rollback rilis server sebesar 99%
Laporan terakhir di bagian Devops berasal dari Viktor Eremchenko, Lead devops engineer di Miro.com (sebelumnya RealTimeBoard).
RealTimeBoard, produk andalan tim Miro, didasarkan pada aplikasi Java monolitik. Mengumpulkan, menguji, dan menerapkannya tanpa downtime adalah tugas yang sulit. Dalam hal ini, penting untuk menerapkan versi kode sedemikian rupa sehingga tidak perlu dibatalkan (ini adalah monolit yang berat).
Dalam perjalanannya membangun sistem yang memungkinkan Anda melakukan hal ini, Miro menempuh jalur yang mencakup pengerjaan arsitektur, alat yang digunakan (Atlassian Bamboo, Ansible, dll), dan pengerjaan struktur tim (sekarang mereka punya tim Devops yang berdedikasi + banyak tim Scrum terpisah dari pengembang dengan profil berbeda).
Jalannya ternyata sulit dan berduri, dan Victor berbagi akumulasi rasa sakit dan optimisme yang tidak berakhir di situ.
Memenangkan buku untuk mengajukan pertanyaan
Bagian belakang
Saya berhasil menghadiri 2 laporan - dari Nikolay Sverchkov (Evil Martians), juga tentang Serverless, dan dari Grigory Koshelev (perusahaan Kontur) tentang telemetri.
Tanpa server untuk manusia biasa
Jika Ruslan Sirkin berbicara tentang apa itu Serverless, Nikolay menunjukkan aplikasi sederhana menggunakan Serverless, dan berbicara tentang detail yang mempengaruhi biaya dan kecepatan aplikasi di AWS Lambda.
Detail yang menarik: elemen berbayar minimum adalah memori 128 Mb dan CPU 100 ms, biayanya $0,000000208. Selain itu, 1 juta permintaan seperti itu per bulan gratis.
Beberapa fungsi Nikolai sering kali melebihi batas 100 ms (aplikasi utama ditulis dalam Ruby), jadi menulis ulang fungsi tersebut di Go memberikan penghematan yang sangat baik.
Vostok Hercules — jadikan telemetri hebat lagi!
Laporan terbaru bagian Backend dari Grigory Koshelev (perusahaan Kontur) tentang telemetri. Telemetri berarti log, metrik, jejak aplikasi.
Untuk tujuan ini, Contour menggunakan alat yang ditulis sendiri yang diposting di Github. Alat dari laporan - Hercules, , digunakan untuk mengirimkan data telemetri.
Laporan Vladimir Lila di bagian Devops membahas penyimpanan dan pemrosesan log di Elasticsearch, namun masih ada tugas mengirimkan log dari ribuan perangkat dan aplikasi, dan alat seperti Vostok Hercules menyelesaikannya.
Sirkuit mengikuti jalur yang diketahui banyak orang - dari RabbitMQ ke Apache Kafka, tetapi tidak semuanya sesederhana itu)) Mereka harus menambahkan Zookeeper, Cassandra, dan Graphite ke sirkuit. Saya tidak akan mengungkapkan sepenuhnya informasi dalam laporan ini (bukan profil saya), jika Anda tertarik, Anda dapat menunggu slide dan videonya di website konferensi.
Bagaimana jika dibandingkan dengan konferensi lain?
Saya tidak bisa membandingkannya dengan konferensi di Moskow dan St. Petersburg, saya bisa membandingkannya dengan acara lain di Ural dan dengan 404fest di Samara.
DAMP diadakan dalam 8 bagian, ini merupakan rekor konferensi Ural. Bagian Sains dan Manajemen sangat besar, ini juga tidak biasa. Penonton di Yekaterinburg cukup terstruktur - kota ini memiliki departemen pengembangan besar untuk Yandex, Kontur, Tinkoff, dan ini berdampak pada laporan.
Hal menarik lainnya adalah banyak perusahaan yang menghadirkan 3-4 pembicara di konferensi sekaligus (seperti yang terjadi pada Kontur, Evil Martians, Tinkoff). Banyak dari mereka yang menjadi sponsor, namun laporannya cukup setara dengan laporan lainnya, ini bukan laporan iklan.
Pergi atau tidak pergi? Jika Anda tinggal di Ural atau sekitarnya, Anda memiliki kesempatan dan tertarik dengan topik tersebut - ya, tentu saja. Jika Anda berpikir tentang perjalanan jauh, saya akan melihat topik laporan dan laporan video dari tahun-tahun sebelumnya dan membuat keputusan.
Keuntungan lain dari konferensi di daerah, pada umumnya, adalah mudahnya berkomunikasi dengan pembicara setelah laporan; hanya saja jumlah pelamar untuk komunikasi semacam itu lebih sedikit.
Terima kasih kepada Dump dan Ekaterinburg! )
Sumber: www.habr.com
