Trading bot-এর VPS-এ আসলে কী গুরুত্বপূর্ণ?

একটি trading bot-এর VPS থেকে যা প্রয়োজন

trading bot-এর জন্য VPS সাধারণত চারটি বিষয়ের ভিত্তিতে মূল্যায়ন করা হয়: process বন্ধ হয়ে গেলে সেটি কি আবার চালু হয়, clock কি সঠিক থাকে, API (application programming interface) key চুরি করা কি কঠিন, এবং bot বন্ধ হলে আপনি কি তা জানতে পারেন। retail bot-এর ক্ষেত্রে raw speed এই তালিকায় অনেক নিচে থাকে। কারণ order path-এর ধীরতম অংশ হলো আপনার broker এবং তার সঙ্গে দূরত্ব, Python চালানো host নয়।

এটি একটি engineering guide। এখানে কোনো financial advice নেই এবং কোনো strategy নিয়ে আলোচনা করা হয়নি।

Uptime হলো restart discipline, sales page-এর একটি সংখ্যা নয়

পৃথিবীর প্রতিটি host 99.9 percent uptime প্রচার করে। এই সংখ্যা hypervisor-এর uptime বোঝায়, আপনার bot-এর নয়। Unhandled exception, reconnect না করা websocket, অথবা OOM (out of memory) killer-এর কারণে bot বন্ধ হয়ে যেতে পারে, অথচ server পুরো সময় চালু থাকতে পারে। তাই কার্যকর প্রশ্ন হলো, আপনার process বন্ধ হওয়ার পরের 10 seconds-এ কী ঘটে।

Bot-কে systemd service হিসেবে চালান এবং restart-এর দায়িত্ব init system-কে দিন। একটি unit file ছয়টি line-এ এটি করতে পারে।

