ការកំណត់ទំហំសមស្របសម្រាប់ចង្កោម Kafka នៅក្នុង Kubernetes

ចំណាំ។ បកប្រែ៖ នៅក្នុងអត្ថបទនេះ Banzai Cloud ចែករំលែកឧទាហរណ៍អំពីរបៀបដែលឧបករណ៍ផ្ទាល់ខ្លួនរបស់វាអាចត្រូវបានប្រើដើម្បីធ្វើឱ្យ Kafka ងាយស្រួលប្រើនៅក្នុង Kubernetes ។ ការណែនាំខាងក្រោមបង្ហាញពីរបៀបដែលអ្នកអាចកំណត់ទំហំដ៏ល្អប្រសើរនៃហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នក និងកំណត់រចនាសម្ព័ន្ធ Kafka ខ្លួនវាដើម្បីសម្រេចបាននូវលំហូរដែលត្រូវការ។

Apache Kafka គឺជាវេទិកាស្ទ្រីមចែកចាយសម្រាប់បង្កើតប្រព័ន្ធផ្សាយតាមពេលវេលាជាក់ស្តែងដែលអាចទុកចិត្តបាន ធ្វើមាត្រដ្ឋាន និងដំណើរការខ្ពស់។ សមត្ថភាពគួរឱ្យចាប់អារម្មណ៍របស់វាអាចត្រូវបានពង្រីកដោយប្រើ Kubernetes ។ សម្រាប់រឿងនេះយើងបានបង្កើត ប្រតិបត្តិករ Kafka ប្រភពបើកចំហ និងឧបករណ៍មួយហៅថា Supertubes. ពួកគេអនុញ្ញាតឱ្យអ្នកដំណើរការ Kafka លើ Kubernetes និងប្រើប្រាស់មុខងារផ្សេងៗរបស់វា ដូចជាការកែតម្រូវការកំណត់រចនាសម្ព័ន្ធឈ្មួញកណ្តាល ការធ្វើមាត្រដ្ឋានដោយផ្អែកលើម៉ែត្រជាមួយនឹងតុល្យភាពឡើងវិញ ការយល់ដឹងអំពីរ៉ាកែត "ទន់" (ពិរោះ) ការចេញផ្សាយបច្ចុប្បន្នភាព។ល។

សាកល្បង Supertubes ក្នុងក្រុមរបស់អ្នក៖

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ឬទំនាក់ទំនង ឯកសារ. អ្នកក៏អាចអានអំពីសមត្ថភាពមួយចំនួនរបស់ Kafka ដែលជាការងារដែលដំណើរការដោយស្វ័យប្រវត្តិដោយប្រើ Supertubes និង Kafka operator។ យើងបានសរសេរអំពីពួកគេរួចហើយនៅលើប្លក់៖

• អូ​ទេ! ប្រតិបត្តិករ Kafka មួយផ្សេងទៀតសម្រាប់ Kubernetes;
• ត្រួតពិនិត្យ និងដំណើរការ Kafka ដោយផ្អែកលើរង្វាស់ Prometheus;
• Kafka rack ការយល់ដឹងនៅលើ Kubernetes;
• កំពុងដំណើរការ Apache Kafka លើ Istio - គោល;
• អ្នកប្រើប្រាស់បានផ្ទៀងផ្ទាត់ និងចូលប្រើចង្កោមដែលបានគ្រប់គ្រងជាមួយប្រតិបត្តិករ Kafka;
• ការធ្វើឱ្យប្រសើរការវិល Kafka និងការកំណត់រចនាសម្ព័ន្ធថាមវន្តនៅលើ Kubernetes;
• តម្រងពិធីការប្រេសិតសម្រាប់ Kafka, meshed.

នៅពេលអ្នកសម្រេចចិត្តដាក់ពង្រាយ Kafka cluster នៅលើ Kubernetes អ្នកទំនងជានឹងប្រឈមមុខនឹងបញ្ហាប្រឈមក្នុងការកំណត់ទំហំដ៏ល្អប្រសើរនៃហេដ្ឋារចនាសម្ព័ន្ធមូលដ្ឋាន និងតម្រូវការក្នុងការកែសម្រួលការកំណត់រចនាសម្ព័ន្ធ Kafka របស់អ្នកឱ្យបានល្អ ដើម្បីបំពេញតាមតម្រូវការនៃដំណើរការ។ ដំណើរការអតិបរមារបស់ឈ្មួញកណ្តាលនីមួយៗត្រូវបានកំណត់ដោយដំណើរការនៃសមាសធាតុហេដ្ឋារចនាសម្ព័ន្ធមូលដ្ឋាន ដូចជាអង្គចងចាំ ខួរក្បាល ល្បឿនឌីស កម្រិតបញ្ជូនបណ្តាញជាដើម។

