សន្និសិទ DUMP | grep 'backend|devops'

កាលពីសប្តាហ៍មុនខ្ញុំបានទៅសន្និសិទ DUMP IT (https://dump-ekb.ru/) នៅ Yekaterinburg ហើយខ្ញុំចង់ប្រាប់អ្នកពីអ្វីដែលត្រូវបានពិភាក្សានៅក្នុងផ្នែក Backend និង Devops និងថាតើសន្និសីទ IT ក្នុងតំបន់មានតម្លៃគួរយកចិត្តទុកដាក់ដែរឬទេ។

Nikolay Sverchkov ពី Evil Martians អំពី Serverless

តើមានអ្វីនៅទីនោះ?

សរុបមក សន្និសិទនេះមាន 8 ផ្នែក៖ ផ្នែកខាងក្រោយ ផ្នែកខាងមុខ ទូរសព្ទចល័ត ការធ្វើតេស្ត និង QA ការអភិវឌ្ឍន៍ ការរចនា វិទ្យាសាស្រ្ត និងការគ្រប់គ្រង។

ដោយវិធីនេះ សាលធំជាងគេគឺនៅវិទ្យាសាស្រ្ត និងការគ្រប់គ្រង)) សម្រាប់មនុស្ស 350 នាក់ក្នុងម្នាក់ៗ។ Backend និង Frontend មិនតូចជាងនេះទេ។ បន្ទប់ Devops គឺតូចបំផុត ប៉ុន្តែសកម្ម។

ខ្ញុំបានស្តាប់របាយការណ៍នៅក្នុងផ្នែក Devops និង Backend ហើយនិយាយបន្តិចបន្តួចជាមួយអ្នកនិយាយ។ ខ្ញុំ​ចង់​និយាយ​អំពី​ប្រធាន​បទ​ដែល​គ្រប​ដណ្តប់ ហើយ​ពិនិត្យ​មើល​ផ្នែក​ទាំង​នេះ​នៅ​ក្នុង​សន្និសីទ។

អ្នកតំណាងរបស់ SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) បាននិយាយនៅក្នុងផ្នែក Devops និង Backend ។ ប្រធានបទគ្របដណ្តប់ CI/CD ធ្វើការជាមួយសេវាកម្មជួរ ការកត់ត្រា ប្រធានបទគ្មានម៉ាស៊ីនមេ និងការធ្វើការជាមួយ PostgreSQL នៅក្នុង Go ត្រូវបានគ្របដណ្តប់យ៉ាងល្អ។

មានរបាយការណ៍ផងដែរដោយ Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank ប៉ុន្តែខ្ញុំមិនមានពេលវេលាដើម្បីចូលរួមជាមួយពួកគេទេ (ការថតវីដេអូនិងស្លាយនៃរបាយការណ៍មិនទាន់មានទេពួកគេសន្យាថានឹងបង្ហោះវាក្នុងរយៈពេល 2 សប្តាហ៍។ នៅលើ dump-ekb.ru) ។

ផ្នែក Devops

អ្វី​ដែល​គួរ​ឱ្យ​ភ្ញាក់​ផ្អើល​នោះ​គឺ​ផ្នែក​នេះ​ត្រូវ​បាន​គេ​ប្រារព្ធ​ធ្វើ​នៅ​ក្នុង​សាល​តូច​បំផុត​ដែល​មាន​ប្រហែល ៥០ កៅអី។ មនុស្សសូម្បីតែឈរនៅច្រកផ្លូវ :) ខ្ញុំនឹងប្រាប់អ្នកអំពីរបាយការណ៍ដែលខ្ញុំបានគ្រប់គ្រងដើម្បីស្តាប់។

Elastic ទម្ងន់មួយ petabyte

