Trading bot-க்கு சிறந்த VPS-ஐ தேர்வு செய்வது எப்படி?

Trading bot-க்கு VPS-ல் தேவைப்படுபவை

Trading bot-களுக்கான VPS-ன் தரம் நான்கு விஷயங்களை அடிப்படையாகக் கொண்டது: ஒரு process செயலிழந்தால் அது தானாக மீண்டும் தொடங்குகிறதா, system clock சரியாக உள்ளதா, API (application programming interface) keys திருடப்படாமல் பாதுகாப்பாக உள்ளனவா, மற்றும் bot இயங்குவதை நிறுத்திவிட்டால் உங்களுக்குத் தெரிய வருகிறதா என்பதுதான் அவை. ஒரு retail bot-ஐப் பொறுத்தவரை, அதன் raw speed என்பது மிகக் குறைந்த முக்கியத்துவமே கொண்டது. ஏனெனில், உங்கள் order path-ல் மெதுவான பகுதி என்பது உங்கள் broker மற்றும் அதற்கான தூரம் மட்டுமே; உங்கள் Python code-ஐ இயக்கும் host அல்ல.

இது ஒரு பொறியியல் வழிகாட்டி. இதில் நிதி ஆலோசனைகள் எதுவும் இல்லை, எந்தவொரு வர்த்தக உத்தியும் விவாதிக்கப்படவில்லை.

Uptime என்பது மறுதொடக்கம் செய்யும் ஒழுக்கம், விற்பனைப் பக்கத்தில் உள்ள ஒரு எண் அல்ல

உலகில் உள்ள ஒவ்வொரு host-ம் 99.9 சதவீத uptime-ஐ விளம்பரப்படுத்துகிறது. அந்த எண் hypervisor-ஐக் குறிக்கிறதே தவிர, உங்கள் bot-ஐ அல்ல. ஒரு unhandled exception, மீண்டும் இணையாத websocket, அல்லது OOM (out of memory) killer ஆகியவற்றால் ஒரு bot செயலிழக்கலாம், ஆனால் server தொடர்ந்து இயங்கிக்கொண்டே இருக்கும். எனவே, உங்கள் process வெளியேறிய பிறகு அடுத்த பத்து வினாடிகளில் என்ன நடக்கிறது என்பதே முக்கியமான கேள்வி.

Bot-ஐ ஒரு systemd service-ஆக இயக்கவும், மறுதொடக்கம் செய்யும் பொறுப்பை init system-இடம் விட்டுவிடவும். ஒரு unit file-ல் இதை ஆறு வரிகளில் செய்யலாம்.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 என்பது மக்கள் கவனிக்கத் தவறும் வரி. இயல்பாக, systemd 10 வினாடிகளில் 5 முறை மறுதொடக்கம் செய்த பிறகு முயற்சியைக் கைவிட்டு, unit-ஐ failed நிலையில் நிரந்தரமாக வைத்துவிடும்; இது அதிகாலை 03:00 மணிக்கு நீங்கள் விரும்பாத ஒரு செயலாக இருக்கும். இதை 0 என அமைப்பது rate limit-ஐ நீக்கும், எனவே crash-loop ஆகும் bot அமைதியாகிவிடாமல் தொடர்ந்து முயற்சிக்கும். RestartSec=10 அந்த loop-ஐ exchange-ல் மீண்டும் மீண்டும் இணைக்க முயற்சிப்பதிலிருந்து தடுக்கும்.

கோப்பை நம்புவதற்கு முன் சரிபார்க்கவும், பிறகு அதைத் தொடங்கவும்:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable என்பது reboot-க்குப் பிறகும் நிலைத்திருக்கும் பாதியாகும், மேலும் kernel updates-க்கு reboot அவசியம். Bot அமைதியாகச் செயலிழந்து வருகிறதா என்பதை அறிய, systemd-இடம் restart counter-ஐக் கேட்கவும்:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 ஒரு வாரத்திற்குப் பிறகு இருந்தால், அது ஆரோக்கியமான bot ஆகும். NRestarts=812 என்பது இரவு முழுவதும் மீண்டும் மீண்டும் இணையும் ஒரு process-ல் நீங்கள் வர்த்தகம் செய்கிறீர்கள் என்று அர்த்தம். தினசரி அறிக்கை போன்ற திட்டமிடப்பட்ட பணிகளுக்கான timers உட்பட, முழு unit file-ன் கட்டமைப்பு running a program as a systemd service பகுதியில் விவரிக்கப்பட்டுள்ளது.

கடிகாரத்தை UTC-க்கு அமைத்து, அது ஒத்திசைக்கப்பட்டுள்ளதை உறுதி செய்தல்