តាមឧត្ដមគតិ ការកំណត់រចនាសម្ព័ន្ធរបស់ឈ្មួញកណ្តាលគួរតែមានដូចដែលធាតុហេដ្ឋារចនាសម្ព័ន្ធទាំងអស់ត្រូវបានប្រើដើម្បីសមត្ថភាពអតិបរមារបស់ពួកគេ។ ទោះយ៉ាងណាក៏ដោយនៅក្នុងជីវិតពិតការរៀបចំនេះគឺស្មុគស្មាញណាស់។ វាទំនងជាអ្នកប្រើប្រាស់នឹងកំណត់រចនាសម្ព័ន្ធឈ្មួញកណ្តាលដើម្បីបង្កើនការប្រើប្រាស់សមាសភាគមួយ ឬពីរ (ថាស អង្គចងចាំ ឬខួរក្បាល)។ និយាយជាទូទៅ ឈ្មួញកណ្តាលបង្ហាញប្រតិបត្តិការអតិបរមានៅពេលដែលការកំណត់រចនាសម្ព័ន្ធរបស់វាអនុញ្ញាតឱ្យប្រើសមាសធាតុយឺតបំផុតក្នុងកម្រិតពេញលេញបំផុត។ វិធីនេះយើងអាចទទួលបានគំនិតរដុបនៃបន្ទុកដែលឈ្មួញកណ្តាលម្នាក់អាចដោះស្រាយបាន។

តាមទ្រឹស្តី យើងក៏អាចប៉ាន់ប្រមាណចំនួនឈ្មួញកណ្តាលដែលត្រូវការដើម្បីដោះស្រាយបន្ទុកដែលបានផ្តល់ឱ្យ។ ទោះយ៉ាងណាក៏ដោយ នៅក្នុងការអនុវត្តមានជម្រើសនៃការកំណត់រចនាសម្ព័ន្ធជាច្រើននៅកម្រិតផ្សេងៗគ្នា ដែលវាជាការលំបាកខ្លាំងណាស់ (ប្រសិនបើមិនអាចទៅរួច) ដើម្បីវាយតម្លៃការអនុវត្តសក្តានុពលនៃការកំណត់រចនាសម្ព័ន្ធជាក់លាក់ណាមួយ។ ម្យ៉ាងវិញទៀត វាជាការលំបាកខ្លាំងណាស់ក្នុងការរៀបចំផែនការកំណត់រចនាសម្ព័ន្ធដោយផ្អែកលើការអនុវត្តដែលបានផ្តល់ឱ្យមួយចំនួន។

សម្រាប់អ្នកប្រើប្រាស់ Supertubes ជាធម្មតាយើងប្រកាន់យកវិធីសាស្រ្តដូចខាងក្រោម៖ យើងចាប់ផ្តើមជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធមួយចំនួន (ហេដ្ឋារចនាសម្ព័ន្ធ + ការកំណត់) បន្ទាប់មកវាស់ស្ទង់ដំណើរការរបស់វា កែតម្រូវការកំណត់ឈ្មួញកណ្តាល និងដំណើរការម្តងទៀត។ វាកើតឡើងរហូតដល់សមាសធាតុយឺតបំផុតនៃហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានប្រើប្រាស់ពេញលេញ។

នៅក្នុងវិធីនេះ យើងទទួលបានគំនិតកាន់តែច្បាស់អំពីចំនួនឈ្មួញកណ្តាលមួយក្រុមដែលត្រូវការដើម្បីដោះស្រាយបន្ទុកជាក់លាក់មួយ (ចំនួនឈ្មួញកណ្តាលក៏អាស្រ័យលើកត្តាផ្សេងទៀតផងដែរ ដូចជាចំនួនអប្បបរមានៃការចម្លងសារ ដើម្បីធានាភាពធន់ ចំនួនភាគថាស។ អ្នកដឹកនាំជាដើម) ។ លើសពីនេះ យើងទទួលបានការយល់ដឹងអំពីសមាសធាតុហេដ្ឋារចនាសម្ព័ន្ធដែលទាមទារការធ្វើមាត្រដ្ឋានបញ្ឈរ។