ផ្នែកនេះបានចាប់ផ្តើមជាមួយនឹងរបាយការណ៍ដោយ Vladimir Lil (SKB-Kontur) អំពី Elasticsearch នៅ Kontur ។ ពួកវាមាន Elastic ធំល្មម និងផ្ទុកបាន (ទិន្នន័យ ~ 800 TB, ~ 1.3 petabytes ដោយគិតគូរពីភាពលែងត្រូវការតទៅទៀត)។ Elasticsearch សម្រាប់សេវាកម្ម Kontur ទាំងអស់គឺនៅលីវ មាន 2 ចង្កោម (នៃ 7 និង 9 servers) ហើយមានសារៈសំខាន់ខ្លាំងណាស់ដែល Kontur មានវិស្វករ Elasticsearch ពិសេស (តាមពិតគឺ Vladimir ខ្លួនឯង)។

លោកវ្ល៉ាឌីមៀក៏បានចែករំលែកគំនិតរបស់គាត់អំពីអត្ថប្រយោជន៍នៃ Elasticsearch និងបញ្ហាដែលវានាំមក។

អត្ថប្រយោជន៍៖

• កំណត់ហេតុទាំងអស់ស្ថិតនៅក្នុងកន្លែងតែមួយ ងាយស្រួលចូលទៅកាន់ពួកគេ។
• រក្សាទុកកំណត់ហេតុរយៈពេលមួយឆ្នាំ និងងាយស្រួលវិភាគ
• ល្បឿនខ្ពស់នៃការធ្វើការជាមួយកំណត់ហេតុ
• ការមើលឃើញទិន្នន័យត្រជាក់ចេញពីប្រអប់

បញ្ហា៖

• ឈ្មួញកណ្តាលសារគឺត្រូវតែមាន (សម្រាប់ Kontur តួនាទីរបស់វាត្រូវបានលេងដោយ Kafka)
• លក្ខណៈពិសេសនៃការធ្វើការជាមួយ Elasticsearch Curator (បង្កើតបន្ទុកខ្ពស់តាមកាលកំណត់ពីការងារធម្មតានៅក្នុង Curator)
• គ្មានការអនុញ្ញាតដែលភ្ជាប់មកជាមួយទេ (សម្រាប់តែប្រាក់ដាច់ដោយឡែក ឬជាកម្មវិធីជំនួយប្រភពបើកចំហនៃកម្រិតផ្សេងៗគ្នានៃការត្រៀមខ្លួនសម្រាប់ផលិតកម្ម)

មានតែការពិនិត្យវិជ្ជមានអំពី Open Distro សម្រាប់ Elasticsearch :) បញ្ហាដូចគ្នានៃការអនុញ្ញាតត្រូវបានដោះស្រាយនៅទីនោះ។

តើ petabyte មកពីណា?ថ្នាំងរបស់ពួកគេមានម៉ាស៊ីនមេដែលមាន 12 * 8 Tb SATA + 2 * 2 Tb SSD ។ ការផ្ទុកត្រជាក់នៅលើ SATA, SSD សម្រាប់តែឃ្លាំងសម្ងាត់ក្តៅ (កន្លែងផ្ទុកក្តៅ)។
ម៉ាស៊ីនមេ 7+9, (7 + 9) * 12 * 8 = 1536 Tb ។
ផ្នែកមួយនៃលំហគឺស្ថិតនៅក្នុងទុនបំរុងទុកមួយឡែកសម្រាប់ការប្រើប្រាស់ឡើងវិញ។ល។
កំណត់ហេតុពីកម្មវិធីប្រហែល 90 ត្រូវបានផ្ញើទៅកាន់ Elasticsearch រួមទាំងសេវាកម្មរាយការណ៍ទាំងអស់របស់ Kontur, Elba ជាដើម។

លក្ខណៈពិសេសនៃការអភិវឌ្ឍន៍នៅលើ Serverless

បន្ទាប់គឺជារបាយការណ៍របស់ Ruslan Serkin ពី DataArt អំពី Serverless ។

