SRE: කාර්ය සාධන විශ්ලේෂණය. Go හි සරල වෙබ් සේවාදායකයක් භාවිතා කරමින් වින්‍යාස කිරීමේ ක්‍රමය

කාර්ය සාධන විශ්ලේෂණය සහ සුසර කිරීම ගනුදෙනුකරුවන් සඳහා කාර්ය සාධන අනුකූලතාව තහවුරු කිරීම සඳහා බලවත් මෙවලමකි.

සුසර කිරීමේ අත්හදා බැලීම් සඳහා විද්‍යාත්මක ප්‍රවේශයක් යෙදීමෙන් වැඩසටහනක ඇති බාධක පරීක්ෂා කිරීමට කාර්ය සාධන විශ්ලේෂණය භාවිතා කළ හැක. Go webserver එකක් උදාහරණයක් ලෙස භාවිතා කරමින්, කාර්ය සාධන විශ්ලේෂණය සහ සුසර කිරීම සඳහා පොදු ප්‍රවේශයක් මෙම ලිපිය අර්ථ දක්වයි.

මෙහි පැතිකඩ මෙවලම් ඇති බැවින් Go විශේෂයෙන් හොඳයි pprof සම්මත පුස්තකාලයේ.

උපාය මාර්ග

අපගේ ව්‍යුහාත්මක විශ්ලේෂණය සඳහා සාරාංශ ලැයිස්තුවක් නිර්මාණය කරමු. බුද්ධිය හෝ අනුමාන කිරීම මත පදනම්ව වෙනස්කම් කිරීම වෙනුවට තීරණ ගැනීමට සමහර දත්ත භාවිතා කිරීමට අපි උත්සාහ කරමු. මෙය සිදු කිරීම සඳහා අපි මෙය කරන්නෙමු:

• අපි ප්රශස්තිකරණ සීමාවන් (අවශ්යතා) තීරණය කරමු;
• අපි පද්ධතිය සඳහා ගනුදෙනු භාරය ගණනය කරමු;
• අපි පරීක්ෂණය සිදු කරන්න (දත්ත සාදන්න);
• අපි නිරීක්ෂණය කරමු;
• අපි විශ්ලේෂණය කරමු - සියලු අවශ්යතා සපුරා තිබේද?
• අපි එය විද්‍යාත්මකව පිහිටුවා, උපකල්පනයක් කරන්න;
• මෙම උපකල්පනය පරීක්ෂා කිරීම සඳහා අපි අත්හදා බැලීමක් කරන්නෙමු.

සරල HTTP සේවාදායක ගෘහ නිර්මාණ ශිල්පය

මෙම ලිපිය සඳහා අපි Golang හි කුඩා HTTP සේවාදායකයක් භාවිතා කරමු. මෙම ලිපියෙන් සියලුම කේතයන් සොයා ගත හැක මෙහි.

විශ්ලේෂණය කෙරෙන යෙදුම එක් එක් ඉල්ලීම සඳහා Postgresql මත විමසන HTTP සේවාදායකයකි. අතිරේකව, යෙදුම් සහ පද්ධති ප්‍රමිතික එකතු කිරීම සහ ප්‍රදර්ශනය කිරීම සඳහා Prometheus, node_exporter සහ Grafana ඇත.

සරල කිරීම සඳහා, තිරස් පරිමාණය (සහ ගණනය කිරීම් සරල කිරීම) සඳහා එක් එක් සේවාව සහ දත්ත සමුදාය එකට යොදවා ඇති බව අපි සලකමු:

ඉලක්ක නිර්වචනය කිරීම

මෙම පියවරේදී අපි ඉලක්කය තීරණය කරමු. අපි විශ්ලේෂණය කිරීමට උත්සාහ කරන්නේ කුමක්ද? එය අවසන් වීමට කාලය පැමිණ ඇති බව අප දන්නේ කෙසේද? මෙම ලිපියෙන්, අපට සේවාදායකයින් සිටින බවත් අපගේ සේවාව තත්පරයකට ඉල්ලීම් 10 ක් සකසන බවත් අපි සිතමු.

