ＭＴ４用ＥＡ実行環境構築 － トレード用ＰＣの障害への備えと「myfxbook」

さてまたしても１ヶ月以上前になってしまった前回は、スマホからＭＴ４操作時の誤操作防止対策について書きました。今回は、ＭＴ４用ＥＡ実行用ＰＣの障害発生時を想定した対策と「myfxbook」利用を検討している様子について書いてみたいと思います。

まず、どうやって障害を検出してそれを知るのか？という点から。

【ＰＣ障害と障害通知方法】

－－－－－－－－－－－－－－－－－－－－－－－－－

これは以下のブログ記事で書いたとおり、「myfxbook」というサービスを利用する事にした。

参考：（過去記事）障害対策でＶＰＳは必要？自宅でどうする？

本当は、自宅のもう一台の予備用ＰＣからトレード用ＰＣが動いているかどうかを監視する方法もあったけど、予備用ＰＣがとても古い機種で、スペックが低く、立ち上げているだけで結構電力を使ってしまい、電気代に影響する事が判明。

本業ならクラスタ構成にするけど、個人でそんな事はできない。仮に電気代が問題無いレベルなのであれば、監視用アプリを作る事になる。どうせ自宅の別ＰＣで自作監視用アプリ作るのであれば、自動切換え（フェイルオーバー）したくなるのが人情。

参考：日本HP 連載 HAクラスターの教科書～フェイルオーバーの仕組みを知る～

●参考：もしＰＣ障害対策アプリを作るとするなら

簡単な仕組みで言うと、ロック・ディスク方式で、マシン構成（前述リンク先）にある、ＮＡＳにロック用ファイルを生成して、現用トレード用ＰＣで該当ファイルをロックしておき、予備機では、そのファイルのロックを試行する。もしロックに成功したら、現用トレード用ＰＣが障害停止したとみなして、予備機のMT4用EAを起動するという単純なロジック。

けど、考慮漏れが怖い。

一番怖いのは誤検知で、誤検知の要因はいろいろある。

普段からＮＡＳ自体の排他が時々おかしくなる事があったり、各種バックアップでＮＡＳが高負荷になるタイミングがあったり、決して安定している訳でも無い。

で、考慮漏れがあった場合何が発生するかというと、ＭＴ４用ＥＡが２台のＰＣで同時実行されることになって、結果的に２倍のリスクを取る事になる。

リスクが顕在化した時のインパクトが大きいのでＰＣ障害対策アプリ開発は止める事にした。

－－－－－－－－－－－－－－－－－－－－－－－－－

という事で、アプリ自作は却下し、「myfxbook」利用案を採用。

そして次は「myfxbook」について

【「myfxbook」で障害検出する設定方法】

－－－－－－－－－－－－－－－－－－－－－－－－－

１．そもそも「myfxbook」というサービスって？

このサービス自体は、海外のＷｅｂページで、MT4用EAのパフォーマンスを見れたり、自分のパフォーマンスを他人にＷｅｂで公開する事ができるのが目的（多分）。

このサービスがどうやってＥＡパフォーマンスを把握しているかと言うと、MT4がPublisherという機能でトレードデータを送信。「myfxbook」側で受信したデータを加工してWebに表示させてる。なので、MT4のPublisherへの設定と、「myfxbook」への設定が必要。MT4のパスワードには読み込み専用のパスワード（Investor)があるので、それを「myfxbook」に設定する。なので、たとえ「myfxbook」に問題があっても、勝手にトレード状況を変更されたりしないので安心。

＃他にもトレード状況を把握するサービスがあるけど、専用ＤＬＬとかをＭＴ４に組み込まないといけないのが、安定性を損ねそうでちょっと嫌・・・

で、この「myfxbook」は、ＭＴ４から一定間隔毎にデータを受信して、Ｗｅｂ表示画面に反映させるのですが、この「データ」が来なくなったら、「来なくなった旨」を指定メールアドレスにメール通知する機能があるので、これを利用する。

２．「myfxbook」での設定方法

基本的なmyfxbookの設定方法は、以下のブログで丁寧に説明されてます。

・ただいまFX自動売買中

　「MT4（メタトレーダー）の取引情報を分析・シェアできる『myfxbook』の登録方法」

これらの設定をした後、以下で障害を検出する様に設定。

「myfxbook」 → （右上）「Settings」 → 「Messages」タブ内の「Account Update Failure Notification」

※設定例（私の場合）

上記設定の場合、３０分間ＭＴ４から更新が来なければメールが来る事になる。

ＭＴ４からは５分間各でデータを送信しているのに、３０分間停止しないとメールが来ないのは検出時間が長すぎるのでは？という疑問が当然の様に出てくるのですが、理由があります。

－－－－－－－－－－－－－－－－－－－－－－－－－

【「myfxbook」で障害検出運用をしてみると】

