કુબરનેટીસમાં કાફકા ક્લસ્ટર માટે યોગ્ય કદ નક્કી કરવું

નૉૅધ. અનુવાદ: આ લેખમાં, Banzai ક્લાઉડ તેના કસ્ટમ ટૂલ્સનો ઉપયોગ કેવી રીતે કરી શકાય છે તેનું ઉદાહરણ કફકાને કુબરનેટીસમાં વાપરવાનું સરળ બનાવે છે. નીચેની સૂચનાઓ સમજાવે છે કે તમે તમારા ઈન્ફ્રાસ્ટ્રક્ચરનું શ્રેષ્ઠ કદ કેવી રીતે નક્કી કરી શકો છો અને જરૂરી થ્રુપુટ હાંસલ કરવા માટે કાફકાને જ રૂપરેખાંકિત કરી શકો છો.

Apache Kafka એ વિશ્વસનીય, માપી શકાય તેવી અને ઉચ્ચ-પ્રદર્શન રીઅલ-ટાઇમ સ્ટ્રીમિંગ સિસ્ટમ્સ બનાવવા માટે વિતરિત સ્ટ્રીમિંગ પ્લેટફોર્મ છે. તેની પ્રભાવશાળી ક્ષમતાઓને કુબરનેટ્સનો ઉપયોગ કરીને વિસ્તૃત કરી શકાય છે. આ માટે અમે વિકાસ કર્યો છે ઓપન સોર્સ કાફકા ઓપરેટર અને એક સાધન કહેવાય છે સુપરટ્યુબ્સ. તેઓ તમને કુબરનેટ્સ પર કાફકા ચલાવવા અને તેની વિવિધ સુવિધાઓનો ઉપયોગ કરવાની મંજૂરી આપે છે, જેમ કે બ્રોકર કન્ફિગરેશનને ફાઇન-ટ્યુનિંગ, રિબેલેન્સિંગ સાથે મેટ્રિક-આધારિત સ્કેલિંગ, રેક અવેરનેસ, "સોફ્ટ" (ઉપયોગી) અપડેટ્સ રોલ આઉટ, વગેરે.

તમારા ક્લસ્ટરમાં સુપરટ્યુબ અજમાવો:

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

અથવા સંપર્ક કરો દસ્તાવેજીકરણ. તમે કાફકાની કેટલીક ક્ષમતાઓ વિશે પણ વાંચી શકો છો, જેની સાથે કામ સુપરટ્યુબ અને કાફકા ઓપરેટરનો ઉપયોગ કરીને સ્વચાલિત છે. અમે તેમના વિશે બ્લોગ પર પહેલેથી જ લખ્યું છે:

• અરે નહિ! કુબરનેટસ માટે અન્ય કાફકા ઓપરેટર;
• પ્રોમિથિયસ મેટ્રિક્સના આધારે કાફકાનું નિરીક્ષણ અને સંચાલન કરો;
• કુબરનેટ્સ પર કાફકા રેક જાગૃતિ;
• Istio - બેન્ચમાર્ક ઉપર અપાચે કાફકા ચલાવી રહ્યા છે;
• કાફકા ઓપરેટર સાથે વપરાશકર્તા પ્રમાણિત અને ઍક્સેસ નિયંત્રિત ક્લસ્ટરો;
• કાફકા રોલિંગ અપગ્રેડ અને કુબરનેટ્સ પર ગતિશીલ ગોઠવણી;
• કાફકા માટે દૂત પ્રોટોકોલ ફિલ્ટર, મેશેડ.

જ્યારે તમે કુબરનેટ્સ પર કાફકા ક્લસ્ટરને જમાવવાનું નક્કી કરો છો, ત્યારે તમને સંભવતઃ અંતર્ગત ઈન્ફ્રાસ્ટ્રક્ચરનું શ્રેષ્ઠ કદ નક્કી કરવાના પડકારનો સામનો કરવો પડશે અને થ્રુપુટ જરૂરિયાતોને પહોંચી વળવા માટે તમારા કાફકા રૂપરેખાંકનને ફાઇન-ટ્યુન કરવાની જરૂરિયાતનો સામનો કરવો પડશે. દરેક બ્રોકરનું મહત્તમ પ્રદર્શન અંતર્ગત માળખાકીય ઘટકો જેમ કે મેમરી, પ્રોસેસર, ડિસ્ક સ્પીડ, નેટવર્ક બેન્ડવિડ્થ વગેરેના પ્રભાવ દ્વારા નક્કી કરવામાં આવે છે.