Ruslan បាននិយាយអំពីការអភិវឌ្ឍន៍ជាមួយនឹងវិធីសាស្រ្ត Serverless ជាទូទៅ និងអ្វីដែលជាលក្ខណៈពិសេសរបស់វា។

Serverless គឺជាវិធីសាស្រ្តមួយសម្រាប់ការអភិវឌ្ឍន៍ដែលអ្នកអភិវឌ្ឍន៍មិនប៉ះហេដ្ឋារចនាសម្ព័ន្ធតាមមធ្យោបាយណាមួយឡើយ។ ឧទាហរណ៍ - AWS Lambda Serverless, Kubeless.io (Serverless នៅខាងក្នុង Kubernetes), មុខងារ Google Cloud ។

កម្មវិធី Serverless ដ៏ល្អគឺគ្រាន់តែជាមុខងារដែលផ្ញើសំណើទៅកាន់អ្នកផ្តល់សេវា Serverless តាមរយៈ API Gateway ពិសេស។ សេវាមីក្រូដ៏ល្អមួយ ខណៈពេលដែល AWS Lambda ក៏គាំទ្រភាសាកម្មវិធីទំនើបមួយចំនួនធំផងដែរ។ ការចំណាយលើការថែរក្សា និងដាក់ពង្រាយហេដ្ឋារចនាសម្ព័ន្ធក្លាយជាសូន្យក្នុងករណីអ្នកផ្តល់សេវាពពក ការគាំទ្រកម្មវិធីតូចៗក៏នឹងមានតម្លៃថោកណាស់ (AWS Lambda - $0.2 / 1 លានសំណើសាមញ្ញ) ។

លទ្ធភាពធ្វើមាត្រដ្ឋាននៃប្រព័ន្ធបែបនេះគឺស្ទើរតែល្អឥតខ្ចោះ - អ្នកផ្តល់សេវាពពកថែរក្សាវាដោយខ្លួនឯង Kubeless ធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិនៅក្នុងចង្កោម Kubernetes ។

មានគុណវិបត្តិ៖

• ការអភិវឌ្ឍន៍កម្មវិធីធំៗកាន់តែពិបាក
• មានការលំបាកជាមួយនឹងកម្មវិធីទម្រង់ (អ្នកគ្រាន់តែចូលប្រើកំណត់ហេតុប៉ុណ្ណោះ ប៉ុន្តែមិនមានប្រវត្តិរូបក្នុងន័យធម្មតាទេ)
• គ្មានកំណែ

និយាយឱ្យត្រង់ទៅ ខ្ញុំបានលឺអំពី Serverless កាលពីប៉ុន្មានឆ្នាំមុន ប៉ុន្តែប៉ុន្មានឆ្នាំមកនេះ វាមិនច្បាស់សម្រាប់ខ្ញុំពីរបៀបប្រើវាឱ្យបានត្រឹមត្រូវទេ។ បន្ទាប់ពីរបាយការណ៍របស់ Ruslan ការយល់ដឹងបានលេចឡើង ហើយបន្ទាប់ពីរបាយការណ៍របស់ Nikolai Sverchkov (Evil Martians) ពីផ្នែក Backend វាត្រូវបានបង្រួបបង្រួម។ វាមិនមែនជាឥតប្រយោជន៍ទេដែលខ្ញុំបានទៅសន្និសីទ :)

CI គឺសម្រាប់អ្នកក្រ ឬតើវាសមនឹងសរសេរ CI ផ្ទាល់ខ្លួនរបស់អ្នកសម្រាប់ស្ទូឌីយោគេហទំព័រ?

លោក Mikhail Radionov ប្រធានស្ទូឌីយោគេហទំព័រ Flag មកពី Yekaterinburg បាននិយាយអំពី CI/CD ដែលសរសេរដោយខ្លួនឯង។

