AWS를 활용한 확장성 높은 모바일 트레이딩 시스템 (MTS) 구축하기

MTS 현황 및 클라우드 도입의 필요성

실시간으로 장소의 제약 없이 주식 거래가 가능한 MTS 서비스를 이용하는 개인투자자가 지속적으로 증가하고 있습니다. 한국은행이 올해 발표한 2021년 금융정보화 추진 현황에 따르면 MTS 서비스 이용 고객 수는 전년 대비 약 2배 증가한 3034만명이고 MTS 서비스 이용건수는 전년대비 72% 증가한 일평균 1억 9999만건이며, 이중 조회 서비스는 1억 7561건으로 87.7%를 차지했습니다. MTS 서비스 이용금액은 일평균 약 32조원으로 지난 2년 간 264% 증가했으며 이 중 매매거래가 89.9%를 차지했습니다. 그리고 해외주식 거래대금은 3년간 11배 증가했고 잔고는 5배 증가했으며, 균등배정방식의 공모주 청약이 연달아 진행되면서 개인투자자들의 시장 참여가 확대되었습니다. 이렇듯 MTS 서비스를 이용하는 개인투자자들의 시장 참여가 확대되고 있지만 개장 직후 접속이 지연되거나 적시에 거래를 하지 못하는 상황이 지속적으로 발생하는 등 개인투자자들이 입는 피해 역시 끊임없이 발생하고 있습니다.

이를 방지하기 위해 증권사는 IT 자원을 사전에 충분히 확보해야 하는데, 자원을 확보하기 위한 규모 산정이 어려울 뿐만 아니라 온프레미스에 이를 구축하고 운영하기 위해서는 많은 비용이 소요됩니다. 하지만 온프레미스 MTS를 클라우드로 확장할 경우 주식거래가 집중되는 패턴을 분석해서 자원 배포를 스케줄링 할 수 있을 뿐만 아니라 예측하지 못한 규모의 거래를 수용할 수 있는 MTS를 구축할 수 있으며 대규모의 거래량을 처리한 이후에는 자원을 축소할 수 있기 때문에 증권사는 클라우드 자원을 탄력적으로 사용하여 효율적인 비용으로 MTS 서비스를 투자자에게 제공할 수 있습니다.

이 글에서는 온프레미스 MTS를 클라우드로 확장하기 위해 온프레미스 데이터 센터와 AWS 클라우드를 연결하고 거래소로부터 제공받은 시세 데이터를 클라우드로 전달하기 위한 두 가지 방법과 AWS 클라우드에서 멀티캐스트 프로토콜을 활용한 시세 데이터 트래픽 전송 방법을 살펴보겠습니다. 그리고 다중 인터페이스를 사용하는 채널 서버의 구성 사례와 MTS 고가용성 확보 방안을 알아보겠습니다.

온프레미스 MTS 구조와 서비스 흐름

먼저 증권사 온프레미스 데이터 센터에 구축된 MTS 구조를 살펴보도록 하겠습니다.

[온프레미스 MTS 구조 및 서비스 흐름도]

증권사의 정보 시스템은 크게 대외계, 계정계, 채널계, 정보계로 구분할 수 있습니다. 증권사 대외계 시스템(FEP)은 거래소, 예탁원, 감독원 등 대외 기관과 연계 업무를 처리하는 시스템으로 MTS 서비스에 필요한 시장 정보 수신 및 매매 처리를 위해 거래소(KRX)와 연결되어 있습니다. 계정계 시스템은 계좌, 출납, 매매, 신용 등의 업무를 다루는 시스템으로 구성되어 있으며 트레이딩 서비스를 위한 비즈니스 애플리케이션이 여기에 해당됩니다. 채널계는 HTS(Home Trading System), MTS(Mobile Trading System), WTS(Web Trading System) 등으로 구성되며 계정계 시스템과 연계하기 위해 MCI(Multi Channel Integration)로 통합하는 것이 일반적입니다. 부하 분산 솔루션은 MTS 서비스를 제공하는 채널 서버에 대한 Health Check, 부하 분산, DR 전환 등을 목적으로 사용합니다. 정보계 시스템은 기업 활동을 수집, 분석하고 성과를 측정하는 시스템으로 투자자에게 맞춤형 서비스를 제공하기 위한 통계적 기법을 사용합니다.