В Google SRE පොත තෝරාගැනීමේ සහ ආකෘති නිර්මාණය කිරීමේ ක්රම විස්තරාත්මකව සාකච්ඡා කෙරේ. අපි එයම කර ආකෘති ගොඩනඟමු:

• ප්‍රමාදය: ඉල්ලීම්වලින් 99%ක්ම 60msට අඩු කාලයකින් සම්පූර්ණ කළ යුතුය;
• පිරිවැය: සේවාව සාධාරණ ලෙස කළ හැකි යැයි අප සිතන අවම මුදල් ප්‍රමාණය පරිභෝජනය කළ යුතුය. මෙය සිදු කිරීම සඳහා, අපි ප්‍රතිදානය උපරිම කරමු;
• ධාරිතා සැලසුම් කිරීම: සමස්ත පරිමාණ ක්‍රියාකාරීත්වය ඇතුළුව යෙදුමේ අවස්ථා කීයක් ධාවනය කිරීමට අවශ්‍ය වේද යන්න සහ මූලික බර සහ ප්‍රතිපාදන අවශ්‍යතා සපුරාලීමට අවස්ථා කීයක් අවශ්‍ය වේද යන්න අවබෝධ කර ගැනීම සහ ලේඛනගත කිරීම අවශ්‍ය වේ. අතිරික්තය n+1.

ප්‍රමාදයට විශ්ලේෂණයට අමතරව ප්‍රශස්තකරණය අවශ්‍ය විය හැක, නමුත් ප්‍රතිදානය පැහැදිලිව විශ්ලේෂණය කළ යුතුය. SRE SLO ක්‍රියාවලිය භාවිතා කරන විට, නිෂ්පාදන හිමිකරු විසින් නියෝජනය කරනු ලබන පාරිභෝගිකයා හෝ ව්‍යාපාරය වෙතින් ප්‍රමාද ඉල්ලීම පැමිණේ. තවද අපගේ සේවාව කිසිදු සැකසුමකින් තොරව ආරම්භයේ සිටම මෙම වගකීම ඉටු කරනු ඇත!

පරීක්ෂණ පරිසරයක් සැකසීම

පරීක්ෂණ පරිසරයක ආධාරයෙන්, අපගේ පද්ධතිය මත මනින ලද බරක් තැබීමට අපට හැකි වනු ඇත. විශ්ලේෂණය සඳහා, වෙබ් සේවාවේ කාර්ය සාධනය පිළිබඳ දත්ත උත්පාදනය කරනු ලැබේ.

ගනුදෙනු භාරය

මෙම පරිසරය භාවිතා කරයි එළවළු නවත්වන තෙක් අභිරුචි HTTP ඉල්ලීම් අනුපාතයක් සෑදීමට:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

නිරීක්ෂණය

ධාවන වේලාවේදී ගනුදෙනු භාරය යොදනු ලැබේ. යෙදුම (ඉල්ලීම් ගණන, ප්‍රතිචාර ප්‍රමාදය) සහ මෙහෙයුම් පද්ධති (මතකය, CPU, IOPS) ප්‍රමිතික වලට අමතරව, යෙදුම් පැතිකඩ එහි ගැටළු ඇති තැන සහ CPU කාලය පරිභෝජනය කරන්නේ කෙසේද යන්න තේරුම් ගැනීමට ක්‍රියාත්මක වේ.

පැතිකඩ කිරීම

පැතිකඩ කිරීම යනු යෙදුමක් ක්‍රියාත්මක වන විට CPU වේලාව කොතැනට යන්නේදැයි බැලීමට ඔබට ඉඩ සලසන මිනුම් වර්ගයකි. ප්‍රොසෙසරය කොපමණ කාලයක් වැය කරන්නේද යන්න නිවැරදිව තීරණය කිරීමට එය ඔබට ඉඩ සලසයි:

අපතේ යන CPU කාලය සහ අනවශ්‍ය වැඩ සිදු කිරීම පිළිබඳ අවබෝධයක් ලබා ගැනීමට විශ්ලේෂණය අතරතුර මෙම දත්ත භාවිතා කළ හැක. Go (pprof) හට පැතිකඩ ජනනය කළ හැකි අතර සම්මත මෙවලම් කට්ටලයක් භාවිතයෙන් ඒවා ගිනි ප්‍රස්ථාර ලෙස දෘශ්‍යමාන කළ හැක. මම ඒවායේ භාවිතය සහ සැකසුම් මාර්ගෝපදේශය ගැන පසුව ලිපියෙන් කතා කරමි.

