සියල්ල හොඳයි!
මගේ නම නිකිටා, මම Cian ඉංජිනේරු කණ්ඩායමේ කණ්ඩායම් නායකයා. ආයතනයේ මගේ වගකීමක් වන්නේ නිෂ්පාදනයේ යටිතල පහසුකම් සම්බන්ධ සිදුවීම් ගණන බිංදුවට අඩු කිරීමයි.
පහත සාකච්ඡා කරනු ලබන දේ අපට බොහෝ වේදනාවක් ගෙන දුන් අතර, මෙම ලිපියේ අරමුණ වන්නේ අනෙක් පුද්ගලයින් අපගේ වැරදි නැවත කිරීමෙන් වැළැක්වීම හෝ අවම වශයෙන් ඔවුන්ගේ බලපෑම අවම කිරීමයි.
පූර්විකාව
බොහෝ කලකට පෙර, Cian මොනොලිත් වලින් සමන්විත වූ විට සහ තවමත් ක්ෂුද්‍ර සේවා පිළිබඳ ඉඟියක් නොතිබූ විට, අපි පිටු 3-5 ක් පරීක්ෂා කිරීමෙන් සම්පතක ඇති බව මැනිය.
ඔවුන් පිළිතුරු දෙයි - සියල්ල හොඳයි, ඔවුන් දිගු වේලාවක් පිළිතුරු නොදෙන්නේ නම් - අවදියෙන්. එය සිදුවීමක් ලෙස සැලකීම සඳහා ඔවුන් කොපමණ කාලයක් රැකියාවෙන් ඉවත්ව සිටිය යුතුද යන්න රැස්වීම්වලදී මිනිසුන් විසින් තීරණය කරන ලදී. සිද්ධිය පිළිබඳ පරීක්ෂණ සඳහා සෑම විටම ඉංජිනේරුවන් කණ්ඩායමක් සම්බන්ධ විය. විමර්ශනය අවසන් වූ විට, ඔවුන් පශ්චාත් මරණ පරීක්ෂණයක් ලිවීය - ආකෘතියෙන් විද්‍යුත් තැපෑලෙන් වාර්තාවක්: සිදු වූ දේ, එය කොපමණ කාලයක් පැවතුනි, මේ මොහොතේ අප කළ දේ, අනාගතයේදී අප කරන්නේ කුමක්ද.
වෙබ් අඩවියේ ප්‍රධාන පිටු හෝ අපි පහළට ගොස් ඇති බව අප තේරුම් ගන්නා ආකාරය
දෝෂයේ ප්‍රමුඛතාවය කෙසේ හෝ අවබෝධ කර ගැනීම සඳහා, අපි ව්‍යාපාර ක්‍රියාකාරීත්වය සඳහා වඩාත් තීරණාත්මක අඩවි පිටු හඳුනාගෙන ඇත. ඒවා භාවිතා කරමින්, අපි සාර්ථක/අසාර්ථක ඉල්ලීම් සහ කල් ඉකුත්වීම් ගණන ගණන් කරමු. අපි වැඩ කරන කාලය මනින්නේ මෙහෙමයි.
වෙබ් අඩවියේ ප්‍රධාන සේවාව සඳහා වගකිව යුතු සුපිරි-වැදගත් කොටස් ගණනාවක් ඇති බව අපි කියමු - දැන්වීම් සෙවීම සහ ඉදිරිපත් කිරීම. අසාර්ථක වන ඉල්ලීම් ගණන 1% ඉක්මවන්නේ නම්, මෙය තීරණාත්මක සිදුවීමකි. ප්‍රධාන කාලය තුළ මිනිත්තු 15 ක් ඇතුළත දෝෂ අනුපාතය 0,1% ඉක්මවන්නේ නම්, මෙය ද තීරණාත්මක සිදුවීමක් ලෙස සැලකේ. මෙම නිර්ණායක බොහෝ සිදුවීම් ආවරණය කරයි; ඉතිරිය මෙම ලිපියේ විෂය පථයෙන් ඔබ්බට ය.
ඉහළම හොඳම සිදුවීම් Cian
එබැවින්, සිදුවීමක් සිදු වූ බව නිශ්චය කිරීමට අපි නියත වශයෙන්ම ඉගෙන ගෙන ඇත.
දැන් සෑම සිදුවීමක්ම විස්තරාත්මකව විස්තර කර ඇති අතර ජිරා වීර කාව්‍යයේ පිළිබිඹු වේ. මාර්ගය වන විට: මේ සඳහා අපි වෙනම ව්‍යාපෘතියක් ආරම්භ කළෙමු, එය FAIL ලෙස හැඳින්වේ - එහි නිර්මාණය කළ හැක්කේ වීර කාව්‍ය පමණි.
පසුගිය වසර කිහිපය තුළ ඔබ සියලු අසාර්ථකත්වයන් එකතු කරන්නේ නම්, නායකයින් වන්නේ:
- mssql සම්බන්ධ සිදුවීම්;
- බාහිර සාධක නිසා ඇතිවන සිදුවීම්;
- පරිපාලක දෝෂ.
පරිපාලකයින්ගේ වැරදි මෙන්ම තවත් රසවත් අසාර්ථකත්වයන් පිළිබඳව වඩාත් විස්තරාත්මකව බලමු.
පස්වන ස්ථානය - "DNS හි දේවල් පිළිවෙලට තැබීම"
එය කුණාටු සහිත අඟහරුවාදා දිනයක් විය. DNS පොකුරේ අනුපිළිවෙල නැවත ස්ථාපිත කිරීමට අපි තීරණය කළා.
මට අවශ්‍ය වූයේ අභ්‍යන්තර DNS සේවාදායකයන් bind සිට powerdns වෙත මාරු කිරීමටයි, මේ සඳහා සම්පූර්ණයෙන්ම වෙනම සේවාදායකයන් වෙන් කිරීම, DNS හැර වෙනත් කිසිවක් නොමැති තැන.
අපි අපගේ DCs වල සෑම ස්ථානයකම එක් DNS සේවාදායකයක් තැබූ අතර, කලාප බැඳීමේ සිට powerdns වෙත ගෙන යාමට සහ යටිතල පහසුකම් නව සේවාදායකයන් වෙත මාරු කිරීමට මොහොත පැමිණ ඇත.
චලනය මධ්‍යයේ, සියලුම සේවාදායකයන් මත දේශීය හැඹිලි බන්ධනවල නිශ්චිතව දක්වා ඇති සියලුම සේවාදායකයන්ගෙන්, ශාන්ත පීටර්ස්බර්ග් හි දත්ත මධ්‍යස්ථානයේ තිබූ එකක් පමණක් ඉතිරි විය. මෙම DC මුලින් අපට විවේචනාත්මක නොවන බව ප්‍රකාශ කරන ලද නමුත් හදිසියේම අසාර්ථක වීමේ තනි ලක්ෂ්‍යයක් බවට පත්විය.
මොස්කව් සහ ශාන්ත පීටර්ස්බර්ග් අතර ඇළ කඩා වැටුණේ මෙම නැවත ස්ථානගත කිරීමේ කාලය තුළ ය. අපි ඇත්තටම මිනිත්තු පහක් DNS නොමැතිව සිටි අතර සත්කාරක සමාගම ගැටලුව විසඳූ විට නැවත නැගිට්ටෙමු.
නිගමන:
මීට පෙර අපි වැඩ සඳහා සූදානම් වීමේදී බාහිර සාධක නොසලකා හැරියේ නම්, දැන් ඒවා අප සූදානම් වන දේ ලැයිස්තුවට ඇතුළත් කර ඇත. දැන් අපි සියලුම සංරචක n-2 වෙන් කර ඇති බව සහතික කිරීමට උත්සාහ කරන්නෙමු, කාර්යය අතරතුර අපට මෙම මට්ටම n-1 දක්වා අඩු කළ හැකිය.
- ක්‍රියාකාරී සැලැස්මක් සකස් කිරීමේදී, සේවාව අසාර්ථක විය හැකි ස්ථාන සලකුණු කර, සෑම දෙයක්ම “නරක සිට නරක අතට” ගිය අවස්ථාවක් ගැන කල්තියා සිතන්න.
- විවිධ භූ ස්ථාන/දත්ත මධ්‍යස්ථාන/රාක්ක/ස්විච/ආදාන හරහා අභ්‍යන්තර DNS සේවාදායකයන් බෙදාහරින්න.
- සෑම සේවාදායකයකම, දේශීය හැඹිලි DNS සේවාදායකයක් ස්ථාපනය කරන්න, එය ඉල්ලීම් ප්‍රධාන DNS සේවාදායකයන් වෙත හරවා යවන අතර, එය නොමැති නම්, එය හැඹිලියෙන් ප්‍රතිචාර දක්වයි.
හතරවන ස්ථානය - "Nginx හි දේවල් පිරිසිදු කිරීම"
එක් හොඳ දවසක්, අපගේ කණ්ඩායම තීරණය කළේ “අපට මෙය ප්‍රමාණවත්” බවයි, සහ nginx වින්‍යාසයන් ප්‍රතිනිර්මාණය කිරීමේ ක්‍රියාවලිය ආරම්භ විය. ප්‍රධාන ඉලක්කය වන්නේ වින්‍යාසයන් අවබෝධාත්මක ව්‍යුහයකට ගෙන ඒමයි. මීට පෙර, සෑම දෙයක්ම "ඓතිහාසිකව ස්ථාපිත" වූ අතර කිසිදු තර්කයක් ගෙන ගියේ නැත. දැන් සෑම server_name එකක්ම එකම නමින් ගොනුවකට ගෙන ගොස් ඇති අතර සියලුම වින්‍යාසයන් ෆෝල්ඩර වලට බෙදා හැර ඇත. මාර්ගය වන විට, වින්‍යාසය රේඛා 253949 ක් හෝ අක්ෂර 7836520 ක් අඩංගු වන අතර මෙගාබයිට් 7 ක් පමණ ගත වේ. ව්යුහයේ ඉහළම මට්ටම:
Nginx ව්යුහය
├── access
│ ├── allow.list
...
│ └── whitelist.conf
├── geobase
│ ├── exclude.conf
...
│ └── geo_ip_to_region_id.conf
├── geodb
│ ├── GeoIP.dat
│ ├── GeoIP2-Country.mmdb
│ └── GeoLiteCity.dat
├── inc
│ ├── error.inc
...
│ └── proxy.inc
├── lists.d
│ ├── bot.conf
...
│ ├── dynamic
│ └── geo.conf
├── lua
│ ├── cookie.lua
│ ├── log
│ │ └── log.lua
│ ├── logics
│ │ ├── include.lua
│ │ ├── ...
│ │ └── utils.lua
│ └── prom
│ ├── stats.lua
│ └── stats_prometheus.lua
├── map.d
│ ├── access.conf
│ ├── ..
│ └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│ ├── cian.ru
│ │ ├── cian.ru.conf
│ │ ├── ...
│ │ └── my.cian.ru.conf
├── service.d
│ ├── ...
│ └── status.conf
└── upstream.d
├── cian-mcs.conf
├── ...
└── wafserver.confඑය වඩා හොඳ විය, නමුත් වින්‍යාසය නැවත නම් කිරීම සහ බෙදා හැරීමේ ක්‍රියාවලියේදී, ඒවායින් සමහරක් වැරදි දිගුවක් ඇති අතර ඇතුළත් *.conf විධානයට ඇතුළත් කර නොමැත. එහි ප්‍රතිඵලයක් වශයෙන්, සමහර සත්කාරකයන් නොමැති වූ අතර 301 ප්‍රධාන පිටුව වෙත ආපසු ලබා දෙන ලදී. ප්‍රතිචාර කේතය 5xx/4xx නොවීම නිසා මෙය ක්ෂණිකව අවධානයට ලක් නොවූ නමුත් උදෑසන පමණි. ඊට පස්සේ, අපි යටිතල පහසුකම් සංරචක පරීක්ෂා කිරීම සඳහා පරීක්ෂණ ලිවීමට පටන් ගත්තා.
නිගමන:
- ඔබේ වින්‍යාසය නිවැරදිව ව්‍යුහගත කරන්න (nginx පමණක් නොව) සහ ව්‍යාපෘතියේ මුල් අවධියේදී ව්යුහය ගැන සිතන්න. මේ ආකාරයෙන් ඔබ ඔවුන් කණ්ඩායමට වඩාත් තේරුම් ගත හැකි වනු ඇත, එය TTM අඩු කරනු ඇත.
- සමහර යටිතල පහසුකම් සංරචක සඳහා පරීක්ෂණ ලියන්න. උදාහරණයක් ලෙස: සියලුම ප්‍රධාන සේවාදායක_නම් නිවැරදි තත්ත්‍වය + ප්‍රතිචාර ශරීරය ලබා දෙන බව පරීක්ෂා කිරීම. අලුයම 3 ට වියරුවෙන් මතක තබා නොගැනීම සඳහා, සංරචකයේ මූලික කාර්යයන් පරීක්ෂා කරන ස්ක්‍රිප්ට් කිහිපයක් අතේ තිබීම පමණක් ප්‍රමාණවත් වනු ඇත.
තෙවන ස්ථානය - "හදිසියේම කැසැන්ඩ්‍රා හි ඉඩ නැති වී ගියේය"
දත්ත ක්රමයෙන් වර්ධනය වූ අතර, කැසැන්ඩ්‍රා පොකුරේ විශාල කේස් අවකාශ අළුත්වැඩියා කිරීම අසාර්ථක වීමට පටන් ගන්නා මොහොත දක්වා සියල්ල හොඳින් පැවතුනි, මන්ද ඒවා සංයුක්ත කිරීම ක්රියා කළ නොහැකි බැවිනි.
එක් කුණාටු සහිත දිනක පොකුර පාහේ වට්ටක්කා බවට පත් විය, එනම්:
- පොකුරේ ඉතිරිව ඇති මුළු ඉඩ ප්රමාණයෙන් 20% ක් පමණ විය;
- කොටස්වල ඉඩ නොමැතිකම නිසා නෝඩයක් එකතු කිරීමෙන් පසු පිරිසිදු කිරීම සිදු නොවන නිසා නෝඩ් සම්පූර්ණයෙන්ම එකතු කළ නොහැක;
- සංයුක්ත කිරීම ක්රියා නොකරන බැවින් ඵලදායිතාව ක්රමයෙන් පහත වැටේ;
- පොකුර හදිසි මාදිලියේ ඇත.
පිටවීම - අපි පිරිසිදු කිරීමකින් තොරව තවත් නෝඩ් 5 ක් එකතු කළෙමු, ඉන්පසු අපි ඒවා ක්‍රමානුකූලව පොකුරෙන් ඉවත් කර නැවත ඇතුල් කිරීමට පටන් ගත්තෙමු, ඉඩ නොමැති හිස් නෝඩ් මෙන්. අපි කැමති ප්‍රමාණයට වඩා වැඩි කාලයක් ගත කළා. පොකුර අර්ධ වශයෙන් හෝ සම්පූර්ණයෙන් නොලැබීමේ අවදානමක් පැවතුනි.
නිගමන:
- සියලුම cassandra සේවාදායකයන් මත, එක් එක් කොටසෙහි ඉඩ ප්රමාණයෙන් 60% කට වඩා වැඩි නොවිය යුතුය.
- ඒවා 50% cpu ට නොඅඩු ලෙස පැටවිය යුතුය.
- ධාරිතාව සැලසුම් කිරීම ගැන ඔබ අමතක නොකළ යුතු අතර එහි විශේෂතා මත පදනම්ව එක් එක් සංරචක සඳහා එය සිතා බැලිය යුතුය.
- පොකුරේ වැඩි නෝඩ්, වඩා හොඳය. කුඩා දත්ත ප්‍රමාණයක් අඩංගු සේවාදායකයන් වේගයෙන් අධික ලෙස පටවනු ලබන අතර එවැනි පොකුරක් නැවත පණ ගැන්වීමට පහසුය.
දෙවන ස්ථානය - "කොන්සල් යතුරු-අගය ගබඩාවෙන් දත්ත අතුරුදහන් විය"
සේවා සොයා ගැනීම සඳහා, අපි, බොහෝ අය මෙන්, කොන්සල් භාවිතා කරන්නෙමු. නමුත් අපි ඒකලිතයේ නිල්-කොළ සැකැස්ම සඳහා එහි ප්‍රධාන අගය ද භාවිතා කරමු. එය යෙදවීමේදී ස්ථාන වෙනස් කරන සක්‍රීය සහ අක්‍රිය උඩුගං පිළිබඳ තොරතුරු ගබඩා කරයි. මෙම කාර්යය සඳහා, KV සමඟ අන්තර්ක්‍රියා කරන යෙදවුම් සේවාවක් ලියා ඇත. යම් අවස්ථාවක දී, KV වෙතින් දත්ත අතුරුදහන් විය. මතකයෙන් ප්‍රතිසාධනය කර ඇත, නමුත් දෝෂ ගණනාවක් සමඟ. එහි ප්‍රතිඵලයක් ලෙස, උඩුගත කිරීමේදී, උඩුගත කිරීම් මත පැටවීම අසමාන ලෙස බෙදී ගිය අතර, CPU මත බැක්එන්ඩ් අධික ලෙස පැටවීම හේතුවෙන් අපට බොහෝ දෝෂ 502ක් ලැබිණි. එහි ප්‍රතිඵලයක් වශයෙන්, අපි කොන්සල් KV සිට postgres වෙත මාරු කළෙමු, එතැනින් ඒවා ඉවත් කිරීම එතරම් පහසු නැත.
නිගමන:
- කිසිදු අවසරයකින් තොරව සේවාවන් වෙබ් අඩවියේ ක්‍රියාකාරිත්වයට වැදගත් දත්ත අඩංගු නොවිය යුතුය. උදාහරණයක් ලෙස, ඔබට ES හි අවසරයක් නොමැති නම්, අවශ්‍ය නොවන සෑම තැනකම ජාල මට්ටමින් ප්‍රවේශය ප්‍රතික්ෂේප කිරීම වඩා හොඳය, අවශ්‍ය ඒවා පමණක් තබන්න, සහ action.destructive_requires_name: true.
- ඔබේ උපස්ථ සහ ප්‍රතිසාධන යාන්ත්‍රණය කල්තියා පුහුණු කරන්න. උදාහරණයක් ලෙස, උපස්ථ සහ ප්‍රතිසාධනය කළ හැකි ස්ක්‍රිප්ට් එකක් කල්තියා සාදන්න (උදාහරණයක් ලෙස, python හි).
පළමු ස්ථානය - "කැප්ටන් නොපැහැදිලි"
යම් අවස්ථාවක, පසු අන්තයේ 10+ සේවාදායකයන් ඇති අවස්ථා වලදී nginx උඩුගත කිරීම් මත අසමාන බර බෙදා හැරීමක් අපි දුටුවෙමු. round-robin විසින් 1 වන සිට අවසාන upstream දක්වා ඉල්ලීම් යැවීම සහ සෑම nginx නැවත පූරණය නැවත ආරම්භ කිරීමත් නිසා, පළමු upstreams වලට සෑම විටම අනෙක් ඒවාට වඩා වැඩි ඉල්ලීම් ලැබුණි.එම නිසා, ඔවුන් මන්දගාමීව ක්රියා කළ අතර මුළු වෙබ් අඩවියම පීඩාවට පත් විය. වාහන තදබදය වැඩි වීමත් සමඟ මෙය වැඩි වැඩියෙන් කැපී පෙනුණි. සසම්භාවී සක්‍රීය කිරීම සඳහා nginx යාවත්කාලීන කිරීම ක්රියා කළේ නැත - අපට 1.15 අනුවාදය (ඒ මොහොතේ) ආරම්භ නොවූ lua කේතයක් නැවත කළ යුතුය. අපට අපගේ nginx 1.14.2 පැච් කිරීමට සිදු විය, එයට අහඹු සහය හඳුන්වා දීම. මෙම ගැටළුව විසඳා ඇත. මෙම දෝෂය "කැප්ටන් නොපැහැදිලි" කාණ්ඩය දිනා ගනී.
නිගමන:
මෙම දෝෂය ගවේෂණය කිරීම ඉතා සිත්ගන්නාසුළු හා උද්යෝගිමත් විය).
- එවැනි උච්චාවචනයන් ඉක්මනින් සොයා ගැනීමට ඔබට උපකාර වන පරිදි ඔබේ අධීක්ෂණය සංවිධානය කරන්න. උදාහරණයක් ලෙස, ඔබට ELK භාවිතා කර එක් එක් upstream හි එක් එක් පසු අන්තය මත rps නිරීක්ෂණය කිරීමට, nginx හි දෘෂ්ටිකෝණයෙන් ඔවුන්ගේ ප්‍රතිචාර කාලය නිරීක්ෂණය කිරීමට හැකිය. මෙම අවස්ථාවේ දී, මෙය අපට ගැටලුව හඳුනා ගැනීමට උපකාරී විය.
එහි ප්‍රතිඵලයක් වශයෙන්, ඔබ කරමින් සිටින දෙයට වඩා සූක්ෂම ප්‍රවේශයකින් බොහෝ අසාර්ථකත්වයන් වළක්වා ගත හැකිව තිබුණි. අපි හැම විටම මර්ෆිගේ නීතිය මතක තබා ගත යුතුය: වැරදි විය හැකි ඕනෑම දෙයක් වැරදි වනු ඇත, සහ එය මත පදනම්ව සංරචක ගොඩනැගීම.
මූලාශ්රය: www.habr.com