투자자가 모바일 단말에서 MTS 서비스를 이용하는 순서는 다음과 같습니다.

• 단계 1 : 투자자는 모바일 단말에서 증권사 전용 앱으로 MTS 서비스에 접속합니다.
• 단계 2 : 투자자의 MTS 서비스 요청은 부하 분산 솔루션에 의해 MTS 채널 서버로 분산되고, 모바일 단말은 MTS 채널 서버와 연결됩니다.
• 단계 3 : MTS 채널 서버는 거래소로부터 시세 등 매매에 필요한 정보를 수신하고 있습니다.
• 단계 4 : MTS 채널 서버는 거래소로부터 수신한 정보를 채널 서버와 연결된 투자자의 모바일 단말에 제공합니다.
• 단계 5 : 투자자는 MTS 채널 서버로부터 수신한 정보를 기반으로 매매를 진행합니다.

• 단계 6 : 투자자의 매매 요청은 AP 서버에서 로직(예: 주문 가능 금액, 증거금 확인 등)을 처리한 후 거래소에 주문을 전달합니다.

하지만 온프레미스 인프라 환경에서는 급격하게 변하는 시장 상황과 기업공개(IPO, Initial Public Offering)와 같은 대형 이벤트에 맞춰 대규모 신규 자원을 적시에 조달하기 어렵습니다. 많은 시간과 인건비, 그리고 조달 비용이 발생하기 때문이며 요즘과 같이 시장 상황이 불투명할 경우에는 더더욱 이러한 의사결정을 하기 어렵습니다.

이를 해결하기 위해 최근 증권사는 클라우드를 이용한 MTS 서비스 제공에 많은 관심을 갖고 있습니다. 그렇다면 온프레미스 MTS를 AWS 클라우드로 확장하여 클라우드 자원을 탄력적으로 사용하고 효율적인 비용으로 MTS 서비스를 투자자에게 제공하려면 어떻게 해야 할까요?

온프레미스 네트워크를 클라우드로 확장

먼저 온프레미스 MTS 서비스를 클라우드로 확장하기 위해 온프레미스 데이터 센터와 AWS 자원을 연결하는 방법을 알아보겠습니다. 온프레미스 데이터 센터와 AWS 자원을 연결하기 위해서는 전용선 또는 VPN을 이용할 수 있지만 낮은 지연(Low latency)을 위해 전용선으로 연결하는 것이 일반적입니다. 거래소로부터 수신한 시세 데이터를 채널 서버의 위치와 상관없이 높은 수준의 네트워크 품질로 모바일 단말에 제공해야만 MTS 서비스 사용자에게 안정적인 투자 경험을 제공할 수 있기 때문입니다.

[전용선으로 온프레미스 네트워크를 AWS 클라우드로 확장]

AWS Direct Connect 서비스는 공용 인터넷을 경유하지 않고 온프레미스 데이터 센터와 AWS 자원간 직접 연결하여 프라이빗 네트워크 환경을 제공하기 때문에 온프레미스 MTS를 클라우드로 확장하기 위해 가장 먼저 고려해야 하는 AWS 네트워크 서비스입니다. AWS Direct Connect 도입 시 전세계 리전별로 운영되고 있는 Direct Connect Location 파트너를 지정하여 온프레미스 데이터 센터와 AWS 클라우드를 전용선으로 연결할 수 있는데, 이때 Location 파트너를 복수로 지정하거나 Location 내 회선을 다중화하여 네트워크 가용성을 높일 수 있습니다.

전용선으로 온프레미스 네트워크를 AWS 클라우드로 확장한 이후에는 MTS 서비스에 필요한 채널 서버 등 컴퓨팅 자원을 AWS 내에 배포합니다.

