ट्रेडिंग bot साठी VPS मध्ये खरे महत्त्वाचे काय?

ट्रेडिंग bot ला VPS कडून काय आवश्यक असते

ट्रेडिंग bot साठी VPS चे मूल्यमापन चार गोष्टींवर केले जाते: प्रक्रिया बंद पडल्यानंतर पुन्हा सुरू होते का, घड्याळ अचूक आहे का, API (application programming interface) keys चोरी करणे कठीण आहे का, आणि ती थांबल्यावर तुम्हाला कळते का. Retail bot साठी कच्चा वेग या यादीत बराच खाली येतो, कारण तुमच्या order path मधील धीमा भाग म्हणजे तुमचा broker आणि त्याच्यापर्यंतचे अंतर असते; तुमचा Python चालवणारा host नव्हे.

हे engineering मार्गदर्शक आहे. यातील कोणतीही माहिती financial advice नाही आणि कोणत्याही strategy ची चर्चा केलेली नाही.

Uptime म्हणजे विक्री पृष्ठावरील संख्या नव्हे, तर restart शिस्त

जगातील प्रत्येक host 99.9 टक्के uptime ची जाहिरात करतो. हा आकडा hypervisor चे वर्णन करतो, तुमच्या bot चे नाही. unhandled exception, पुन्हा कधीही reconnect न होणारा websocket किंवा OOM (out of memory) killer यांमुळे bot बंद पडतो, आणि server संपूर्ण वेळ सुरू राहतो. त्यामुळे उपयुक्त प्रश्न असा आहे की तुमची process बंद झाल्यानंतरच्या दहा सेकंदांत काय होते.

bot systemd service म्हणून चालवा आणि restart ची जबाबदारी 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 restart नंतर प्रयत्न सोडते आणि unit ला कायमचे failed state मध्ये ठेवते. 03:00 वाजता तुम्हाला नेमके हेच वर्तन नको असते. ते 0 वर सेट केल्यास rate limit अक्षम होते. त्यामुळे crash-loop मध्ये अडकलेला bot शांत न बसता पुन्हा प्रयत्न करत राहतो. RestartSec=10 हा loop exchange वर reconnect चा अतिताण आणण्यापासून थांबवतो.

फाइलवर विश्वास ठेवण्यापूर्वी तिची तपासणी करा. त्यानंतर ती सुरू करा:

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 याचा अर्थ तुम्ही संपूर्ण रात्र reconnect होणाऱ्या process वर trading करत होता. दररोजच्या report सारख्या scheduled jobs साठी timers सह संपूर्ण unit file ची रचना systemd service म्हणून program चालवणे येथे दिली आहे.

घड्याळ UTC वर सेट करा आणि ते समकालित असल्याचे सिद्ध करा

Exchange API timestamp सह विनंत्यांवर स्वाक्षरी करतात आणि एका मर्यादेपेक्षा बाहेरील विनंत्या नाकारतात. ही मर्यादा अनेकदा 5 सेकंद किंवा त्याहून कमी असते. घड्याळातील फरकामुळे authentication failure सारख्या त्रुटी दिसतात. त्यामुळे वेळ तपासण्यापूर्वी लोक अनेक तास keys बदलत राहतात. Binance-style API मध्ये संदेश स्पष्ट असतो: Timestamp for this request was 1000ms ahead of the server's time.

Server UTC वर सेट करा. Local time zones मुळे daylight saving चा बदल होतो. हा बदल trading session च्या मध्यात होऊ शकतो.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu मध्ये systemd-timesyncd उपलब्ध असते. हे SNTP (simple network time protocol) client आहे. Logs साठी ते पुरेसे आहे. परंतु काही milliseconds च्या मर्यादेत वेळ ठेवणे आवश्यक असल्यास ते अपुरे आहे, कारण ते एका server कडून polling करते आणि घड्याळाचे सतत नियमन करत नाही. त्याऐवजी 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. काही milliseconds पेक्षा कमी मूल्य योग्य आहे. जर त्यात Leap status : Not synchronised दिसले, तर chrony अद्याप कोणत्याही server पर्यंत पोहोचलेले नाही. याचे सामान्य कारण outbound UDP 123 अवरोधित असणे हे आहे. एक मिनिट थांबा. Firewall rules मध्ये बदल करण्यापूर्वी पुन्हा तपासा.

API keys कुठेही कॉपी होणाऱ्या ठिकाणी ठेवू नका

