ડિપ્લોય્સને શૂન્ય 502 એરર સુધી કેવી રીતે લાવ્યા

Mythex ના બેકએન્ડને જ્યારે પણ ડિપ્લોય કરતા, ત્યારે થોડી વિનંતીઓ 502 Bad Gateway સાથે નિષ્ફળ જતી. બહુ બધી નહીં — પણ ડિપ્લોય દરમિયાન 502 એટલે કોઈના ક્લિકે કંઈ કર્યું નહીં, અથવા કોઈ બિલ્ડ જોઈ રહ્યું હતું તે ક્ષણભર અટકી ગયું. અમે તેને બે અલગ સમસ્યાઓ સુધી શોધી કાઢી: એક સ્વ-સુધારક વૉચડૉગ જે અમારા ડિપ્લોય્સ સામે લડતો હતો, અને સર્વર સાંભળવાનું બંધ કરે અને લોડ બેલેન્સર તેને ટ્રાફિક મોકલવાનું બંધ કરે તે વચ્ચેનો અંતર. ફિક્સ પછી સતત ત્રણ પ્રોડક્શન ડિપ્લોય્સમાં સંખ્યા 10 થી 6 અને પછી 0 થઈ.

સેટઅપ

અમારા API અને ઓર્કેસ્ટ્રેટર AWS Application Load Balancer (ALB) પાછળ નાના સર્વરોના જૂથ પર કન્ટેનર તરીકે ચાલે છે. ડિપ્લોય એક સમયે એક સર્વર અપડેટ કરે છે: જૂના કન્ટેનર ડ્રેઇન કરે છે, નવા શરૂ કરે છે, અને આગળ વધે છે. દરેક સર્વર પરનો વૉચડૉગ તપાસે છે કે કન્ટેનર ચાલુ છે, અને જે ન ચાલતું હોય તેને ફરી શરૂ કરે છે — જેથી રાત્રે 3 વાગ્યે ક્રેશ થયેલી પ્રક્રિયા કોઈને જગાડ્યા વિના પાછી આવે.

બંને પોતાની રીતે વાજબી છે. સાથે મળીને તે વાજબી નહોતા.

સમસ્યા 1: વૉચડૉગ ડિપ્લોય સામે દોડતો હતો

વૉચડૉગ દર મિનિટે ચાલતો અને એક નિષ્ફળ હેલ્થ ચેક પર "હીલ" કરતો. ડિપ્લોય જાણીજોઈને 150 સેકન્ડ સુધી સર્વિસને ડ્રેઇન કરે છે — તે દરમિયાન હેલ્થ ચેક નિષ્ફળ જવું અપેક્ષિત છે. તેથી વૉચડૉગ દરેક ડિપ્લોય દરમિયાન ચાલી પડતો.

મોટાભાગે તે રેસ હાનિકારક રીતે હારતો. એકવાર તે જીતી ગયો: તેણે ડિપ્લોયની વચ્ચે compose file (કયા કન્ટેનર ચાલવા જોઈએ તેનું વર્ણન) ફરી લખી નાખી, અને સર્વર પર ગેટવે કન્ટેનર બિલકુલ બાકી ન રહ્યો — જ્યારે ડિપ્લોય જૉબે સફળતાની જાણ કરી.

ફિક્સ:

• એક લૉક. ડિપ્લોય હવે સર્વરના bootstrap script જેવો જ ફાઇલ લૉક લે છે, જેથી વૉચડૉગ અને ડિપ્લોય ક્યારેય એકસાથે ન ચાલી શકે.
• ચાર સ્ટ્રાઇક, એક નહીં. વૉચડૉગને કાર્ય કરતા પહેલાં સતત ચાર નિષ્ફળ ચેક જોઈએ. ડ્રેઇન થતી સર્વિસ હવે મૃત જેવી દેખાતી નથી.
• એક વ્યાખ્યા. compose file હવે સર્વર્સ પર પ્રકાશિત થયેલો એક જ સ્ત્રોત છે, નકલો નથી જે અલગ પડી શકે.
• ચકાસો, વિશ્વાસ ન કરો. ડિપ્લોય જૉબ હવે કોઈ આદેશ પરત આવ્યો એટલા માટે પાસ થતી નથી. સફળ થતા પહેલાં તે દરેક સર્વરના API, ઓર્કેસ્ટ્રેટર, ગેટવે અને પબ્લિશ વર્કરને તપાસે છે.

સમસ્યા 2: સર્વર ટ્રાફિક જતા પહેલાં જ નીકળી જતું

બીજી સમસ્યા વધુ શાંત હતી. ડિપ્લોય સર્વરને ડ્રેઇન કરે ત્યારે, સર્વર તેના હેલ્થ એન્ડપોઇન્ટ પર 503 આપવા લાગે છે જેથી લોડ બેલેન્સર તેને રોટેશનમાંથી કાઢી નાખે. અમારું સર્વર આ 5 સેકન્ડ સુધી કરતું, પછી બંધ થઈ જતું.