આદર્શરીતે, બ્રોકર રૂપરેખાંકન એવું હોવું જોઈએ કે તમામ ઈન્ફ્રાસ્ટ્રક્ચર તત્વો તેમની મહત્તમ ક્ષમતાઓ માટે ઉપયોગમાં લેવાય. જો કે, વાસ્તવિક જીવનમાં આ સેટઅપ ખૂબ જટિલ છે. તે વધુ સંભવ છે કે વપરાશકર્તાઓ એક અથવા બે ઘટકો (ડિસ્ક, મેમરી અથવા પ્રોસેસર) નો મહત્તમ ઉપયોગ કરવા માટે બ્રોકર્સને ગોઠવશે. સામાન્ય રીતે કહીએ તો, બ્રોકર મહત્તમ કામગીરી દર્શાવે છે જ્યારે તેનું રૂપરેખાંકન સૌથી ધીમા ઘટકને તેની સંપૂર્ણ હદ સુધી ઉપયોગમાં લેવાની મંજૂરી આપે છે. આ રીતે આપણે એક બ્રોકર હેન્ડલ કરી શકે તેવા લોડનો રફ આઈડિયા મેળવી શકીએ છીએ.

સૈદ્ધાંતિક રીતે, અમે આપેલ લોડને હેન્ડલ કરવા માટે જરૂરી બ્રોકરોની સંખ્યાનો પણ અંદાજ લગાવી શકીએ છીએ. જો કે, વ્યવહારમાં વિવિધ સ્તરો પર ઘણા બધા રૂપરેખાંકન વિકલ્પો છે કે ચોક્કસ રૂપરેખાંકનની સંભવિત કામગીરીનું મૂલ્યાંકન કરવું ખૂબ જ મુશ્કેલ (જો અશક્ય ન હોય તો) છે. બીજા શબ્દોમાં કહીએ તો, આપેલ કામગીરીના આધારે રૂપરેખાંકનનું આયોજન કરવું ખૂબ જ મુશ્કેલ છે.

સુપરટ્યુબ યુઝર્સ માટે, અમે સામાન્ય રીતે નીચેનો અભિગમ અપનાવીએ છીએ: અમે અમુક રૂપરેખાંકન (ઇન્ફ્રાસ્ટ્રક્ચર + સેટિંગ્સ) સાથે પ્રારંભ કરીએ છીએ, પછી તેનું પ્રદર્શન માપીએ છીએ, બ્રોકર સેટિંગ્સને સમાયોજિત કરીએ છીએ અને પ્રક્રિયાને ફરીથી પુનરાવર્તન કરીએ છીએ. જ્યાં સુધી ઈન્ફ્રાસ્ટ્રક્ચરના સૌથી ધીમા ઘટકનો સંપૂર્ણ ઉપયોગ ન થાય ત્યાં સુધી આવું થાય છે.

આ રીતે, અમને સ્પષ્ટ ખ્યાલ આવે છે કે ક્લસ્ટરને ચોક્કસ લોડને હેન્ડલ કરવા માટે કેટલા બ્રોકર્સની જરૂર છે (દલાલોની સંખ્યા અન્ય પરિબળો પર પણ આધાર રાખે છે, જેમ કે સ્થિતિસ્થાપકતાને સુનિશ્ચિત કરવા માટે સંદેશની પ્રતિકૃતિઓની ન્યૂનતમ સંખ્યા, પાર્ટીશનની સંખ્યા. નેતાઓ, વગેરે). વધુમાં, અમે ઇન્ફ્રાસ્ટ્રક્ચર ઘટકોને વર્ટિકલ સ્કેલિંગની જરૂર છે તેની સમજ મેળવીએ છીએ.