गळती झालेली exchange key, गळती झालेल्या SSH key पेक्षा अधिक धोकादायक असते, कारण withdrawal permission मुळे ती लगेच पैशांमध्ये रूपांतरित होऊ शकते. बहुतांश जोखीम कमी करण्यासाठी दोन सवयी पुरेशा आहेत.

पहिले, bot key ला कधीही withdrawal permission देऊ नका. exchange ही सुविधा देत असल्यास, key ला तुमच्या server च्या IP address शी बांधा. चोरीला गेलेली 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 मध्ये quote आणि export नसलेल्या साध्या 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 नसलेले आणि login करण्यासाठी 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 चालवणे येथे दिले आहे. SSH keys आणि firewall यांसह server baseline मधील उर्वरित बाबी नवीन VPS वर पहिल्या 10 मिनिटांत येथे दिल्या आहेत.

तुमच्या broker च्या आधी सेवा बंद असल्याचे शोधा

systemctl status प्रक्रियेस चालू असल्याचे सांगते. Bot प्रत्यक्षात काही कार्य करत आहे, असे ती सांगत नाही. बंद websocket विरुद्ध retry loop मध्ये अडकलेली प्रक्रिया systemd करू शकणाऱ्या प्रत्येक तपासणीत यशस्वी ठरू शकते.

त्याऐवजी heartbeat वापरा. Uptime Kuma मध्ये push monitors आहेत. यामध्ये bot ने ठरावीक वेळापत्रकानुसार URL ला call करणे अपेक्षित असते. Call येणे थांबल्यावर ते alert देते. Main loop च्या शेवटी, bot चालू असल्याचे सिद्ध करणाऱ्या भागानंतर call ठेवा. उदाहरणार्थ, यशस्वी market data read नंतर.

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

Monitor interval तुमच्या loop time च्या साधारण दुप्पट ठेवा. त्यामुळे सामान्य jitter मुळे page होणार नाही. Monitor bot पेक्षा वेगळ्या server वर चालवा. कारण ज्यावर लक्ष ठेवले आहे त्याच्यासोबत monitor बंद झाल्यास तो काहीही report करणार नाही. Setup ची माहिती Uptime Kuma सह self-hosted status monitoring मध्ये दिली आहे.

Disk alert देखील जोडा. Verbose logs लिहिणारा bot काही आठवड्यांत root filesystem भरू शकतो. Disk पूर्ण भरल्यावर network call नव्हे, तर database write थांबते. त्यामुळे लक्षणे विचित्र दिसतात. journalctl --vacuum-time=14d आणि /etc/systemd/journald.conf मधील SystemMaxUse= line journal ची मर्यादा ठेवतात.

प्रामाणिक भाग: विलंबाचा मुख्य कारण तुमचा होस्ट नसतो

ट्रेडिंग VPS उत्पादनांची बाजारपेठ येथे तांत्रिक स्वरूप गमावते. विपणन पृष्ठांवर sub-millisecond आकडे दिले जातात आणि होस्टमुळेच तुम्हाला ऑर्डरची पूर्तता मिळते किंवा नाही, असा आभास निर्माण केला जातो. जवळजवळ प्रत्येक retail bot साठी हे खरे नाही.

तुमची ऑर्डर 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 साठी हा विलंब सहसा tens किंवा hundreds of milliseconds मध्ये मोजला जातो.

अंदाज न लावता त्याचे मोजमाप करा. curl वास्तविक endpoint साठी connection time आणि first-byte time दाखवते:

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

तुम्ही कोणताही candidate server निश्चित करण्यापूर्वी तेथून ही command चालवा. जर connect 0.180 seconds असेल, तर तुम्ही चुकीच्या continent वर आहात. हे दुरुस्त करणे उपयुक्त ठरेल. जर connect 0.004 seconds आणि ttfb 0.140 seconds असेल, तर उरलेला विलंब broker च्या processing मुळे आहे. होस्ट बदलल्याने त्यावर परिणाम होणार नाही.

मग होस्ट कधी महत्त्वाचा ठरतो? तुम्ही venue सोबत colocated किंवा cross-connected असता आणि queue position साठी स्पर्धा करत असता तेव्हा. हा वेगळ्या budget असलेला वेगळा व्यवसाय आहे. तुमचा स्वतःचा code bottleneck असतो तेव्हाही होस्ट महत्त्वाचा ठरतो. प्रत्येक tick वेळी full history वर indicators पुन्हा मोजणारा bot प्रत्येक loop साठी 200 milliseconds CPU time खर्च करू शकतो. हा तुम्ही कोणताही अतिरिक्त खर्च न करता नियंत्रित करू शकणारा वास्तविक विलंब आहे. अधिक वेगवान server घेण्यापूर्वी loop चे profile तयार करा.