ක්රියාත්මක කිරීම, නිරීක්ෂණ, විශ්ලේෂණය.

අපි අත්හදා බැලීමක් කරමු. අපි කාර්ය සාධනය ගැන සෑහීමකට පත් වන තුරු අපි ඉටු කරන්නෙමු, නිරීක්ෂණය කරන්නෙමු සහ විශ්ලේෂණය කරන්නෙමු. පළමු නිරීක්ෂණවල ප්රතිඵල ලබා ගැනීම සඳහා එය යෙදීම සඳහා අත්තනෝමතික ලෙස අඩු බරක් අගයක් තෝරා ගනිමු. සෑම ඊළඟ පියවරකදීම අපි යම් වෙනසක් සමඟ තෝරාගත් යම් පරිමාණ සාධකයක් සමඟ බර වැඩි කරන්නෙමු. එක් එක් බර පරීක්ෂණ ධාවනය සකස් කරන ලද ඉල්ලීම් ගණන සමඟ සිදු කෙරේ: make load-test LOAD_TEST_RATE=X.

තත්පරයකට ඉල්ලීම් 50ක්

ඉහළ ප්‍රස්ථාර දෙක කෙරෙහි අවධානය යොමු කරන්න. අපගේ යෙදුම තත්පරයකට ඉල්ලීම් 50ක් ක්‍රියාවට නංවන බව ඉහළ වම්පස පෙන්වයි (එය සිතන්නේ) සහ ඉහළ දකුණේ එක් එක් ඉල්ලීමේ කාලසීමාව පෙන්වයි. පරාමිති දෙකම අපට අපගේ කාර්ය සාධන සීමාවන් තුළ සිටිනවාද නැද්ද යන්න බැලීමට සහ විශ්ලේෂණය කිරීමට උපකාරී වේ. ප්‍රස්ථාරයේ රතු රේඛාව HTTP ඉල්ලීම් ප්‍රමාදය 60ms හි SLO පෙන්වයි. රේඛාව පෙන්නුම් කරන්නේ අප අපගේ උපරිම ප්‍රතිචාර කාලයට වඩා බෙහෙවින් අඩු බවයි.

පිරිවැය පැත්ත දෙස බලමු:

තත්පරයකට ඉල්ලීම් 10000 / සේවාදායකයකට ඉල්ලීම් 50 කට = සේවාදායකයන් 200 + 1

අපට තවමත් මෙම අගය වැඩිදියුණු කළ හැකිය.

තත්පරයකට ඉල්ලීම් 500ක්

බර පැටවීම තත්පරයකට ඉල්ලීම් 500ක් වූ විට වඩාත් රසවත් දේවල් සිදු වීමට පටන් ගනී:

නැවතත්, ඉහළ වම් ප්‍රස්ථාරයේ යෙදුම සාමාන්‍ය බරක් වාර්තා කරන බව ඔබට දැක ගත හැකිය. මෙය එසේ නොවේ නම්, යෙදුම ක්‍රියාත්මක වන සේවාදායකයේ ගැටලුවක් තිබේ. ප්‍රතිචාර ප්‍රමාද ප්‍රස්ථාරය ඉහළ දකුණේ පිහිටා ඇති අතර, තත්පරයකට ඉල්ලීම් 500 ක් ප්‍රතිචාර දැක්වීමේ ප්‍රමාදයක් 25-40ms දක්වා ඇති බව පෙන්වයි. 99 වැනි ප්‍රතිශතය තවමත් ඉහත තෝරාගත් 60ms SLO වෙත හොඳින් ගැලපේ.

පිරිවැය අනුව:

තත්පරයකට ඉල්ලීම් 10000 / සේවාදායකයකට ඉල්ලීම් 500 කට = සේවාදායකයන් 20 + 1

සෑම දෙයක්ම තවමත් වැඩිදියුණු කළ හැකිය.