[MTS 서비스 트래픽을 온프레미스 데이터 센터(제 1, 2센터)와 AWS 클라우드로 분산]

AWS 클라우드에 배포하는 컴퓨팅 자원은 온프레미스 데이터 센터에 배포한 서버와는 다르게 MTS 서비스 트래픽 규모에 따라 서버 확장(scale out 또는 scale up)과 축소(scale in 또는 scale down)가 가능하기 때문에 효율적인 비용으로 MTS 운영이 가능합니다. 온프레미스 데이터 센터와 AWS 클라우드에 배포한 채널 서버는 모바일 단말을 이용하는 투자자에게 동일한 사용자 경험을 제공하며, 투자자가 MTS 서비스에 접속할 경우 해당 트래픽은 부하 분산 솔루션에 의해 데이터 센터 또는 채널 서버 인스턴스 단위로 분산됩니다.

• 온프레미스 네트워크와 AWS 클라우드 자원간의 커뮤니케이션 패턴은 다음을 참조 하십시오.
• 전용선을 연결 방식은 다음을 참조 하십시오.

온프레미스 시세 데이터를 클라우드에 전달하는 방법

온프레미스 데이터 센터와 AWS 자원간 낮은 지연으로 커뮤니케이션이 가능하고 채널 서버를 분산해서 배포했다면 다음은 온프레미스 데이터 센터로부터 AWS 클라우드로 시세 데이터를 전달하기 위한 기술을 도입해야 합니다. 이때 유니캐스트(Unicast) 혹은 멀티캐스트(Multicast) 프로토콜을 이용해서 온프레미스 데이터 센터에서 AWS 클라우드로 시세 데이터를 전달 할 수 있습니다.

[유니캐스트를 사용하는 A증권사와 멀티캐스트 프로토콜을 사용하는 B증권사의 시세 데이터 흐름]

유니캐스트를 사용할 경우 온프레미스의 메시징 시스템을 이용하여 Pub/Sub 메시징 패턴으로 거래소로부터 수신한 시세 데이터를 AWS에 배포한 채널 서버로 직접 전달할 수 있습니다. 이때 메시징 시스템을 온프레미스 데이터 센터가 아닌 AWS 클라우드에 구축하는 것도 고민해 볼 수 있습니다.

멀티캐스트를 사용할 경우 온프레미스 데이터 센터 내에서 사용하는 멀티캐스트 도메인을 AWS 내부에서 사용하기 위해서는 터널링(tunneling) 메커니즘과 IGMP(Internet Group Management Protocol), PIM(Protocol Independent Multicast)과 같은 멀티캐스트 라우팅 프로토콜이 필요합니다. 이를 위해 먼저, 온프레미스 데이터 센터와 AWS 간 터널링(예: GRE)을 구성하고 구성된 터널 인터페이스 위에 멀티캐스트 라우팅 프로토콜(예: PIM)을 적용할 수 있는 3rd party 가상 라우터를 AWS 내에 설치해야 합니다. 3rd party 가상 라우터까지 수신된 멀티캐스트 트래픽은 AWS Transit Gateway의 IGMP(또는 Static) 프로토콜 기능을 통해 복수개의 멤버 인스턴스로 전송이 가능합니다.

AWS 클라우드에서의 멀티캐스트 시세 데이터 트래픽

앞서 살펴봤듯이 AWS 클라우드는 시세 데이터를 전달하기 위한 유니캐스트와 멀티캐스트 프로토콜을 모두 지원합니다.

유니캐스트를 사용할 경우 AWS에 배포한 채널 서버들은 메시징 시스템에 의해 온프레미스로부터 시세 데이터를 직접 수신하게 되지만, 멀티캐스트를 사용할 경우에는 AWS 내 설치한 가상 라우터와 멀티캐스트 트래픽 라우팅을 지원하는 AWS Transit Gateway을 이용해야 온프레미스 멀티캐스트 스트림을 AWS 내 채널 서버가 수신할 수 있습니다.

[온프레미스 멀티캐스트 스트림을 AWS 내 채널 서버까지 전달하는 과정]

