【要約】GMOコインFX APIで閉場なのに建玉取得が通った話 — 参照系では開閉が分からない [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が自動売買システムの決済シーケンスにおいて、市場の開閉判定を「参照系APIの成否」で行おうとした際に直面した問題である。APIの応答仕様を誤認することで、閉場中もシステムが稼働し続けるリスクが生じた。
- ・閉場中もPrivate参照系APIがHTTP 200および
status: 0を返す。 - ・APIの成否と市場の状態が分離されており、参照系APIは市場の状態に関わらず正常応答する。
- ・代理判定では閉場を検知できず、エラーを誘発する発注系APIへ遷移してしまう。
// Approach
開発者が誤判定を防ぐため、市場ステータスを直接取得する公式APIを主判定に採用した。APIの成否と市場の状態を明確に区別する設計へと変更している。
- ・
GET /public/v1/statusのdata.statusを確認する。 - ・
OPENの場合のみ続行し、それ以外や取得失敗時は閉場として扱うfail-safe設計を導入する。 - ・参照系APIは「API自体の健全性」を確認する二次的なチェックとして併用する。
- ・
tickerの価格有無による判定は、閉場中も価格が返るため採用しない。
// Result
開発者が市場の状態を正確に把握し、閉場中に不要な発注リクエストを送るリスクを排除した。判定ロジックの堅牢性が向上し、運用上の信頼性が確保された。
- ・市場ステータスとAPI成否を分離して管理し、閉場検知とAPI障害検知の両立を実現した。
- ・未知の値やエラー時も閉場扱いとする堅牢な判定ロジックを構築した。
- ・これにより、閉場中の誤った発注試行によるシステムエラーを未然に防ぐことが可能となった。
Senior Engineer Insight
> APIの「通信成功」と「業務成功」の混同は、金融システムにおいて致命的なバグを生む。本件のように、APIがHTTP 200を返しても業務的なエラー（閉場）が含まれる設計は珍しくない。設計者は「APIが生きていること」と「取引が可能であること」を明確に区別すべきである。二段構えのチェックは、運用時の障害切り分け（市場閉鎖か、API障害か）のコストを下げるため、実戦的な判断と言える。