තත්පරයකට ඉල්ලීම් 1000ක්

විශිෂ්ට දියත් කිරීම! යෙදුම තත්පරයකට ඉල්ලීම් 1000ක් ක්‍රියාත්මක කළ බව පෙන්වයි, නමුත් ප්‍රමාද සීමාව SLO විසින් උල්ලංඝනය කර ඇත. මෙය ඉහළ දකුණු ප්‍රස්ථාරයේ p99 පේළියේ දැකිය හැක. p100 රේඛාව බොහෝ ඉහළ මට්ටමක පැවතුනද, සැබෑ ප්‍රමාදයන් උපරිම 60ms ට වඩා වැඩි ය. යෙදුම ඇත්ත වශයෙන්ම කරන්නේ කුමක්දැයි සොයා බැලීමට අපි පැතිකඩ වෙත කිමිදෙමු.

පැතිකඩ කිරීම

පැතිකඩ කිරීම සඳහා, අපි පැටවීම තත්පරයකට ඉල්ලීම් 1000 ලෙස සකසා, පසුව භාවිතා කරන්න pprof යෙදුම CPU කාලය ගත කරන්නේ කොතැනදැයි සොයා බැලීමට දත්ත ග්‍රහණය කර ගැනීමට. HTTP අන්ත ලක්ෂ්‍යය සක්‍රිය කිරීමෙන් මෙය කළ හැක pprof, පසුව, පැටවීම යටතේ, curl භාවිතයෙන් ප්රතිඵල සුරකින්න:

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

ප්‍රතිඵල මෙසේ පෙන්විය හැක:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

යෙදුම CPU කාලය ගත කරන ස්ථානය සහ කොපමණ ප්‍රස්ථාර පෙන්වයි. විස්තරයෙන් බ්‍රෙන්ඩන් ග්‍රෙග්:

X අක්ෂය යනු අකාරාදී පිළිවෙලට වර්ග කර ඇති අට්ටි පැතිකඩ ජනගහනයයි (මෙය කාලය නොවේ), Y අක්ෂය අට්ටියේ ගැඹුර පෙන්වයි, [ඉහළ] ශුන්‍යයේ සිට ගණන් කරයි. සෑම සෘජුකෝණාස්රයක්ම අට්ටි රාමුවකි. රාමුව පුළුල් වන තරමට එය බොහෝ විට අට්ටිවල පවතී. ඉහළින් ඇති දේ CPU මත ක්‍රියාත්මක වන අතර පහත ඇත්තේ ළමා මූලද්‍රව්‍ය වේ. වර්ණ සාමාන්‍යයෙන් කිසිවක් අදහස් නොකරයි, නමුත් රාමු වෙනස් කිරීම සඳහා අහඹු ලෙස තෝරා ගනු ලැබේ.

විශ්ලේෂණය - උපකල්පනය

සුසර කිරීම සඳහා, අපි නාස්ති වූ CPU කාලය සොයා ගැනීමට උත්සාහ කරමු. අපි වැඩකට නැති වියදම් විශාලම මූලාශ්‍ර සොයමින් ඒවා ඉවත් කරන්නෙමු. හොඳයි, පැතිකඩකරණය මඟින් යෙදුම එහි ප්‍රොසෙසරයේ කාලය ගත කරන්නේ කොතැනද යන්න ඉතා නිවැරදිව හෙළි කරයි, ඔබට එය කිහිප වතාවක් කිරීමට සිදු විය හැකි අතර, ඔබට යෙදුම් මූල කේතය වෙනස් කිරීමට, පරීක්ෂණ නැවත ක්‍රියාත්මක කිරීමට සහ කාර්ය සාධනය ඉලක්කයට ළඟා වන බව දැකීමට අවශ්‍ය වනු ඇත.