આ લેખ પ્રારંભિક રૂપરેખાંકનોમાં સૌથી ધીમા ઘટકોમાંથી સૌથી વધુ મેળવવા અને કાફકા ક્લસ્ટરના થ્રુપુટને માપવા માટે અમે જે પગલાં લઈએ છીએ તેના વિશે વાત કરશે. અત્યંત સ્થિતિસ્થાપક રૂપરેખાંકન માટે ઓછામાં ઓછા ત્રણ ચાલતા દલાલોની જરૂર છે (min.insync.replicas=3), ત્રણ અલગ અલગ ઍક્સેસિબિલિટી ઝોનમાં વિતરિત. કુબરનેટ્સ ઈન્ફ્રાસ્ટ્રક્ચરને ગોઠવવા, માપવા અને મોનિટર કરવા માટે, અમે હાઇબ્રિડ ક્લાઉડ્સ માટે અમારા પોતાના કન્ટેનર મેનેજમેન્ટ પ્લેટફોર્મનો ઉપયોગ કરીએ છીએ - પાઇપલાઇન. તે ઓન-પ્રિમાઈસ (બેર મેટલ, વીએમવેર) અને પાંચ પ્રકારના વાદળો (અલીબાબા, AWS, Azure, Google, Oracle) તેમજ તેમના કોઈપણ સંયોજનને સપોર્ટ કરે છે.

કાફકા ક્લસ્ટર ઈન્ફ્રાસ્ટ્રક્ચર અને રૂપરેખાંકન પર વિચારો

નીચેના ઉદાહરણો માટે, અમે ક્લાઉડ પ્રદાતા તરીકે AWS અને Kubernetes વિતરણ તરીકે EKS પસંદ કર્યું છે. સમાન રૂપરેખાંકનનો ઉપયોગ કરીને અમલ કરી શકાય છે પી.કે.ઇ. - CNCF દ્વારા પ્રમાણિત, Banzai ક્લાઉડ તરફથી કુબરનેટ્સનું વિતરણ.

ડિસ્ક

એમેઝોન વિવિધ ઓફર કરે છે EBS વોલ્યુમ પ્રકારો. મૂળમાં gpxNUMX и io1 જો કે, ઉચ્ચ થ્રુપુટની ખાતરી કરવા માટે ત્યાં SSD ડ્રાઈવો છે gpxNUMX સંચિત ક્રેડિટ વાપરે છે (I/O ક્રેડિટ્સ), તેથી અમે પ્રકાર પસંદ કર્યો io1, જે સતત ઉચ્ચ થ્રુપુટ ઓફર કરે છે.

દાખલાના પ્રકારો

કાફકાનું પ્રદર્શન ઓપરેટિંગ સિસ્ટમના પેજ કેશ પર ખૂબ જ નિર્ભર છે, તેથી અમને બ્રોકર્સ (JVM) અને પેજ કેશ માટે પૂરતી મેમરી સાથેના દાખલાઓની જરૂર છે. દાખલો c5.2xમોટો - સારી શરૂઆત, કારણ કે તેમાં 16 GB મેમરી છે અને EBS સાથે કામ કરવા માટે ઑપ્ટિમાઇઝ. તેનો ગેરલાભ એ છે કે તે દર 30 કલાકમાં માત્ર 24 મિનિટથી વધુ સમય માટે મહત્તમ પ્રદર્શન પ્રદાન કરવામાં સક્ષમ છે. જો તમારા વર્કલોડને લાંબા સમય સુધી પીક પરફોર્મન્સની જરૂર હોય, તો તમે અન્ય ઉદાહરણ પ્રકારો પર વિચાર કરી શકો છો. તે બરાબર છે કે અમે શું કર્યું, અંતે બંધ c5.4xમોટો. તે મહત્તમ થ્રુપુટ પ્રદાન કરે છે 593,75 Mb/s. EBS વોલ્યુમનું મહત્તમ થ્રુપુટ io1 દાખલા કરતા વધારે c5.4xમોટો, તેથી ઇન્ફ્રાસ્ટ્રક્ચરનું સૌથી ધીમું તત્વ આ ઇન્સ્ટન્સ પ્રકારનું I/O થ્રુપુટ હોવાની શક્યતા છે (જે અમારા લોડ પરીક્ષણોએ પણ પુષ્ટિ કરવી જોઈએ).