Exchange API-கள் கோரிக்கைகளை ஒரு timestamp-உடன் கையொப்பமிடுகின்றன. 5 வினாடிகளுக்கு மேல் காலதாமதம் ஏற்படும் கோரிக்கைகளை அவை நிராகரித்துவிடும். கடிகாரத்தில் ஏற்படும் கால விலகல் (drift), authentication தோல்வி போன்ற பிழைகளை உருவாக்கும். இதனால், நேரத்தைச் சரிபார்க்காமல் பயனர்கள் பல மணிநேரம் keys-ஐ மாற்றிக்கொண்டிருப்பார்கள். Binance-முறை API-களில் இதற்கான செய்தி தெளிவாக இருக்கும்: Timestamp for this request was 1000ms ahead of the server's time.

Server-ஐ UTC நேரத்திற்கு அமைக்கவும். உள்ளூர் நேர மண்டலங்கள் (local time zones) daylight saving மாற்றத்தை ஏற்படுத்தும், இது வர்த்தக அமர்வின் நடுவில் சிக்கலை உருவாக்கலாம்.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu-வில் systemd-timesyncd உள்ளது, இது ஒரு SNTP (simple network time protocol) client ஆகும். இது logs-க்கு போதுமானது, ஆனால் சில மில்லி விநாடிகளுக்குள் துல்லியமாக இருக்க வேண்டிய எதற்கும் இது போதாது. ஏனெனில், இது ஒரு server-ஐ மட்டுமே தொடர்பு கொள்கிறது மற்றும் கடிகாரத்தை தொடர்ந்து சீரமைப்பதில்லை. அதற்கு பதிலாக chrony-ஐப் பயன்படுத்தவும்:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

chronyc tracking-லிருந்து வாசிக்க வேண்டிய வரி System time ஆகும், உதாரணமாக System time : 0.000031415 seconds fast of NTP time. சில மில்லி விநாடிகளுக்குக் கீழ் இருந்தால் அது சரியான நிலை. அது Leap status : Not synchronised என்று காட்டினால், chrony இன்னும் எந்த server-ஐயும் அடையவில்லை என்று அர்த்தம். பொதுவாக outbound UDP 123 தடுக்கப்பட்டிருப்பதே இதற்குக் காரணம். firewall விதிகளை மாற்றுவதற்கு முன், ஒரு நிமிடம் காத்திருந்து மீண்டும் சரிபார்க்கவும்.

API keys-ஐ நீங்கள் நகலெடுக்கும் இடங்களில் வைக்காதீர்கள்

கசிந்த exchange key, கசிந்த SSH key-ஐ விட ஆபத்தானது; ஏனெனில், withdrawal அனுமதி இருந்தால் அது உடனடியாக பணமாக மாற்றப்படலாம். இரண்டு பழக்கங்கள் பெரும்பாலான அபாயங்களைக் குறைக்கின்றன.

முதலாவதாக, ஒரு bot key-க்கு ஒருபோதும் withdrawal அனுமதியை வழங்காதீர்கள். exchange அதை ஆதரித்தால், அந்த key-ஐ உங்கள் server-ன் IP address-உடன் பிணைக்கவும் (bind). திருடப்பட்ட key-ஐ பயனற்றதாக்கும் ஒரே கட்டுப்பாடு இதுதான்.

இரண்டாவதாக, secret-ஐ code directory-க்குள் வைக்காதீர்கள். /opt/tradingbot-க்குள் இருக்கும் எதுவும் ஏதோ ஒரு கட்டத்தில் git repository அல்லது backup archive-ல் சேர்ந்துவிடும். அதை root-க்கு சொந்தமான, systemd மட்டும் வாசிக்கக்கூடிய கோப்பில் வைக்கவும்:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

இந்தக் கோப்பில் KEY=value வரிகள் மேற்கோள் குறிகள் (quotes) இல்லாமலும், export இல்லாமலும் இருக்க வேண்டும். Mode 640 மற்றும் group bot என்பது, service user-ஆல் மட்டுமே அதை வாசிக்க முடியும், மற்றவர்களால் முடியாது என்பதைக் குறிக்கிறது. sudo -u bot cat /etc/tradingbot/api.env மூலம் இதைச் சரிபார்க்கவும், பின்னர் வேறு ஏதேனும் user மூலம் முயற்சிக்கும்போது அது Permission denied பிழையுடன் தோல்வியடைய வேண்டும்.

Bot-ஐ root ஆகவோ அல்லது உங்கள் login user ஆகவோ இயக்கக்கூடாது. shell மற்றும் home directory இல்லாத ஒரு system account-ஐ உருவாக்கவும்:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