－－－－－－－－－－－－－－－－－－－－－－－－－

１．「myfxbook」による検出の特性

さて、今までの説明だと、これでＰＣ障害検出に課題がなさそうに見えるのですが、実はそうでもありません（涙）　冒頭に触れたとおり、実は本記事投稿時点で、「myfxbook」自体が不安定なのです（涙）

MT4からデータ送信時に、MT4でエラーを検出して送信リトライされている分にはいいのですが、どうもMT4側動作にも問題がある様で、「myfxbook」からの応答待ち状態で、Publisher機能が停止している事がよくあります。結果どうなるかと言うと、前述の障害検出メールが送信される事になり、誤検出。

救いは、例えPublisherが停止していても、EAは動作継続できている点。

なので、障害検出メール受信したのでトレード用ＰＣ状況確認してみても、何の問題も発生していないという事がしばしば。少し前は本当に頻繁だったけど、本ブログ記事投稿時点では少しマシになった感じ。

ちなみに、Publisherが一旦停止してしまった状態になると、MT4再起動しないとPublisher動作が復活しない様です。

２．「myfxbook」から障害検出メールを受信した時

前述の通り、「myfxbook」からの障害検出メール受信は「ガセ」が多いので、本当に障害が発生しているのか確認が必要で、以下が手順書。

●「予備用PCへの切替判断」手順

１．myfxbookからのメール契機

２．myfxbookで更新日時確認（３０分以内であればＯＫ）

３．TeamViwerでログインし、パブリッシャー停止障害が発生していればＭＴ４を再起動

４．TeamViwerでログインできなかった場合、以下。

５．LiveMessengerのログイン状態を確認する　→　予備用ＰＣもオフラインであればＩＳＰ障害と判定

６．TeamViwerで予備用ＰＣにログインする

７．予備用ＰＣからメインＰＣにUltraVNCを実行し、停止している事を確認した時点で、ＰＣ障害と判定する

－－－－－－－－－－－－－－－－－－－－－－－－－

さて、無事にＰＣ障害を検出できても、復旧できなければ意味が無いという事で、次の内容は予備用PCへの切替方法について。まずはおさらいとして、マシン機器構成。

・ＭＴ４用ＥＡ実行環境構築 － 障害対策でＶＰＳは必要？自宅でどうする？

　※後半【構成概略】参照

そして、予備用ＰＣへの切替方式について。

【予備用ＰＣへの切替方式】

－－－－－－－－－－－－－－－－－－－－－－－－－

大枠の考え方は、予備用PCにも同じ設定をしておいて、MT4の大域変数が格納されているファイルを定期的(5分毎)にNASへバックアップ。ＰＣ切替時は、NAS内の大域変数ファイルを、予備用PCのMT4実行環境にコピーして、MT4を起動するという流れ。定期的なバックアップには「Buckup」というソフト、予備用PCへの大域変数ファイルコピーは「BunBackup」というソフトを使用。

●「予備用PCへの切替」手順

１．TeamViwerで予備用ＰＣにログインする

２．「PC障害時用」フォルダをあける

