ඔබේ සේවා පද්ධතියේ රීට්රයි (retry) ක්රියාවලිය පාලනය නොකරයි නම්, තද අඩුකිරීමක් (retry storm) නිසා සරල දෝෂයක්ම සේවා බිඳවැටුමකට පත් වෙයි. ගූගල්ගේ SRE පොතේ උදාහරණයක් මත, තත්පර කිහිපයක් තුළ 10,000 QPS (queries per second) ප්රමාණයක් පවත්වාගෙන යන පසුබලයක් 100 QPS කින් අධික වීමෙන් පසු, ඒ 100 අසාර්ථක ඉල්ලීම් නැවතත් රීට්රයි වීමෙන් තද බරක් තැනේ.
මෙම තත්ත්වයෙහි ප්රධාන ගැටලුව වන්නේ රීට්රයි කිරීමේදී එම ඉල්ලීම නැවතත් ඒම පද්ධතියට යැවීමයි. පද්ධතිය තවමත් සම්පූර්ණයෙන්ම කාර්යබහුලව තිබෙන බැවින්, රීට්රයි ඉල්ලීම් මූලික ඉල්ලීම්වලට වඩා වැඩි CPU, memory, file descriptor වැනි සම්පත් භාවිතා කරයි. ඒ නිසා මුලින් තිබූ 100 QPS අධිකත්වය 1,000 QPS, 10,000 QPS වැනි විශාල අගයන් වෙත පත් වෙයි, පද්ධතියේ සම්පත් අවසන් වීමෙන් ක්රැෂ් වීමට ඉඩ දේ.
මෙම ගැටලුවට විසඳුමක් ලෙස, "retry budget" (රීට්රයි අනුමත ප්රමාණය) එකක් සකස් කිරීම, සහ එක් තට්ටුවක් (layer) එකම රීට්රයි කළ යුතු බව තීරණය කිරීමයි. උදාහරණයක් ලෙස, API පාර්ශවය පමණක් රීට්රයි කළ යුතු අතර, බ්රවුසරය හෝ ඩේටාබේස් තට්ටුව ඒක නැවතත් නොකරයි. මෙය රීට්රයි සංඛ්යාව කාලය තුළ පමණක් නොව, සම්පත් අඩංගුවට අනුව සීමා කරයි.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තාක්ෂණික සමාජය තවත් ඉදිරියට යාමට, මෙම සංකල්පය වැදගත් වේ. සිසුන්, සංවර්ධකයින්, ව්යාපාරිකයින් සඳහා පහත වාසි ලබා දේ:
- විශ්වාසනීය සේවා – රීට්රයි මත පදනම් වූ අධික භාරය නිසා සේවා බිඳවැටුම් අඩු වේ.
- කාර්යක්ෂම සම්පත් පාලනය – Budget එකක් තබා CPU, memory වැනි සම්පත් අධික භාවිතය වැළැක්විය හැක.
- අයිඩම්පොටන්සි (Idempotency) ක්රමවේද – POST, DELETE වැනි non‑idempotent ඉල්ලීම් දෙවරක් සිදු නොවීමට ක්රමලේඛනයේ යෙදවීම.
- DevOps ක්රියාකාරිත්වය – SRE මට්ටමේ පරිපාලන ක්රමවලට අනුකූලව, සේවා මට්ටමේ SLA (Service Level Agreement) නඩත්තු කිරීම.
ඉදිරියේදී, ශ්රී ලංකාවේ තාක්ෂණික සමාජය මෙම නව පාලන මාර්ගෝපදේශ අනුගමනය කරමින්, ස්ථායි, ඉක්මන්, සහ විශ්වාසනීය පද්ධති නිර්මාණයට මඟ පෙන්වයි.
අවසානයේ, රීට්රයි පාලනයට Budget එකක් එක් කිරීම, exponential backoff පමණක් නොව, පද්ධතියේ සම්පත් පරිභෝගයත්, සේවා විශ්වාසනීයත්වයත් එකට සලකා බලන ප්රතිපත්තියක් බවට පත්වේ. ඔබේ යෙදුම මෙය අනුගමනය නොකරන්නේ නම්, අනාගතයේදී සුළු දෝෂයක්ම බරපතළ outage එකකට පත් විය හැක.
