Trading botக்கு VPS-ல் உண்மையில் முக்கியமானவை என்ன?

Trading botக்கு VPS-இலிருந்து தேவையானவை

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

இது ஒரு engineering guide. இதில் எதுவும் financial advice அல்ல. எந்த strategy பற்றியும் இதில் விவாதிக்கப்படவில்லை.

Uptime என்பது sales page-இல் உள்ள எண்ணிக்கை அல்ல; restart discipline ஆகும்

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

Bot-ஐ systemd service ஆக இயக்கி, restart பொறுப்பை init system-க்கு ஒப்படையுங்கள். Unit file இதை 6 lines-இல் செய்கிறது.

[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 என்பது பலர் தவறவிடும் line ஆகும். இயல்பாக, systemd 10 seconds-இல் 5 restarts ஏற்பட்டதும் முயற்சியை நிறுத்தி, unit-ஐ failed state-இல் நிரந்தரமாக வைத்திருக்கும். 03:00 மணிக்கு நீங்கள் விரும்பாத நடத்தை இதுவே. இதை 0 என அமைத்தால் rate limit முடக்கப்படும். எனவே crash-loop ஆகும் bot அமைதியாக நிற்பதற்குப் பதிலாக தொடர்ந்து முயற்சிக்கும். RestartSec=10 அந்த loop காரணமாக exchange-க்கு தொடர்ச்சியான reconnects அனுப்பப்படுவதைத் தடுக்கிறது.

File-ஐ நம்புவதற்கு முன் சரிபார்த்து, பின்னர் அதை start செய்யுங்கள்:

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 காரணமாக reboots ஏற்படும். Bot அமைதியாக நிறுத்தப்பட்டுக்கொண்டிருக்கிறதா என்பதை அறிய, restart counter-ஐ systemd-யிடம் கேளுங்கள்:

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

ஒரு வாரத்திற்குப் பிறகு NRestarts=0 இருப்பது healthy bot-ஐக் குறிக்கிறது. NRestarts=812 என்பது, இரவு முழுவதும் reconnect ஆகும் process-ஐ நம்பி நீங்கள் trading செய்துள்ளீர்கள் என்பதைக் குறிக்கிறது. Daily report போன்ற scheduled jobs-க்கான timers உட்பட, முழுமையான unit file anatomy systemd service ஆக ஒரு program-ஐ இயக்குதல் பகுதியில் விளக்கப்பட்டுள்ளது.

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

Exchange APIs, requests-இல் timestamp-ஐ பயன்படுத்தி sign செய்கின்றன. குறிப்பிட்ட window-க்கு வெளியிலுள்ள requests-ஐ அவை நிராகரிக்கின்றன. இந்த window பெரும்பாலும் 5 seconds அல்லது அதற்கும் குறைவாக இருக்கும். Clock drift காரணமாக authentication failure போலத் தோன்றும் errors உருவாகலாம். அதனால், நேரத்தைச் சரிபார்ப்பதற்கு முன் மக்கள் பல மணி நேரம் keys-ஐ rotate செய்கின்றனர். Binance-style APIs-இல் message நேரடியாக இருக்கும்: Timestamp for this request was 1000ms ahead of the server's time.

Server-ஐ UTC-க்கு அமைக்கவும். Local time zones, daylight saving jump-ஐ உருவாக்குகின்றன. அது trading session-ன் நடுவில் நிகழலாம்.

sudo timedatectl set-timezone UTC
timedatectl

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

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

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

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

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

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

அடுத்து, secret-ஐ code directory-க்கு வெளியே வைத்திருங்கள். /opt/tradingbot-க்குள் உள்ள எதுவும் விரைவில் git repository அல்லது backup archive-ல் சேரும். systemd மட்டுமே படிக்கக்கூடிய, root-owned file-ல் அதை வையுங்கள்:

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

அந்த file-ல் quotes இல்லாமல், export இல்லாமல், plain KEY=value lines மட்டும் இருக்க வேண்டும். bot group உடன் Mode 640 அமைத்தால் 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

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

உங்கள் broker அறியும் முன் அது செயலிழந்துவிட்டதை கண்டறியவும்

systemctl status process இயங்குகிறது என்று தெரிவிக்கிறது. Bot எந்தச் செயலையும் செய்கிறது என்று அது தெரிவிக்காது. செயலிழந்த websocket-க்கு எதிராக retry loop-ல் சிக்கிய process, systemd செய்யக்கூடிய ஒவ்வொரு சரிபார்ப்பையும் கடந்து விடும்.

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

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

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

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

நேர்மையான பகுதி: latency பெரும்பாலும் உங்கள் host காரணமாக இல்லை

இங்குதான் trading VPS products-க்கான சந்தை technical வரம்பை விட்டு விலகுகிறது. Marketing pages sub-millisecond அளவுகளை மேற்கோள் காட்டி, உங்களுக்கும் order fill-க்கும் இடையில் இருப்பது host எனக் குறிப்பிடுகின்றன. கிட்டத்தட்ட அனைத்து retail bot-களுக்கும் இது உண்மை அல்ல.

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

ஊகிப்பதற்குப் பதிலாக அளவிடுங்கள். curl ஒரு உண்மையான endpoint-க்கான connection மற்றும் 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-இல் commit செய்வதற்கு முன் இதை இயக்குங்கள். connect 0.180 seconds என்றால், நீங்கள் தவறான continent-இல் இருக்கிறீர்கள். அதைச் சரிசெய்வது பயனுள்ளது. connect 0.004 seconds என்றும் ttfb 0.140 seconds என்றும் இருந்தால், மீதமுள்ள delay broker processing காரணமாகும். எந்த host மாற்றமும் அதை மாற்றாது.

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

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

productionக்கு முன் சரிபார்ப்பு பட்டியல்

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

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

FAQ

ஒரு trading bot-க்கு low-latency அல்லது bare metal server தேவையா?

அதே venue-வில் உள்ள பிற automated participants-ஐ execution speed அடிப்படையில் நீங்கள் போட்டியிடும் போது மட்டும் அது தேவைப்படும். அத்தகைய சூழலில் பொதுவான VPS-ஐவிட colocation வழக்கமாகப் பொருத்தமானது. Retail bot-க்கு round trip நேரத்தை geography மற்றும் broker-ன் சொந்த processing ஆகியவை பெரும்பாலும் தீர்மானிக்கும். எனவே API endpoint-க்கு அருகிலுள்ள server-ஐத் தேர்ந்தெடுத்து, வேகமான server-க்கு பணம் செலுத்துவதற்கு முன் curl மற்றும் mtr மூலம் அளவிடுங்கள்.

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

பெரும்பாலான single-strategy bot-கள் network-bound ஆக இருக்கும். Events இல்லாத இடைவெளிகளில் அவை idle நிலையில் இருக்கும். July 2026 நிலவரப்படி, சில நூறு instruments-ஐக் கண்காணிக்கும் Python bot-ஐ 2 vCPU மற்றும் 2 GB RAM கையாளும். Tick history-ஐ process-க்குள் வைத்திருக்கும்போது அல்லது local database-ஐ இயக்கும்போது memory கட்டுப்பாடாகிறது. எனவே ஊகிப்பதற்குப் பதிலாக free -h மற்றும் journal-ஐக் கண்காணித்து OOM kill messages உள்ளதா எனப் பாருங்கள்.

timestamp error காரணமாக எனது exchange API requests-ஐ ஏன் நிராகரிக்கிறது?

Server clock, exchange-ன் signing window-ஐத் தாண்டும் அளவுக்கு drift ஆகியுள்ளது. இது பொதுவாக சில seconds மட்டுமே இருக்கும். chrony-ஐ நிறுவி, chronyc tracking சிறிய System time offset-ஐயும் synchronised leap status-ஐயும் காட்டுகிறது என்பதை உறுதிப்படுத்துங்கள். Daylight saving மாற்றம் clock-ஐ மாற்றாதபடி machine-ஐ UTC-க்கு அமைக்கவும். API key-ஐ மாற்றுவது clock பிரச்சினையைச் சரிசெய்யாது.

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

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

Bot-ஐயும் monitoring-ஐயும் அதே VPS-ல் இயக்கலாமா?

இயக்கலாம். ஆனால் அது முக்கியமான நாளில் தவறான நிலையை உங்களுக்குக் காட்டும். காரணம், bot-ஐ நிறுத்தும் outage monitor-ஐயும் நிறுத்திவிடும். Alerting-ஐ தனி machine-ல் வைத்திருங்கள். முடிந்தால் வேறு provider அல்லது region-ஐப் பயன்படுத்துங்கள். Bot-ன் server-ஐ bot மற்றும் அதன் logs-க்கு மட்டும் பயன்படுத்துங்கள்.