Trading Botları İçin VPS Seçerken Ne Önemli?

Bir trading botun VPS'den gereksinimleri

Trading botları için kullanılan bir VPS dört ölçüte göre değerlendirilir: işlem sonlandığında yeniden başlatılabiliyor mu, sistem saati doğru mu, API (application programming interface) anahtarlarının çalınması zor mu ve bot durduğunda bundan haberdar olunuyor mu. Perakende bir bot için ham hız bu listede oldukça alt sıralardadır. Bunun nedeni, emir akışındaki yavaşlığın VPS'yi çalıştıran ana bilgisayardan değil, brokerdan ve brokerla arasındaki mesafeden kaynaklanmasıdır.

Bu bir mühendislik kılavuzudur. Buradaki hiçbir bilgi finansal tavsiye niteliğinde değildir ve herhangi bir strateji ele alınmamaktadır.

Çalışma süresi (uptime) bir satış sayfasındaki sayı değil, yeniden başlatma disiplinidir

Taahhüt edilen çalışma süresi oranları farklılık gösterir. AWS, tek bir EC2 örneği için en az yüzde 99.5, birden fazla kullanılabilirlik alanına yayılan uygun dağıtımlar için ise yüzde 99.99 oranında çalışma süresi belirtir. Bu taahhütler altyapının erişilebilirliğini kapsar, botunuzun sağlığını değil. Botunuz işlenmemiş bir istisna, yeniden bağlanmayan bir websocket veya OOM (bellek yetersizliği) sonlandırıcı nedeniyle kapanabilir; sunucu ise tüm bu süre boyunca çalışmaya devam eder. Bu nedenle asıl önemli soru, süreciniz kapandıktan sonraki on saniye içinde ne olduğudur.

Botu bir systemd servisi olarak çalıştırın ve yeniden başlatma sorumluluğunu init sistemine bırakın. Bir unit dosyası bunu sağlar.