ស្ទូឌីយោរបស់គាត់បានចេញពី "សៀវភៅដៃ CI/CD" (ចូលទៅក្នុងម៉ាស៊ីនមេតាមរយៈ SSH ធ្វើ git pull ធ្វើម្តងទៀត 100 ដងក្នុងមួយថ្ងៃ) ទៅ Jenkins និងឧបករណ៍ដែលសរសេរដោយខ្លួនឯងដែលអនុញ្ញាតឱ្យអ្នកត្រួតពិនិត្យកូដ និងអនុវត្តការចេញផ្សាយដែលហៅថា Pullkins .

ហេតុអ្វីបានជា Jenkins មិនធ្វើការ? វាមិនបានផ្តល់ភាពបត់បែនគ្រប់គ្រាន់តាមលំនាំដើម និងពិបាកពេកក្នុងការប្ដូរតាមបំណង។

"ទង់" អភិវឌ្ឍនៅក្នុង Laravel (ក្របខ័ណ្ឌ PHP) ។ នៅពេលបង្កើតម៉ាស៊ីនមេ CI/CD លោក Mikhail និងសហការីរបស់គាត់បានប្រើប្រាស់យន្តការដែលភ្ជាប់មកជាមួយរបស់ Laravel ដែលហៅថា Telescope and Envoy។ លទ្ធផលគឺម៉ាស៊ីនមេនៅក្នុង PHP (សូមចំណាំ) ដែលដំណើរការសំណើ webhook ចូល អាចបង្កើត frontend និង backend ដាក់ពង្រាយទៅកាន់ server ផ្សេងៗ និងរាយការណ៍ទៅ Slack ។

បន្ទាប់មក ដើម្បីអាចអនុវត្តការដាក់ពង្រាយពណ៌ខៀវ/បៃតង និងមានការកំណត់ឯកសណ្ឋាននៅក្នុងបរិយាកាសអភិវឌ្ឍន៍-ដំណាក់កាល-ផលិតផល ពួកគេបានប្តូរទៅ Docker ។ គុណសម្បត្តិនៅតែដដែល លទ្ធភាពនៃការធ្វើឱ្យបរិយាកាសដូចគ្នា និងការដាក់ពង្រាយគ្មានថ្នេរត្រូវបានបន្ថែម ហើយតម្រូវការក្នុងការរៀន Docker ដើម្បីធ្វើការជាមួយវាបានត្រឹមត្រូវត្រូវបានបន្ថែម។

គម្រោងនេះគឺនៅលើ Github

របៀបដែលយើងបានកាត់បន្ថយចំនួននៃការវិលត្រឡប់មកវិញរបស់ម៉ាស៊ីនមេ 99%

របាយការណ៍ចុងក្រោយនៅក្នុងផ្នែក Devops គឺមកពី Viktor Eremchenko វិស្វករ Lead devops នៅ Miro.com (អតីត RealTimeBoard) ។

RealTimeBoard ដែលជាផលិតផលលេចធ្លោរបស់ក្រុម Miro គឺផ្អែកលើកម្មវិធី Java monolithic ។ ការប្រមូល សាកល្បង និងដាក់ពង្រាយវាដោយគ្មានពេលសម្រាកគឺជាកិច្ចការដ៏លំបាកមួយ។ ក្នុងករណីនេះ វាមានសារៈសំខាន់ណាស់ក្នុងការដាក់ពង្រាយកំណែនៃកូដបែបនេះ ដើម្បីកុំឱ្យវាវិលត្រឡប់មកវិញ (វាជា monolith ធ្ងន់)។

នៅតាមផ្លូវបង្កើតប្រព័ន្ធដែលអនុញ្ញាតឱ្យអ្នកធ្វើបែបនេះ Miro បានឆ្លងកាត់ផ្លូវដែលរួមមានការងារលើស្ថាបត្យកម្ម ឧបករណ៍ដែលបានប្រើ (Atlassian Bamboo, Ansible ។ល។) និងធ្វើការលើរចនាសម្ព័ន្ធក្រុម (ឥឡូវនេះពួកគេមាន ក្រុម Devops ដែលខិតខំប្រឹងប្រែង + ក្រុម Scrum ដាច់ដោយឡែកជាច្រើនពីអ្នកអភិវឌ្ឍន៍ទម្រង់ផ្សេងៗគ្នា) ។