அந்த ஒவ்வொரு flag-ன் பின்னணியில் உள்ள காரணம் மற்றும் ProtectSystem=strict எந்த அளவுக்குச் செயல்படுகிறது என்பது unprivileged user-ஆக services-ஐ இயக்குதல் பகுதியில் உள்ளது. server baseline-ன் மீதமுள்ள பகுதிகள், SSH keys மற்றும் firewall ஆகியவை புதிய VPS-ல் முதல் பத்து நிமிடங்கள் பகுதியில் உள்ளன.

உங்கள் broker அறிவதற்கு முன்பே service முடங்கியிருப்பதை கண்டறியவும்

systemctl status, process இயங்கிக்கொண்டிருப்பதாகக் கூறுகிறது. ஆனால், bot எந்த வேலையும் செய்யவில்லை என்று அர்த்தமல்ல. ஒரு dead websocket-உடன் retry loop-ல் சிக்கியிருக்கும் process, systemd செய்யும் அனைத்து சோதனைகளையும் கடந்துவிடும்.

அதற்கு பதிலாக heartbeat-ஐப் பயன்படுத்தவும். Uptime Kuma-வில் push monitors உள்ளன: உங்கள் bot ஒரு குறிப்பிட்ட கால இடைவெளியில் ஒரு URL-ஐ அழைக்க வேண்டும் என்று அது எதிர்பார்க்கிறது, அந்த அழைப்பு வராவிட்டால் அது எச்சரிக்கை செய்யும். உங்கள் main loop-ன் இறுதியில், bot உயிருடன் இருப்பதை உறுதிப்படுத்தும் market data வாசிப்பு போன்ற செயல்களுக்குப் பிறகு இந்த அழைப்பை வைக்கவும்.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Monitor interval-ஐ உங்கள் loop நேரத்தைப் போல இரண்டு மடங்காக அமைக்கவும், அப்போதுதான் சாதாரண jitter-க்காக உங்களுக்குத் தேவையற்ற எச்சரிக்கைகள் வராது. Monitor-ஐ bot இயங்கும் server-லிருந்து வேறொரு server-ல் இயக்கவும், ஏனெனில் கண்காணிக்கப்படும் அதே server செயலிழந்தால், monitor-ஆல் எதையும் தெரிவிக்க முடியாது. இதற்கான அமைப்பு Uptime Kuma மூலம் self-hosted status monitoring பகுதியில் விவரிக்கப்பட்டுள்ளது.

Disk alert-ஐயும் சேர்க்கவும். அதிகப்படியான logs-ஐ எழுதும் bot, சில வாரங்களிலேயே root filesystem-ஐ நிரப்பிவிடும். Disk நிறைந்தால் database-ல் எழுதுவது நின்றுவிடும், ஆனால் network அழைப்பு தொடரும், இதனால் விசித்திரமான அறிகுறிகள் தோன்றும். journalctl --vacuum-time=14d மற்றும் /etc/systemd/journald.conf-ல் உள்ள ஒரு SystemMaxUse= வரி ஆகியவை journal-ன் அளவைக் கட்டுக்குள் வைத்திருக்கும்.

உண்மை என்னவென்றால்: latency பெரும்பாலும் உங்கள் host-ஆல் ஏற்படுவதில்லை

இங்குதான் trading VPS தயாரிப்புகளுக்கான சந்தை தொழில்நுட்ப ரீதியாக இருப்பதில்லை. சந்தைப்படுத்தல் பக்கங்கள் மில்லி-செகண்டிற்கும் குறைவான வேகத்தைக் குறிப்பிடுகின்றன, மேலும் host தான் உங்கள் வர்த்தகத்திற்கும் (fill) இடையூறாக இருப்பதாகக் காட்டுகின்றன. பெரும்பாலான சில்லறை வர்த்தக bot-களுக்கு இது உண்மையல்ல.

உங்கள் order, bot-லிருந்து exchange அல்லது broker endpoint-க்கு பொது இணையம் (public internet) வழியாகச் செல்கிறது. அந்தப் பாதையில் உடல் ரீதியான தூரம் மற்றும் உங்கள் provider-க்கும் அவர்களின் provider-க்கும் இடையிலான peering ஆகியவையே முக்கியப் பங்கு வகிக்கின்றன. Frankfurt-ல் உள்ள ஒரு server, Tokyo-வில் உள்ள endpoint-உடன் தொடர்பு கொள்ளும்போது, CPU எவ்வளவு வேகமாக இருந்தாலும் சுமார் 250 மில்லி-செகண்டுகள் round trip நேரம் எடுக்கும். அதன்பின், broker-ன் சொந்த அமைப்புகள் அவற்றின் queue, risk checks மற்றும் rate limits-ஐச் சேர்க்கின்றன; சில்லறை வர்த்தகக் கணக்குகளுக்கு இவை பொதுவாக பத்து அல்லது நூறு மில்லி-செகண்டுகளில் அளவிடப்படுகின்றன.