អត្ថបទនេះនឹងនិយាយអំពីជំហានដែលយើងធ្វើដើម្បីទទួលបានច្រើនបំផុតពីសមាសធាតុយឺតបំផុតក្នុងការកំណត់រចនាសម្ព័ន្ធដំបូង និងវាស់ស្ទង់លំហូរនៃចង្កោម Kafka ។ ការ​កំណត់​រចនាសម្ព័ន្ធ​ធន់​ខ្ពស់​តម្រូវ​ឱ្យ​មាន​ឈ្មួញ​កណ្តាល​យ៉ាង​ហោច​ណាស់​បី​នាក់​ដែល​កំពុង​រត់ (min.insync.replicas=3) ត្រូវបានចែកចាយនៅទូទាំងតំបន់ភាពងាយស្រួលចំនួនបីផ្សេងគ្នា។ ដើម្បីកំណត់រចនាសម្ព័ន្ធ ធ្វើមាត្រដ្ឋាន និងត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធ Kubernetes យើងប្រើវេទិកាគ្រប់គ្រងកុងតឺន័រផ្ទាល់ខ្លួនរបស់យើងសម្រាប់ពពកចម្រុះ - បំពង់បង្ហូរ. វាគាំទ្រនៅក្នុងបរិវេណ (លោហៈទទេ, VMware) និងពពកប្រាំប្រភេទ (Alibaba, AWS, Azure, Google, Oracle) ក៏ដូចជាការរួមបញ្ចូលគ្នានៃពួកវាណាមួយ។

គំនិតលើហេដ្ឋារចនាសម្ព័ន្ធចង្កោម Kafka និងការកំណត់រចនាសម្ព័ន្ធ

សម្រាប់ឧទាហរណ៍ខាងក្រោម យើងបានជ្រើសរើស AWS ជាអ្នកផ្តល់សេវាពពក និង EKS ជាការចែកចាយ Kubernetes ។ ការកំណត់រចនាសម្ព័ន្ធស្រដៀងគ្នាអាចត្រូវបានអនុវត្តដោយប្រើ P.K.E. - ការចែកចាយ Kubernetes ពី Banzai Cloud បញ្ជាក់ដោយ CNCF ។

ថាស

ក្រុមហ៊ុន Amazon ផ្តល់ជូនផ្សេងៗគ្នា ប្រភេទបរិមាណ EBS. នៅស្នូល gp2 и io1 ទោះយ៉ាងណាក៏ដោយមានដ្រាយ SSD ដើម្បីធានាបាននូវលំហូរខ្ពស់។ gp2 ប្រើប្រាស់ឥណទានបង្គរ (ឥណទាន I/O)ដូច្នេះយើងចូលចិត្តប្រភេទ io1ដែលផ្តល់ទិន្នផលខ្ពស់ជាប់លាប់។

ប្រភេទឧទាហរណ៍

ការអនុវត្តរបស់ Kafka គឺពឹងផ្អែកយ៉ាងខ្លាំងទៅលើឃ្លាំងសម្ងាត់ទំព័ររបស់ប្រព័ន្ធប្រតិបត្តិការ ដូច្នេះយើងត្រូវការវត្ថុដែលមានអង្គចងចាំគ្រប់គ្រាន់សម្រាប់ឈ្មួញកណ្តាល (JVM) និងឃ្លាំងសម្ងាត់ទំព័រ។ ឧ c5.2x ធំ - ការចាប់ផ្តើមដ៏ល្អព្រោះវាមានអង្គចងចាំ 16 GB និង ធ្វើឱ្យប្រសើរឡើងដើម្បីធ្វើការជាមួយ EBS. គុណវិបត្តិរបស់វាគឺថាវាមានសមត្ថភាពត្រឹមតែផ្តល់នូវដំណើរការអតិបរមាមិនលើសពី 30 នាទីរៀងរាល់ 24 ម៉ោងម្តង។ ប្រសិនបើបន្ទុកការងាររបស់អ្នកទាមទារឱ្យមានដំណើរការខ្ពស់បំផុតក្នុងរយៈពេលវែងជាងនេះ អ្នកប្រហែលជាចង់ពិចារណាប្រភេទឧទាហរណ៍ផ្សេងទៀត។ នោះហើយជាអ្វីដែលពួកយើងបានធ្វើ ដោយឈប់នៅ c5.4x ធំ. វាផ្តល់នូវលំហូរចូលអតិបរមា 593,75 Mbps. លំហូរអតិបរមានៃបរិមាណ EBS io1 ខ្ពស់ជាងឧទាហរណ៍ c5.4x ធំដូច្នេះ ធាតុយឺតបំផុតនៃហេដ្ឋារចនាសម្ព័ន្ធទំនងជាឆ្លងកាត់ I/O នៃប្រភេទវត្ថុនេះ (ដែលការធ្វើតេស្តផ្ទុករបស់យើងគួរតែបញ្ជាក់ផងដែរ)។

បណ្តាញ

លំហូរនៃបណ្តាញត្រូវតែមានទំហំធំល្មមបើប្រៀបធៀបទៅនឹងដំណើរការរបស់ VM instance និង disk បើមិនដូច្នេះទេបណ្តាញនឹងមានបញ្ហា។ ក្នុងករណីរបស់យើងចំណុចប្រទាក់បណ្តាញ c5.4x ធំ គាំទ្រល្បឿនរហូតដល់ 10 Gb/s ដែលខ្ពស់ជាង I/O តាមរយៈ VM instance ។

