질문)
최근들어서 HTS나 MTS클라이언트에서 데이타의 송수신과정을 REDIS를 활용하는 예가 많다고 합니다. 실제 TCP/IP소켓통신으로 HTS나 MTS클라이언트와 서버를 만드는것보다 효과적일까요?

답변)

요즘 HTS (Home Trading System), MTS (Mobile Trading System)에서 Redis를 활용한 송수신 처리가 많아진 배경과, 그것이 기존의 TCP/IP 소켓 통신 구조보다 왜 더 효과적일 수 있는지를 설명드리겠습니다.


✅ 요약 결론

단순한 요청/응답 구조만 있는 경우엔 TCP/IP 소켓 통신이 빠를 수 있지만,
HTS/MTS처럼 다수의 실시간 데이터, 멀티 프로세스, 비동기처리, 병렬성이 중요한 시스템에서는
Redis를 중간 브로커로 활용하는 방식이 구조적으로 훨씬 효과적입니다.


✅ 비교: 전통적인 TCP/IP vs Redis 기반 메시지 브로커 방식

항목전통 TCP/IP 직접통신Redis 활용 구조
통신 구조 클라이언트 ↔ 서버 직접 연결 클라이언트 ↔ Redis ↔ 서버
연결 수 각 클라이언트마다 연결 필요 Redis와만 연결 유지
병렬성 직접 구현 필요 (epoll, 스레드 등) Redis가 Pub/Sub, Stream 지원
확장성 서버 부하 증가 시 수평 확장 어려움 Redis Cluster로 손쉬운 분산처리
데이터 공유 프로세스 간 공유 어려움 (IPC 필요) Redis가 공유 메모리 역할
복잡성 낮음 (단일 시스템이면) 구조는 조금 복잡하지만 확장성 우수
장애 대응 직접 로직 작성 필요 Redis Sentinel, AOF 등 내장 기능 있음
 

✅ HTS/MTS에서 Redis가 활용되는 실제 이유

  1. 🔁 Pub/Sub 또는 Stream으로 실시간 시세 브로드캐스팅
    • 서버가 1번 계산하면, Redis가 다수 클라이언트에게 푸시
    • 예: "삼성전자 현재가 83,400원"을 Redis가 10만 명에게 전송
  2. 🧵 멀티 프로세스 간 데이터 공유
    • 주문 처리기, 체결 처리기, 시세 처리기 등 여러 프로세스가 Redis를 통해 데이터를 교환
    • LPOP, XREAD, BRPOP 등으로 안정적 큐 역할
  3. ⚙️ 비동기 처리와 부하 분산
    • 클라이언트가 요청한 주문을 Redis에 넣으면, 백엔드 프로세스가 꺼내 처리
    • 이때 서버는 즉시 응답 가능 → 빠른 체감 속도 제공
  4. 📈 통계, 로그, 알람 등 다양한 활용
    • Redis는 단순 캐시를 넘어서, 지표 수집/모니터링에도 활용

✅ Redis가 성능도 뛰어난 이유

  • C로 만들어진 단일 스레드 event loop 구조 (굉장히 빠름)
  • 키 기반 접근은 대부분 O(1)
  • 평균 레이턴시: < 1ms, 초당 수십만 건 처리 가능
  • CPU 및 I/O 병목에 강하고, 데이터 구조 다양함 (list, set, stream 등)

✅ 실제 도입 사례

  • 국내 금융사: 키움증권, NH투자증권 등에서 Redis 기반 실시간 푸시 처리 적용
  • 해외: Robinhood, Binance 등도 Redis 기반 마이크로서비스 연동

✅ 결론 요약

상황추천 방식
단일 시스템, 트래픽 적고 구조 단순함 TCP/IP 직접 통신
수많은 클라이언트, 시세/주문/체결 등 비동기 시스템 Redis 활용 구조 강력 추천
 

✅ 부가 설명

Redis를 사용한다고 해서 TCP를 쓰지 않는 건 아닙니다.
보통 구조는 이렇게 됩니다:

markdown
복사편집
HTS/MTS ↔ (TCP) ↔ 프론트 서버 ↔ (Redis로 데이터 전송) ↔ 백엔드 처리기 ↕ 실시간 시세 시스템

즉, TCP는 입출구용, Redis는 내부 데이터 전달 및 공유용으로 조화롭게 사용됩니다.

+ Recent posts