FX自動取引システム「jiji」のバージョンアップ構想

追記(2015-12-01):

FXシステムトレードフレームワーク「Jiji」の新バージョンをリリースしました!

jiji2.unageanu.net

使ってみて、ご意見など頂けるとうれしいです。

---

ContainerJSのメンテがひと段落したところで、次は jijiです。 初版をリリースしてから6年近く。いい加減 ruby2.x には対応しないとなー、今作るならこんな風にするかなー、というネタも入れて構想をまとめてみました。

こんな機能も欲しいとかあれば、コメントなどでご意見いただければ嬉しいです。 すでに少し実装しているので、反響があったらGitHubにPushするよ!!

スマホ対応と、エージェントとのインタラクション

• スマホに対応。モバイルファーストに。

  • 外出先でも、スマホから手軽に取引状況をチェックできるようにする。
  • バックテストの開始やテスト結果の確認もスマホから空き時間にできるようにしたい。
    
    

• エージェントとのインタラクションに対応する

  • スマホ時代になって、「システムからの通知をリアルタイムに受け取ってアクションを返す」ことが現実的にできるようになってきた。
  • jijiのエージェントにも、エージェントから通知を送ったり、命令を受け付ける仕組みを用意して、 プログラムによる完全自動取引に加えて、「裁量での取引をプログラムがアシストする」形のシステムも作れるようにしたい。

  • 具体的には、以下のような使い方ができるかと。
    
    

  • 1. 指標のPush通知で裁量トレード

    • カスタマイズ可能な汎用指標通知システムとして使うモデル。
    • エージェントで指標を監視して、取引のタイミングでPush通知を送る
    • 通知を受けて、人が判断して取引を実行
      
      

  • 2. ロスカットをシステム化して徹底

    • 裁量でトレードするけど、ポジションの管理とロスカットはシステムで強制的に実行
    • どうしてもロスカットできないあなたに
      
      

  • 3. 承認制システムトレード

    • エージェントが自動で取引をおこない、ポジションを持つ前に利用者に承認を得るモデル
    • 試験運転期間や、ダマシに弱いシステムを運用するときも安心
      
      

  • 4. トレンドにあわせて複数のシステムを用意して切り替え

    • あらゆるトレンドに動的に対応するシステムを作るのは難しいので、トレンドごとにシステムを用意
    • スマホからトレンドの変化を判断し、リアルタイムに切り替えて運用する
      
      

  • 5. 完全自動でのシステムトレード

    • もちろん、完全自動でのシステムトレードにも使えます。
    • 取引結果だけ、Pushで通知
      
      

クラウド運用のサポート

• Heroku/AWSでの運用に対応して、運用コストを下げる。

  • 現行版は自宅サーバーでの利用を想定していたけど、セキュリティとかプロバイダの制約が厳しくなってきている感がある。
  • 逆に、HerokuやAWSなどのクラウド環境は、ここ数年で一気に進歩して、個人でも利用しやすくなってきた。
  • 自動取引システムだと、性能はでなくてもいいけど可用性は担保したい。なので、クラウド運用は向いていると思う。
    • 1サーバーあたりの利用人数は多くないので、性能はでなくてもOK
    • ただし、可用性は担保したい(ネットワーク断線とか停電によるサーバー停止は痛い)
  • 可用性を高めるため、プロバイダ2重契約してバックアップ回線を確保したり、UPS買ったりするよりコストは下げられるはず。
  • あとは、MT使ってる人だとWindowsのVPS借りて運用というのは聞きますね。それと比べても安くできる見込み。
    
    

• 無料枠でもそこそこ動くようにして、導入の敷居も低く。

  • Heroku なら1クリックデプロイができるので、インストールも簡単にできると期待。
  • AWS は Docker コンテナを用意すれば簡単かな?

複数ノードでのバックテスト実行

• クラウドでちよっと心配なのはバックテスト。あれサーバーリソース喰うんですよね・・。 あと、無料枠だとストレージ容量が制限されるので、バックテスト用にレート情報を何年も残しておくのも厳しい。
• ということで、 バックテストは別ノードで実行できる仕組み をいれたい。以下のような感じ。
  • 1.連続稼働が必要な実取引はクラウドサーバーで運用
  • 2.クラウドで収集したデータを、自宅サーバーのバックテストノードに定期的に同期
  • 3.同期したデータを使ってバックテストを実施
• バックテストノードは、可用性低くていい & 安いストレージが使いたいので、自宅サーバーを想定。
  • もちろん、クラウドでも使えるようにする。

• ただ、これ、実装はかなり大変な気が・・・・。

WebインターフェイスをREST に変更

• 時代の流れに従い、JSON-RPCはやめる。
• 仕様も公開して、汎用のレート情報収集サーバーとしても使えるようにしたい。

その他、技術的なこと

• ruby2.x で動作するようにする

  • これはさすがにやらないとヤバい。

• データストレージをDBに

  • 導入のしやすさから旧バージョンはcsvにしたけど、ストレージ容量を食い過ぎ。(実装が富豪なのもあるけど)
  • herokuで使うならDBはMongoDBをあたりかな。
    • herokuで使えるデータストレージのうち、無料で使える容量が一番大きいので。
    • PostgreSQLも使えるけど、10,000行じゃさすがに足りないですからね。

• チャートでFlash使ってるのも何とかしないと

• クラウドに置くなら、認証の仕組みとかもいるかなー。

妄想は膨らむばかりです。