• 단계 1 : 온프레미스 멀티캐스트 스트림을 AWS 내 가상 라우터가 수신합니다.
• 단계 2 : 가상 라우터는 수신한 멀티캐스트 스트림을 AWS Transit Gateway의 멀티캐스트 도메인 그룹으로 전송합니다.
• 단계 3 : AWS Transit Gateway는 수신한 멀티캐스트 스트림을 가상 라우터 소스 ENI와 동일한 멀티캐스트 도메인 그룹의 멤버 ENI(채널 서버)에 전달합니다.

가상 라우터는 AWS 내에서 멀티캐스트 소스 역할을 담당합니다. 즉, 가상 라우터는 온프레미스 데이터 센터로부터 멀티캐스트 트래픽을 항상 수신하여 AWS Transit Gateway로 전달합니다. 이를 구현하기 위해서 가상 라우터에서는 수신이 필요한 모든 멀티캐스트 도메인에 대해 정적(Static) IGMP join 설정을 해야 합니다. 그리고 멀티캐스트 소스인 가상 라우터는 반드시 Nitro 인스턴스 타입이어야 합니다.

AWS Transit Gateway는 멀티캐스트 라우팅을 지원하는 AWS 네트워크 서비스로 가상 라우터로부터 수신한 시세 데이터를 멀티캐스트 도메인 그룹에 속한 멤버 인스턴스들에게 전달합니다. 즉, 가상 라우터가 멀티캐스트 소스가 되어 AWS Transit Gateway에 트래픽을 보내고 Transit Gateway는 시세 데이터를 멀티캐스트 도메인에 속한 구성원에게 전달합니다.

가상 라우터가 수신한 시세 데이터를 동일한 멀티캐스트 도메인 그룹에 속한 멤버 인스턴스들에게 전달하기 위한 AWS Transit Gateway 작업 순서는 다음과 같습니다.

[가상 라우터로부터 수신한 시세 데이터를 채널 서버에 전달하기 위한 AWS Transit Gateway 작업 순서]

• 단계 1 : AWS Transit Gateway(TGW)를 생성합니다.(멀티캐스트 도메인 기능 활성화)
• 단계 2 : AWS TGW를 VPC에 연결(Attachment) 합니다.
• 단계 3 : AWS TGW를 가용 영역의 서브넷(Subnet)과 연결(Association) 합니다.
• 단계 4 : AWS TGW 멀티캐스트 도메인을 생성합니다.
• 단계 5 : 소스와 멤버의 네트워크 인터페이스(ENI, Elastic Network Interface)가 있는 서브넷을 멀티캐스트 도메인에 연결합니다.
• 단계 6 : 멀티캐스트 도메인 그룹(예: 224.0.0.2) 내에서 멀티캐스트 소스(가상 라우터)에 해당되는 네트워크 인터페이스를 선택합니다.
• 단계 7 : 멀티캐스트 도메인 그룹(예: 224.0.0.2) 내에서 멀티캐스트 멤버(채널 서버들)에 해당되는 네트워크 인터페이스를 선택합니다.

아래는 동일한 멀티캐스트 도메인 그룹 주소에 해당하는 소스(가상 라우터)와 멤버 인스턴스의 네트워크 인터페이스 정보와, AWS Transit Gateway 내에서 멀티캐스트 도메인 그룹 IP 주소(224.0.0.2)에 대한 소스와 멤버 네트워크 인터페이스를 정적으로 구성한 예시입니다.

[멀티캐스트 소스(가상 라우터)와 멤버 인스턴스의 네트워크 인터페이스 정보]

[멀티캐스트 도메인 그룹 주소(224.0.0.2)에 대한 소스와 멤버 인스턴스들의 네트워크 인터페이스 등록]