ផ្លូវ​បាន​ប្រែ​ទៅ​ជា​លំបាក និង​បន្លា ហើយ Victor បាន​ចែក​រំលែក​ការ​ឈឺចាប់ និង​សុទិដ្ឋិនិយម​ដែល​មិន​បាន​បញ្ចប់​នៅ​ទី​នោះ។

ឈ្នះសៀវភៅសម្រាប់សួរសំណួរ

ផ្នែកខាងក្រោយ

ខ្ញុំបានចូលរួមក្នុងរបាយការណ៍ចំនួន 2 - ពី Nikolay Sverchkov (Evil Martians) ផងដែរអំពី Serverless និងពី Grigory Koshelev (ក្រុមហ៊ុន Kontur) អំពី telemetry ។

គ្មានម៉ាស៊ីនបម្រើសម្រាប់តែមនុស្សស្លាប់

ប្រសិនបើ Ruslan Sirkin និយាយអំពីអ្វីដែល Serverless គឺ Nikolay បានបង្ហាញកម្មវិធីសាមញ្ញៗដោយប្រើ Serverless ហើយនិយាយអំពីព័ត៌មានលម្អិតដែលប៉ះពាល់ដល់តម្លៃ និងល្បឿននៃកម្មវិធីនៅក្នុង AWS Lambda។

ព័ត៌មានលម្អិតគួរឱ្យចាប់អារម្មណ៍៖ ធាតុដែលបានបង់អប្បបរមាគឺ 128 Mb នៃអង្គចងចាំ និង 100 ms CPU វាមានតម្លៃ 0,000000208 ដុល្លារ។ លើសពីនេះទៅទៀត សំណើបែបនេះ 1 លានក្នុងមួយខែគឺមិនគិតថ្លៃទេ។

មុខងារមួយចំនួនរបស់ Nikolai ជាញឹកញាប់លើសពីដែនកំណត់ 100 ms (កម្មវិធីសំខាន់ត្រូវបានសរសេរជា Ruby) ដូច្នេះការសរសេរវាឡើងវិញនៅក្នុង Go ផ្តល់នូវការសន្សំដ៏ល្អ។

Vostok Hercules - ធ្វើឱ្យ telemetry អស្ចារ្យម្តងទៀត!

របាយការណ៍ចុងក្រោយបង្អស់នៃផ្នែក Backend ពី Grigory Koshelev (ក្រុមហ៊ុន Kontur) អំពី telemetry ។ Telemetry មានន័យថា កំណត់ហេតុ រង្វាស់ ដានកម្មវិធី។

ចំពោះគោលបំណងនេះ Contour ប្រើឧបករណ៍សរសេរដោយខ្លួនឯងដែលបានបង្ហោះនៅលើ Github ។ ឧបករណ៍ពីរបាយការណ៍ - Hercules, github.com/vostok/herculesត្រូវបានប្រើដើម្បីបញ្ជូនទិន្នន័យ telemetry ។

របាយការណ៍របស់វ្ល៉ាឌីមៀ លីឡា នៅក្នុងផ្នែក Devops បានពិភាក្សាអំពីការរក្សាទុក និងដំណើរការកំណត់ហេតុនៅក្នុង Elasticsearch ប៉ុន្តែនៅតែមានភារកិច្ចក្នុងការបញ្ជូនកំណត់ហេតុពីឧបករណ៍ និងកម្មវិធីរាប់ពាន់ ហើយឧបករណ៍ដូចជា Vostok Hercules ដោះស្រាយបញ្ហាទាំងនោះ។