નેટવર્ક

નેટવર્ક થ્રુપુટ VM ઇન્સ્ટન્સ અને ડિસ્કના પ્રદર્શનની તુલનામાં પૂરતું મોટું હોવું જોઈએ, અન્યથા નેટવર્ક અડચણ બની જાય છે. અમારા કિસ્સામાં, નેટવર્ક ઇન્ટરફેસ c5.4xમોટો 10 Gb/s સુધીની ઝડપને સપોર્ટ કરે છે, જે VM ઇન્સ્ટન્સના I/O થ્રુપુટ કરતાં નોંધપાત્ર રીતે વધારે છે.

બ્રોકર જમાવટ

CPU, મેમરી, નેટવર્ક અને ડિસ્ક સંસાધનો માટે અન્ય પ્રક્રિયાઓ સાથે સ્પર્ધા કરવાનું ટાળવા માટે બ્રોકર્સને સમર્પિત નોડ્સ પર (કુબરનેટ્સમાં સુનિશ્ચિત) તૈનાત કરવા જોઈએ.

જાવા સંસ્કરણ

તાર્કિક પસંદગી Java 11 છે કારણ કે તે ડોકર સાથે સુસંગત છે તે અર્થમાં કે JVM જે કન્ટેનરમાં બ્રોકર ચાલી રહ્યું છે તેના માટે ઉપલબ્ધ પ્રોસેસર્સ અને મેમરીને યોગ્ય રીતે નક્કી કરે છે. CPU મર્યાદા મહત્વપૂર્ણ છે તે જાણીને, JVM આંતરિક અને પારદર્શક રીતે GC થ્રેડો અને JIT થ્રેડોની સંખ્યા સેટ કરે છે. અમે કાફકા ઇમેજનો ઉપયોગ કર્યો banzaicloud/kafka:2.13-2.4.0, જેમાં Java 2.4.0 પર કાફકા વર્ઝન 2.13 (સ્કેલા 11)નો સમાવેશ થાય છે.

જો તમે કુબરનેટ્સ પર Java/JVM વિશે વધુ જાણવા માંગતા હો, તો અમારી નીચેની પોસ્ટ્સ તપાસો:

• શા માટે મારી Java એપ્લિકેશન OOMKilled છે;
• Java 10 એપ્લિકેશન માટે કન્ટેનરનું કદ યોગ્ય રીતે કેવી રીતે કરવું.

બ્રોકર મેમરી સેટિંગ્સ

બ્રોકર મેમરીને રૂપરેખાંકિત કરવા માટે બે મુખ્ય પાસાઓ છે: JVM અને કુબરનેટ્સ પોડ માટે સેટિંગ્સ. પોડ માટે સેટ કરેલી મેમરી મર્યાદા મહત્તમ ઢગલા કદ કરતાં મોટી હોવી જોઈએ જેથી JVM પાસે જાવા મેટાસ્પેસ માટે જગ્યા હોય, જે તેની પોતાની મેમરીમાં રહે છે અને ઓપરેટિંગ સિસ્ટમ પેજ કેશ માટે, જેનો કાફકા સક્રિયપણે ઉપયોગ કરે છે. અમારા પરીક્ષણોમાં અમે પેરામીટર્સ સાથે કાફકા બ્રોકર્સ લોન્ચ કર્યા છે -Xmx4G -Xms2G, અને પોડ માટે મેમરી મર્યાદા હતી 10 Gi. મહેરબાની કરીને નોંધ કરો કે JVM માટે મેમરી સેટિંગ્સનો ઉપયોગ કરીને આપમેળે મેળવી શકાય છે -XX:MaxRAMPercentage и -X:MinRAMPercentage, પોડ માટે મેમરી મર્યાદા પર આધારિત છે.

બ્રોકર પ્રોસેસર સેટિંગ્સ