तुम्ही निवडलेल्या होस्टमध्ये geography, stable networking आणि OOM killer ला कधीही हस्तक्षेप करण्याची वेळ येऊ नये इतकी memory महत्त्वाची आहे. July 2026 पर्यंत, memory मध्ये काही hundred symbols असलेला single-strategy Python bot 2 GB RAM आणि 2 vCPU वर सहज चालतो. tick history local database मध्ये ठेवत असल्यास memory वाढवा.

प्री-लाइव्ह करण्यापूर्वीची संक्षिप्त तपासणीसूची

1. systemctl is-enabled tradingbot enabled दर्शवते आणि सेवा sudo reboot नंतरही सुरू राहते.
2. chronyc tracking प्रणालीच्या वेळेतील फरक काही मिलीसेकंदांपेक्षा कमी असल्याचे दर्शवते.
3. API key ला trading परवानगी आहे, withdrawal परवानगी नाही आणि exchange अशी सुविधा देत असल्यास IP allowlist कॉन्फिगर केलेली आहे.
4. sudo systemctl kill -s SIGKILL tradingbot वापरून process बंद केल्यावर तो RestartSec च्या आत पुन्हा सुरू होतो.
5. bot मुद्दाम थांबवल्यावर heartbeat monitor एका interval च्या आत तुम्हाला page पाठवतो.
6. Logs ची मर्यादा निश्चित केलेली आहे आणि df -h मध्ये root filesystem वर पुरेशी मोकळी जागा आहे.

वास्तविक निधी वापरण्यापूर्वी संपूर्ण प्रक्रिया exchange च्या sandbox मध्ये किंवा paper mode मध्ये एक आठवडा चालवा. वरील प्रत्येक बाब त्या आठवड्यात किमान एकदा अपयशी ठरते. हाच त्या आठवड्याचा उद्देश आहे.

FAQ

ट्रेडिंग bot साठी कमी-latency किंवा bare metal server आवश्यक आहे का?

तुम्ही त्याच venue वर सहभागी असलेल्या इतर स्वयंचलित सहभागींपेक्षा execution speed मध्ये स्पर्धा करत असाल, तरच आवश्यक आहे. अशा वेळी सामान्य-purpose VPS ऐवजी colocation आवश्यक असते. Retail bot साठी round trip वर geography आणि broker ची स्वतःची processing यांचा अधिक प्रभाव असतो. त्यामुळे API endpoint जवळचा server निवडा आणि अधिक वेगवान server साठी पैसे देण्यापूर्वी curl आणि mtr वापरून मोजमाप करा.

ट्रेडिंग bot साठी किती RAM आणि CPU आवश्यक आहे?

बहुतेक single-strategy bot network-bound असतात आणि events दरम्यान निष्क्रिय असतात. July 2026 पर्यंत, काहीशे instruments track करणाऱ्या 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 install करा. chronyc tracking मध्ये लहान System time offset आणि synchronised leap status दिसत असल्याची खात्री करा. Machine UTC वर set करा, जेणेकरून daylight saving change मुळे clock shift होणार नाही. API key rotate केल्याने clock problem सुटत नाही.

माझ्या माहितीशिवाय bot रात्रभर बंद पडू नये यासाठी काय करावे?

bot systemd अंतर्गत Restart=always आणि StartLimitIntervalSec=0 सह चालवा. त्यामुळे crash loop कायमचा थांबण्याऐवजी पुन्हा प्रयत्न करत राहील. त्यानंतर प्रत्येक successful loop च्या शेवटी bot पाठवेल असा heartbeat जोडा. Restart मुळे process पुन्हा सुरू होतो. Process जिवंत असला पण अडकलेला असण्याची स्थिती heartbeat मुळे समजते.

Bot आणि monitoring एकाच VPS वर चालवू शकतो का?

चालवू शकता. मात्र आवश्यक त्या दिवशी monitoring तुम्हाला चुकीची माहिती देईल, कारण bot बंद पाडणारा outage monitoring देखील बंद पाडेल. Alerting वेगळ्या machine वर ठेवा. शक्य असल्यास वेगळा provider किंवा region वापरा. Bot चा server फक्त bot आणि त्याच्या logs साठी वापरा.