트레이딩 데스크 IT 장애 사례 (25.3.16)

Algo Trading 장애

1. 2009년이었습니다. 시작 스크립트의 Java 매개변수의 문자열을 256자 이상으로 만들었는데 Windows 2K가 이를 지원하지 않았기 때문에 전체 컨버터블 데스크 (전환사채 트레이딩 테스크, 채권과 옵션을 분리하여 차익거래 등을 수행하는 데스크) 에서 기본 트레이딩 앱을 실행할 수 없었습니다.
2. 알고리즘이 거래 체결 시 심볼 (티커) 를 무작위로 변경하기로 결정했습니다(예: 애플 AAPL의 봇 100이 시스코 CSCO의 봇 100이 됨). 일일 거래 범위를 벗어난 거래를 파악하기 위해 야후 파이낸스를 사용해야 했습니다.
3. 도킹된 블랙베리로 인해 주말 데스크톱 재부팅 작업이 멈췄습니다.  블랙베리 도킹을 해제하면 스크립트가 거래 시간 동안 트레이딩 플로어의 절반을 재부팅하는 것으로 진행되었습니다.
4. 거래소 콜로에서 증기 파이프가 파열되어 콜로와의 연결이 끊겼습니다. (거래소 가격 데이터 스트림의 subscription session 연결이 끊어진것으로 보임) 그래도 트레이딩 엔진은 계속 거래되었습니다. 🤦🏼
5. 단일 CronJob  스크립트로 백그라운로 40개 이상의 인스턴스를 시작하게 되어 있었고 누군가 새 작업에 "&"를 추가 (이전 명령어가 정상이면 다음 명령어 실행하는 옵션) 하는 것을 잊어버려서 예약된 재부팅이 이루어지지 않았습니다. 해당 인스턴스가 재부팅될 때까지 거래 시간 중에 CronJob이 "동결 해제"된 후 모두 재부팅되었습니다.

 

채결ID 번호 부족

1. 네트워크 팀이 내부 포트 스캔을 수행을 했었고 빅 센트럴 앱 컨트롤러가 연결 및 연결 해제를 재시작 이벤트로 해석한 것만 제외하고 정상이었습니다. 결국 전체 트레이딩 시스템을 거래 시간 중에 재시작했습니다. 😱
2. 레거시 트레이딩 시스템은 하루 10,000건만 지원했습니다. 2008년 말, 주식 거래량이 폭증했습니다. 결국 해결 방법은 "토요일로부터의 체결 ID를 빌리는것이었습니다.“ (주말의 경우 거래가 거의 없기 때문에 채번을 미리 땡겨서 사용한것으로 보임)

 

트레이더 데스크탑 컴퓨터 먹통

1. 트레이더가 문제가 생겨서 로컬 데스크톱 로그를 이메일로 저에게 보냈습니다. '보내기'를 누르자 트레이더의 전체 컴퓨터가 잠겨버렸습니다. 이 또한 거래 시간 중에 일어난 일 입니다.. 😇
2. 뉴욕에 있는 국제 세일즈 트레이더(ST, 기관대상 영업하는 트레이더)는 런던에 있는 서버를 기반으로 앱을 사용하고 있었습니다. 인터컨티넨탈 GUI와 하루 종일 주문이 몰리면 재시작에 최소 20분 이상 걸렸습니다. ST를 도와주러 갔는데 앱이 잠겼습니다. 해결책은 재시작뿐입니다.
3. ST: "재시작까지 얼마나 걸려요!", 나: "최소 20분은 걸려서 당신은 거래 마감 시간을 놓칠 수 있어요." 저는 그가 화를 내는 것을 기다리고 있었습니다 (이런 상황에서는 화를 내는 것은 트레이더의 일반적인 반응입니다).
4. 그는 자리에서 일어나 책상을 향해 고개를 돌리며 "얘들아! 내 앱이 망가져서 (My app is fu*ked) 거래 마감 시간을 놓칠 것 같으니 여기서 나가야겠어!" (나 짤릴거 같아 라는 의미인듯…) 라고 말하며 트레이딩 플로어를 향해 걸어 나갔습니다. #legend
5. 고객 주문을 전자적으로 접수하는 시스템을 재시작해야 하지만(15~20분) 전화 주문은 계속 들어오고 있으며 고객에게 전화로 제공한 가격을 지불해야 합니다. 재시작하는 동안에도 IT 데스크에서는 대기 중인 주문과 세부 정보(예: 매수/매도)를 볼 수 있었습니다.
6. 영업 트레이딩 헤드가 데스크에 와서 팀과 다시 컨퍼런스 콜을 열고 전체 팀에게 실시간으로 주문을 라우팅했습니다. (일명 플로어 트레이딩, 2010년 이전에는 트레이딩 핏에서 수신호로 주문과 거래를 처리 하였음. 라우팅은 고객 거래가 들어오면 각 시장이나 북에 맞게 거래를 보내는 것을 의미) 제가 본 기술 문제에 대한 가장 놀라운 구식 거래 해결 방법입니다. 그는 정말 좋은 사람이었어요! 👍

 