멀티캐스트 도메인 그룹에서 소스로 사용하는 네트워크 인터페이스는 가상 라우터의 네트워크 인터페이스(10.0.0.25)이고, 멤버 인스턴스들은 멀티캐스트를 수신하기 위한 채널 서버들의 네트워크 인터페이스 주소(10.0.1.7, 10.0.1.79, 10.0.1.236)입니다. 이 구성은 멀티캐스트 그룹에 속하는 소스와 멤버를 정적(Static)으로 구성한 사례이지만 IGMP로 구성할 수도 있습니다. AWS Transit Gateway에서 IGMP로 구성할 경우 멤버 인스턴스는 AWS Transit Gateway에 IGMP join 메세지를 전송하여, 원하는 멀티캐스트 그룹에 자동으로 등록되어 시세 데이터 트래픽을 수신할 수 있습니다.

• AWS Transit Gateway에서의 멀티캐스트 설정은 다음을 참조 하십시오.

거래소로부터 수신한 시세 데이터를 멀티캐스트 프로토콜을 사용해서 AWS 내 채널 서버까지 전달하기 위한 방법을 종합하면 아래와 같습니다.

[멀티캐스트 프로토콜을 사용해서 거래소로부터 AWS 내 채널 서버까지 시세 데이터를 전달 방법]

거래소로부터 시세 데이터를 수신하는 대외계 시스템(FEP)은 온프레미스에 있는 채널 서버 뿐만 아니라 AWS 클라우드에 배포한 채널 서버에도 멀티캐스트 프로토콜을 사용해서 시세 데이터를 제공합니다. AWS 내에 구축한 가상 라우터는 온프레미스의 멀티캐스트 라우터로부터 터널 인터페이스와 멀티캐스트 라우팅 프로토콜을 사용해서 시세 데이터를 수신하고, 수신한 시세 데이터를 AWS Transit Gateway에 구성한 멀티캐스트 도메인 그룹 주소 정보에 따라 채널 서버에 제공합니다.

다중 인터페이스를 사용하는 채널 서버 구성

MTS 서비스를 위한 채널 서버는 온프레미스로부터 수신한 시세데이터를 모바일 단말에 제공하는 것 이외에도 주문을 수신하거나 기타 투자정보를 투자자에게 제공합니다. 이때 채널 서버는 보안 요구 사항 또는 데이터의 종류나 프로토콜에 따라 네트워크를 분할할 수 있으며 분할한 네트워크 단위로 라우팅 경로를 구성할 수 있습니다.

아래는 멀티캐스트 프로토콜을 사용하는 Egress(시세) 트래픽과 Ingress(주문) 트래픽에 대한 네트워크를 분할한 예입니다. MTS 서비스 이용자는 접속 전용 네트워크를 통해서 채널 서버에 접속합니다. 시세 전용 네트워크에서는 온프레미스로부터 수신한 시세데이터만 처리하고 주문 전용 네트워크에서는 MTS 서비스 이용자의 매매 데이터를 처리합니다.

[다중 인터페이스를 사용하는 채널 서버의 네트워크 분할]

증권사 온프레미스 데이터 센터와 AWS 클라우드는 전용선으로 연결되었습니다. 이때 AWS 클라우드 환경에서의 네트워크 복잡도를 줄이고 VPC 확장성을 고려해서 전용선(AWS Direct Connect)을 AWS Transit Gateway(TGW2)와 연결했습니다. MTS VPC와 가상 라우터 VPC는 TGW2와 연결(Attachment)했고 TGW1은 멀티캐스트 송수신을 위한 것으로 멀티캐스트 도메인 그룹(주소, 소스, 멤버)을 관리하기 위해 연결(Attachment)했습니다. MTS VPC에 배포한 개별 MTS 채널 서버는 3개의 네트워크 인터페이스로 구성되었습니다. 대외 접속용 트래픽을 위한 네트워크 인터페이스, 시세 데이터를 수신하기 위한 네트워크 인터페이스, 그리고 주문을 처리하기 위한 네트워크 인터페이스입니다. 3개의 네트워크 인터페이스는 각각의 서브넷에 배포되었으며 서로 다른 라우팅 경로로 구성되어 있습니다.