ஊகிப்பதற்குப் பதிலாக அதை அளவிடுங்கள். curl ஒரு உண்மையான endpoint-க்கான இணைப்பு மற்றும் முதல்-byte நேரத்தை (first-byte times) அறிக்கையிடுகிறது:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

நீங்கள் ஒரு server-ஐத் தேர்ந்தெடுப்பதற்கு முன் அதை இயக்கிப் பாருங்கள். connect 0.180 வினாடிகள் என்றால், நீங்கள் தவறான கண்டத்தில் இருக்கிறீர்கள் என்று அர்த்தம், அதைச் சரிசெய்வது அவசியம். connect 0.004 வினாடிகளாகவும், ttfb 0.140 வினாடிகளாகவும் இருந்தால், மீதமுள்ள தாமதம் broker-ன் செயலாக்கத்தால் ஏற்படுகிறது; எந்த host மாற்றமும் இதைச் சரிசெய்யாது.

அப்படியானால் host எப்போது முக்கியமானது? நீங்கள் venue-உடன் colocated அல்லது cross-connected ஆக இருந்து, queue நிலையில் போட்டியிடும்போது இது முக்கியமானது; இது வேறு பட்ஜெட் மற்றும் வேறு வணிகம். மேலும் உங்கள் சொந்த code-ல் bottleneck இருக்கும்போது இது முக்கியமானது: ஒவ்வொரு tick-க்கும் முழு வரலாற்றையும் வைத்து indicators-ஐ மீண்டும் கணக்கிடும் ஒரு bot, ஒவ்வொரு loop-க்கும் 200 மில்லி-செகண்ட் CPU-வை வீணாக்கலாம்; இது நீங்கள் இலவசமாகக் கட்டுப்படுத்தக்கூடிய உண்மையான latency ஆகும். வேகமான server-ஐத் தேடுவதற்கு முன், உங்கள் loop-ஐ profile செய்யுங்கள்.

நீங்கள் தேர்ந்தெடுக்கும் host-ல் புவியியல் அமைப்பு, நிலையான நெட்வொர்க்கிங் மற்றும் OOM killer தலையிடாத அளவுக்குப் போதுமான memory ஆகியவை முக்கியம். ஜூலை 2026 நிலவரப்படி, நினைவகத்தில் சில நூறு symbols-ஐக் கொண்ட ஒரு single-strategy Python bot, 2 GB RAM மற்றும் 2 vCPU-வில் சிறப்பாக இயங்கும். நீங்கள் tick வரலாற்றை local database-ல் வைத்திருந்தால், கூடுதல் memory-ஐச் சேர்க்கவும்.

நேரடி பயன்பாட்டிற்கு முந்தைய சரிபார்ப்புப் பட்டியல்

1. systemctl is-enabled tradingbot கட்டளை enabled-ஐ அச்சிடுகிறது, மேலும் sudo reboot-க்கு பிறகும் service தொடர்ந்து இயங்குகிறது.
2. chronyc tracking சில மில்லி விநாடிகளுக்குக் குறைவான system time offset-ஐக் காட்டுகிறது.
3. API key-க்கு வர்த்தகம் செய்யும் அனுமதி உள்ளது, ஆனால் பணம் எடுக்கும் (withdrawal) அனுமதி இல்லை; exchange வசதி இருந்தால், IP allowlist அமைக்கப்பட்டுள்ளது.
4. sudo systemctl kill -s SIGKILL tradingbot மூலம் process-ஐ நிறுத்திய பிறகு, அது RestartSec காலத்திற்குள் மீண்டும் தொடங்குகிறது.
5. நீங்கள் bot-ஐ வேண்டுமென்றே நிறுத்தும் போது, heartbeat monitor ஒரு இடைவெளிக்குள் உங்களுக்கு எச்சரிக்கை (page) அனுப்புகிறது.
6. Logs கட்டுப்படுத்தப்பட்டுள்ளன, மேலும் df -h-ல் root filesystem-க்குத் தேவையான கூடுதல் இடம் (headroom) உள்ளது.

