හැමෝටම ආයුබෝවන්, මගේ නම ඇලෙක්සැන්ඩර්, මම CIAN හි ඉංජිනේරුවෙකු ලෙස සේවය කරන අතර පද්ධති පරිපාලනය සහ යටිතල පහසුකම් ක්‍රියාවලීන් ස්වයංක්‍රීයකරණයට සම්බන්ධ වෙමි. කලින් ලිපිවල එකකට කමෙන්ට් වලදී, අපි දිනකට 4 TB ලොග් ලබා ගන්නේ කොහෙන්ද සහ අපි ඒවායින් කරන්නේ කුමක්දැයි පවසන ලෙස ඉල්ලා සිටියෙමු. ඔව්, අප සතුව ලඝු-සටහන් රාශියක් ඇති අතර, ඒවා සැකසීම සඳහා වෙනම යටිතල පහසුකම් පොකුරක් නිර්මාණය කර ඇති අතර එමඟින් ගැටළු ඉක්මනින් විසඳීමට අපට ඉඩ සලසයි. දිනෙන් දින වර්ධනය වන දත්ත ප්‍රවාහයක් සමඟ වැඩ කිරීමට වසරක් පුරාවට අපි එය අනුවර්තනය කළ ආකාරය ගැන මෙම ලිපියෙන් මම කතා කරමි.
අපි පටන් ගත්තේ කොහෙන්ද?
පසුගිය වසර කිහිපය තුළ, cian.ru හි බර ඉතා ඉක්මණින් වර්ධනය වී ඇති අතර, 2018 තුන්වන කාර්තුව වන විට සම්පත් ගමනාගමනය මසකට අද්විතීය පරිශීලකයින් මිලියන 11.2 දක්වා ළඟා විය. එකල, තීරණාත්මක අවස්ථාවන්හිදී, අපට ලඝු-සටහන් වලින් 40% ක් දක්වා අහිමි විය, එම නිසා අපට සිදුවීම් සමඟ ඉක්මනින් කටයුතු කිරීමට නොහැකි වූ අතර ඒවා විසඳීමට බොහෝ කාලයක් හා වෑයමක් දැරීය. අපට බොහෝ විට ගැටලුවට හේතුව සොයා ගැනීමට නොහැකි වූ අතර එය ටික වේලාවකට පසු නැවත සිදු වේ. එය අපායක් වූ අතර ඒ සඳහා යමක් කළ යුතුව තිබුණි.
එම අවස්ථාවේදී, අපි ලොග් ගබඩා කිරීම සඳහා සම්මත දර්ශක සැකසුම් සහිත ElasticSearch අනුවාදය 10 සමඟ දත්ත නෝඩ් 5.5.2 ක පොකුරක් භාවිතා කළෙමු. එය ජනප්‍රිය සහ දැරිය හැකි විසඳුමක් ලෙස මීට වසරකට පෙර හඳුන්වා දෙන ලදී: එවිට ලොග් ගලායාම එතරම් විශාල නොවීය, සම්මත නොවන වින්‍යාසයන් ඉදිරිපත් කිරීමේ තේරුමක් නැත.
එන ලොග් සැකසීම ElasticSearch සම්බන්ධීකාරක පහක් මත විවිධ වරායන් මත Logstash විසින් සපයන ලදී. එක් දර්ශකයක්, විශාලත්වය නොසලකා, කොටස් පහකින් සමන්විත විය. පැයකට සහ දෛනික භ්‍රමණයක් සංවිධානය කරන ලද අතර එහි ප්රතිඵලයක් ලෙස සෑම පැයකටම නව කැබලි 100 ක් පමණ පොකුරේ දිස් විය. බොහෝ ලඝු-සටහන් නොතිබුණද, පොකුර හොඳින් මුහුණ දුන් අතර කිසිවෙකු එහි සැකසුම් කෙරෙහි අවධානය යොමු කළේ නැත.
වේගවත් වර්ධනයේ අභියෝග
ක්‍රියාවලි දෙකක් එකිනෙක අතිච්ඡාදනය වීම නිසා ජනනය කරන ලද ලොග පරිමාව ඉතා ඉක්මනින් වර්ධනය විය. එක් අතකින්, සේවාව භාවිතා කරන්නන් සංඛ්යාව වර්ධනය විය. අනෙක් අතට, අපි C# සහ Python හි අපගේ පැරණි ඒකලිතයන් දක්වා ක්‍රියාකාරීව ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයකට මාරු වීමට පටන් ගත්තෙමු. මොනොලිත් කොටස් ප්‍රතිස්ථාපනය කරන ලද නව ක්ෂුද්‍ර සේවා දුසිම් කිහිපයක් යටිතල පහසුකම් පොකුර සඳහා සැලකිය යුතු ලෙස වැඩි ලඝු ජනනය කරන ලදී.
පර්ෂදය ප්‍රායෝගිකව පාලනය කළ නොහැකි තැනට අපව ගෙන ගියේ පරිමාණයෙනි. තත්පරයට පණිවිඩ 20 ක වේගයකින් ලඝු-සටහන් පැමිණීමට පටන් ගත් විට, නිතර නිතර නිෂ්ඵල කරකැවීම කැබලි ගණන 6 දහස දක්වා වැඩි කළ අතර, නෝඩයකට කැබලි 600 කට වඩා වැඩි විය.
මෙය RAM බෙදා හැරීමේ ගැටළු වලට තුඩු දුන් අතර, නෝඩයක් කඩා වැටුණු විට, සියලුම කොටස් එකවර චලනය වීමට පටන් ගත් අතර, ගමනාගමනය ගුණ කිරීම සහ අනෙකුත් නෝඩ් පැටවීම, එමඟින් පොකුරට දත්ත ලිවීමට නොහැකි විය. තවද මෙම කාල පරිච්ෙඡ්දය තුළ අපට ලොග් නොමැතිව ඉතිරි විය. තවද සේවාදායකයේ ගැටලුවක් තිබේ නම්, අපට මූලික වශයෙන් පොකුරෙන් 1/10 ක් අහිමි විය. කුඩා දර්ශක විශාල සංඛ්යාවක් සංකීර්ණත්වය එකතු කරන ලදී.
ලඝු-සටහන් නොමැතිව, සිදුවීමට හේතු අපට නොතේරුණු අතර ඉක්මනින් හෝ පසුව නැවතත් එම පෝරකයට නැඟිය හැකි අතර, අපගේ කණ්ඩායමේ දෘෂ්ටිවාදය තුළ මෙය පිළිගත නොහැකි විය, මන්ද අපගේ සියලු වැඩ යාන්ත්‍රණයන් ප්‍රතිවිරුද්ධ දෙය කිරීමට සැලසුම් කර ඇති බැවිනි - කිසි විටෙකත් නැවත නොකරන්න එකම ගැටළු. මෙය සිදු කිරීම සඳහා, රාජකාරියේ යෙදී සිටින ඉංජිනේරුවන් කණ්ඩායමක් ප්‍රමිතික වලින් පමණක් නොව, ලඝු-සටහන් වලින් ද ඇඟවීම් නිරීක්ෂණය කළ බැවින්, අපට සම්පූර්ණ ලඝු පරිමාව සහ ඒවා තත්‍ය වේලාවට බෙදා හැරීම අවශ්‍ය විය. ගැටලුවේ පරිමාණය තේරුම් ගැනීමට, එකල මුළු ලොග් පරිමාව දිනකට 2 TB පමණ විය.
ලඝු-සටහන් නැතිවීම සම්පූර්ණයෙන්ම ඉවත් කිරීමට සහ බල මජයර් අතරතුර ඒවා ELK පොකුරට බෙදා හැරීමේ කාලය උපරිම මිනිත්තු 15 දක්වා අඩු කිරීමට අපි ඉලක්කයක් තැබුවෙමු (අපි පසුව අභ්‍යන්තර KPI ලෙස මෙම අගය මත විශ්වාසය තැබුවෙමු).
නව භ්රමණ යාන්ත්රණය සහ උණුසුම් උණුසුම් නෝඩ්
ElasticSearch අනුවාදය 5.5.2 සිට 6.4.3 දක්වා යාවත්කාලීන කිරීමෙන් අපි පොකුරු පරිවර්තනය ආරම්භ කළෙමු. නැවත වරක් අපගේ අනුවාදය 5 පොකුර මිය ගිය අතර, අපි එය නිවා දැමීමට සහ සම්පූර්ණයෙන්ම යාවත්කාලීන කිරීමට තීරණය කළෙමු - තවමත් ලඝු-සටහන් නොමැත. ඉතින් අපි පැය කිහිපයකින් මේ සංක්‍රමණය කළා.
මෙම අදියරේ දී වඩාත්ම විශාල පරිමාණ පරිවර්තනය වූයේ අතරමැදි බෆරයක් ලෙස සම්බන්ධීකාරකයක් සහිත නෝඩ් තුනක Apache Kafka ක්රියාත්මක කිරීමයි. පණිවිඩ තැරැව්කරු ElasticSearch සමඟ ඇති ගැටළු වලදී ලොග් අහිමි වීමෙන් අපව බේරා ගත්තේය. ඒ අතරම, අපි පොකුරට නෝඩ් 2 ක් එකතු කර දත්ත මධ්යස්ථානයේ විවිධ රාක්කවල පිහිටා ඇති "උණුසුම්" නෝඩ් තුනක් සහිත උණුසුම්-උණුසුම් ගෘහ නිර්මාණ ශිල්පයකට මාරු විය. කිසිදු තත්වයක් යටතේ නැති නොවිය යුතු වෙස් මුහුණක් භාවිතා කරමින් අපි ඔවුන් වෙත ලොග හරවා යැව්වෙමු - nginx, මෙන්ම යෙදුම් දෝෂ ලොග. කුඩා ලඝු-සටහන් ඉතිරි නෝඩ් වෙත යවන ලදි - නිදොස්කරණය, අනතුරු ඇඟවීම, ආදිය, සහ පැය 24 කට පසු, "උණුසුම්" නෝඩ් වලින් "වැදගත්" ලොග් මාරු කරන ලදී.
කුඩා දර්ශක සංඛ්යාව වැඩි නොකිරීමට, අපි කාල භ්රමණයෙන් පෙරළීමේ යාන්ත්රණය වෙත මාරු විය. දර්ශක ප්‍රමාණයෙන් භ්‍රමණය ඉතා විශ්වාස කළ නොහැකි බව සංසදවල බොහෝ තොරතුරු තිබුණි, එබැවින් අපි දර්ශකයේ ලේඛන ගණන අනුව භ්‍රමණය භාවිතා කිරීමට තීරණය කළෙමු. අපි එක් එක් දර්ශකය විශ්ලේෂණය කර භ්‍රමණය ක්‍රියා කළ යුතු ලේඛන ගණන සටහන් කළෙමු. මේ අනුව, අපි ප්‍රශස්ත ෂාර්ඩ් ප්‍රමාණයට ළඟා වී ඇත - 50 GB ට වඩා වැඩි නොවේ.
පොකුරු ප්රශස්තකරණය
කෙසේ වෙතත්, අපි සම්පූර්ණයෙන්ම ගැටළු වලින් මිදුනේ නැත. අවාසනාවකට මෙන්, කුඩා දර්ශක තවමත් දර්ශනය විය: ඒවා නිශ්චිත පරිමාවට ළඟා නොවීය, කරකැවී නැත, සහ දින තුනකට වඩා පැරණි දර්ශක ගෝලීය පිරිසිදු කිරීම මගින් මකා දමන ලදී, මන්ද අපි දිනය අනුව භ්‍රමණය ඉවත් කළෙමු. මෙය පොකුරෙන් දර්ශකය සම්පූර්ණයෙන්ම අතුරුදහන් වීම නිසා දත්ත අහිමි වීමට හේතු විය, සහ නොපවතින දර්ශකයකට ලිවීමට උත්සාහ කිරීම කළමනාකරණය සඳහා අප භාවිතා කළ භාරකරුගේ තර්කනය බිඳ දැමීය. ලිවීම සඳහා වූ අන්වර්ථය දර්ශකයක් බවට පරිවර්තනය කර පෙරළීමේ තර්කනය බිඳ දැමූ අතර සමහර දර්ශකවල පාලනයකින් තොරව 600 GB දක්වා වර්ධනය විය.
උදාහරණයක් ලෙස, භ්රමණ වින්‍යාසය සඳහා:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
පෙරළීමේ අන්වර්ථයක් නොතිබුනේ නම්, දෝෂයක් සිදු විය:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
අපි මීළඟ පුනරාවර්තනය සඳහා මෙම ගැටලුවට විසඳුම අත්හැර වෙනත් ගැටලුවක් භාර ගත්තෙමු: අපි එන ලොග් (අනවශ්‍ය තොරතුරු ඉවත් කිරීම සහ පොහොසත් කිරීම) සකසන Logstash හි ඇදීමේ තර්කනය වෙත මාරු විය. අපි එය docker හි තැබුවෙමු, එය අපි docker-compose හරහා දියත් කළෙමු, තවද අපි logstash-exporter ද එහි තැබුවෙමු, එය log stream හි මෙහෙයුම් අධීක්ෂණය සඳහා Prometheus වෙත ප්‍රමිතික යවයි. මේ ආකාරයට එක් එක් වර්ගයේ ලොග් සැකසීම සඳහා වගකිව යුතු ලොග්ස්ටාෂ් අවස්ථා ගණන සුමට ලෙස වෙනස් කිරීමට අපි අපටම අවස්ථාව ලබා දුන්නෙමු.
අපි පොකුර වැඩිදියුණු කරන අතරතුර, cian.ru හි ගමනාගමනය මසකට අද්විතීය පරිශීලකයින් මිලියන 12,8 දක්වා වැඩි විය. එහි ප්‍රති result ලයක් වශයෙන්, අපගේ පරිවර්තනයන් නිෂ්පාදනයේ වෙනස්කම් වලට වඩා ටිකක් පිටුපසින් ඇති බව පෙනී ගිය අතර, “උණුසුම්” නෝඩ් වලට බර සමඟ සාර්ථකව කටයුතු කිරීමට නොහැකි වූ අතර ලොග් සම්පූර්ණ බෙදා හැරීම මන්දගාමී වීම අපට මුහුණ දීමට සිදු විය. අපට අසාර්ථකත්වයකින් තොරව “උණුසුම්” දත්ත ලැබුණි, නමුත් ඉතිරිය බෙදා හැරීමට මැදිහත් වීමට සහ දර්ශක ඒකාකාරව බෙදා හැරීම සඳහා අතින් පෙරළීමක් කිරීමට අපට සිදු විය.
ඒ අතරම, පොකුරේ ලොග්ස්ටැෂ් අවස්ථා වල සැකසුම් පරිමාණය කිරීම සහ වෙනස් කිරීම එය දේශීය ඩොකර්-රචනයක් වීම නිසා සංකීර්ණ වූ අතර සියලුම ක්‍රියා අතින් සිදු කරන ලදී (නව කෙළවර එකතු කිරීම සඳහා, සියල්ල අතින්ම යා යුතුය. සේවාදායකයන් සහ docker-compose up -d සෑම තැනකම කරන්න).
ලොග් නැවත බෙදා හැරීම
මේ වසරේ සැප්තැම්බර් මාසයේදී, අපි තවමත් මොනොලිත් කපා දමමින් සිටියෙමු, පොකුරේ බර වැඩි වෙමින් පැවතුනි, සහ ලොග් ගලායාම තත්පරයට පණිවිඩ 30 ට ළඟා විය.
දෘඪාංග යාවත්කාලීන කිරීමකින් අපි ඊළඟ පුනරාවර්තනය ආරම්භ කළෙමු. අපි සම්බන්ධීකාරකවරුන් පස් දෙනෙකුගෙන් තුනකට මාරු වී, දත්ත නෝඩ් ප්‍රතිස්ථාපනය කර මුදල් සහ ගබඩා ඉඩ ප්‍රමාණය අනුව ජයග්‍රහණය කළෙමු. නෝඩ් සඳහා අපි වින්යාස දෙකක් භාවිතා කරමු:
- "උණුසුම්" නෝඩ් සඳහා: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 සඳහා 1 සහ Hot3 සඳහා 2).
- "උණුසුම්" නෝඩ් සඳහා: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
මෙම පුනරාවර්තනයේදී, අපි පෙරටුගාමී nginx ලඝු-සටහන් වලට සමාන ඉඩක් ගන්නා ක්ෂුද්‍ර සේවා වල ප්‍රවේශ ලොග සහිත දර්ශකය "උණුසුම්" නෝඩ් තුනකින් යුත් දෙවන කණ්ඩායමට ගෙන ගියෙමු. අපි දැන් පැය 20 ක් සඳහා "උණුසුම්" නෝඩ් වල දත්ත ගබඩා කර, පසුව ඉතිරි ලොග් වලට "උණුසුම්" නෝඩ් වෙත මාරු කරමු.
කුඩා දර්ශක අතුරුදහන් වීමේ ගැටලුව අපි ඒවායේ භ්‍රමණය නැවත සකස් කිරීමෙන් විසඳා ගත්තෙමු. දැන් දර්ශක සෑම පැය 23 කට වරක් භ්‍රමණය වේ, එහි කුඩා දත්ත තිබුණත්. මෙය කැබලි ගණන තරමක් වැඩි කළේය (ඒවායින් 800 ක් පමණ තිබුණි), නමුත් පොකුරු කාර්ය සාධනය පිළිබඳ දෘෂ්ටි කෝණයෙන් එය ඉවසිය හැකිය.
එහි ප්රතිඵලයක් වශයෙන්, පොකුරේ "උණුසුම්" හයක් සහ "උණුසුම්" නෝඩ් හතරක් පමණි. මෙය දිගු කාල පරාසයන් තුළ ඉල්ලීම් මත සුළු ප්‍රමාදයක් ඇති කරයි, නමුත් අනාගතයේදී නෝඩ් ගණන වැඩි කිරීමෙන් මෙම ගැටළුව විසඳනු ඇත.
මෙම පුනරාවර්තනය අර්ධ-ස්වයංක්‍රීය පරිමාණය නොමැතිකම පිළිබඳ ගැටළුව ද විසඳා ඇත. මෙය සිදු කිරීම සඳහා, අපි යටිතල පහසුකම් Nomad පොකුරක් යොදවා ඇත - අපි දැනටමත් නිෂ්පාදනයේ යොදවා ඇති දේට සමානයි. දැනට, Logstash ප්‍රමාණය බර අනුව ස්වයංක්‍රීයව වෙනස් නොවේ, නමුත් අපි මෙයට පැමිණෙමු.
අනාගතය සඳහා සැලසුම්
ක්රියාත්මක කරන ලද වින්‍යාසය මැනවින් පරිපූර්ණ වන අතර දැන් අපි 13,3 TB දත්ත ගබඩා කරමු - සියලුම ලොග් දින 4 ක් සඳහා, අනතුරු ඇඟවීම් හදිසි විශ්ලේෂණය සඳහා අවශ්‍ය වේ. අපි සමහර ලඝු-සටහන් ප්‍රමිතික බවට පරිවර්තනය කරමු, එය අපි ග්‍රැෆයිට් වෙත එකතු කරමු. ඉංජිනේරුවන්ගේ වැඩ පහසු කිරීම සඳහා, අපි යටිතල පහසුකම් පොකුර සඳහා මිනුම් සහ පොදු ගැටළු අර්ධ ස්වයංක්‍රීයව අලුත්වැඩියා කිරීම සඳහා ස්ක්‍රිප්ට් ඇත. ලබන වසර සඳහා සැලසුම් කර ඇති දත්ත නෝඩ් ගණන වැඩි කිරීමෙන් පසුව, අපි දින 4 සිට 7 දක්වා දත්ත ගබඩා කිරීමට මාරු වන්නෙමු. මෙහෙයුම් කටයුතු සඳහා මෙය ප්‍රමාණවත් වනු ඇත, මන්ද අපි සෑම විටම හැකි ඉක්මනින් සිදුවීම් විමර්ශනය කිරීමට උත්සාහ කරන අතර දිගු කාලීන පරීක්ෂණ සඳහා ටෙලිමෙට්‍රි දත්ත ඇත.
2019 ඔක්තෝම්බර් මාසයේදී, cian.ru වෙත ගමනාගමනය දැනටමත් මසකට අද්විතීය පරිශීලකයින් මිලියන 15,3 දක්වා වර්ධනය වී ඇත. මෙය ලඝු-සටහන් ලබා දීම සඳහා වාස්තු විද්‍යාත්මක විසඳුමේ බරපතල පරීක්ෂණයක් බවට පත් විය.
දැන් අපි ElasticSearch 7 අනුවාදයට යාවත්කාලීන කිරීමට සූදානම් වෙමින් සිටිමු. කෙසේ වෙතත්, මේ සඳහා අපට ElasticSearch හි බොහෝ දර්ශක සිතියම්ගත කිරීම යාවත්කාලීන කිරීමට සිදුවනු ඇත, මන්ද ඒවා 5.5 අනුවාදයෙන් මාරු වී 6 වන අනුවාදයෙන් අත්හරින ලද ඒවා ලෙස ප්‍රකාශ කර ඇත (ඒවා හුදෙක් අනුවාදයේ නොමැත. 7) මෙයින් අදහස් කරන්නේ යාවත්කාලීන කිරීමේ ක්‍රියාවලියේදී අනිවාර්යයෙන්ම යම් ආකාරයක බලහත්කාරයක් ඇති වන අතර එමඟින් ගැටළුව විසඳන අතරතුර ලඝු-සටහන් නොමැතිව අපව අත්හරිනු ඇත. 7 අනුවාදයෙන්, අපි වැඩි දියුණු කළ අතුරු මුහුණතක් සහ නව පෙරහන් සමඟ කිබානා දෙස බලා සිටිමු.
අපි අපගේ ප්‍රධාන ඉලක්කය සාක්ෂාත් කර ගත්තෙමු: අපි ලඝු-සටහන් අහිමි වීම නැවැත්වූ අතර යටිතල පහසුකම් පොකුරේ අක්‍රිය කාලය සතියකට 2-3 බිඳ වැටීම් සිට මසකට පැය කිහිපයක් නඩත්තු කටයුතු දක්වා අඩු කළෙමු. නිෂ්පාදනයේ මෙම සියලු කාර්යයන් පාහේ නොපෙනේ. කෙසේ වෙතත්, දැන් අපට අපගේ සේවාව සමඟ සිදුවන්නේ කුමක්ද යන්න නිවැරදිව තීරණය කළ හැකිය, අපට එය ඉක්මනින් නිහඬ මාදිලියකින් කළ හැකි අතර ලඝු-සටහන් අහිමි වනු ඇතැයි කරදර නොවන්න. පොදුවේ, අපි තෘප්තිමත්, සතුටු සහ නව සූරාකෑම් සඳහා සූදානම් වන අතර, අපි පසුව කතා කරමු.
මූලාශ්රය: www.habr.com