Simple Execution Process
สำหรับ execution process นี้เป็นส่วนหนึ่งของระบบ Execution Management System (EMS) เวอร์ชั่นแรกที่ผมออกแบบโดยเน้นความเรียบง่าย เพื่อให้สามารถใช้เทรดได้ทุก symbol และทุกตลาด แต่ในความเรียบง่ายนี้ก็มีข้อจำกัดบ้างคือ 1 bot / 1 trade model / 1 symbol / 1 position / 1 microservice ในอนาคตผมจะออกแบบและพัฒนาระบบ execution ใหม่ๆ ขึ้นมาอีก เพื่อให้รองรับรูปแบบของบอทและกลยุทธ์การเทรดที่หลากหลายขึ้น
Two Trading States Processing Design Pattern
อธิบายหลักการ Two Trading States Processing ซึ่ง state แรกอาจเรียกว่า passive state หรือจังหวะทำ passive prediction และ state ที่สองอาจเรียกว่า active state หรือจังหวะทำ active prediction
ข้อสังเกตเพื่อให้จำง่ายๆ คือ state แรกไม่ต้องใช้ข้อมูลสถานะบัญชี, พอร์ตโฟลิโอ, positions, trades, orders แต่ใน state ที่สองจำเป็นต้องใช้ ดังนั้นใน state แรกจึงใช้แค่ข้อมูลราคาและ fundamental ก็พอ จึงสามารถประมวลผลแบบ vectorize ได้ทำให้รันได้เร็วประหยัดเวลา แต่ state ที่สองข้อมูลสถานะต่างๆ มีค่าเปลี่ยนไปเรื่อยๆ ตามเวลาที่เปลี่ยนไป จึงเหมาะกับการประมวลผลแบบ interval หรือแบบ loop มากกว่า ซึ่งใช้เวลามากกว่าการประมวลผลแบบ vectorize
ขณะบอทรัน ตอนที่ feed ข้อมูลราคาให้บอท ตามเลือกว่าจะ feed ข้อมูลพอร์ตฯ ข้อมูลบัญชี ข้อมูลออร์เดอร์ที่ค้างอยู่ ฯลฯ ให้พร้อมกันไปด้วยมั้ย
Architecture View: Architecture Overview (รออัพเดต)
ภาพรวมของ DeepQuant Algorithmic System Architecture คือ มีชุดโรบอทกระจายไปเทรดในหลาย cloud instance เพื่อเทรดในหลายตลาด ซึ่งสามารถติดตามการทำงานและการลงทุนได้ผ่าน mobile app โดยมีรายละเอียดดังนี้
- หัวใจสำคัญของ architecture นี้คือการเป็น unified architecture ที่ช่วยให้สร้างโรบอทเทรดได้ในหลายตลาดและหลายแพลตฟอร์ม เนื่องจากแต่ละตลาดมักมีหลายแพลตฟอร์ม เช่น ตลาด FOREX มีทั้ง MT4, OANDA Open API และอีกหลายแพลตฟอร์ม
- Unified architecture ครอบคลุมทั้งด้าน architectural process (กระบวนการทำงานของระบบ), data schema (มี data schema กลางสำหรับ position, order, account), market/exchange gateway (ระบบเชื่อมต่อกับตลาด/โบรกเกอร์/exchange ที่ใช้ common interface เดียวกัน), model & robot template (เทมเพลตโค้ดและโมเดล) ซึ่งช่วยลด learning curve ให้แก่ผู้ใช้ ไม่ต้องไปเรียนรู้แพลตฟอร์มในตลาดต่างๆ ที่มีมากมายและหลากหลายมาก ทั้งหลายภาษาโปรแกรม, หลายเทคโนโลยี ฯ กล่าวสั้นๆ คือ เหนื่อยศึกษาครั้งแรกทีเดียว ก็สามารถสร้างโรบอทเทรดได้ในหลายตลาด ซึ่งการสร้างโมเดลและโรบอทในการเทรดในแต่ละตลาดมีส่วนแตกต่างกันเพียงเล็กน้อยเท่านั้น ทำให้ผู้ใช้ไปมุ่งเน้นที่การสร้างโมเดลและโรบอทได้เต็มที่
- ผู้ใช้ติดตามพอร์ตโฟลิโอ, การทำงานของโรบอท และปรับค่า strategy setting ผ่าน mobile app
- มีระบบกลาง (control system) ที่ช่วยเชื่อมต่อกับระบบติดตามการทำงานของชุดโรบอทต่างๆ (monitoring system)
- แต่ละชุดโรบอทประกอบด้วย trading robot และ trading model หลายตัว ที่เทรดในตลาดเดียวกันและโบรกเกอร์หรือ exchange เดียวกัน
- แต่ละชุดโรบอททำงานอยู่ใน container (Docker) เพื่อสะดวกในด้าน portability เช่น การรับส่งชุดไฟล์, การนำไปใช้, การก๊อปปี้แจกไฟล์ให้สมาชิกในกลุ่ม deepquant, การติดตั้ง ฯ
- แต่ละชุดโรบอทมีเซอร์วิสด้าน log agent และ metrics agent เพื่อทำหน้าที่ส่ง log (สถานะการทำงานของโรบอทและสถานะพอร์ตโฟลิโอกับสถานะบัญชี) กับ metrics (สถานะการใช้ทรัพยากรเครื่อง เช่น ซีพียู, หน่วยความจำ, ดิสก์ ฯ) ไปยังระบบ monitoring system ซึ่งรับผิดชอบโดยชุด ELK stack (elasticsearch, logstash, kibana), Prometheus
- ข้อมูล log ซึ่งปกติเป็น text เก็บลงในฐานข้อมูล elasticsearch ซึ่งเก่งในด้าน full text search ช่วยให้ค้นหาข้อความ เช่น operation log, error message, json payload เป็นต้น
- ข้อมูล metrics ซึ่งเป็นปกติเป็นข้อมูลตัวเลข เก็บลงระบบ Prometheus
- ใน Docker ของชุดโรบอท ประกอบด้วยเซอร์วิส web ซึ่งใช้ Flask เป็น web server ขนาดเล็ก เนื่องจากโรบอทไม่ได้ทำงานหนัก ไม่ได้รับโหลดหนักมาก, ใช้ Redis เป็น cache เพื่อใช้พักข้อมูล, ใช้ InfluxDB เป็น time series database เพื่อเก็บข้อมูลราคาและข้อมูลอื่นๆ ที่ชุดโรบอทใช้
- ใน Docker ของชุดโรบอท ยังมีเซอร์วิส log agent กับ metrics agent อยู่ด้วย
- ใน Docker ของบางชุดโรบอท มีเซอร์วิสระบบ data feed รันอยู่ด้วย เช่น ชุดโรบอทที่เทรด TFEX ผ่าน Settrade Open API, ชุดโรบอทที่เทรด crypto เป็นต้น
- *NOTE: architecture นี้ไม่ได้ตั้งใจออกแบบเพื่อจะไปประกวดชิงรางวัลที่ไหน ดังนั้นยังมีอีกหลายจุดมากที่ยังต้องได้รับการปรับปรุง และยังสามารถพัฒนาต่อยอดให้ฉลาดและสมบูรณ์ขึ้นได้อีกมาก มาช่วยๆ กันครับ ^^
Architecture View: Data Pipeline (ตัวเก่า)
*NOTE: กลไกตัวนี้เลิกใช้แล้ว เนื่องจากเวอร์ชั่นปัจจุบันได้แยกโมเดล ML/DL/RL ออกไป โดยมี REST API มาครอบ เพื่อความสะดวกในการจัดการโมเดล ML/DL/RL มากขึ้น แต่บทความนี้ผมไม่ได้ลบ เนื่องจากเก็บไว้ให้ศึกษา และเผื่อนำบางส่วนมาใช้หรือพัฒนาต่อยอดได้ในอนาคต
กลไกส่วน distributed data pipeline using asynchronous messaging, dataset mapping และสรุป use case ของการใช้ data คร่าวๆ ทั้งส่วน price, indicators, features, trade dataกลไกนี้สามารถรันแบบ local บนเครื่องเดียวกับ frontend robot (MT4/5, cTrader, Amibroker) และ backend robot (Python) ได้ หรือจะแบ่งส่วนกระจายรันหลายเครื่องก็ได้
Data Joint in Data Pipeline
เวลาออกแบบสถาปัตยกรรมระบบ ผมชอบกำหนด ‘ข้อต่อ’ ไว้หลายจุดเพื่อใช้เป็นจุดเชื่อมต่อส่วนต่างๆ ในโครงสร้างสถาปัตยกรรม ไม่ให้มี coupling ต่อกันโดยตรง
เช่น ระหว่างเลเยอร์กับเลเยอร์, ระหว่าง subsystem กับ subsystem, ระหว่างระบบกับระบบ, ระหว่าง domain กับ domain โดยเฉพาะสิ่งที่อยู่กันคนละ boundary แล้วต้อง interoperate กัน ก็จะไม่ให้มันคุยกันตรงๆ ต้องคุยกันผ่าน ‘ข้อต่อ’ เท่านั้น (ยอมช้านิดแต่ยืดหยุ่น)
ผมชอบเรียกจุดข้อต่อนี้ว่า ‘joint’ เช่น จุดที่ใช้ pattern พวก Adapter, Proxy, Facade, Front Controller, Proactor, Reactor, Gateway, DAO, Interceptor,…
Architecture View: Domain Model (รออัพเดต)
Domain Model ในส่วน Strategy Robot กับ Trading Robot ไม่รวมส่วน Execution Management กับ Portfolio Management
=========================
Domain Model มีประโยชน์ในการ capture องค์ความรู้หลัก (domain knowledge) ของระบบงานออกมา อธิบายโครงสร้างและความสัมพันธ์ระหว่างกัน แบ่งองค์ประกอบสำคัญออกเป็นส่วนๆ เพื่อช่วยให้เข้าใจภาพรวม และใช้ขับเคลื่อนการออกแบบสถาปัตยกรรมระบบและบริหารระบบ
=========================
แบ่งออกเป็น 4 โดเมนหลักได้แก่
- Trading endpoint domain (สีเขียว)
- Robot domain (สีแดง)
- Data domain (สีเหลือง)
- model domain (สีฟ้า)
Architecture View: Architectural Drivers
Architectural Driver คือ ปัจจัยขับเคลื่อนการออกแบบและการทำงานในส่วนสถาปัตยกรรมระบบ เน้นที่ Quality Attribute หรือ คุณภาพระบบ
คุณภาพของสถาปัตยกรรมระบบที่ออกแบบขึ้น มุ่งเน้นไปที่คุณภาพหลักดังนี้: Reliability, Availability, Modifiability, Usability, Interoperability, Testability, Manageability, Performance
Parallel Computing กับ Distributed Computing (รออัพเดต)
parallel computing กับ distributed computing ต่างกันยังไง? และใช้ร่วมกันได้ยังไง?
เหตุผลที่เลือกใช้ InfluxDB เก็บราคาและ time series data
เราใช้ influxdb (https://www.influxdata.com/products/influxdb-overview/) ในระบบเรา (รันอยู่ใน docker) ในการเก็บข้อมูลประเภท time series data เช่น ราคา, trade action, trade statistics, trade position ฯ
ส่วนเหตุผล (design rationale) ที่ผมเลือกใช้ InfluxDB คือ
- เป็น time series database อันดับต้นๆ เลย
- doc ดีมาก มีตัวอย่างเยอะ มี REST API
- คนใช้เยอะ benchmark ดี
- ผมถามเพื่อนๆ น้องๆ ที่รู้จัก ที่เค้าใช้ในสเกลใหญ่ๆ เค้าแนะนำ influxdb
- มันขึ้นชื่อเรื่องเร็วมาก
- คำสั่งเป็น SQL คล้าย SQL ใน RDBMS ทำให้เรียนรู้ไม่ยาก
- รองรับฟังก์ชั่น, การคำนวณ และการทำงานแบบ time series เช่น การ aggregate ตามเวลา, insert or update โดยเช็กจาก time ซึ่งอันนี้สะดวกมาก เหมาะกับงานเราสุดๆ เวลามีราคาใหม่ฟีดเข้ามา แต่แท่งยังไม่จบก็ update ทับ แต่ถ้าขึ้นแท่งราคาใหม่ก็ insert
- รูปแบบการตั้ง index (tag) ก็เหมาะกับงานเราดี
- มี official python library และอัพเดตบ่อยใช้ได้
ประยุกต์ Software Product Line ใช้ในระบบ Algo Trading
Software Product Line เน้นเรื่องการสร้าง reusable asset เพื่อจะได้ประหยัดเวลา ค่าใช้จ่าย และหยาดเหงื่อ ในการพัฒนาระบบ (โปรดักต์) ใหม่ๆ
ระบบ algorithmic trading ของเรา ผมจึงผสาน software product line architecture เข้าไปด้วย…. เพราะเป้าหมายส่วนตัวของผมเอง ผมจะสร้างโรบอทหลายสิบ หรือกว่าร้อยตัว จึงต้องเน้นคุมโครงสร้างโรบอทให้มีเอกภาพ เพื่อจะให้มี resilient สูง (ยืดหยุ่นสูง) จะได้ปรับปรุงและสร้างโรบอทเพิ่มได้ง่ายในอนาคต