ការដាក់ពង្រាយឈ្មួញកណ្តាល

ឈ្មួញកណ្តាលគួរតែត្រូវបានដាក់ឱ្យប្រើប្រាស់ (បានកំណត់ពេលនៅក្នុង Kubernetes) ទៅនឹងថ្នាំងដែលខិតខំប្រឹងប្រែងដើម្បីជៀសវាងការប្រកួតប្រជែងជាមួយនឹងដំណើរការផ្សេងទៀតសម្រាប់ CPU, memory, network, and disk resources។

កំណែ Java

ជម្រើសឡូជីខលគឺ Java 11 ព្រោះវាត្រូវគ្នាជាមួយ Docker ក្នុងន័យថា JVM កំណត់យ៉ាងត្រឹមត្រូវនូវ processors និង memory ដែលមាននៅក្នុងកុងតឺន័រដែលឈ្មួញកណ្តាលកំពុងដំណើរការ។ ដោយដឹងថាដែនកំណត់របស់ដំណើរការមានសារៈសំខាន់ JVM កំណត់ចំនួនខ្សែស្រឡាយ GC និងខ្សែស្រឡាយ JIT ប្រកបដោយតម្លាភាព។ យើងបានប្រើរូបភាព Kafka banzaicloud/kafka:2.13-2.4.0ដែលរួមបញ្ចូល Kafka កំណែ 2.4.0 (Scala 2.13) នៅលើ Java 11 ។

ប្រសិនបើអ្នកចង់ស្វែងយល់បន្ថែមអំពី Java/JVM នៅលើ Kubernetes សូមពិនិត្យមើលការបង្ហោះខាងក្រោមរបស់យើង៖

• ហេតុអ្វីបានជាកម្មវិធី Java របស់ខ្ញុំត្រូវបាន OOMKilled;
• របៀបកំណត់ទំហំធុងឱ្យបានត្រឹមត្រូវសម្រាប់កម្មវិធី Java 10.

ការកំណត់មេម៉ូរីរបស់ឈ្មួញកណ្តាល

មានទិដ្ឋភាពសំខាន់ពីរក្នុងការកំណត់រចនាសម្ព័ន្ធអង្គចងចាំឈ្មួញកណ្តាល៖ ការកំណត់សម្រាប់ JVM និងសម្រាប់ផត Kubernetes ។ ដែនកំណត់អង្គចងចាំដែលបានកំណត់សម្រាប់ផតត្រូវតែធំជាងទំហំអតិបរមា ដូច្នេះ JVM មានកន្លែងសម្រាប់ Java metaspace ដែលស្ថិតនៅក្នុងអង្គចងចាំរបស់វាផ្ទាល់ និងសម្រាប់ឃ្លាំងសម្ងាត់ទំព័រប្រព័ន្ធប្រតិបត្តិការដែល Kafka ប្រើយ៉ាងសកម្ម។ នៅក្នុងការធ្វើតេស្តរបស់យើងយើងបានបើកដំណើរការឈ្មួញកណ្តាល Kafka ជាមួយនឹងប៉ារ៉ាម៉ែត្រ -Xmx4G -Xms2Gហើយដែនកំណត់នៃការចងចាំសម្រាប់ផតគឺ 10 Gi. សូមចំណាំថាការកំណត់អង្គចងចាំសម្រាប់ JVM អាចទទួលបានដោយស្វ័យប្រវត្តិដោយប្រើ -XX:MaxRAMPercentage и -X:MinRAMPercentageដោយផ្អែកលើដែនកំណត់នៃការចងចាំសម្រាប់ផត។

ការកំណត់ដំណើរការរបស់ឈ្មួញកណ្តាល

និយាយជាទូទៅ អ្នកអាចធ្វើឱ្យប្រសើរឡើងនូវការអនុវត្តដោយការបង្កើនភាពស្របគ្នាដោយការបង្កើនចំនួនខ្សែស្រឡាយដែលប្រើដោយ Kafka ។ ដំណើរការកាន់តែច្រើនដែលមានសម្រាប់ Kafka កាន់តែប្រសើរ។ នៅក្នុងការធ្វើតេស្តរបស់យើង យើងបានចាប់ផ្តើមជាមួយនឹងដែនកំណត់នៃ 6 processors ហើយបន្តិចម្តងៗ (តាមរយៈការធ្វើម្តងទៀត) បានបង្កើនចំនួនរបស់ពួកគេដល់ 15។ លើសពីនេះ យើងកំណត់ num.network.threads=12 នៅក្នុងការកំណត់ឈ្មួញកណ្តាល ដើម្បីបង្កើនចំនួនខ្សែស្រឡាយដែលទទួលទិន្នន័យពីបណ្តាញ ហើយបញ្ជូនវា។ ដោយ​ដឹង​ភ្លាមៗ​ថា​ឈ្មួញ​កណ្តាល​ដែល​តាម​មិន​អាច​ទទួល​ការ​ចម្លង​បាន​លឿន​គ្រប់គ្រាន់​នោះ​ពួកគេ​បាន​លើក​ឡើង num.replica.fetchers ដល់ 4 ដើម្បីបង្កើនល្បឿនដែលឈ្មួញកណ្តាលចម្លងសារពីអ្នកដឹកនាំ។