សៀគ្វីនេះបានដើរតាមផ្លូវដែលមនុស្សជាច្រើនស្គាល់ - ពី RabbitMQ ទៅ Apache Kafka ប៉ុន្តែមិនមែនអ្វីៗទាំងអស់គឺសាមញ្ញទេ)) ពួកគេត្រូវបន្ថែម Zookeeper, Cassandra និង Graphite ទៅក្នុងសៀគ្វី។ ខ្ញុំនឹងមិនបង្ហាញទាំងស្រុងនូវព័ត៌មាននៅលើរបាយការណ៍នេះទេ (មិនមែនជាប្រវត្តិរូបរបស់ខ្ញុំទេ) ប្រសិនបើអ្នកចាប់អារម្មណ៍ អ្នកអាចរង់ចាំស្លាយ និងវីដេអូនៅលើគេហទំព័រសន្និសីទ។

តើ​វា​ប្រៀប​ធៀប​ទៅ​នឹង​សន្និសីទ​ផ្សេង​ទៀត​យ៉ាង​ណា?

ខ្ញុំមិនអាចប្រៀបធៀបវាជាមួយសន្និសីទនៅទីក្រុងមូស្គូ និងសាំងពេទឺប៊ឺគបានទេ ខ្ញុំអាចប្រៀបធៀបវាជាមួយព្រឹត្តិការណ៍ផ្សេងទៀតនៅអ៊ុយរ៉ាល់ និងជាមួយ 404fest នៅសាម៉ារ៉ា។

DAMP ត្រូវបានប្រារព្ធឡើងជា 8 ផ្នែក នេះគឺជាកំណត់ត្រាសម្រាប់សន្និសីទ Ural ។ ផ្នែកវិទ្យាសាស្ត្រ និងការគ្រប់គ្រងធំណាស់ នេះក៏មិនធម្មតាដែរ។ ទស្សនិកជននៅ Yekaterinburg មានរចនាសម្ព័ន្ធល្អ - ទីក្រុងមាននាយកដ្ឋានអភិវឌ្ឍន៍ធំសម្រាប់ Yandex, Kontur, Tinkoff ហើយនេះទុកសញ្ញារបស់វានៅលើរបាយការណ៍។

ចំណុចគួរឱ្យចាប់អារម្មណ៍មួយទៀតគឺថាក្រុមហ៊ុនជាច្រើនមានវាគ្មិន 3-4 នៅក្នុងសន្និសីទក្នុងពេលតែមួយ (នេះជាករណីជាមួយ Kontur, Evil Martians, Tinkoff) ។ ពួកគេជាច្រើនគឺជាអ្នកឧបត្ថម្ភ ប៉ុន្តែរបាយការណ៍គឺដូចគ្នាទៅនឹងអ្នកផ្សេងទៀត ទាំងនេះមិនមែនជារបាយការណ៍ផ្សាយពាណិជ្ជកម្មទេ។

ទៅឬមិនទៅ? ប្រសិនបើអ្នករស់នៅក្នុង Urals ឬនៅក្បែរនោះអ្នកមានឱកាសនិងចាប់អារម្មណ៍លើប្រធានបទ - បាទពិតណាស់។ ប្រសិនបើអ្នកកំពុងគិតអំពីការធ្វើដំណើរដ៏វែងឆ្ងាយ ខ្ញុំនឹងមើលប្រធានបទនៃរបាយការណ៍ និងរបាយការណ៍វីដេអូពីឆ្នាំមុនៗ www.youtube.com/user/videoitpeople/videos និងបានធ្វើការសម្រេចចិត្ត។
អត្ថប្រយោជន៍មួយទៀតនៃសន្និសិទក្នុងតំបន់ ជាក្បួនគឺវាងាយស្រួលក្នុងការទំនាក់ទំនងជាមួយវាគ្មិនបន្ទាប់ពីរបាយការណ៍ មានអ្នកដាក់ពាក្យតិចជាងសម្រាប់ការទំនាក់ទំនងបែបនេះ។

សូមអរគុណដល់ Dump និង Ekaterinburg! )

ប្រភព: www.habr.com