પરંતુ ALB હેલ્થ ફક્ત અમુક સમયાંતરે તપાસતું, અને કોઈ ટાર્ગેટને રૂટ કરવાનું બંધ કરતા પહેલાં તેને ક્રમિક ઘણા નિષ્ફળ ચેકની જરૂર પડતી — શરૂથી અંત સુધી લગભગ 60 સેકન્ડ સુધી. તેથી લગભગ 55 સેકન્ડ સુધી લોડ બેલેન્સર એવા સર્વરને વાસ્તવિક વિનંતીઓ મોકલતું રહ્યું જે પહેલેથી સાંભળતું બંધ થઈ ગયું હતું. એ અમારા 502 હતા.

ફિક્સ એ હતો કે બે ટાઇમલાઇન્સ મેળ ખાય:

• ટાર્ગેટ ગ્રૂપ હવે દર 5 સેકન્ડે ચેક કરે છે અને 2 નિષ્ફળતા પછી ટાર્ગેટને unhealthy ગણે છે — તેને નોંધવામાં લગભગ 10 સેકન્ડ.
• ડ્રેઇન હેલ્થ ચેક નિષ્ફળ થવા માંડ્યા પછી 15 સેકન્ડ સુધી વાસ્તવિક ટ્રાફિક સેવા આપતું રહે છે, જેથી હંમેશાં ઓવરલેપ રહે.
• આ સેટિંગ્સ કન્સોલમાં કોઈએ એકવાર ક્લિક કરેલી જગ્યાએ નહીં, પણ ઇન્ફ્રાસ્ટ્રક્ચર બનાવતી script માં રહે છે.

નંબરોને એકબીજાને સાચા રાખવા

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

તેથી અમે તે સંબંધો ટેસ્ટ તરીકે લખ્યા: ડ્રેઇન હેલ્થ ચેક અંતરાલ × નિષ્ફળતા થ્રેશોલ્ડ કરતાં લાંબું હોવું જોઈએ; ફરીથી healthy ગણાવામાં લાગતો સમય ટૂંકો રહેવો જોઈએ; આખું ડ્રેઇન કન્ટેનરના stop grace period ની અંદર બેસવું જોઈએ. એક નંબર બદલો અને બીજા ન બદલો, તો CI નિષ્ફળ જાય છે. અમે ટેસ્ટ્સને પોતાને પણ mutation-test કર્યા — દરેક નંબર ખોટી કિંમતે બદલ્યો અને ચકાસ્યું કે ટેસ્ટ તેને પકડે છે.

ડિપ્લોય માપવું સહેલાઈથી ખોટું થાય છે

અમારું પહેલું માપ કહેતું કે સ્વચ્છ ડિપ્લોય લગભગ 3% તૂટેલો છે. એવું નહોતું. અમે દરેક બિન-200 પ્રતિસાદ ગણતા હતા, અને ડ્રેઇન દરમિયાન હેલ્થ એન્ડપોઇન્ટ પરથી આવેલું 503 નિષ્ફળતા નથી — તે ડ્રેઇન પોતાનું કામ કરી રહ્યું છે, લોડ બેલેન્સરને કહી રહ્યું છે કે તે સર્વરને પસંદ ન કરે જ્યારે તે હજી વાસ્તવિક વિનંતીઓ સેવા આપી રહ્યું છે.

વપરાશકર્તા જે અનુભવે છે તે 502 છે: વિનંતી કંઈ સુધી પહોંચી નહીં. ફક્ત તેને ગણવાથી સાચું ચિત્ર મળ્યું — ત્રણ પ્રોડક્શન ડિપ્લોય્સમાં 10, પછી 6, પછી 0.

અમે શું શીખ્યા

• સ્વ-સુધારણાને આયોજિત ડાઉનટાઇમની ખબર હોવી જોઈએ. જે વૉચડૉગ ડિપ્લોય અને ક્રેશ વચ્ચે ફરક ન પાડી શકે તે આખરે ડિપ્લોય સામે લડશે.
• ડ્રેઇનિંગ એક હેન્ડશેક છે. લોડ બેલેન્સરે સાબિત રીતે ટ્રાફિક મોકલવાનું બંધ કર્યું ત્યાં સુધી સર્વરે સેવા આપતા રહેવું જોઈએ, અને તે સમય સર્વર પર નહીં, બેલેન્સર પર સેટ થાય છે.
• ઇન્વેરિયન્ટ્સને ટેસ્ટ તરીકે એન્કોડ કરો. ઓપરેશનલ નંબર્સ બદલાય છે. તેમને એકબીજા સાથે જોડતા ટેસ્ટ નથી બદલાતા.
• માપતા પહેલાં નક્કી કરો કે શું માપવું છે. "ભૂલો" ખોટો મેટ્રિક હતો; "જે વિનંતીઓ કંઈ સુધી પહોંચી નહીં" સાચો મેટ્રિક હતો.

જો તમે Mythex પર એપ પબ્લિશ કરો છો, તો આમાંનું કંઈ તમને દેખાતું નથી — અને તે જ મુદ્દો છે. સંબંધિત: તમારી પબ્લિશ થયેલી એપ ફરી પબ્લિશ થતી વખતે કેવી રીતે ચાલુ રહે છે.