බ්‍රෙන්ඩන් ග්‍රෙග්ගේ නිර්දේශ අනුගමනය කරමින්, අපි ප්‍රස්ථාරය ඉහළ සිට පහළට කියවමු. සෑම පේළියක්ම අට්ටි රාමුවක් (ක්‍රියාකාරී ඇමතුම) පෙන්වයි. පළමු පේළිය වැඩසටහනට ඇතුල් වන ස්ථානය, අනෙකුත් සියලුම ඇමතුම් වල මාපියන් (වෙනත් වචන වලින් කිවහොත්, අනෙකුත් සියලුම ඇමතුම් එය ඔවුන්ගේ තොගයේ ඇත). ඊළඟ පේළිය දැනටමත් වෙනස් ය:

ඔබ ප්‍රස්ථාරයේ ශ්‍රිතයක නමක් මත කර්සරය ගෙන ගියහොත්, නිදොස්කරණයේදී එය අට්ටියේ තිබූ මුළු කාලය පෙන්වනු ඇත. HTTPServe ශ්‍රිතය එහි 65% කාලය, අනෙකුත් ධාවන කාල කාර්යයන් විය runtime.mcall, mstart и gc, ඉතිරි කාලය ගත්තා. විනෝදජනක කරුණ: මුළු කාලයෙන් 5%ක් DNS විමසුම් සඳහා වැය වේ:

වැඩසටහන සොයන ලිපින Postgresql ට අයත් වේ. මත ක්ලික් කරන්න FindByAge:

සිත්ගන්නා කරුණ නම්, වැඩසටහන පෙන්නුම් කරන්නේ, ප්‍රතිපත්තිමය වශයෙන්, ප්‍රමාදයන් එකතු කරන ප්‍රධාන ප්‍රභවයන් තුනක් ඇති බවයි: සම්බන්ධතා විවෘත කිරීම සහ වසා දැමීම, දත්ත ඉල්ලා සිටීම සහ දත්ත සමුදායට සම්බන්ධ කිරීම. ප්‍රස්ථාරයෙන් පෙන්නුම් කරන්නේ DNS ඉල්ලීම්, සම්බන්ධතා විවෘත කිරීම සහ වසා දැමීම සම්පූර්ණ ක්‍රියාත්මක කිරීමේ කාලයෙන් 13% ක් පමණ ගත වන බවයි.

උපකල්පනය: සංචිතය භාවිතයෙන් සම්බන්ධතා නැවත භාවිතා කිරීම තනි HTTP ඉල්ලීමක කාලය අඩු කළ යුතු අතර, ඉහළ ප්‍රතිදානයකට සහ අඩු ප්‍රමාදයකට ඉඩ සලසයි..

යෙදුම සැකසීම - අත්හදා බැලීම

අපි මූලාශ්‍ර කේතය යාවත්කාලීන කරන්නෙමු, එක් එක් ඉල්ලීම සඳහා Postgresql වෙත සම්බන්ධතාවය ඉවත් කිරීමට උත්සාහ කරන්න. පළමු විකල්පය භාවිතා කිරීමයි සම්බන්ධතා සංචිතය යෙදුම් මට්ටමින්. මෙම අත්හදා බැලීමේදී අපි අපි එය සකස් කරමු යන්න සඳහා sql ධාවකය භාවිතයෙන් සම්බන්ධතා එකතු කිරීම:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

ක්රියාත්මක කිරීම, නිරීක්ෂණ, විශ්ලේෂණය

තත්පරයකට ඉල්ලීම් 1000ක් සමඟ පරීක්ෂණය නැවත ආරම්භ කිරීමෙන් පසුව, p99 හි ප්‍රමාද මට්ටම් 60ms ක SLO සමඟ සාමාන්‍ය තත්ත්වයට පැමිණ ඇති බව පැහැදිලිය!

වියදම කීයද?

තත්පරයකට ඉල්ලීම් 10000 / සේවාදායකයකට ඉල්ලීම් 1000 කට = සේවාදායකයන් 10 + 1

අපි එය වඩාත් හොඳින් කරමු!

තත්පරයකට ඉල්ලීම් 2000ක්

පැටවීම දෙගුණ කිරීම එකම දෙය පෙන්වයි, ඉහළ වම් ප්‍රස්ථාරයෙන් පෙන්නුම් කරන්නේ යෙදුම තත්පරයකට ඉල්ලීම් 2000 ක් සැකසීමට කළමනාකරණය කරන බවයි, p100 60ms ට වඩා අඩුය, p99 SLO තෘප්තිමත් කරයි.