거래소 IP 변경 미대응 장애

1. 나스닥에서 IP를 전환한다고 알려왔습니다. 정상입니다. 네트워크 팀이 변경하는 것을 잊어버렸습니다. 변경 당일: NASDAQ과 거래할 수 없고 우리는 마켓 메이커이기 때문에 모든 것이 엉망이 됩니다. 방화벽 팀과 통화 중입니다: "죄송합니다, 모든 방화벽 변경은 3일 전에 통지해야 합니다." 🤦🏼
2. 저: "저희는 나스닥 마켓 메이커이고 거래할 수 없는 건 어떤 의미인지 아시죠?". 방화벽팀: "네, 죄송합니다." 다행히 라디안츠가 새로운 경로를 추가해 주었고 위기는 해결되었습니다. 😭

 

SSO 장애

1. 직원 수가 30만 명에 달하는 회사에서 SSO (SingleSignOn) 마비가 발생했습니다. 담당팀에 전화를 걸자 자동화된 음성으로 "276번째로 통화에 참여하셨습니다."라는 메시지가 나옵니다. 예전에는 이를 '파티 라인'이라고 불렀던 것 같습니다. 🥲

 

개발 검증

1. XML을 사용하여 작성이 수작업으로 이루어지고 오타가 읽기 오류로 발생하고 $X,000 수준의 규정 벌금이 부과되는 정말 중요한 컴포넌트가 있었습니다. 개발자에게 질문: "최소한 검증이라도 받을 수 있을까요?" 개발자: "하하, 뭐?"
2. 좋은 점: 모든 로그 메시지에 주문 ID가 있는 crossing 엔진을 지원하게 되어 운이 좋았다고 생각했습니다. 운이 좋았죠. 그러다가 자체 시스템을 보유한 마켓 메이킹 회사를 인수했습니다. 그 시스템은 두 주문이 교차하는 이유를 간단한 영어로 알려주었습니다. #Magic
3. “우리는 개발, 테스트(QA), 운영 환경에 분리해서 각각 빌드를 하고 있는데 빌드에 git 커밋 ID를 태그해야 하나요? 왜 그렇게 해야 하나요?"
4. automated crossing 엔진에 테스트 심볼 (티커, 즉 테스트 증권코드) 과 함께 주문을 보냈습니다. 이어서 street (실제 거래로) 전송을 시도했지만 거부되었습니다. 알고 보니 거부 시 속도 제한이 없어서 서비스 거부되는 방식으로 주문을 계속 보내게 되었고 결국 ECN (전자거래채널, 장외거래전자중계회사)에서 전화가 왔고 ... 😱
5. 우리는 주문을 모두 취소 시켰습니다. 거부(reject) 된 모든 주문이 거대한 빙산처럼 시스템을 통과하여 각 컴포넌트에 부딪히면서 각 시스템을 무너뜨리고 있다는 사실을 거의 알지 못했습니다. 최고의 날은 아닙니다. 😢
6. 위와 같은 일이 있은 후 모두가 말했습니다: "적어도 우리 매뉴얼, 클릭 트레이딩 시스템에서는 그런 일은 절대 일어나지 않게 해야한다!" 다만, ST가 주문에 코멘트를 달기 전까지는 말이죠. 코멘트가 트레이더에게 전달되면 트레이더의 GUI는 다른 필드가 필요하다고 판단하여 이를 다시 ST GUI로 보냅니다.
7. ST GUI는 "이것은 나를 위한 것이 아닙니다! 트레이더 GUI로 돌아가세요!"라고 말합니다. 메시지가 앞뒤로 핑퐁되는 것을 알아낼 때까지 수십만 번 반복합니다. 세일즈와 트레이딩이 모두 중단될 뻔했습니다.

원문 출처

https://x.com/alexpotato/status/1215876962809339904?s=46