સામાન્ય રીતે કહીએ તો, તમે કાફકા દ્વારા ઉપયોગમાં લેવાતા થ્રેડોની સંખ્યામાં વધારો કરીને સમાનતા વધારીને પ્રદર્શનમાં સુધારો કરી શકો છો. કાફકા માટે જેટલા વધુ પ્રોસેસર્સ ઉપલબ્ધ છે, તેટલા વધુ સારા. અમારા પરીક્ષણમાં, અમે 6 પ્રોસેસર્સની મર્યાદા સાથે શરૂઆત કરી અને ધીમે ધીમે (પુનરાવર્તન દ્વારા) તેમની સંખ્યા વધારીને 15 કરી. વધુમાં, અમે સેટ num.network.threads=12 નેટવર્કમાંથી ડેટા મેળવતા અને તેને મોકલતા થ્રેડોની સંખ્યા વધારવા માટે બ્રોકર સેટિંગ્સમાં. તરત જ શોધ્યું કે અનુયાયી દલાલો ઝડપથી પ્રતિકૃતિઓ પ્રાપ્ત કરી શકતા નથી, તેઓએ ઉભા કર્યા num.replica.fetchers ફોલોઅર બ્રોકર્સ નેતાઓના સંદેશાઓની નકલ કરે છે તે ઝડપ વધારવા માટે 4.

લોડ જનરેશન ટૂલ

તમારે સુનિશ્ચિત કરવું જોઈએ કે કાફકા ક્લસ્ટર (જે બેન્ચમાર્ક કરવામાં આવી રહ્યું છે) તેના મહત્તમ લોડ સુધી પહોંચે તે પહેલાં પસંદ કરેલ લોડ જનરેટરની ક્ષમતા સમાપ્ત થઈ ન જાય. બીજા શબ્દોમાં કહીએ તો, લોડ જનરેશન ટૂલની ક્ષમતાઓનું પ્રારંભિક મૂલ્યાંકન કરવું જરૂરી છે, અને તેના માટે પૂરતા પ્રમાણમાં પ્રોસેસર્સ અને મેમરી સાથે ઉદાહરણ પ્રકારો પણ પસંદ કરવા. આ કિસ્સામાં, અમારું સાધન કાફકા ક્લસ્ટર હેન્ડલ કરી શકે તે કરતાં વધુ ભાર ઉત્પન્ન કરશે. ઘણા પ્રયોગો પછી, અમે ત્રણ નકલો પર સ્થાયી થયા c5.4xમોટો, જેમાંના દરેકમાં જનરેટર ચાલતું હતું.

બેન્ચમાર્કિંગ

પ્રદર્શન માપન એ પુનરાવર્તિત પ્રક્રિયા છે જેમાં નીચેના તબક્કાઓ શામેલ છે:

• ઈન્ફ્રાસ્ટ્રક્ચર સેટ કરવું (EKS ક્લસ્ટર, કાફકા ક્લસ્ટર, લોડ જનરેશન ટૂલ, તેમજ પ્રોમિથિયસ અને ગ્રાફના);
• એકત્રિત પ્રદર્શન સૂચકાંકોમાં રેન્ડમ વિચલનોને ફિલ્ટર કરવા માટે ચોક્કસ સમયગાળા માટે લોડ જનરેટ કરવું;
• અવલોકન કરેલ પ્રદર્શન સૂચકાંકોના આધારે બ્રોકરના ઈન્ફ્રાસ્ટ્રક્ચર અને રૂપરેખાંકનને સમાયોજિત કરવું;
• જ્યાં સુધી કાફકા ક્લસ્ટર થ્રુપુટનું જરૂરી સ્તર પ્રાપ્ત ન થાય ત્યાં સુધી પ્રક્રિયાનું પુનરાવર્તન કરો. તે જ સમયે, તે સતત પુનઃઉત્પાદનક્ષમ હોવું જોઈએ અને થ્રુપુટમાં ન્યૂનતમ ભિન્નતા દર્શાવવી જોઈએ.

