금융투자회사는 개인 투자자와 기관 투자자를 대상으로 투자 조언, 자산 관리, 브로커리지 서비스 등을 제공합니다. 이러한 서비스에 대응해서 주문시스템, 시세처리시스템, 입출금시스템 등을 구축관리하고 있고요.
이번 글에서는 Cloud Native 기술을 통해 우리 증권 시스템에서 어떤 문제를 해결하고 또 어떤 장점을 가질 수 있는지 코스콤이 생각하는 차세대 증권 시스템 모습을 그려보려고 합니다.
왜 주문서비스인가?
금융투자협회에 따르면 국내 주식거래활동계좌 수는 2019년 2,936만 개 2020년 3,549만 개 2021년 2022년 5,551만 개 2023년 말 6870만 개로 증가했습니다. 최근 5년간 두 배 넘는 규모입니다. 활동계좌수 증가가 말해주는 것처럼 투자에 대한 사회적 관심이 커졌습니다. 자연스럽게 주식주문도 많아졌고, 신규주식상장이나 경제지표, 정책, 산업별 이슈가 발표되면 주문량이 급격히 늘어나는 일은 운영 중에 자주 겪는 현상입니다.
만약 실시간으로 사용량에 대응해 시스템의 자원이 늘어날 수 있었다면 어땠을까요. 적어도 많은 서비스가 예상되는 시점에 맞춰 미리 시스템을 확장할 수 있는 시스템이었다면 장애를 사전에 피할 수 있지 않았을까 합니다. 전체 시스템이 확장가능한 아키텍처가 아니어도 주문서비스만이라도 확장가능한 형태라면 이러한 문제를 극복할 수 있지 않을까요. 이러한 전략을 '주문분리모델'이라고 하겠습니다. 그리고 저희가 앞서 소개했던 차세대 금융 프레임워크(이하 FICO)를 통해 주문분리모델을 구현해 보았습니다.
주문분리모델
주문분리모델 PoC는 주문서비스의 기능을 MSA로 구현하여 클라우드 인프라 환경을 유연하게 활용할 수 있는지를 확인하는 게 목적입니다. 사용자 입장에서 필요한 계좌개설부터 주문 및 결제에 이르기까지 과정에서 주문체결서비스를 Cloud Native기반의 기술로 구현 및 실행하고 결제 및 입출금 등의 업무는 분리된 Legacy인프라 환경에서 서비스하는 형태로 설계하였습니다.
구현된 시스템을 조금 더 자세히 살펴보겠습니다. 우선 계좌 입출금을 담당하는 출납 AP를 구현합니다. 출납 AP는 고정된 인프라 환경에서 운영되는 시스템입니다. 위의 그림에서 Legacy 시스템에 해당하는 부분이라고 볼 수 있습니다. 그리고 사용자의 주문요청을 처리하는 주문 AP가 있습니다. 주문 AP는 클라우드 환경에서 쿠버네티스 서비스 형태로 구현되어 서비스 부하에 따라 scale-out방식의 성능확장을 할 수 있도록 합니다. 그리고 AP의 성능확장에 대응할 수 있도록 scalable 한 DB를 사용하여 구현하였습니다.
출납과 주문서비스는 독립된 시스템이지만 사용자의 계좌, 예수금, 주식잔고와 같은 데이터를 공유합니다. 이 데이터를 어떤 서비스영역에 두고 또 어떻게 접근해야 하는지에 대한 설계도 중요한 부분입니다. 이런 데이터 Ownership을 정의하고 MSA설계방법에 대해서는 다음에 자세히 소개하겠습니다.
Scalable 성능테스트
구성한 주문분리모델이 대량 서비스 요청 상황에 대응해 적절한 성능확장과 서비스 품질을 유지하는지 확인하기 위해 JMeter를 사용하여 2만 개 계좌를 대상으로 대략 30분 동안 주문을 요청하는 테스트를 진행했습니다.
이 과정 동안 주문 AP의 POD 수는 1개에서 6개까지 늘어났고, Scalable DB는 3대에서 6대로 순차적으로 확장시켜 보았습니다.
서비스 요청수와 그에 따른 초당요청처리(TPS), 서비스 응답시간, CPU자원 사용량, 초당쿼리처리량 등을 측정한 결과입니다. 서비스 요청 처리 건수가 점차 늘어나는 상황에서 그에 상응하는 TPS 성능향상을 볼 수 있습니다.
주문서비스의 응답시간은 부하인입에 따라 다소 늘어나는 구간이 관찰되지만, DB노드를 scale-out 한 이후(09:05 이후)부터 향상되는 것을 볼 수 있었습니다.
결론
Cloud Native기반 주문분리모델은 POD scale-out 통한 자원확장 및 DB scale-out을 통한 성능확장성이 가능한 아키텍처임을 알 수 있습니다. PoC를 통해 자원확장을 통한 TPS증가와 응답시간 향상을 확인할 수 있었습니다. 저희는 성능테스트 외에도 fail-over 테스트와 정합성 테스트를 실시하였고, 다음 3가지 가능성을 확인할 수 있었다고 생각합니다.
- 아키텍처의 성능확장성 : 주문업무 부하 상황 시, 원활한 처리를 위한 scale-out 아키텍처 구현 및 성능 검증
- 비즈니스 정합성유지 : 분리구성 및 fail-over시 예수금, 증거금, 잔고 등 주요 데이터 정합성 확보
- 병행운영가능성 : 단계적 차세대 시스템 구축 및 전환을 고려하여 Legacy시스템과의 업무 경계 식별 및 병행 운영 가능성 확인
댓글