ផ្ទុកឧបករណ៍បង្កើត

អ្នកគួរតែធានាថាម៉ាស៊ីនភ្លើងផ្ទុកដែលបានជ្រើសរើសមិនអស់សមត្ថភាព មុនពេលដែលចង្កោម Kafka (ដែលកំពុងត្រូវបានសម្គាល់) ឈានដល់ការផ្ទុកអតិបរមារបស់វា។ ម្យ៉ាងវិញទៀត វាចាំបាច់ក្នុងការធ្វើការវាយតម្លៃបឋមអំពីសមត្ថភាពរបស់ឧបករណ៍បង្កើតបន្ទុក ហើយជ្រើសរើសប្រភេទឧទាហរណ៍សម្រាប់វាជាមួយនឹងចំនួន processor និងអង្គចងចាំគ្រប់គ្រាន់។ ក្នុងករណីនេះ ឧបករណ៍របស់យើងនឹងផលិតបន្ទុកច្រើនជាងចង្កោម Kafka អាចដោះស្រាយបាន។ បន្ទាប់ពីការពិសោធន៍ជាច្រើន យើងបានដោះស្រាយលើច្បាប់ចម្លងចំនួនបី c5.4x ធំដែលនីមួយៗមានម៉ាស៊ីនភ្លើងកំពុងដំណើរការ។

ការដាក់ពិន្ទុ

ការវាស់វែងការអនុវត្តគឺជាដំណើរការដដែលៗដែលរួមមានដំណាក់កាលដូចខាងក្រោមៈ

• ការរៀបចំហេដ្ឋារចនាសម្ព័ន្ធ (ចង្កោម EKS, ចង្កោម Kafka, ឧបករណ៍បង្កើតបន្ទុក ក៏ដូចជា Prometheus និង Grafana);
• បង្កើតបន្ទុកសម្រាប់រយៈពេលជាក់លាក់មួយ ដើម្បីត្រងគម្លាតចៃដន្យនៅក្នុងសូចនាករការអនុវត្តដែលបានប្រមូល។
• ការកែតម្រូវហេដ្ឋារចនាសម្ព័ន្ធ និងការកំណត់រចនាសម្ព័ន្ធរបស់ឈ្មួញកណ្តាលដោយផ្អែកលើសូចនាករការអនុវត្តដែលបានអង្កេត។
• ដំណើរការម្តងទៀតរហូតដល់កម្រិតដែលត្រូវការនៃលំហូរចង្កោម Kafka ត្រូវបានសម្រេច។ ក្នុងពេលជាមួយគ្នានេះ វាត្រូវតែអាចផលិតឡើងវិញបានជាប់លាប់ និងបង្ហាញពីការប្រែប្រួលតិចតួចបំផុតក្នុងការបញ្ជូន។

ផ្នែកបន្ទាប់ពិពណ៌នាអំពីជំហានដែលត្រូវបានអនុវត្តកំឡុងពេលដំណើរការកំណត់ពិន្ទុក្រុមសាកល្បង។

ឧបករណ៍

ឧបករណ៍ខាងក្រោមត្រូវបានប្រើដើម្បីដាក់ពង្រាយការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋានយ៉ាងឆាប់រហ័ស បង្កើតបន្ទុក និងវាស់វែងការអនុវត្ត៖