[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টি restart-এর পর চেষ্টা বন্ধ করে এবং unit-কে স্থায়ীভাবে failed state-এ রেখে দেয়। 03:00-এ আপনি ঠিক এই আচরণ চান না। এটিকে 0 সেট করলে rate limit নিষ্ক্রিয় হয়। ফলে crash-loop-এ পড়া bot নীরব হয়ে না থেকে পুনরায় চালু হওয়ার চেষ্টা করতে থাকে। RestartSec=10 এই loop-কে exchange-এ অতিরিক্ত reconnect পাঠানো থেকে থামায়।

File-টি বিশ্বাস করার আগে পরীক্ষা করুন, তারপর এটি চালু করুন:

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-এর ওপর নির্ভর করে trading করেছেন যা সারা রাত reconnect করেছে। Daily report-এর মতো scheduled jobs-এর timer-সহ সম্পূর্ণ unit file anatomy systemd service হিসেবে একটি program চালানো-এ ব্যাখ্যা করা হয়েছে।

ঘড়ির সময় UTC-তে সেট করুন এবং এটি সিঙ্ক্রোনাইজড প্রমাণ করুন

এক্সচেঞ্জ API-গুলো টাইমস্ট্যাম্প দিয়ে রিকোয়েস্টে স্বাক্ষর করে এবং নির্দিষ্ট সময়সীমার বাইরে থাকা যেকোনো রিকোয়েস্ট প্রত্যাখ্যান করে। এই সময়সীমা প্রায়ই 5 সেকেন্ড বা তারও কম হয়। ঘড়ির সময় সরে গেলে এমন ত্রুটি দেখা দেয়, যা authentication ব্যর্থতার মতো মনে হয়। তাই সময় পরীক্ষা করার আগে অনেকে ঘণ্টার পর ঘণ্টা key পরিবর্তন করতে থাকেন। Binance-ধরনের API-তে বার্তাটি সরাসরি: Timestamp for this request was 1000ms ahead of the server's time।

সার্ভারের সময় UTC-তে সেট করুন। স্থানীয় time zone ব্যবহার করলে daylight saving-এর কারণে সময় এক ধাপে পরিবর্তিত হবে। এই পরিবর্তন trading session-এর মাঝখানে ঘটতে পারে।

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu-তে systemd-timesyncd থাকে। এটি একটি SNTP (simple network time protocol) client। Log-এর জন্য এটি যথেষ্ট। তবে কয়েক মিলিসেকেন্ডের সীমার মধ্যে সময় ধরে রাখতে হলে এটি দুর্বল, কারণ এটি একটি server-কে poll করে এবং ঘড়ির সময়কে ধারাবাহিকভাবে নিয়ন্ত্রণ করে না। এর পরিবর্তে 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। কয়েক মিলিসেকেন্ডের কম মান স্বাভাবিক। যদি মানটি 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-এ চলে যায়। এটি এমন একটি root-owned file-এ রাখুন, যা শুধু 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

ফাইলটিতে উদ্ধৃতিচিহ্ন ছাড়া এবং কোনো export ছাড়া সাধারণ KEY=value line থাকবে। 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

এই flag-গুলোর প্রতিটির কারণ এবং ProtectSystem=strict আসলে কত দূর পর্যন্ত কার্যকর হয়, তা unprivileged user হিসেবে services চালানো-এ ব্যাখ্যা করা হয়েছে। server baseline-এর বাকি অংশ—SSH keys এবং firewall—নতুন VPS-এ প্রথম দশ মিনিট-এ রয়েছে।

আপনার ব্রোকারের আগে বুঝে নিন যে এটি বন্ধ

systemctl status দেখায় যে প্রসেসটি চলছে। এটি দেখায় না যে বট কোনো কাজ করছে। বন্ধ websocket-এর বিরুদ্ধে retry loop-এ আটকে থাকা প্রসেস systemd-এর প্রতিটি পরীক্ষা পাস করতে পারে।

এর পরিবর্তে heartbeat ব্যবহার করুন। Uptime Kuma-তে push monitor আছে। এটি প্রত্যাশা করে যে আপনার বট নির্দিষ্ট সময়সূচি অনুযায়ী একটি URL-এ কল করবে। কল আসা বন্ধ হলে এটি সতর্কবার্তা দেয়। আপনার main loop-এর শেষে কলটি যোগ করুন। এটি এমন অংশের পরে রাখুন যা বট সচল থাকার প্রমাণ দেয়, যেমন সফল market data পড়া।

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

মনিটরের interval আপনার loop time-এর প্রায় দ্বিগুণ নির্ধারণ করুন। এতে স্বাভাবিক jitter-এর কারণে অপ্রয়োজনীয় page হবে না। মনিটরটি বটের থেকে আলাদা server-এ চালান। কারণ যে জিনিসটি এটি পর্যবেক্ষণ করে, তার সঙ্গেই মনিটর বন্ধ হয়ে গেলে এটি কোনো প্রতিবেদন দিতে পারে না। Setup-এর বিবরণ Uptime Kuma দিয়ে self-hosted status monitoring-এ আছে।

এছাড়া disk alert যোগ করুন। verbose log লিখলে একটি বট কয়েক সপ্তাহের মধ্যে root filesystem পূর্ণ করে ফেলতে পারে। Disk পূর্ণ হলে network call নয়, database write বন্ধ হয়। তাই লক্ষণগুলো অস্বাভাবিক দেখায়। journalctl --vacuum-time=14d এবং /etc/systemd/journald.conf-এ একটি SystemMaxUse= line journal-এর আকার সীমাবদ্ধ রাখে।

সৎ কথাটি: লেটেন্সির প্রধান কারণ সাধারণত আপনার host নয়

এখানেই trading VPS পণ্যের বাজার প্রযুক্তিনির্ভর থাকা বন্ধ করে। Marketing পৃষ্ঠাগুলো sub-millisecond পরিসংখ্যান দেখায় এবং এমন ধারণা দেয় যে আপনার order পূরণ হওয়ার পথে host-ই প্রধান বাধা। প্রায় সব retail bot-এর ক্ষেত্রে তা নয়।

আপনার order bot থেকে public internet ব্যবহার করে exchange বা broker endpoint-এ যায়। এই পথের লেটেন্সি মূলত ভৌগোলিক দূরত্ব এবং আপনার provider ও তাদের provider-এর মধ্যকার peering দ্বারা নির্ধারিত হয়। Frankfurt-এর একটি server থেকে Tokyo-এর endpoint-এ সংযোগ করলে CPU যত দ্রুতই হোক, round trip-এ প্রায় 250 milliseconds লাগবে। এরপর broker-এর নিজস্ব queue, risk check এবং rate limit যুক্ত হয়। Retail account-এর ক্ষেত্রে এগুলো সাধারণত কয়েক দশক বা কয়েক শত 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

আপনি কোনো server নেওয়ার সিদ্ধান্তের আগে candidate server থেকে এটি চালান। যদি connect 0.180 seconds হয়, তাহলে server-টি ভুল মহাদেশে রয়েছে এবং সেটি পরিবর্তন করা সার্থক। যদি connect 0.004 seconds এবং ttfb 0.140 seconds হয়, তাহলে বাকি বিলম্ব broker-এর processing-এর কারণে হচ্ছে। কোনো host পরিবর্তন করে এটি কমানো যাবে না।

তাহলে host কখন গুরুত্বপূর্ণ? যখন আপনি venue-এর সঙ্গে colocated বা cross-connected অবস্থায় queue position-এর জন্য প্রতিযোগিতা করছেন। এটি ভিন্ন বাজেটের একটি ভিন্ন ব্যবসা। আপনার নিজের code bottleneck হলেও host গুরুত্বপূর্ণ। যেমন, একটি bot প্রতিটি tick-এ সম্পূর্ণ history-এর ওপর indicator পুনরায় গণনা করলে প্রতি loop-এ CPU-এর 200 milliseconds ব্যয় হতে পারে। এটি এমন বাস্তব লেটেন্সি, যা আপনি কোনো অতিরিক্ত খরচ ছাড়াই নিয়ন্ত্রণ করতে পারেন। দ্রুততর server খোঁজার আগে loop-টির profile নিন।

আপনার বেছে নেওয়া host-এর ক্ষেত্রে গুরুত্বপূর্ণ বিষয় হলো geography, স্থিতিশীল networking এবং পর্যাপ্ত memory, যাতে OOM killer-এর কোনো প্রভাব না থাকে। July 2026 অনুযায়ী, memory-তে কয়েক শত symbol থাকা একটি 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-তে ট্রেডিংয়ের অনুমতি আছে, withdrawal-এর অনুমতি নেই এবং exchange এ সুবিধা দিলে IP allowlist কনফিগার করা আছে।
4. sudo systemctl kill -s SIGKILL tradingbot দিয়ে প্রসেস বন্ধ করলে সেটি RestartSec-এর মধ্যে আবার চালু হয়।
5. আপনি ইচ্ছাকৃতভাবে bot বন্ধ করলে heartbeat monitor এক interval-এর মধ্যেই আপনাকে page করে।
6. Logs-এর আকার সীমাবদ্ধ এবং df -h-এ root filesystem-এ পর্যাপ্ত খালি জায়গা আছে।

আসল funds ব্যবহারের আগে exchange-এর sandbox অথবা paper mode-এ পুরো প্রক্রিয়াটি এক সপ্তাহ চালান। ওই সপ্তাহে উপরের প্রতিটি বিষয় অন্তত একবার ব্যর্থ হবে। এক সপ্তাহ চালানোর উদ্দেশ্যই এটি যাচাই করা।

FAQ

ট্রেডিং বটের কি কম-লেটেন্সি বা bare metal server প্রয়োজন?

শুধু তখনই প্রয়োজন, যখন একই venue-তে অন্য স্বয়ংক্রিয় অংশগ্রহণকারীদের সঙ্গে execution speed নিয়ে প্রতিযোগিতা করছেন। সে ক্ষেত্রে সাধারণত general purpose VPS-এর বদলে colocation ব্যবহার করা হয়। Retail bot-এর ক্ষেত্রে round trip মূলত ভৌগোলিক দূরত্ব এবং broker-এর নিজস্ব processing-এর কারণে নির্ধারিত হয়। তাই API endpoint-এর কাছাকাছি একটি server বেছে নিন এবং আরও দ্রুত server-এর জন্য অর্থ দেওয়ার আগে curl ও mtr দিয়ে মাপ নিন।

ট্রেডিং বটের কত RAM এবং CPU প্রয়োজন?

বেশিরভাগ single-strategy bot network-bound থাকে এবং event-এর মাঝের সময়ে idle থাকে। July 2026 অনুযায়ী, 2 vCPU এবং 2 GB RAM কয়েকশো instrument track করা একটি Python bot চালানোর জন্য যথেষ্ট। Process-এর মধ্যে tick history ধরে রাখলে বা local database চালালে memory সীমাবদ্ধতা হয়ে দাঁড়ায়। তাই অনুমান না করে free -h এবং journal-এ OOM kill message monitor করুন।

Timestamp error দেখিয়ে আমার exchange API request প্রত্যাখ্যান করে কেন?

Server clock-এর সময় exchange-এর signing window-এর বাইরে drift করেছে, সাধারণত কয়েক সেকেন্ড। chrony install করুন। chronyc tracking-এ অল্প System time offset এবং synchronised leap status দেখাচ্ছে কি না নিশ্চিত করুন। Machine-টি UTC-তে সেট করুন, যাতে daylight saving change-এর কারণে সময় কখনও বদলে না যায়। API key ঘোরালে clock-এর সমস্যা ঠিক হয় না।

আমাকে না জানিয়ে রাতে বট বন্ধ হয়ে যাওয়া কীভাবে রোধ করব?

Restart=always এবং StartLimitIntervalSec=0 ব্যবহার করে systemd-এর অধীনে এটি চালান। এতে crash loop স্থায়ীভাবে বন্ধ না হয়ে পুনরায় চেষ্টা করতে থাকবে। এরপর প্রতিটি সফল loop-এর শেষে bot যে heartbeat পাঠাবে, তা যোগ করুন। Restart process পরিচালনা করে। Process চালু থাকলেও আটকে গেলে heartbeat সেই অবস্থা শনাক্ত করে।

একই VPS-এ কি বট এবং monitoring চালাতে পারি?

পারেন। তবে যেদিন এটি গুরুত্বপূর্ণ হবে, monitoring আপনাকে ভুল তথ্য দেবে। কারণ bot বন্ধ করে দেওয়া outage একই সঙ্গে monitor-কেও বন্ধ করে দেবে। Alerting আলাদা machine-এ রাখুন, সম্ভব হলে ভিন্ন provider বা region-এ। Bot-এর server শুধু bot এবং তার log-এর জন্য ব্যবহার করুন।