අපගේ එක් එක් ඒකාබද්ධකාරී (partner) සමාගම තම උපාංග ගොඩනැගීමේ firmware එක නවීකරණය කළා. ඒ අනුව සෑම උපාංගයක්ම එකම වේලාවේ සින්ක් කිරීමේ ඉල්ලීමක් එවීමත් සමඟ API ඉල්ලීම් 40/s සිට 1,600/s දක්වා සීමා රහිතව ඉහළ ගියේය. මෙය කිසිදු අහිතකර ක්රියාකාරකමක් නොව, සජීවී උපාංගවල configuration වෙනස් වීම නිසා ඇති වූ “retry storm” එකක්.
අපේ පද්ධතියේ පූර්ව වසරකට වැඩි කාලයක් භාවිතා කරමින් තිබූ fixed‑window counter (ග්රාහකයාට 60‑තත්පරයකදී X ඉල්ලීම්) මෙම සිදුවීමේදී අඩුපාඩු පෙන්වා දුන්නා. Fixed window එකේ වැරැද්ද නම්, කවුන්ටර් එකේ සීමාව ඉක්මවා යාමට 2 ගුණයක් පමණ ඉඩ ලැබීම – එක කාල සීමාවේ අවසානයේ සහ නව කාල සීමාවේ ආරම්භයේ එකවර සීමාව භාවිතා කිරීම. නමුත් මෙහිදී ගැටළුව තවත් තරමට වැඩි වුණේ, ගොඩනැගීමේ ඉල්ලීම් 40 ගුණයක් වැඩිවූ විට, සීමා ඉක්මවා යාමත් සමඟ සියලුම ඉල්ලීම් 429 (Too Many Requests) ප්රතිචාරයක් ලබා දුන්නා.
මෙම ගැටළුවට token bucket යන නවීන පාලන ක්රමය හොඳ පිළිතුරක් විය. ටෝකන් බක්කට් එකේ උපරිම ටෝකන ගණන (bucket depth) හා පුරවැසි වේගය (refill rate) නියම කර, ඉල්ලීමකට එක් ටෝකනයක් ගෙවීමට සිදු වේ. කෙටි කාලීන බර්ස්ට් (උදා: වෙබ් පිටුවක් පූරණය කිරීමේදී එකවර API ඇමතුම් 5ක්) බක්කට් එකේ ටෝකන පරිභෝජනය කරයි, නමුත් ඉතිරි ටෝකන තිබීම නිසා සේවා අඩු නොවේ. දිගු කාලීන අධික භාරයක් එන විට, බක්කට් එක පුරවා ගැනීමේ වේගයට අනුව ඉල්ලීම් ස්ලෝවීව අඩු කරයි, අහඹු “hard cut” නොකර.
අපි මුලින්ම API key එකකට එක් බක්කට් එකක් භාවිතා කළා, නමුත් එක් එක් ග්රාහකයාට වෙනම බක්කට් එකක් තබා ගැනීමේ වැදගත්කම ඉක්මනින් අවබෝධ වුණා. ගෝලීය බක්කට් එකක් (global bucket) භාවිතා කළහොත් එක් ග්රාහකයාගේ බර්ස්ට් සියලුම ග්රාහකයින්ගේ සේවාව අඩු කරනු ඇත. Redis පයිප්ලයින්ග් සහ pipelining තාක්ෂණය භාවිතයෙන් පරීක්ෂණය කළා, එය වැඩි Redis round‑trip එකක් ගත වුණත්, කාර්ය සාධනයේ ප්රභේදයක් නොපැමිණි.
429 ප්රතිචාර සමඟ Retry‑After ශීර්ෂකය (header) යොදා ගැනීමත්, එය නියමිත refill වේගයට ගැලපෙන ලෙස සැකසීමත් ඉතා වැදගත්. අපි මුලින්ම අධික කාලයක් පසු කරමින් තිබූ බැවින්, ග්රාහකයින් “retry” කිරීමේදී නව බර්ස්ට් එකක් සාදන අවස්ථාවක් ඇති වුණා. ඒ නිසා Retry‑After කාලය සැකසීමෙන් දෙවන “thundering‑herd” පිරිස අඩු කළා.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තාක්ෂණික ආරම්භකයන්, මැදමැදියන් සහ ව්යාපාරිකයන්ට token bucket පද්ධතිය අනුගමනය කිරීමෙන් API විශ්වාසනීයතාවය වැඩිවේ. ග්රාහකයින්ගේ අධික ඉල්ලීම් හෝ අහඹු බර්ස්ට් එකක් පවා සේවා නතර නොවී, සුමට throttling සිදු කරයි. එමඟින් සමාගම්වලට downtime අඩු කර, පාරිභෝගික අත්දැකීම වැඩි කර, cloud පරිසරයේ resource utilisation එකත් වැඩි කරයි. තවත්, per‑client bucket යොදා ගැනීමෙන් එක් පාරිභෝගිකයාගේ ගැටළුව අනෙක් පාරිභෝගිකයන්ට බලපාන්නේ නැත, මෙය SaaS ව්යාපාරයන්ට විශේෂයෙන් වැදගත්.
අවසන් වශයෙන්, rate limiting එකක් “රක්ෂක” වශයෙන් පමණක් නොව, “සංවාදක” වශයෙන්ද පාවිච්චි කළ යුතු බව අපි ඉගෙන ගත්තා. Partner‑ට webhook එකක් එවීම, bucket තත්ත්වය සහ refill rate තොරතුරු එක්ක, ගැටළුව ඉක්මනින් හඳුනාගැනීමට සහ නඩත්තු කණ්ඩායම් අතර සන්නිවේදනය පහසු කරයි.
මෙම අත්දැකීමෙන් අපගේ API ආරක්ෂාව තවත් ශක්තිමත් වුණා, සහ ලෝකයේ ඕනෑම API සපයන්නාට token bucket පද්ධතියේ වැදගත්කම තේරුම් ගත හැකිය.