• Banzai Cloud Pipeline សម្រាប់ការរៀបចំ EKS cluster ពី Amazon c Prometheus (ដើម្បីប្រមូល Kafka និងមាត្រដ្ឋានហេដ្ឋារចនាសម្ព័ន្ធ) និង ហ្គ្រេណាណា (ដើម្បីស្រមៃមើលម៉ែត្រទាំងនេះ) ។ យើងបានទាញយកប្រយោជន៍ រួមបញ្ចូលគ្នា в បំពង់បង្ហូរ សេវាកម្មដែលផ្តល់នូវការត្រួតពិនិត្យសហព័ន្ធ ការប្រមូលកំណត់ហេតុកណ្តាល ការស្កេនភាពងាយរងគ្រោះ ការសង្គ្រោះគ្រោះមហន្តរាយ សុវត្ថិភាពកម្រិតសហគ្រាស និងច្រើនទៀត។
• Sangrenel - ឧបករណ៍សម្រាប់ផ្ទុកសាកល្បងចង្កោម Kafka ។
• ផ្ទាំងគ្រប់គ្រង Grafana សម្រាប់ការមើលឃើញម៉ែត្រ Kafka និងហេដ្ឋារចនាសម្ព័ន្ធ៖ Kubernetes Kafka, អ្នកនាំចេញថ្នាំង.
• Supertubes CLI សម្រាប់វិធីងាយស្រួលបំផុតក្នុងការដំឡើងក្រុម Kafka នៅលើ Kubernetes ។ Zookeeper, Kafka operator, Envoy និងសមាសភាគជាច្រើនទៀតត្រូវបានដំឡើង និងកំណត់រចនាសម្ព័ន្ធយ៉ាងត្រឹមត្រូវដើម្បីដំណើរការក្រុម Kafka ដែលត្រៀមរួចជាស្រេចផលិតនៅលើ Kubernetes ។
  • ដើម្បីដំឡើង supertubes CLI ប្រើការណែនាំដែលបានផ្តល់ឱ្យ នៅទីនេះ.

ចង្កោម EKS

រៀបចំចង្កោម EKS ជាមួយនឹងថ្នាំងកម្មករពិសេស c5.4x ធំ នៅក្នុងតំបន់ដែលអាចរកបានផ្សេងៗគ្នាសម្រាប់ផតជាមួយឈ្មួញកណ្តាល Kafka ក៏ដូចជាថ្នាំងដែលឧទ្ទិសសម្រាប់ម៉ាស៊ីនភ្លើងផ្ទុក និងហេដ្ឋារចនាសម្ព័ន្ធត្រួតពិនិត្យ។

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

នៅពេលដែល EKS cluster ដំណើរការហើយ សូមបើកការរួមបញ្ចូលរបស់វា។ សេវាត្រួតពិនិត្យ - នាងនឹងដាក់ពង្រាយ Prometheus និង Grafana ទៅជាចង្កោម។

សមាសធាតុនៃប្រព័ន្ធ Kafka

ដំឡើងសមាសធាតុប្រព័ន្ធ Kafka (Zookeeper, kafka-operator) នៅក្នុង EKS ដោយប្រើ supertubes CLI៖

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ចង្កោម Kafka

តាមលំនាំដើម EKS ប្រើបរិមាណ EBS នៃប្រភេទ gp2ដូច្នេះ អ្នកត្រូវបង្កើតថ្នាក់ផ្ទុកដាច់ដោយឡែក ដោយផ្អែកលើភាគ io1 សម្រាប់ក្រុម Kafka៖

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

កំណត់ប៉ារ៉ាម៉ែត្រសម្រាប់ឈ្មួញកណ្តាល min.insync.replicas=3 និងដាក់ពង្រាយ pods ឈ្មួញកណ្តាលនៅលើថ្នាំងនៅក្នុងតំបន់ដែលមានចំនួនបីផ្សេងគ្នា៖

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

ប្រធានបទ

យើងបានដំណើរការឧទាហរណ៍ម៉ាស៊ីនភ្លើងផ្ទុកចំនួនបីស្របគ្នា។ ពួកគេម្នាក់ៗសរសេរទៅប្រធានបទរៀងៗខ្លួន ពោលគឺយើងត្រូវការប្រធានបទសរុបចំនួនបី៖

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

សម្រាប់ប្រធានបទនីមួយៗ កត្តាចម្លងគឺ 3 - តម្លៃអប្បបរមាដែលបានណែនាំសម្រាប់ប្រព័ន្ធផលិតកម្មដែលមានកម្រិតខ្ពស់។

ផ្ទុកឧបករណ៍បង្កើត

យើងបានបើកដំណើរការច្បាប់ចម្លងចំនួនបីនៃម៉ាស៊ីនភ្លើងផ្ទុក (នីមួយៗបានសរសេរនៅក្នុងប្រធានបទដាច់ដោយឡែក) ។ សម្រាប់ការផ្ទុកផតរបស់ម៉ាស៊ីនភ្លើង អ្នកត្រូវកំណត់ភាពស្និទ្ធស្នាលរបស់ថ្នាំង ដូច្នេះពួកវាត្រូវបានកំណត់ពេលតែនៅលើថ្នាំងដែលបានបែងចែកសម្រាប់ពួកវាប៉ុណ្ណោះ៖

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

ចំណុចមួយចំនួនដែលត្រូវកត់សម្គាល់៖