આગળનો વિભાગ પરીક્ષણ ક્લસ્ટર બેન્ચમાર્કિંગ પ્રક્રિયા દરમિયાન કરવામાં આવેલા પગલાંઓનું વર્ણન કરે છે.

સાધનો

નીચેના ટૂલ્સનો ઉપયોગ બેઝલાઇન રૂપરેખાંકનને ઝડપથી જમાવવા, લોડ જનરેટ કરવા અને પ્રભાવ માપવા માટે કરવામાં આવ્યો હતો:

• Banzai મેઘ પાઇપલાઇન એમેઝોન સીમાંથી EKS ક્લસ્ટરનું આયોજન કરવા માટે પ્રોમિથિયસ (કાફકા અને ઈન્ફ્રાસ્ટ્રક્ચર મેટ્રિક્સ એકત્રિત કરવા) અને ગ્રાફના (આ મેટ્રિક્સની કલ્પના કરવા માટે). અમે લાભ લીધો સંકલિત в પાઇપલાઇન સેવાઓ કે જે ફેડરેટેડ મોનિટરિંગ, સેન્ટ્રલાઈઝ લોગ કલેક્શન, નબળાઈ સ્કેનિંગ, ડિઝાસ્ટર રિકવરી, એન્ટરપ્રાઈઝ-ગ્રેડ સુરક્ષા અને ઘણું બધું પ્રદાન કરે છે.
• સંગ્રેનલ - કાફકા ક્લસ્ટરને લોડ કરવા માટેનું એક સાધન.
• કાફકા મેટ્રિક્સ અને ઈન્ફ્રાસ્ટ્રક્ચરને વિઝ્યુઅલાઈઝ કરવા માટે ગ્રાફના ડેશબોર્ડ્સ: કુબરનેટસ કાફકા, નોડ નિકાસકાર.
• Kubernetes પર કાફકા ક્લસ્ટર સેટ કરવાની સૌથી સરળ રીત માટે સુપરટ્યુબ CLI. ઝૂકીપર, કાફકા ઓપરેટર, દૂત અને અન્ય ઘણા ઘટકો કુબરનેટ્સ પર ઉત્પાદન-તૈયાર કાફકા ક્લસ્ટર ચલાવવા માટે સ્થાપિત અને યોગ્ય રીતે ગોઠવેલ છે.
  • સ્થાપન માટે સુપરટ્યુબ CLI આપેલ સૂચનાઓનો ઉપયોગ કરો અહીં.

EKS ક્લસ્ટર

સમર્પિત વર્કર નોડ્સ સાથે EKS ક્લસ્ટર તૈયાર કરો c5.4xમોટો કાફકા બ્રોકર્સ સાથે પોડ્સ માટે વિવિધ પ્રાપ્યતા ઝોનમાં, તેમજ લોડ જનરેટર અને મોનિટરિંગ ઈન્ફ્રાસ્ટ્રક્ચર માટે સમર્પિત નોડ્સ.

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

એકવાર EKS ક્લસ્ટર તૈયાર થઈ જાય અને ચાલુ થઈ જાય, તેના સંકલિતને સક્ષમ કરો મોનીટરીંગ સેવા - તે પ્રોમિથિયસ અને ગ્રાફનાને ક્લસ્ટરમાં જમાવશે.

કાફકા સિસ્ટમ ઘટકો

સુપરટ્યુબ CLI નો ઉપયોગ કરીને EKS માં કાફકા સિસ્ટમ ઘટકો (ઝૂકીપર, કાફકા-ઓપરેટર) ઇન્સ્ટોલ કરો:

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

કાફકા ક્લસ્ટર