உண்மையான பணத்தைப் பயன்படுத்துவதற்கு முன்பு, ஒரு வாரம் முழுவதையும் exchange-ன் sandbox அல்லது paper mode-ல் இயக்கவும். அந்த வாரத்தில் மேலே உள்ள ஒவ்வொரு அம்சமும் குறைந்தது ஒரு முறையாவது தோல்வியடையும்; அதுவே இந்த வாரத்தின் நோக்கமாகும்.

FAQ

Trading bot-க்கு low-latency அல்லது bare metal server அவசியமா?

அதே தளத்தில் உள்ள பிற தானியங்கி பங்கேற்பாளர்களை விட வேகமான execution தேவைப்பட்டால் மட்டுமே இது அவசியம். இதற்கு பொதுவாக VPS-ஐ விட colocation சிறந்தது. சில்லறை வர்த்தக bot-களைப் பொறுத்தவரை, round trip நேரம் என்பது புவியியல் மற்றும் broker-ன் செயலாக்கத்தையே சார்ந்துள்ளது. எனவே, API endpoint-க்கு அருகில் உள்ள server-ஐத் தேர்வு செய்யவும். எதையும் வாங்குவதற்கு முன் curl மற்றும் mtr மூலம் அளவீடுகளைச் சரிபார்க்கவும்.

Trading bot-க்கு எவ்வளவு RAM மற்றும் CPU தேவை?

பெரும்பாலான ஒற்றை-உத்தி (single-strategy) bot-கள் network-ஐச் சார்ந்தே இயங்குகின்றன, நிகழ்வுகளுக்கு இடையில் இவை செயலற்ற நிலையில் இருக்கும். ஜூலை 2026 நிலவரப்படி, சில நூறு கருவிகளைக் கண்காணிக்கும் Python bot-க்கு 2 vCPU மற்றும் 2 GB RAM போதுமானது. Tick history-ஐ நினைவகத்தில் வைத்திருக்கும்போதோ அல்லது local database-ஐ இயக்கும்போதோ நினைவகம் ஒரு தடையாக மாறலாம். எனவே, ஊகிப்பதற்குப் பதிலாக free -h மற்றும் journal-ல் உள்ள OOM kill செய்திகளைக் கவனிக்கவும்.

எனது exchange API ஏன் timestamp பிழையுடன் கோரிக்கைகளை நிராகரிக்கிறது?

Server-ன் கடிகாரம் exchange-ன் signing window-ஐ விட்டு விலகிவிட்டது; இது பொதுவாக சில வினாடிகள் ஆகும். chrony-ஐ நிறுவி, chronyc tracking மூலம் System time offset குறைவாக இருப்பதையும், leap status ஒத்திசைக்கப்பட்டுள்ளதையும் உறுதிப்படுத்தவும். பகல்நேர சேமிப்பு நேர மாற்றத்தால் பாதிப்பு ஏற்படாமல் இருக்க, machine-ஐ UTC-க்கு அமைக்கவும். API key-ஐ மாற்றுவது கடிகாரப் பிரச்சினையைச் சரிசெய்யாது.

நான் அறியாமல் இரவு நேரத்தில் எனது bot செயலிழப்பதைத் தடுப்பது எப்படி?

அதை systemd-ன் கீழ் Restart=always மற்றும் StartLimitIntervalSec=0 உடன் இயக்கவும். இதனால் crash loop ஏற்பட்டால், நிரந்தரமாக நின்றுவிடாமல் மீண்டும் மீண்டும் முயற்சிக்கும். ஒவ்வொரு வெற்றிகரமான loop-ன் முடிவிலும் bot ஒரு heartbeat-ஐ அனுப்பும்படி அமைக்கவும். Restart வசதி process-ஐக் கவனித்துக்கொள்ளும். Process உயிருடன் இருந்து ஆனால் முடங்கியிருந்தால், இந்த heartbeat அதைக் கண்டறியும்.

Bot-ஐயும் எனது கண்காணிப்பு அமைப்பையும் ஒரே VPS-ல் இயக்கலாமா?

இயக்கலாம், ஆனால் முக்கியமான நேரத்தில் கண்காணிப்பு அமைப்பு தவறான தகவலைத் தரக்கூடும். ஏனெனில், bot-ஐ முடக்கும் ஒரு outage கண்காணிப்பு அமைப்பையும் சேர்த்து முடக்கிவிடும். எச்சரிக்கை அமைப்புகளை (alerting) தனி machine-ல் வைத்திருக்கவும்; முடிந்தால் வெவ்வேறு provider அல்லது பிராந்தியத்தில் வைத்திருக்கவும். Bot-ன் server-ஐ bot மற்றும் அதன் logs-க்கு மட்டுமே பயன்படுத்தவும்.