• ម៉ាស៊ីនបង្កើតបន្ទុកបង្កើតសារដែលមានប្រវែង 512 បៃ ហើយបោះផ្សាយវាទៅ Kafka ជាបាច់នៃ 500 សារ។
• ដោយប្រើអាគុយម៉ង់ -required-acks=all ការបោះពុម្ភផ្សាយត្រូវបានចាត់ទុកថាទទួលបានជោគជ័យនៅពេលដែលការចម្លងសារដែលបានធ្វើសមកាលកម្មទាំងអស់ត្រូវបានទទួល និងបញ្ជាក់ដោយឈ្មួញកណ្តាល Kafka ។ នេះមានន័យថា នៅក្នុងតារាងគោល យើងបានវាស់មិនត្រឹមតែល្បឿននៃអ្នកដឹកនាំទទួលសារប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងអ្នកដើរតាមពួកគេចម្លងសារទៀតផង។ គោលបំណងនៃការធ្វើតេស្តនេះគឺមិនមែនដើម្បីវាយតម្លៃល្បឿនអានរបស់អតិថិជននោះទេ។ (អ្នកប្រើប្រាស់) ថ្មីៗនេះបានទទួលសារដែលនៅតែមាននៅក្នុងឃ្លាំងសម្ងាត់ទំព័រប្រព័ន្ធប្រតិបត្តិការ និងការប្រៀបធៀបរបស់វាជាមួយនឹងល្បឿនអានសារដែលផ្ទុកនៅលើថាស។
• ម៉ាស៊ីនភ្លើងដំណើរការ 20 កម្មករស្របគ្នា (-workers=20) កម្មករនិមួយៗមានអ្នកផលិត 5 នាក់ដែលចែករំលែកទំនាក់ទំនងរបស់កម្មករទៅនឹងក្រុម Kafka ។ ជាលទ្ធផលម៉ាស៊ីនភ្លើងនីមួយៗមានអ្នកផលិត 100 នាក់ ហើយពួកគេទាំងអស់ផ្ញើសារទៅកាន់ចង្កោម Kafka ។

តាមដានសុខភាពរបស់ចង្កោម

កំឡុងពេលធ្វើតេស្តផ្ទុកបន្ទុកនៃចង្កោម Kafka យើងក៏បានត្រួតពិនិត្យសុខភាពរបស់វាផងដែរ ដើម្បីធានាថាមិនមានការចាប់ផ្ដើម pod ឡើងវិញ គ្មានការចម្លងចេញពីការធ្វើសមកាលកម្ម និងលំហូរអតិបរមាជាមួយនឹងការប្រែប្រួលតិចតួចបំផុត៖

• ម៉ាស៊ីនបង្កើតបន្ទុកសរសេរស្ថិតិស្តង់ដារអំពីចំនួនសារដែលបានបោះពុម្ព និងអត្រាកំហុស។ អត្រាកំហុសគួរតែនៅដដែល 0,00%.
• ត្រួត​ពិនិត្យ​ពេល​បើកបរដែលដាក់ពង្រាយដោយ kafka-operator ផ្តល់នូវផ្ទាំងគ្រប់គ្រង ដែលយើងក៏អាចត្រួតពិនិត្យស្ថានភាពនៃចង្កោមបានផងដែរ។ ដើម្បីមើលបន្ទះនេះធ្វើ៖

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• កម្រិត ISR (ចំនួននៃការចម្លង "នៅក្នុងសមកាលកម្ម") បង្រួម និងពង្រីកគឺស្មើនឹង 0 ។

លទ្ធផលវាស់វែង

3 ឈ្មួញកណ្តាល ទំហំសារ - 512 បៃ

ជាមួយនឹងភាគថាសចែកចាយស្មើៗគ្នានៅទូទាំងឈ្មួញកណ្តាលចំនួនបី យើងអាចសម្រេចបាននូវការអនុវត្ត ~ 500 Mb/s (ប្រហែល 990 ពាន់សារក្នុងមួយវិនាទី):

ការប្រើប្រាស់អង្គចងចាំរបស់ម៉ាស៊ីននិម្មិត JVM មិនលើសពី 2 GB៖

លំហូរនៃឌីសបានឈានដល់កម្រិតបញ្ជូនអតិបរមា I/O node លើករណីទាំងបីដែលឈ្មួញកណ្តាលកំពុងដំណើរការ៖

ពីទិន្នន័យលើការប្រើប្រាស់អង្គចងចាំដោយថ្នាំង វាធ្វើតាមថាការបណ្ដោះអាសន្នប្រព័ន្ធ និងឃ្លាំងសម្ងាត់បានយក ~ 10-15 GB៖

3 ឈ្មួញកណ្តាល ទំហំសារ - 100 បៃ

នៅពេលដែលទំហំសារថយចុះ លំហូរចូលធ្លាក់ចុះប្រហែល 15-20%៖ ពេលវេលាដែលបានចំណាយក្នុងដំណើរការសារនីមួយៗប៉ះពាល់ដល់វា។ លើសពីនេះទៀតការផ្ទុករបស់ខួរក្បាលបានកើនឡើងស្ទើរតែទ្វេដង។