મૂળભૂત રીતે, EKS EBS પ્રકારનો ઉપયોગ કરે છે gpxNUMX, તેથી તમારે વોલ્યુમના આધારે અલગ સ્ટોરેજ ક્લાસ બનાવવાની જરૂર છે io1 કાફકા ક્લસ્ટર માટે:

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 અને ત્રણ અલગ-અલગ ઉપલબ્ધતા ઝોનમાં નોડ્સ પર બ્રોકર પોડ્સનો ઉપયોગ કરો:

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 બાઇટ્સ લંબાઈના સંદેશાઓ જનરેટ કરે છે અને 500 સંદેશાઓના બેચમાં કાફકાને પ્રકાશિત કરે છે.
• દલીલનો ઉપયોગ કરીને -required-acks=all કાફકા બ્રોકર્સ દ્વારા સંદેશની તમામ સિંક્રનાઇઝ્ડ પ્રતિકૃતિઓ પ્રાપ્ત થાય અને તેની પુષ્ટિ કરવામાં આવે ત્યારે પ્રકાશન સફળ માનવામાં આવે છે. આનો અર્થ એ છે કે બેન્ચમાર્કમાં અમે માત્ર સંદેશા પ્રાપ્ત કરનારા નેતાઓની ગતિ જ નહીં, પણ તેમના અનુયાયીઓ સંદેશાઓની નકલ કરતા પણ માપ્યા હતા. આ પરીક્ષણનો હેતુ ઉપભોક્તા વાંચવાની ઝડપનું મૂલ્યાંકન કરવાનો નથી (ગ્રાહકો) તાજેતરમાં પ્રાપ્ત થયેલા સંદેશાઓ કે જે હજુ પણ OS પૃષ્ઠ કેશમાં રહે છે, અને ડિસ્ક પર સંગ્રહિત સંદેશાઓની વાંચન ઝડપ સાથે તેની સરખામણી.
• લોડ જનરેટર 20 કામદારોને સમાંતર ચલાવે છે (-workers=20). દરેક કાર્યકરમાં 5 ઉત્પાદકો હોય છે જે કાફકા ક્લસ્ટર સાથે કામદારનું જોડાણ વહેંચે છે. પરિણામે, દરેક જનરેટરમાં 100 ઉત્પાદકો હોય છે, અને તેઓ બધા કાફકા ક્લસ્ટરને સંદેશા મોકલે છે.

ક્લસ્ટરના આરોગ્યની દેખરેખ

કાફકા ક્લસ્ટરના લોડ પરીક્ષણ દરમિયાન, અમે કોઈ પોડ પુનઃપ્રારંભ, કોઈ આઉટ-ઓફ-સિંક પ્રતિકૃતિઓ અને ન્યૂનતમ વધઘટ સાથે મહત્તમ થ્રુપુટ નથી તેની ખાતરી કરવા માટે તેના સ્વાસ્થ્યનું પણ નિરીક્ષણ કર્યું:

• લોડ જનરેટર પ્રકાશિત થયેલા સંદેશાઓની સંખ્યા અને ભૂલ દર વિશે પ્રમાણભૂત આંકડા લખે છે. ભૂલ દર એ જ રહેવો જોઈએ 0,00%.
• ક્રુઝ નિયંત્રણ, કાફકા-ઓપરેટર દ્વારા તૈનાત, ડેશબોર્ડ પ્રદાન કરે છે જ્યાં અમે ક્લસ્ટરની સ્થિતિનું પણ નિરીક્ષણ કરી શકીએ છીએ. આ પેનલ જોવા માટે આ કરો:

  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 નોડ થ્રુપુટ સુધી પહોંચ્યું કે જેના પર બ્રોકર્સ ચાલી રહ્યા હતા:

નોડ્સ દ્વારા મેમરી વપરાશ પરના ડેટા પરથી, તે અનુસરે છે કે સિસ્ટમ બફરિંગ અને કેશીંગમાં ~10-15 GBનો સમય લાગ્યો:

3 બ્રોકર્સ, સંદેશનું કદ - 100 બાઇટ્સ

જેમ જેમ સંદેશનું કદ ઘટે છે તેમ, થ્રુપુટ લગભગ 15-20% ઘટે છે: દરેક સંદેશની પ્રક્રિયા કરવામાં વિતાવેલો સમય તેને અસર કરે છે. વધુમાં, પ્રોસેસર લોડ લગભગ બમણો થઈ ગયો છે.