[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, insanların gözden kaçırdığı satırdır. Varsayılan systemd ayarları, ilk başlatma ve manuel başlatmalar dahil olmak üzere 10 saniye içinde 5 başlatmaya izin verir; yönetici yapılandırması bu varsayılanları geçersiz kılabilir. Sınıra ulaşmak otomatik yeniden başlatma denemelerini durdurur, ancak unit manuel olarak, bir zamanlayıcı veya socket aracılığıyla süre dolduktan sonra başlatılabilir. Bu değeri 0 olarak ayarlamak hız sınırını devre dışı bırakır; böylece sürekli hata veren (crash-loop) bir bot sessizleşmek yerine denemeye devam eder. RestartSec=10, bu döngünün borsayı sürekli yeniden bağlanma istekleriyle yormasını engeller.

Güvenmeden önce dosyayı kontrol edin ve ardından başlatın:

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

enable, yeniden başlatma sonrasında da varlığını koruyan kısımdır; çekirdek güncellemeleri yeniden başlatma gerektirir. Botun sessizce ölüp ölmediğini görmek için systemd'den yeniden başlatma sayacını isteyin:

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

NRestarts=0, sayaç en son sıfırlandığından bu yana gerçekleşen otomatik yeniden başlatma işlerini sayar; sağlıklı veya hatasız bir haftayı kanıtlamaz. Manuel yeniden başlatmalar ve systemctl reset-failed sayacı sıfırlar; donmuş bir bot hala sıfır değerini gösterebilir. NRestarts=812, başarılı borsa bağlantılarını veya işlemleri değil, 812 adet yeniden başlatma işini sayar ve bunların ne zaman gerçekleştiği hakkında bilgi vermez. Bot bağlanmadan önceki hatalar da dahil olmak üzere zamanlama ve neden için journal kayıtlarını kontrol edin. Günlük rapor gibi zamanlanmış işler için zamanlayıcılar da dahil olmak üzere unit dosyasının tam yapısı, bir programı systemd servisi olarak çalıştırma bölümünde ele alınmıştır.

Saati UTC olarak ayarlayın ve senkronize olduğunu doğrulayın

Borsa API'leri, imzalı istekleri doğrulamak için zaman damgalarını kullanır; Binance Spot varsayılan olarak 5 saniyelik bir alım penceresi uygular ve sunucu zamanının en az 1 saniye ilerisindeki zaman damgalarını reddeder. Zaman kayması, kimlik doğrulama hatası gibi görünen hatalara yol açar; bu nedenle kullanıcılar zamanı kontrol etmeden önce saatlerce anahtar rotasyonu yaparlar. Binance tarzı API'lerde mesaj tam olarak şudur: Timestamp for this request was 1000ms ahead of the server's time.

Sunucuyu UTC olarak ayarlayın. Yerel saat dilimleri, görüntülenen zamanlarda gün ışığından yararlanma saati geçişlerine neden olur; API'ler tarafından kullanılan Unix zaman damgaları, görüntüleme saat dilimi değiştiğinde değişmez.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu 25.10 sürümünden itibaren varsayılan olarak chrony kullanır; daha eski kurulumlar, bir SNTP (basit ağ zaman protokolü) istemcisi olan systemd-timesyncd kullanabilir. systemd-timesyncd saati ayarlar ancak yanlış bir zaman kaynağını tespit etmek için aynı anda birden fazla sunucuyu sorgulayamaz. Bunun yerine chrony kullanın:

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

chronyc tracking üzerinden okunacak satır System time şeklindedir, örneğin System time : 0.000031415 seconds fast of NTP time. Küçük bir değer, chrony'nin NTP saati için kalan küçük bir düzeltmeyi gösterir; doğruluğu değerlendirmeden önce senkronizasyonu, Root delay ve Root dispersion komutlarını da kontrol edin. Eğer Leap status : Not synchronised değerini görüyorsanız, sunucular yanıt vermiş olsa bile chrony senkronize olmamıştır; ölçümler çok hatalı olduğu gerekçesiyle reddedilebilir. Güvenlik duvarı kurallarına müdahale etmeden önce bir dakika bekleyin ve tekrar kontrol edin.

API anahtarlarını kopyaladığınız yerlerden uzak tutun

Sızdırılmış bir borsa anahtarı, sızdırılmış bir SSH anahtarından daha tehlikelidir; çünkü çekim izni, anahtarın anında paraya dönüştürülmesine olanak tanır. İki alışkanlık riskin büyük kısmını ortadan kaldırır.

İlk olarak, bir bot anahtarına asla çekim izni vermeyin ve borsa destekliyorsa anahtarı sunucunuzun IP adresine sabitleyin. Çalınan bir anahtarı neredeyse işlevsiz kılan tek kontrol budur.

İkinci olarak, gizli anahtarı kod dizininin dışında tutun. /opt/tradingbot içindeki herhangi bir şey er ya da geç bir git deposuna veya yedekleme arşivine girer. Anahtarı, systemd tarafından okunan ve root sahipliğinde olan bir dosyaya koyun:

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

Dosya, tırnak işareti veya export içermeyen düz KEY=value satırlarını tutar. 640 modu, root kullanıcısına okuma/yazma erişimi, bot grubunun üyelerine ise okuma erişimi verir; diğer kullanıcılar için hiçbir izin tanımlanmaz. sudo -u bot cat /etc/tradingbot/api.env ile doğrulama yapın ve ardından bot grubunun dışındaki yetkisiz bir kullanıcıyla deneyin; bu işlem Permission denied hatasıyla başarısız olmalıdır.

Botun kendisi root veya kendi kullanıcı hesabınızla çalışmamalıdır. Servisi başlatmadan veya bot grubuna ait dosyaları oluşturmadan önce, nologin kabuğuna ve ev dizini olarak /var/lib/tradingbot adresine sahip bir sistem hesabı oluşturun:

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

Bu bayrakların her birinin arkasındaki mantık ve ProtectSystem=strict kısıtlamasının kapsamı yetkisiz kullanıcı olarak servis çalıştırma bölümünde açıklanmıştır. Sunucu temel yapılandırmasının geri kalanı, SSH anahtarları ve güvenlik duvarı, yeni bir VPS üzerinde ilk on dakika bölümünde yer almaktadır.

Brokeriniz fark etmeden önce servisin kapalı olduğunu tespit edin

systemctl status, sürecin çalıştığını belirtir. Ancak bu, botun bir işlem yaptığı anlamına gelmez. Ölü bir websocket bağlantısı karşısında yeniden deneme döngüsünde takılı kalan bir süreç, yukarıdaki birim kontrollerinden başarıyla geçer.

Bunun yerine bir heartbeat (kalp atışı) mekanizması kullanın. Uptime Kuma, push monitörlerine sahiptir: botunuzun belirli bir zaman çizelgesinde bir URL'yi çağırmasını bekler ve çağrı gelmediğinde uyarı verir. Bu çağrıyı, botun canlı olduğunu kanıtlayan başarılı bir piyasa verisi okuma işlemi gibi kritik bir adımdan sonra, ana döngünüzün sonuna yerleştirin.

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

Monitör aralığını, normal gecikmelerin (jitter) size gereksiz bildirim göndermemesi için döngü sürenizin yaklaşık iki katı olarak ayarlayın. Monitörü, botun çalıştığı sunucudan farklı bir sunucuda çalıştırın; çünkü izlediği şeyle birlikte çöken bir monitör hiçbir rapor sunamaz. Kurulum süreci Uptime Kuma ile self-hosted durum izleme rehberinde açıklanmıştır.

Ayrıca bir disk uyarısı ekleyin. Ayrıntılı log yazan bir bot, kök dosya sistemini haftalar içinde dolduracaktır. Disk dolduğunda veritabanı yazma işlemleri durur ancak ağ çağrıları devam edebilir; bu durum yanıltıcı belirtilere yol açar. journalctl --vacuum-time=14d ve /etc/systemd/journald.conf içindeki bir SystemMaxUse= satırı, journal boyutunu sınırlı tutmanızı sağlar.

Dürüst olmak gerekirse: gecikmenin ana sebebi sunucunuz değildir

İşlem (trading) VPS ürünleri pazarının teknik olmaktan çıktığı nokta burasıdır. Pazarlama sayfaları milisaniyenin altında değerler vererek, aranızdaki tek engelin sunucu olduğunu ima eder. Bireysel bot kullanıcılarının neredeyse tamamı için durum böyle değildir.

Emriniz, botunuzdan borsa veya aracı kurum uç noktasına (endpoint) genel internet üzerinden ulaşır. Bu yol üzerindeki temel belirleyiciler fiziksel mesafe ve servis sağlayıcınız ile karşı taraf arasındaki peering bağlantılarıdır. Ardından aracı kurumun kendi sistemleri; kuyruk süreleri, risk kontrolleri ve hız sınırlamaları (rate limits) ile gecikmeye ekleme yapar.

Tahmin etmek yerine ölçüm yapın. curl, gerçek bir uç nokta için bağlantı ve ilk bayt sürelerini raporlar:

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

Bir sunucu kiralamadan önce bu testi aday sunucuda çalıştırın. Eğer connect değeri 0.180 saniye ise, bu süre DNS çözümlemesini ve TCP bağlantısını kapsar; hangi kıtada olduğunuzu tek başına belirlemez. Eğer connect değeri 0.004 saniye ve ttfb değeri 0.140 saniye ise, aradaki fark TLS kurulumunu, istek iletimini, ağ gecikmelerini ve sunucu işleme süresini içerir. Sunucu değişikliği bu bileşenlerin bazılarını etkileyebilir, bu nedenle aday lokasyonlardan alınan ölçümleri karşılaştırın.

Peki sunucu ne zaman önem kazanır? Borsayla aynı veri merkezinde (colocation) bulunduğunuzda veya doğrudan bağlantı (cross-connect) kurduğunuzda ve kuyruk sırası için rekabet ettiğinizde; bu, farklı bir bütçe ve farklı bir iş modelidir. Ayrıca kendi kodunuz darboğaz olduğunda: her tick verisinde tüm geçmişi yeniden hesaplayan bir bot, döngü başına 200 milisaniye CPU harcayabilir; bu, ücretsiz olarak kontrol edebileceğiniz gerçek bir gecikmedir. Daha hızlı bir sunucu aramadan önce döngünüzü profilleyin (profile).

Seçeceğiniz sunucuda önemli olan unsurlar coğrafi konum, kararlı bir ağ yapısı ve OOM killer mekanizmasının asla devreye girmeyeceği kadar yeterli bellektir. Eğer tick geçmişini yerel bir veritabanında tutuyorsanız, belleği artırın.

Canlı ortam öncesi kısa kontrol listesi

1. systemctl is-enabled tradingbot komutu enabled çıktısını verir ve servis sudo reboot sinyalinden sonra çalışmaya devam eder.
2. chronyc tracking komutu senkronizasyon durumunu, birkaç milisaniyenin altında bir sistem saati sapmasını ve zamanlama bütçeniz dahilinde root gecikmesi ile dağılımını raporlar.
3. API anahtarı alım-satım iznine sahiptir, çekim izni yoktur ve borsa tarafından sunuluyorsa IP izin listesi tanımlanmıştır.
4. Süreci sudo systemctl kill -s SIGKILL tradingbot ile sonlandırmak, RestartSec gecikmesi ve başlatma süresinden sonra servisin tekrar ayağa kalkmasını sağlar.
5. Heartbeat monitörü, yapılandırılmış aralıktan sonra size bildirim gönderir ve botu kasıtlı olarak durdurduğunuzda yeniden deneme yapar.
6. Log dosyaları sınırlandırılmıştır ve root dosya sistemi df -h üzerinde yeterli boş alana sahiptir.

Gerçek fonları kullanmadan önce tüm sistemi bir hafta boyunca borsanın sandbox ortamında veya kağıt üzerinde işlem modunda çalıştırın. Yukarıdaki her madde bu hafta içinde en az bir kez başarısız olacaktır; bu haftanın amacı da zaten budur.

FAQ

Bir alım satım botu düşük gecikmeli veya bare metal bir sunucuya ihtiyaç duyar mı?

Yalnızca aynı platformda diğer otomatik katılımcılara karşı işlem hızı konusunda rekabet ediyorsanız gereklidir; bu durum genellikle genel amaçlı bir VPS yerine colocation hizmetini zorunlu kılar. Bireysel bir bot için gidiş-dönüş süresi, coğrafi konum ve aracı kurumun kendi işlem süreci tarafından belirlenir. Bu nedenle API uç noktasına yakın bir sunucu seçin ve daha hızlı bir donanıma ödeme yapmadan önce curl ve mtr ile ölçüm yapın.

Bir alım satım botu ne kadar RAM ve CPU'ya ihtiyaç duyar?

Çoğu tek stratejili bot ağa bağımlıdır ve olaylar arasında boşta bekler. Bellek, tick geçmişini süreç içinde tuttuğunuzda veya yerel bir veritabanı çalıştırdığınızda kısıtlayıcı hale gelir. Bu nedenle tahminde bulunmak yerine free -h değerini ve OOM kill mesajları için günlük kayıtlarını izleyin.

Borsa API'si isteklerimi neden zaman damgası hatasıyla reddediyor?

İstek zaman damgası, borsanın kabul ettiği pencerenin dışındadır; saat sapması ve istek gecikmeleri bu sorunda etkilidir. chrony kurun, chronyc tracking çıktısının küçük bir System time sapması ve senkronize bir leap durumu gösterdiğini doğrulayın; ayrıca root gecikmesini ve dağılımını kontrol edin. Makineyi UTC'ye ayarlamak görüntülenen zamanları tutarlı kılar ancak saat sapmasını düzeltmez. API anahtarını yenilemek saat sorununu çözmez.

Botumun gece ben farkında olmadan durmasını nasıl engellerim?

Botu systemd altında Restart=always ve StartLimitIntervalSec=0 ile çalıştırın; böylece bir çökme döngüsü, başlatma hızı sınırına takılmak yerine yeniden denemeye devam eder. Ardından, botun her başarılı döngünün sonunda gönderdiği bir sinyal (heartbeat) ekleyin. Yeniden başlatma işlemi süreci yönetir. Sinyal ise sürecin canlı olduğu ancak kilitlendiği durumları tespit eder.

Botu ve izleme araçlarımı aynı VPS üzerinde çalıştırabilir miyim?

Çalıştırabilirsiniz ancak botu devre dışı bırakan bir kesinti izleme aracını da beraberinde götüreceği için, izleme aracı en çok ihtiyaç duyduğunuz anda sizi yanıltacaktır. Uyarı sistemini ayrı bir makinede, tercihen farklı bir sağlayıcıda veya bölgede tutun; botun sunucusunu yalnızca bot ve günlük kayıtları için kullanın.