ដោយសារថ្នាំងឈ្មួញកណ្តាលនៅតែមានស្នូលដែលមិនបានប្រើ ការអនុវត្តអាចត្រូវបានកែលម្អដោយការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធ Kafka ។ នេះមិនមែនជាកិច្ចការងាយស្រួលនោះទេ ដូច្នេះដើម្បីបង្កើនការបញ្ជូន វាជាការប្រសើរក្នុងការធ្វើការជាមួយសារធំជាង។

4 ឈ្មួញកណ្តាល ទំហំសារ - 512 បៃ

អ្នកអាចបង្កើនការអនុវត្តនៃចង្កោម Kafka បានយ៉ាងងាយស្រួលដោយគ្រាន់តែបន្ថែមឈ្មួញកណ្តាលថ្មី និងរក្សាតុល្យភាពនៃភាគថាស (នេះធានាថាបន្ទុកត្រូវបានចែកចាយស្មើៗគ្នារវាងឈ្មួញកណ្តាល)។ ក្នុងករណីរបស់យើង បន្ទាប់ពីបន្ថែមឈ្មួញកណ្តាល លំហូរនៃចង្កោមបានកើនឡើងដល់ ~580 Mb/s (~1,1 លានសារក្នុងមួយវិនាទី). កំណើននេះបានប្រែទៅជាតិចជាងការរំពឹងទុក: នេះត្រូវបានពន្យល់ជាចម្បងដោយអតុល្យភាពនៃភាគថាស (មិនមែនឈ្មួញកណ្តាលទាំងអស់ធ្វើការនៅកម្រិតកំពូលនៃសមត្ថភាពរបស់ពួកគេទេ)។

ការប្រើប្រាស់អង្គចងចាំរបស់ម៉ាស៊ីន JVM នៅតែទាបជាង 2 GB៖

ការងាររបស់ឈ្មួញកណ្តាលដែលមានដ្រាយត្រូវបានរងផលប៉ះពាល់ដោយអតុល្យភាពនៃភាគថាស:

ការរកឃើញ

វិធីសាស្រ្តដដែលៗដែលបានបង្ហាញខាងលើអាចត្រូវបានពង្រីកដើម្បីគ្របដណ្តប់លើសេណារីយ៉ូស្មុគ្រស្មាញបន្ថែមទៀតដែលពាក់ព័ន្ធនឹងអ្នកប្រើប្រាស់រាប់រយនាក់ ការបែងចែកឡើងវិញ ការអាប់ដេតរំកិល ការចាប់ផ្តើមផតឡើងវិញ។ល។ ទាំងអស់នេះអនុញ្ញាតឱ្យយើងវាយតម្លៃដែនកំណត់នៃសមត្ថភាពរបស់ចង្កោម Kafka ក្នុងលក្ខខណ្ឌផ្សេងៗ កំណត់ការជាប់គាំងនៅក្នុងប្រតិបត្តិការរបស់វា និងស្វែងរកវិធីដើម្បីប្រយុទ្ធប្រឆាំងនឹងពួកគេ។

យើងរចនា Supertubes ដើម្បីដាក់ពង្រាយចង្កោមយ៉ាងងាយស្រួល និងរហ័ស កំណត់រចនាសម្ព័ន្ធវា បន្ថែម/លុបឈ្មួញកណ្តាល និងប្រធានបទ ឆ្លើយតបទៅនឹងការជូនដំណឹង និងធានាថា Kafka ជាទូទៅដំណើរការបានត្រឹមត្រូវនៅលើ Kubernetes ។ គោលដៅរបស់យើងគឺដើម្បីជួយអ្នកផ្តោតលើកិច្ចការចម្បង ("បង្កើត" និង "ប្រើប្រាស់" សារ Kafka) ហើយទុកការខិតខំប្រឹងប្រែងទាំងអស់ទៅ Supertubes និងប្រតិបត្តិករ Kafka ។

ប្រសិនបើអ្នកចាប់អារម្មណ៍លើបច្ចេកវិទ្យា Banzai Cloud និងគម្រោង Open Source សូមចុះឈ្មោះជាមួយក្រុមហ៊ុននៅ GitHub, LinkedIn ឬ Twitter.

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «រឿងមួយជាមួយប្រតិបត្តិករ Redis នៅក្នុង K8s និងការពិនិត្យឡើងវិញខ្នាតតូចអំពីឧបករណ៍ប្រើប្រាស់សម្រាប់ការវិភាគទិន្នន័យពីមូលដ្ឋានទិន្នន័យនេះ»
• «ការធ្វើចំណាកស្រុកដោយរលូននៃ RabbitMQ ទៅ Kubernetes»
• «zetcd ពី CoreOS៖ ការជំនួស ZooKeeper ជាមួយនឹង...etcd storage"។

ប្រភព: www.habr.com