બ્રોકર નોડ્સમાં હજુ પણ બિનઉપયોગી કોરો હોવાથી, કાફકા રૂપરેખાંકન બદલીને કામગીરી બહેતર બનાવી શકાય છે. આ એક સરળ કાર્ય નથી, તેથી થ્રુપુટ વધારવા માટે મોટા સંદેશાઓ સાથે કામ કરવું વધુ સારું છે.

4 બ્રોકર્સ, સંદેશનું કદ - 512 બાઇટ્સ

તમે ફક્ત નવા બ્રોકર્સ ઉમેરીને અને પાર્ટીશનોનું સંતુલન જાળવીને કાફકા ક્લસ્ટરનું પ્રદર્શન સરળતાથી વધારી શકો છો (આ ખાતરી કરે છે કે લોડ બ્રોકરો વચ્ચે સમાનરૂપે વિતરિત થાય છે). અમારા કિસ્સામાં, બ્રોકર ઉમેર્યા પછી, ક્લસ્ટર થ્રુપુટમાં વધારો થયો ~580 Mb/s (~1,1 મિલિયન સંદેશા પ્રતિ સેકન્ડ). વૃદ્ધિ અપેક્ષા કરતા ઓછી હોવાનું બહાર આવ્યું છે: આ મુખ્યત્વે પાર્ટીશનોના અસંતુલન દ્વારા સમજાવવામાં આવે છે (બધા દલાલો તેમની ક્ષમતાઓની ટોચ પર કામ કરતા નથી).

JVM મશીનનો મેમરી વપરાશ 2 GB ની નીચે રહ્યો:

પાર્ટીશનોના અસંતુલનથી ડ્રાઇવ સાથે દલાલોનું કામ પ્રભાવિત થયું હતું:

તારણો

સેંકડો ઉપભોક્તાઓ, પુનઃવિભાગીકરણ, રોલિંગ અપડેટ્સ, પોડ પુનઃપ્રારંભ વગેરેને સમાવતા વધુ જટિલ દૃશ્યોને આવરી લેવા માટે ઉપર પ્રસ્તુત પુનરાવર્તિત અભિગમને વિસ્તૃત કરી શકાય છે. આ બધું અમને વિવિધ પરિસ્થિતિઓમાં કાફકા ક્લસ્ટરની ક્ષમતાઓની મર્યાદાઓનું મૂલ્યાંકન કરવા, તેની કામગીરીમાં અવરોધોને ઓળખવા અને તેનો સામનો કરવાની રીતો શોધવાની મંજૂરી આપે છે.

અમે ક્લસ્ટરને ઝડપથી અને સરળતાથી ગોઠવવા, તેને ગોઠવવા, બ્રોકર્સ અને વિષયો ઉમેરવા/દૂર કરવા, ચેતવણીઓને પ્રતિસાદ આપવા અને સામાન્ય રીતે કાફકા કુબરનેટ્સ પર યોગ્ય રીતે કામ કરે તેની ખાતરી કરવા માટે અમે સુપરટ્યૂબ્સ ડિઝાઇન કર્યા છે. અમારો ધ્યેય તમને મુખ્ય કાર્ય પર ધ્યાન કેન્દ્રિત કરવામાં મદદ કરવાનો છે (કાફકા સંદેશાઓ "જનરેટ કરો" અને "ઉપયોગ કરો"), અને તમામ સખત મહેનત સુપરટ્યુબ્સ અને કાફકા ઑપરેટર પર છોડી દો.

જો તમને Banzai ક્લાઉડ ટેક્નોલોજી અને ઓપન સોર્સ પ્રોજેક્ટ્સમાં રસ હોય, તો કંપનીમાં સબ્સ્ક્રાઇબ કરો GitHub, LinkedIn અથવા Twitter.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «K8s માં Redis ઑપરેટર સાથેની એક વાર્તા અને આ ડેટાબેઝમાંથી ડેટાનું પૃથ્થકરણ કરવા માટે ઉપયોગિતાઓની મીની-સમીક્ષા»;
• «RabbitMQ નું કુબરનેટ્સમાં સીમલેસ સ્થળાંતર»;
• «CoreOS માંથી zetcd: ZooKeeper ને...etcd સ્ટોરેજ સાથે બદલવું».

સોર્સ: www.habr.com