３．「MT4(予備機への切り替え）」ファイルをダブルクリックし、

　　BunBackupを起動する

４．BunBackupの全バックアップを実行する

　　※これでNASから予備用PCに大域変数格納ファイルがコピーされる

５．MT4を起動し、EA実行ボタン押下後、以下を確認する。

　　・ログインされた事

　　・ＥＡが実行状態になっている事

６．Buckupを起動する

７．ExPingを起動する（※補足を後述）

８．UQ-WiMAX経路を有効にする（※補足を後述）

９．UQ-WiMAXルータの電源をACから取る様に接続しなおす（※補足を後述）

さて上記のうち、「７．」～「９．」について補足説明。

●補足説明

７．これはISP障害検出用のソフトウェアは予備用PCで動かしていないため。

　　以下の「８．」の背景で、UQ-WiMAXを無効化しているので切替ってしまうと通信経路
　　が全断になってしまうので、ISP異常を検出してUQ-WiMAXに経路を切り替える為の
　　「ExPing」は、平常時は停止させているため。

８．UQ-WiMAXと基地局とのパケット通信を極力削減するため、UQ-WiMAXの経路は
　　普段は無効化している。

９．これはUQ-WiMAXルータがメインPCのUSBから電源供給をしている事に起因。

　　この作業は流石に自宅に戻ってから手動で行う。メインPC故障時は新たにPCを購入する。

　　新しいPCのセットアップが終わるまでは予備用PCで運用する。なので電源供給をメインPC

　　から受けれなくなるので、予備用PCから電源供給する様接続しなおす。

－－－－－－－－－－－－－－－－－－－－－－－－－

やっぱり今回もFXブログに見えない・・・

でも、MT4用EA実行環境構築シリーズは一旦これで終わり！

そして、「FXシステムトレード初心者奮闘記」は、ついに「ＭＴ４用ＥＡ実行環境構築」シリーズが終わり、次はまるでＦＸのブログみたいな記事に進むのでした。

＃今ライブ口座で動作中のＥＡ君、口座残高が投入資金＋６％になって利益が出てる状態！！嬉しい！！

ＭＴ４用ＥＡ実行環境構築 － スマホからＭＴ４を操作する（誤操作防止対策）

またしても１ヶ月前になってしまった前回記事は、ＭＴ４用ＥＡ実行環境でインターネット障害発生時の回線自動切換え方式について書きました。今回は、有事の際に、外出先から自宅ＰＣで動かしているＭＴ４を操作する時の工夫について書いてみたいと思います。

本題に入る前に、嬉しい事が！！

なんと、Android用ＭＴ４アプリが登場した！＃"MetaTrader"で検索すると出てきます

なので、外出用ＰＣは不要になり、外出時はスマホだけで障害対応可能。

元々外出用ＰＣの想定利用用途は、外出時に、甚大な災害発生や自宅が火災になった場合等。

これらの状況になった場合は、外出先からでも保有中オーダを全部決済するという運用。

なので、決済さえできれば十分！荷物も軽くなるので嬉しい！

さて、話しは戻して、実行環境全体は、以前の記事の通りで、外出先からスマホで自宅で動作しているＭＴ４を操作する場合は、以前の記事で紹介したスマホ上のTeamViwerでＰＣにリモート操作する。

ちなみに、スマホのTeamViwerからＰＣ上のＭＴ４にアクセスした時は以下の雰囲気。

【スマホからリモートアクセスした様子】

－－－－－－－－－－－－－－－－－－－－－－－－

ピントずれちゃった・・・

－－－－－－－－－－－－－－－－－－－－－－－－

TeamViwerを選んだ理由は、固定ＩＰアドレスもドメインも不要という点と、通信が暗号化されているので、セキュリティの観点で概ね問題ないという理由。「概ね」と書いたのは、この通信自体が、TeamViwerのどこかのサーバを必ず経由しているので、そのサーバではやりたい放題。なので、TeamViwerという会社を信用するかどうかという判断。パスワードが平文でインターネットで流れる様な他のリモートアクセス認証方法よりかはよっぽど安全と考えてTeamViwerにする事にした。

そして、ここでも注意点が。

それは、スマホのちっちゃい画面から指先でＰＣ画面を操作するから、誤操作が発生しやすいという事。

本番開始前、実際にTeamViwerを使ってみた時にまずやってしまったのは、「気配値表示」を表示させた状態での操作。スマホでの操作は、ディスプレイを指でなぞったり、タップしたりする。ＭＴ４の画面がスマホに収まらないので、スクロールも指でなぞって操作。この時に、「気配値表示」にある通貨ペアを選択してチャート上にドロップしてしまった。当然の結果として、ＥＡを動作させていた通貨ペアが変わってしまうという事故が発生。ある意味スマホによる障害復旧というリハーサルをしていたから見つかって良かったとも言える。

この問題は「気配値表示」を非表示にしておけば解決する。

しかし怖いぞ。。。

スマホが時々プチ・フリーズするという事も誤操作につながりやすい。リモートアクセスしている状況はトラブル発生時が想定され、心理的に焦りもあるはず。電車に乗っていて不安定な状況で画面操作が必要になるかもしれない。

他にも誤操作してしまう要因あるはずなので、画面を精査した結果、以下の様にＭＴ４の画面表示を変更。

【誤操作対策】

－－－－－－－－－－－－－－－－－－－－－－－－

・「気配値表示」ウィンドウを非表示に変更

・「新規注文」ボタンを非表示に変更

・「周期設定」を非表示に変更（1Hとか4Hとかのボタンたち）

－－－－－－－－－－－－－－－－－－－－－－－－

これで完璧 ♪

と思ってテスト継続していたら、またしてもあるチャートの通貨ペアが意図しないものに変わっている事を発見。しかも発見したのは、本番開始後の本番用ＭＴ４

ん？？？？？
どうやったら表示しているチャートの通貨ペアを変更できるのだ？？？

メニューはクリックしてないぞ？？？？

そして実験用のＭＴ４で画面操作を試行錯誤した挙句にわかったのは、「取引」タブに表示されているオーダを選択して、チャート上にドロップすると、チャートの通貨ペアが選択していたオーダの通貨ペアに変わってしまうという事。なので、ＭＴ４画面下のタブ選択を、以下の様に「取引」タブではなく、「操作履歴」に変更。

【改善後画面１】

－－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－

それでも、リモートアクセス直後に不用意なＭＴ４操作を行ってしまいそうになったので、今はＭＴ４は最小化。今のトレード用ＰＣの画面はこんなイメージ。

【改善後画面２】

－－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－

これで、誤操作問題は無事落ち着いた。

これでスマホさえあれば外出先でも安心♪

＃携帯電話回線が生きていれば・・・

本番開始時は、最終的に投入する金額の１０％から始めた介があったというもの。

本番誤操作で、本来結構大きな勝ちトレードになるはずだったのを間違って決済してしまうという結果に。

＃不明で把握していないオーダは決済するロジックがあるので。

そして、「FXシステムトレード初心者奮闘記」は、ＭＴ４用ＥＡ実行環境構築で、トレード用ＰＣ障害時の検討に進むのでした。

＃今ライブ口座で動作中のＥＡ君、口座残高は当初資金から０．９％減少。まだ１日も元本上回ってないんですが・・・

ＭＴ４用ＥＡ実行環境構築 － 障害対策でＶＰＳは必要？自宅でどうする？

さて前回は、ＭＴ４用ＥＡ開発で、本番開始までの奮闘状況をまとめた「ＭＴ４用ＥＡ開発時代」が完了したところまで書きました。今回からは、開発したＭＴ４用ＥＡを実行させる環境を構築する様子を書いていきます。第一弾は、実行環境の概略について書いてみたいと思います。

まず方針としては、安定して動作して、障害発生を検出できて、短時間で復旧できるかがポイント。
 

災害／障害対策としては、過去以下の様なブログを書いてた。

【過去記事】

－－－－－－－－－－－－－－－－－－－－－－－－

・ＦＸ売買システム多市場多期間最適化時代 － システムトレードの災害・障害対策について

・ＭＴ４用ＥＡ開発時代 － ＥＡ開発で考慮すべき点について１

－－－－－－－－－－－－－－－－－－－－－－－－

そもそもＭＥ４用ＥＡを、自宅で動かすか、ＶＰＳ上で動かすか。

以下は、某有名ＶＰＳサービスに過去障害も含めて冗長化構成を中心に、ヒアリングをしてみた結果。

【某有名ＶＰＳサービスとの質疑】

－－－－－－－－－－－－－－－－－－－－－－－－

１．リモート接続障害に関して

　　自宅からのリモートデスクトップ接続の障害があった旨がありましたが、その際、
　　レンタルサーバから別の外部サイトへの通信にも障害が発生していたのでしょうか？
　　それともリモートデスクトップ接続だけが障害となったのでしょうか？

　　【回答 】 

　　弊社提供サーバーの問題であるため、外部への通信にも問題が発生してございました。

２．サーバはクラスタ構成でしょうか？

　　リモートデスクトップが動作しているサーバが起動不可等の障害となった場合、どうなるのでしょうか？

　　クラスタ構成を組んでいて、外付けディスクの情報を引き継いだ状態で、自動的に別サーバに切り替
　　わる様になっているのでしょうか？

　　【回答 】 

　　申し訳ございません。自動的に切り替わる状況とはなりません。

　　なお、HDD / ソフトウェア障害によるデータ復旧はできかねます。

　　　○　追加質問１

　　　　　この点ですが、サーバ障害となった場合は、ディスクの中身がクリアされるとして、

　　　　　リモート接続可能な状態になるまでどの程度の時間がかかりますでしょうか？

　　　　　＃５分程度なのか、数時間レベルなのか、数日というレベルなのかといった精度でかまいません

　　　　　【回答】

　　　　　障害の状況によって異なる状況ではございますが、弊社にて

　　　　　想定しうるケースは数時間と判断されます。

　　　○　追加質問２

　　　　　サーバ障害発生時は、利用者にメール通知等がありますでしょうか？

　　　　　メール通知が無い場合、どういった方法で利用者に連絡があるのか教えて

　　　　　頂けないでしょうか？

　　　　　【回答】

　　　　　おそれいりますが弊社にて障害やメンテナンスのご案内は

　　　　　商材ページにてご案内させていただいております。

３．サーバ内臓ディスクはミラーリング（ＲＡＩＤ１等）等はされてますでしょうか？

　　【回答】
　　ミラーリングしております。

４．ネットワーク機器

　　内部ネットワーク機器は多重化されてますでしょうか？

　　ＳＰＯＦ(※１後述）となる箇所はありますでしょうか？

　　【回答】
　　すべての機器において、多重化されておりません。

　　詳細なご案内も控えてさせていただいてます。

５．外部のインターネット接続の冗長構成について

　　サーバから外部のインターネットに接続する際、特定１つのＩＳＰを使用しているのでしょうか？
　　それとも、複数のＩＳＰを併用していて、１つのＩＳＰが通信不可になった場合でも、自動的に
　　他のＩＳＰで通信可能になる様になっているのでしょうか？

　　【回答】
　　特定の通信サービスとなります。

６．外部ネットワーク接続機器は冗長構成になっていますでしょうか？

　　【回答】
　　こちらにつきましてもすべての機器において、冗長化されておりません。

　　詳細なご案内も控えてさせていただいてます。

７．電源の引き込みについて

　　電力会社からサーバ設置しているビル内への電源の引き込みは２系統からでしょうか？

　　それとも、１系統のみでしょうか？

　　【回答】

　　2系統となります。

－－－－－－－－－－－－－－－－－－－－－－－－

※１　ＳＰＯＦ：Single Point Of Failuer

  　　 参考：単一障害点 - Wikipedia

　　　　

■このＶＰＳを使う事で対処できる障害
ＶＰＳで使用しているハードウェアが故障した時でも予備機器で自動復旧されるのは、ハードディスク障害か電力供給障害の時のみ。

■このＶＰＳを使用しても対処できない障害と弊害

　・サーバそのものやネットワークで障害が発生してもメールで通知してくれないので障害に
　　気づく事ができない。

　　　＃後述のmyfxbookを使えば気づく事は可能にはなる。

　・サーバ障害時は数時間停止するし、障害状況によってはディスクがクリアされるかもしれない。
　　障害実績を見ると、思った以上の頻度で障害が発生している。 

　・ネットワーク障害発生時の復旧時間は通信事業者次第。

　・ネットワーク障害中は、当然自宅やスマホからリモートでログインすることができないケースが
　　考えられ、ＥＡを稼動させているＭＴ４がどうなっているのかも見ることができない。

　　当然、自前で予備ＩＳＰを追加する事もできない。

　　→　サーバにリモート接続できなければ、状況把握できないし、どういう対処をすればいいか
　　　　　わからない。

　　　　ＥＡはトレードしてるかもしれないし、していないかもしれないという心理的にドキドキする状況。

　　　　　　＃自宅ＰＣの場合、ケーブルを抜けば少なくとも確実に新規発注はしなくなる。

　・障害が復旧したとしても上記回答内容から想像するに復旧連絡なんて来ないだろうから、
　　時々障害復旧状況をＨＰに見に行かないといけない。

【結論】

手持ち機器の状況と、インターネット障害やＶＰＳ障害発生時の事を考えると、やっぱり自宅で動かしたほうがいいという結論。

＃使ってない古いＰＣがあったのが大きいかも

そして、自宅でＭＴ４用ＥＡの実行環境を以下の様にした。

※参考（過去検討していた時のブログ記事）：「ＭＴ４用ＥＡ開発時代 － ＰＣ障害対策の設計ミスと、デモ口座期限切れ対策」

【構成概略】

－－－－－－－－－－－－－－－－－－－－－－－－
●機器構成 

●ソフトウェア構成

－－－－－－－－－－－－－－－－－－－－－－－－

【構成詳細】

－－－－－－－－－－－－－－－－－－－－－－－－

●パソコン

　・トレード用ＰＣ ： SONY 「VAIO VGN-FE90S」 

　　※メモリは２Ｇに増設済み。ＣＰＵはカスタマイズで２coreを選択。

　・予備用トレードＰＣ ： SHARP 「PC-MV1-C1F」

　・外出時持ち出し用ＰＣ ： SONY 「VAIO PCG-SRX7」

　　※　メモリは２５６ＭＢに増設済み

　・普段使い用ＰＣ ： SONY 「VAIO Fシリーズ VPCF14AFJ」 

　　※カスタムメイド：メモリ８Ｇ、ＳＤＤ２００ＧＢ、ＣＰＵ Intel Core(TM) i7 M640 2.8GHz

●インターネット・ＬＡＮ

　・ＮＴＴ東日本／フレッツ光ネクスト

　・ぷらら／ぷらら光セット

　・ＴＡ／ルータ（レンタル） ： 「PR-S300SE」 

　・無線ＬＡＮステーション ： バッファロー「WZR-HP-G300NH」 

　・スイッチングハブ ： コレガ「CG-SW08GTX2W」

　・ＵＱ－ＷｉＭＡＸ（予備インターネット） ： ステッププラン

　・ＷｉＭＡＸルータ（予備インターネット用） ： 「AtermWM3500R」

●ハードディスク

　・ＮＡＳ ： IODATA 「HDL2-G」 

　・外付けＨＤＤ ： IODATA 「HDJ-U1.0」 

●その他

　・スマホ ： docomo 「AQUOS PHONE SH-12C」 

　・ＵＰＳ ： APC 「ES 750 BE750G-JP」 　　→　ＮＡＳに接続

－－－－－－－－－－－－－－－－－－－－－－－－

【ソフトウェア・利用サービス】

－－－－－－－－－－－－－－－－－－－－－－－－

●パソコン用ソフトウェア

　・TeamViewer Host  →　スマホからのリモートアクセス用

　・UltraVNC 日本語インストール版  → 普段使い用ＰＣからトレード用ＰＣアクセス用

　・BunBackup → トレード用ＰＣのＭＴ４環境バックアップ。１回／１日。

　・Backup → ５分間隔での大域変数のバックアップ

　・ExPing → ＮＷ切替用。詳細は後日。

　・LiveMessenger  → 外出先からトレード用ＰＣの通信状況確認用。

　・WinMailCmd → MT4障害検出時のメール送信用

　・Acronis True Image Home 2010 → トレード用ＰＣのディスク全体をイメージバックアップ

●スマホ用ソフトウェア

　・TeamViwer → トレード用ＰＣへのリモート接続

　・Mercury Mobile(Free) → LiveMessengerクライアント。トレード用ＰＣがＩＳＰ接続できているか確認

●利用サービス

　・myfxbook  → トレード用ＰＣ障害検出、トレード状況確認

－－－－－－－－－－－－－－－－－－－－－－－－

トレード用として新規に購入したのは、WiMAXルータとスマホだけ。

ＰＣがたくさんあるのは、過去の古いＰＣを妻の分も含めて総動員したため。

ＵＰＳは東京電力の計画停電対応用に購入していた。

これでＶＰＳ利用と比較して可用性がどうなったかと言うと、以下の通り。

【ＶＰＳ利用時との違い】

－－－－－－－－－－－－－－－－－－－－－－－－

各障害発生時の可用性比較結果。

○：向上、△：若干低下、×：低下

１．トレード用ＰＣ障害　○

　　myfxbookにより検出（これはVPSでも可能）。外出先からスマホで予備用のトレード用ＰＣに
　　手動切替可能になった。

２．ディスク障害 △

　　発生時はＰＣ障害と同じはずなので、上記「１．」と同じ。

　　但し、ＨＤＤ単発障害でトレード用ＰＣ切替が必要になる。

　　（ＶＰＳの場合は、単発障害では影響がほぼない）

　　復旧はディスク復旧後にゆっくりすればいい。設定はバックアップ。

３．ネットワーク機器障害／外部のインターネット接続の冗長構成 ○

　　myfxbookにより検出（これはVPSでも可能）。UQ-WiMAXに自動切換えされる様になった。

　　→　替わりに７３３円／月固定費（実測値）がかかってしまう。

４．停電対策について ×

　　１系統のみになったので、停電時はトレード用のノートＰＣ搭載バッテリが無くなるまでに

　　何らかの対応が必要。また、ＮＷ切替が発生する。

－－－－－－－－－－－－－－－－－－－－－－－－

元々古いＰＣが妻の分も含めると３台残っていたことも幸いし、上記の自宅構成の方が可用性観点で良いので、自宅で動作させる事に。

一番判断材料として大きいのは、ＩＳＰ障害発生時にＶＰＳでは手も足もでないこと（サーバにリモートログインもできないので）。ＩＳＰはマーケットが開いていても定期的にメンテナンスを実施していたりするので予備ＩＳＰは必須。唯一悩んだのは、電源観点のみ。

今回の自宅ＭＴ４用ＥＡ実行環境は、ＰＣ障害時に自動切換えできないし、ＭＴ４からmyfxbookへのパブリッシャーはよく停止してしまうという貧弱さはあるものの、なんとか満足いくレベル。

なんかＦＸのブログ記事に見えない。。。。

そして、「FXシステムトレード初心者奮闘記」は、「ＭＴ４用ＥＡ実行環境構築」で、ＮＷ切替の仕組み構築に奮闘している様子に続くのでした。

＃今ライブ口座で動作中のＥＡ君は当初資金から１．１５％減少。。しかも一回間違えて意図せず保有中オーダを全決済。。

ＭＴ４用ＥＡ開発時代 － ＭＴ４のバグとOrderSelectの内部動作妄想

さて前回は、トレーディング・プランの見直しをして、ついに本番開始したところまで書きました。今回は、ＭＴ４用ＥＡを開発中に見つけたＭＴ４のバグとOrderSelect動作の妄想について書いてみたいと思います。

今までブログ記事にしてなかったけどＭＴ４用共通部品で対処や検討した点が幾つか。せっかくなので認識してるＭＴ４の問題は一旦吐き出しておこうかと。

【今回のテーマ】

－－－－－－－－－－－－－－－－－－－－－－－－

１．オーダ操作関数から不正なエラーコード返却
２．OrderSelect()について

　　・期待していたＭＴ４内部動作が外れていて障害発生

　　・OrderSelect()内部動作妄想

－－－－－－－－－－－－－－－－－－－－－－－－

という事で一つづつ。

【オーダ操作関数から不正なエラーコード返却】

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

１．OrderModify()で「ERR_INVALID_TICKETが返却が返却される

　　ログに出力していたチケット番号は、口座履歴に存在していて、SL決済されている事を確認済み。

　　

　　本来であれば、トレードサーバで検出されるべき状況なので、

　　「ERR_INVALID_TRADE_PARAMETERS」が返却されるのが正しいはず。

　　

　　推測だけど、OrderSelect()用の内部メモリテーブルが未完成の状態で、指定したチケット番号

　　がどちらにもなかったのが原因なのではないかと思う。※後述

　　Build406で発生。

　　

２．OrderSend()で「ERR_NO_RESULT」が返却される

　　「ERR_NO_RESULT」はOrderModify()の時だけに返却されるエラーコード。

　　ＰＣ過負荷＋ＮＷ過負荷の状態で発生。

　　実は発注成功しているケースがあり、失敗したと思ってリトライすると

　　不要オーダ発生になるので注意。

　　Build225／Build229／Build406で発生。

　　

　　●参考

　　　「ＭＴ４用ＥＡ開発時代 － なんで「ERR_NO_RESULT」やねん。。」

　　

３．OrderSend()/OrderModify()/OrderClose()で「ERR_COMMON_ERROR」

　　ＰＣ過負荷＋ＮＷ過負荷状態なのでバグというかは微妙。

　　但し、OrderSend()では上記「２．」と同じ様に実は発注成功しているケースが

　　あった。これについてはＭＴ４ヘルプの記載漏れだと思う。

　　雰囲気的に通信エラーで発生するっぽく感じた。

　　

４．マーケットが閉じた時に「ERR_TRADE_DISABLED」が返却される。

　　「ODL Japan」の場合のみ発生。

　　デモ口座用のトレードサーバ側の運用の都合かもしれないけど、本来であれば、

　　「ERR_MARKET_CLOSED」が返却されるべき。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

参考：「トレードサーバから返されるエラーコード」

  　　　「stderror.mqh ファイルで定義されているエラー コード定数」

さて「OrderSelect()」問題。

今回新たな障害が発生。OrderSelect()挙動による動作不正を回避するために、あるＭＴ４内部動作を前提としていたけど違ったみたいだから修正したという話。

【発生事象】

－－－－－－－－－－－－－－－－－－－－－－－－－

以下の記事内の、「ERR_INVALID_TRADE_PARAMETERS発生条件－４」のパターンが発生。

そして、「OrderSelect()の結果が最新化されるのはティックデータ受信後のRefreshRates()後」という想定でロジックを組んでいたけど、見事期待が外れて、クリティカル・エラーが発生。

・「ＭＴ４用ＥＡ開発時代 － 警告メールの嵐対応３（ERR_INVALID_TRADE_PARAMETERS再び）」

●発生条件と考察（再掲）

下図の「トレードサーバ」側からの２回目のティックデータ送信をＭＴ４クライアント側で受信するタイミングがずれて、「ＭＴ４クライアント側」の１回目のRefreshRates()実施後になってしまった場合。

・実際とは異なった前提としたＭＴ４内部動作仮説

以下のいづれか（もしくは両方）が違うという事。
・OrderSelect()の結果が最新化されるのが、ティックデータ受信後のRefreshRates()後

・OrderModify()のレスポンスをＭＴ４クライアント側が受信した時に、TimeCurrent()が更新される

・前提とした仮説が違っていた場合の方針

「これでダメなら、後はTimeCurrent()が何秒ずれるまで待つ、という設定を追加するか、クリティカルエラーをあきらめて、警告レベルのエラー扱いにするかぐらいしか思いつかない。」

という事で、前回のＭＴ４用ＥＡ共通部品リリースでは警告レベルのエラーとして扱う事にした。

－－－－－－－－－－－－－－－－－－－－－－－－－

そういや過去の開発経緯を見ると、OrderSelectに振り回されてきた。

【「OrderSelect」に関するブログ記事】

－－－－－－－－－－－－－－－－－－－－－－－－－

・「ＭＴ４用ＥＡ開発時代 － 警告メールの嵐対応（OrderSelect等）」

・「ＭＴ４用ＥＡ開発時代 － 警告メールの嵐対応３（ERR_INVALID_TRADE_PARAMETERS再び）」

・「 ＭＴ４用ＥＡ開発時代 － 「OrderSelect問題」仮説検証結果」

・「ＭＴ４用ＥＡ開発時代 － OrderSelect問題の再発？それとも新たな問題？」

・「ＭＴ４用ＥＡ開発時代 － 「OrderSelect問題」が再発した！！」

・「ＭＴ４用ＥＡ開発時代 － OrderSelect問題パート２が再発。絶対ＭＴ４のバグ！」

－－－－－－－－－－－－－－－－－－－－－－－－－

これらの動きを総合すると、OrderSelect()の動作は以下の雰囲気になるのではないかと。

【OrderSelect()動作概略の妄想】

－－－－－－－－－－－－－－－－－－－－

１．OrderSelect()でのデータ取得元はクライアント上のメモリデータ

２．該当メモリデータは、「取引一覧」と「履歴一覧」の２つに分かれている。

　　排他制御も「取引一覧」と「履歴一覧」は別々に制御。

３．サーバ側での情報変化をクライアント側のメモリデータに反映するタイミングは、

　　何かのオーダ操作やティックデータ受信時等の他動作の延長線上で更新されるのではない。

　　一定間隔等、他動作と同期をとらずにメモリデータが更新される。

４．メモリデータ更新中は排他制御に隙間があり、更新中にOrderSelect()すると

　　不定な結果になるケースがある。

５．サーバ側動作の結果、オーダが「取引一覧」から「履歴一覧」に移動する際、

　　該当オーダ情報が一旦どちらのテーブルにも無いタイミングが存在する。

６．通信障害があると「履歴一覧」は不完全になるケースがある

－－－－－－－－－－－－－－－－－－－－

これを絵にしてみるとこんなイメージ。

【ＳＬ／ＴＰ決済時の「OrderSelect」イメージ】

－－－－－－－－－－－－－－－－－－－－

OrderSelect()用テーブルの状態遷移イメージを書いてみた。

状態１．いくつかの決済済みオーダと保有中オーダがある状態

　　　　左の点線で囲った「取引一覧」は、OrderSelect(MODE_TRADES)で取得されるデータ群。

　　　　右の点線で囲った「履歴一覧」は、OrderSelect(MODE_HISTORY)で取得されるデータ群。

　　　　排他制御は「取引一覧」と「履歴一覧」それぞれ別個に実施されている。

　　　　

状態２．サーバ側でオーダが決済された事を何らかのタイミングで検出

　　　　ここが一番状態として不安定な状態。

　　　　・「保有中オーダ５」がＳＬ／ＴＰ等により決済された旨をサーバ側から受信した後の処理。

　　　　　このオーダがどちらのテーブルにも属していない状態。つまりOrderSelect(BY_TICKET)でも

　　　　　「保有中オーダ５」が見つからない状態になる。

　　　　・この「保有中オーダ５」を「取引一覧」から切り離す処理をしている間に、OrderSelect()

　　　　　ループを行った時に色々不整合が発生しそう。

　　　　・本来であれば、図中の「①切り離し」を処理中は「取引一覧」をロックしていると思う。

　　　　　OrderSelect()で「取引一覧」からデータを読み込む時も「取引一覧」をロックすべき

　　　　　なんだけど、実はしていないんじゃないかという妄想。なので不整合が発生しうる。

　　　　・もしOrderSelect()実行時に排他制御しているのであれば、エラーが発生しうるはず。

　　　　　エラー発生時はGetLastError()にエラーコードが設定されるはずだけど、OrderSelect()は

　　　　　エラーコードが設定されない仕様。

　　　　・「取引一覧」から該当情報を切り離した後、サーバから「保有中オーダ５」の最新情報を

　　　　　　取得する際、通信障害等によりデータ取得失敗した場合、「履歴一覧」に「保有中オーダ５」

　　　　　　の情報が追加されない。

　　　　

状態３．オーダが決済された事が完全にＭＴ４クライアントに反映された

　　　　　 この状態になれば安定する。

　　　　－－－－－－－－－－－－－－－－－－－－

こういうツクリであれば、今まで発生した事象のほとんどで辻褄があう気がする。

で、もしこれが事実であれば、明らかにＭＴ４の設計ミス。

もしＭＴ４を修正するのであれば、以下の様な大幅な修正が必要になってしまうので、修正される可能性は低い（と思う）。

という事で、無駄とはわかりつつもＭＴ４修正案を考えてみたｗ 

【仮説が正しかった場合のＭＴ４設計修正案】

－－－－－－－－－－－－－－－－－－－－

１．オーダを「取引一覧」から切り離して、データ最新化後「履歴一覧」に繋ぎ直すのであれば、

　　排他制御の単位は、「取引一覧」と「履歴一覧」の両方を対象にしないと必ず隙間ができる。

２．OrderSelect()する際は、「取引一覧」と「履歴一覧」の両方をロックしてから実行しないとやはり隙間

　　が発生して不整合が起きる。

３．この両方のテーブルを最新化するＡＰＩが必要。そうでないとサーバからエラー応答がされた時に、

　　クライアントとサーバ側の不整合に起因したエラーなのか、ＥＡバグ起因なのかが区別できない。

－－－－－－－－－－－－－－－－－－－－

さて、どうでしょう？？？？

あくまでも妄想です。。

実際どうなのかを、ご存知の方おられたら教えて欲しいです。。

そして、「FXシステムトレード初心者奮闘記」は、本番開始前に実施したＭＴ４用ＥＡ実行環境構築について進むのでした。

＃今ライブ口座で動作中のＥＡ君は当初資金から０．８７％減少。。