アービトラージ(裁定取引)について考えてみる その2 検証システム準備編

investmentNo Comments

You Are Here:アービトラージ(裁定取引)について考えてみる その2 検証システム準備編

「期末感真っ只中だな」な今日この頃ですが、夏休みの宿題をギリギリにやっている気分になっているueebeeです。
目が覚めてしまったので、「おっさん’s自由研究」な内容を3日坊主を超えるために書きたいと思います。今日でなんとか4日目です。

前回内容に引き続き「アービトラージ取引が、平成も終わりな2019年現在可能か?」がテーマです。
今回は検証システム準備編です。

実際に書いたコードは長文になるので、番外編としてどこかであげたいと思います。

検証に必要なもの

さて本題です。まず検証に必要なものは以下です。

  1. アカウント: 市場(ブローカー)間の差分を取るには最低限2アカウントは必要
  2. クライアント: それぞれのブローカーに接続して、Bid/Askをリアルタイムに取得できるクライアント
  3. サーバー: データを貯め込む何らかのシステム

想定負荷

Bid/Askの情報がどれくらいの頻度で提示されるのかによって、システムへの要求スペックは変わってきそうです。

仮に1secの間に60回Bid/Askのレートが提示されるようだと、1通貨ペア2ブローカーの場合1000万レコード/dayくらい

60(1秒あたり) x 60(秒) x 60(分) x 24(時間) x 2(クライアント数) =  10,368,000レコード/日

1secのあたりに1回Bid/Askのレートが提示されるようだと、1通貨ペア2ブローカーで17万レコード/dayくらい

1(1秒あたり) x 60(秒) x 60(分) x 24(時間) x 2(クライアント数) =  172,800レコード/日

DBレコード数を見積もってetc…とか考え始めはしてみたものの、「1secあたりのレート提示xブローカー数x通貨ペア数がリニアに効くだろうな」くらいしか感覚がつかめませんでした。
肌感が無いのでとりあえずやってみることにしました。
※筆者は投資に関して素人で、経験が全く持って足りません。


システム構成

全体のシステム構成は一旦以下で実装します。

システムイメージ

サーバー側

集めたデータを受け取ってデータをためるサーバー側は、今回はGo+MariaDBで実装します。

  • 言語: Go
    • WEBフレームワーク: echo
    • ORM: gorm
  • データストア: MariaDB
  • 仮想化環境: docker

APIサーバーはGoなので、今回程度のアクセスだと問題にならないはずです。
データストアに使うMariaDBは負荷が高いようなら、APIサーバーとMariaDBの間にmemcachedみたいなKVSを挟もうかなと思います。

今回の趣旨からはズレますが、dockerはほんと素晴らしい。
git cloneしてdocker-compose upするだけでどこでも動くので、Middleware部分をコード化できるのは圧倒的メリットです。

クライアント側

Bid/Askをブローカーから受け取りたいのですが、ブローカーが提供しているAPIがほぼ見つかりません。
RestAPIを提供していて使えそうなのはOanda1社、FIXという私のよく知らないプロトコルのAPIを提供している会社がちらほらという感じです。

上記事情もあり、使えそうなクライアントは メタトレーダー MT4 ほぼ1択です。
RestAPIを提供してくれるOandaみたいなブローカーが、もっと増えれば良いのにと思います。

MT4にはエキスパートアドバイザーという仕組みがあって、MQL4という言語でプログラムを書けば自動で取引を行うことが可能です。

ドキュメントは https://docs.mql4.com/

このMQL4という言語、どこかで聞いたことがあるなぁと記憶を探っていたところ、10年ほど前に職場の先輩Oさんから「MQL書けない?」と聞かれたことがありました。
全く投資に興味がなかったので、リファレンスをチラ見して「C言語みたいな仕様やな」という感想を持ったことを思い出しました。そのタイミングでは、投資が自分からは遠い存在だったので「やったことないですねーすみません」とお断りしてました。今考えると少しもったいなかったかなと思います。

  • Platform: MT4
  • 言語: MQL4/一部C++(Win32API使うことになりそう)

MQLにはTick単位で動作するOnTick()関数があるので、この中で受け取った値をサーバー側APIに投げる実装にします。

検証で必要になるデータについて

以下の指標をためたいと思います。

  • ブローカー
  • Bid
  • Ask
  • 通貨ペア
  • スプレッド
  • サーバー時間
  • レコードが挿入されたタイムスタンプ
  • ボリューム(なんの指標なのかよくわかってない)

gormのモデル経由で操作したいので、出来上がったSchemaは以下になりました。

id  int(10) unsigned    NO  PRI     auto_increment
created_at  timestamp   YES ""      ""
updated_at  timestamp   YES ""      ""
deleted_at  timestamp   YES MUL     ""
account_company varchar(255)    YES ""      ""
bid double  YES ""      ""
ask double  YES ""      ""
currency_pair   varchar(255)    YES ""      ""
spread  double  YES ""      ""
ea_time varchar(255)    YES ""      ""
ea_micro_second varchar(255)    YES ""      ""
volume  double  YES ""      ""

そろそろ会社に行く準備で時間切れなので、今日はここまでにします。
次回はデータが溜められたら、溜まったデータからどんな傾向があるのか調べてみたいと思います。

About the author:

マーケティング屋さんとシステム屋さんの間の領域で活動してるOssanです。東京都在住。 ブラックラグーンとドトールコーヒーと旅とバッカスが好きです。最近興味本位に流されてAI周り、投資周りにも興味があります。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Top