또한 MTS 채널 서버가 3개의 네트워크로 분리된 인터페이스로 트래픽을 보내기 위해서는 채널 서버의 커널 IP 라우팅 테이블에 대한 변경이 필요합니다.

• 시세 데이터를 멀티캐스트 멤버 ENI를 통해서 수신하기 위해서는 멀티캐스트 도메인 그룹 주소(예: 224.0.0.2)에 대해 시세 전용 서브넷의 라우팅 정보를 참조하도록 커널 라우팅 테이블을 등록해야 합니다.
• 주문 데이터를 주문 ENI를 통해서 송수신하기 위해서는 온프레미스의 주문 CIDR에 대해 주문 전용 서브넷의 라우팅 정보를 참고하도록 커널 라우팅 테이블을 동록해야 합니다.
• MTS 단말과 시세 데이터와 주문 데이터를 송수신하기 위해서는 MTS 단말 주소 CIDR(예: 0.0.0.0/0)에 대해 접속 전용 서브넷의 라우팅 정보를 참고하도록 라우팅 테이블을 등록해야 합니다.

MTS 서비스 고가용성(HA, High Availability)을 위한 설계

지금까지 온프레미스 MTS를 클라우드로 확장해서 MTS 서비스를 제공하는 방법을 알아보았습니다. MTS 서비스에 대한 고가용성 확보를 위해서는 다음의 사항을 추가적으로 검토해야 합니다.

[MTS 서비스에 대한 고가용성을 확보하기 위해 센터 또는 가용 영역 수준의 부하 분산 및 장애 격리]

AWS 리전은 복수개의 가용 영역으로 구성되어 있고 각 가용 영역은 물리적으로 분리되어 있기 때문에 가용 영역 단위로 MTS를 다중화 할 수 있습니다. 즉, 가상 라우터(멀티캐스트 프로토콜을 사용할 경우)와 방화벽 그리고 MTS 채널 서버를 각 가용 영역 단위로 배치함으로써 센터 혹은 가용 영역 단위로 MTS 서비스 트래픽을 분산하고 장애를 격리할 수 있습니다.

• AWS에서 가용 영역을 활용한 고가용성 시스템을 설계하기 위해 다음을 참조 하십시오.
• AWS Well-Architected Framework의 Reliability Pillar를 참조 하십시오.

마치며

이 글에서는 AWS 클라우드로 확장하는 모바일 트레이딩 시스템(MTS) 아키텍처를 살펴보았습니다. 온프레미스 네트워크를 AWS 클라우드로 확장하는 것을 시작으로 온프레미스 데이터 센터에서 거래소로부터 수신한 시세 데이터를 AWS 클라우드에 배포한 채널 서버까지 전달하기 위한 두 가지 방법에 대해 알아보았습니다. 그리고 AWS 클라우드 내에서 멀티캐스트 트래픽 라우팅을 위한 AWS Transit Gateway 작업과 다중 인터페이스를 사용하는 채널 서버의 구성 사례, MTS 서비스에 대한 고가용성을 확보하기 위한 사례를 살펴보았습니다.

MTS 서비스 이용 확대와 개인 투자자로부터 신뢰 확보가 중요한 지금, 디지털 전환의 일환으로 모바일 트레이딩 시스템을 클라우드로 확장함으로써 급변하는 시장 상황에서 효율적인 비용으로 IT 자원을 활용하고 더 나아가 고객 경험 향상에 집중할 수 있는 모바일 트레이딩 환경을 만들어 보시길 바랍니다.

금융 뿐만 아니라 멀티미디어, 통신 등 다양한 산업 분야에 속한 기업이 멀티캐스트 애플리케이션을 실행하고 있습니다. 이 글에서 소개한 금융 사례와 더불어 온프레미스의 멀티캐스트 비디오 스트리밍을 AWS와 통합하는 블로그와 AWS re:Invent 2020에 발표한 Using AWS Transit Gateway for your multicast workloads 를 참고하시면 온프레미스의 멀티캐스트 워크로드를 AWS와 통합하는데 있어서 도움이 됩니다.