පිරිවැය අනුව:

තත්පරයකට ඉල්ලීම් 10000 / සේවාදායකයකට ඉල්ලීම් 2000 කට = සේවාදායකයන් 5 + 1

තත්පරයකට ඉල්ලීම් 3000ක්

මෙහිදී යෙදුමට 3000ms ට අඩු p99 ප්‍රමාදයක් සහිත ඉල්ලීම් 60ක් ක්‍රියා කළ හැක. SLO උල්ලංඝනය නොවන අතර, පිරිවැය පහත පරිදි පිළිගනු ලැබේ:

තත්පරයකට ඉල්ලීම් 10000 ක් / සේවාදායකයකට ඉල්ලීම් 3000 කට = සේවාදායකයන් 4 ක් + 1 (කතුවරයා වට කර ඇත, ආසන්න වශයෙන් පරිවර්තකයා)

අපි තවත් විශ්ලේෂණ වටයක් උත්සාහ කරමු.

විශ්ලේෂණය - උපකල්පනය

අපි යෙදුම නිදොස් කිරීමේ ප්‍රතිඵල තත්පරයකට ඉල්ලීම් 3000 බැගින් රැස් කර ප්‍රදර්ශනය කරමු:

තවමත් කාලයෙන් 6% ක් සම්බන්ධතා ඇති කර ගැනීමට වැය වේ. සංචිතය සැකසීම මඟින් කාර්ය සාධනය වැඩි දියුණු කර ඇත, නමුත් දත්ත සමුදායට නව සම්බන්ධතා නිර්මාණය කිරීමේදී යෙදුම දිගටම ක්‍රියා කරන බව ඔබට තවමත් දැක ගත හැකිය.

උපකල්පනය: සම්බන්ධතා, තටාකයක් තිබියදීත්, තවමත් අතහැර දමා පිරිසිදු කර ඇත, එබැවින් යෙදුම ඒවා නැවත සැකසීමට අවශ්ය වේ. පොකුණ ප්‍රමාණයට පොරොත්තු සම්බන්ධතා සංඛ්‍යාව සැකසීම යෙදුම සම්බන්ධතාවයක් නිර්මාණය කිරීමට ගත කරන කාලය අවම කිරීම මගින් ප්‍රමාදයට උදවු විය යුතුය..

යෙදුම සැකසීම - අත්හදා බැලීම

ස්ථාපනය කිරීමට උත්සාහ කරයි MaxIdleConns තටාකයේ ප්‍රමාණයට සමාන (ද විස්තර කර ඇත මෙහි):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

ක්රියාත්මක කිරීම, නිරීක්ෂණ, විශ්ලේෂණය

තත්පරයකට ඉල්ලීම් 3000ක්

p99 සැලකිය යුතු ලෙස අඩු p60 සමග 100ms ට අඩු වේ!

ගිනි ප්‍රස්ථාරය පරීක්ෂා කිරීමෙන් සම්බන්ධතාවය තවදුරටත් නොපෙනෙන බව පෙන්වයි! අපි වඩාත් විස්තරාත්මකව පරීක්ෂා කර බලමු pg(*conn).query - මෙහි සම්බන්ධතාවය ස්ථාපිත වී ඇති බව අපි නොදකිමු.

නිගමනය

පාරිභෝගික අපේක්ෂාවන් සහ ක්‍රියාකාරී නොවන අවශ්‍යතා සපුරාලන බව අවබෝධ කර ගැනීම සඳහා කාර්ය සාධන විශ්ලේෂණය ඉතා වැදගත් වේ. පාරිභෝගික අපේක්ෂාවන් සමඟ නිරීක්ෂණ සංසන්දනය කිරීමෙන් විශ්ලේෂණය පිළිගත හැකි සහ නොකළ යුතු දේ තීරණය කිරීමට උපකාරී වේ. විශ්ලේෂණය සරල සහ ප්‍රවේශ විය හැකි සම්මත පුස්තකාලය තුළ ගොඩනගා ඇති ප්‍රබල මෙවලම් Go සපයයි.

මූලාශ්රය: www.habr.com