위험 관리는 금융 세계 전체에서 매우 중요한 업무이며(다른 분야에서도 점점 더 많이) 은행, 투자자, 보험사 및 기타 금융 기관의 IT팀에게 중요한 투자 영역입니다. SingleStore는 위험 관리, 의사 결정 응용 프로그램 및 분석뿐 아니라 이상거래 탐지 및 자산 관리와 같은 관련 영역을 지원하는 데 매우 적합한 것으로 입증되었습니다.
이 사례 연구에서는 한 주요 금융 서비스 제공업체가 Oracle을 SingleStore와 Kafka로 교체하여 위험 관리 의사 결정의 성능과 개발 용이성을 어떻게 개선하였는지 살펴보겠습니다. 또한 다른 유사한 SingleStore 구현에서 배운 몇 가지 교훈도 포함하겠습니다.
Oracle 기반 데이터 웨어하우스의 문제점
우리와 협력하는 많은 금융 서비스 기관에서 트랜잭션 처리를 위한 데이터베이스로 Oracle이 사용되며, 별도로 데이터 웨어하우스로도 사용됩니다. 이 아키텍처에서 ETL(추출, 변환 및 로드) 프로세스는 운영 데이터베이스와 분석 데이터 웨어하우스 간에 데이터를 이동시킵니다. 다른 ETL 프로세스도 일반적으로 데이터 웨어하우스에 추가 데이터 소스를 로드하는 데 사용됩니다.
이 아키텍처는 기능 기반이고 확장성을 가졌지만 금융 기관의 위험 관리 시스템이 충족해야 하는 증가하는 동시성 및 성능 기대치를 충족하는 데 이상적이지 않습니다. SingleStore 고객은 기존 접근 방식에서 다음과 같은 많은 문제를 경험하였습니다.
● 오래된 데이터. 분석 사용자가 원하는 신선한 트랜잭션 데이터는 항상 일괄 로드(트랜잭션 데이터베이스로), 주기적인 트랜잭션 처리, ETL 프로세스에 의해 처리되므로 OLAP 데이터베이스에 표시되지 못했습니다.
● 다양한 시기의 데이터. 처리 일정이 다른 여러 데이터 소스가 있기 때문에 포괄적인 보고 및 광범위한 쿼리는 가장 느린 프로세스가 최신 상태가 될 때까지 기다려야 했습니다.
● 운영 복잡성. 각각의 ETL 프로세스는 그 자체로 번거롭고, 운영자의 시간을 빼앗았으며, 다른 프로세스와 혼동되었습니다.
● 취약성. 여러 프로세스를 조정해야 하기 때문에 한 영역에 문제가 발생하면 모든 분석 사용자에게 문제가 발생하였습니다.
● 비용. 기업은 데이터베이스 및 관련 기술에 대해 너무 많은 고가의 계약을 맺어야 했고, 운영을 위해 다양하고 전문화된 기술을 가진 인력을 너무 많이 필요해졌습니다.
위험 관리에 사용되는 데이터베이스에 필요한 것
위험 관리에 사용되는 데이터베이스에 대한 요구 사항은 다른 데이터 관련 프로젝트에 대한 요구 사항이 더욱 강화된 것입니다. 위험 관리에 사용되는 데이터베이스는 다음과 같은 데이터 아키텍처를 지원해야 합니다.
● 빠른. 강력한 규제압력 하에서 금융 서비스 기업은 그들이 보유하고 있는 모든 데이터를 사용할 책임이 있습니다. 질문에 대한 느린 답변은 허용되지 않습니다.
● 최신 데이터 취급. 일반적인 주기로 OLTP 데이터베이스, ETL 프로세스를 거쳐 OLAP 데이터베이스/데이터 웨어하우스로 이동된 분석용 데이터는 오래된 것입니다. 이것은 위험 관리에서 더이상 용납되지 않습니다.
● 스트리밍 지원. 금융 기관은 즉각적인 분석 가용성을 위해 수신데이터를 데이터베이스로 스트리밍해야 한다는 압력이 증가하고 있습니다. 오늘날 Kafka는 빠른 연결을 제공합니다. 데이터베이스는 데이터를 처리하고 스마트하게 이동시키는 역할을 해야 합니다.
● 높은 동시성. 기업의 최고 경영진은 전사적 분석 가시성을 원하며, 점점 더 많은 직원들은 일상 업무에 분석이 필요하다고 생각합니다. 이는 데이터베이스 기반 분석이 모두에 대해 우수한 응답성과 함께 많은 수의 동시 사용자를 지원해야 함을 의미합니다.
● 유연성. 위험 관리 데이터베이스는 수신 데이터가 있는 곳, 사용자가 있는 곳 근처 또는 조합된 곳에서 호스팅해야 할 수 있습니다. 따라서 이러한 요구 사항을 충족하기 위해 필요에 따라 모든 퍼블릭 클라우드, 온프레미스, 컨테이너 또는 가상 머신 또는 혼합 환경에서 실행할 수 있어야 합니다.
● 확장성. 수집 및 처리 요구 사항은 데이터 전송 체인의 모든 부분에서 빠르게 증가할 수 있습니다. 데이터베이스는 필요할 때마다 임의의 대용량을 제공할 수 있도록 확장 가능해야 합니다.
● SQL 지원. 많은 인기 있는 비즈니스 인텔리전스(BI) 툴이 SQL을 사용하고 많은 사용자가 SQL에서 애드혹(Ad-hoc) 쿼리를 작성하는 방법을 알고 있습니다. 또한 SQL은 수십 년 동안 최적화되었기 때문에 SQL 지원 데이터베이스가 성능 요구 사항을 충족할 가능성이 더 높습니다.
위험 관리 시스템을 위한 두 가지 중요한 기능은 위험 관리 시스템을 구동하는 데이터베이스에서 이러한 가치 있는 특성의 중요성을 강조합니다.
첫 번째 영역은 사전 거래 분석의 필요성입니다. 거래자는 거래의 리스크 프로파일에 대한 쿼리에 대한 적극적인 피드백을 원합니다. 그들과 조직은 또한 비정상적으로 위험하거나 사전 설정된 위험 임계값을 초과하는 거래에 대한 배경 분석 및 경고가 필요합니다.
거래 전 분석은 계산이 많이 필요하지만 다른 작업을 느리게 해서는 안됩니다(위의 "빠른" 및 "높은 동시성" 참조). 이 분석은 거래가 실행될 때 실행되거나 거래 실행의 전제 조건으로 실행될 수 있습니다. 또한 분석이 조직의 지침을 벗어나는 경우 거래에 플래그가 지정되거나 지연될 수 있습니다.
What-if 분석(가정 분석) 또는 논리적 보완인 익스포저(Exposure = 위험에 노출된어 있는 자산)) 분석은 위험 관리에 매우 중요한 두 번째 영역입니다. 익스포저 분석은 "일본 엔화에 대한 직접 익스포저는 무엇입니까?"와 같은 질문에 답합니다. 즉, 자산의 어느 부분이 엔화로 표시됩니까?
엔화 가치가 크게 오르거나 내리면 영향을 받는 모든 자산인 간접 익스포저에 대해 질문하는 것도 마찬가지로 중요합니다. 이러한 종류의 분석을 통해 조직은 포트폴리오가 그룹으로서 특정 국가, 통화, 상품 등으로 너무 강하게 이동하는 경우 발생할 수 있는 심각한 문제를 피할 수 있습니다.
What-if 분석은 이와 동일한 질문을 다루지만 더 구체적으로 만듭니다. "엔이 5% 오르고 중국 위안화가 2% 하락한다면?" 이것은 한 국가의 경제가 뜨거워지고 다른 국가의 경제가 둔화될 때 발생할 수 있는 일련의 관련 통화 이동입니다.
이러한 질문은 계산 집약적이며, 답변을 위해 사용 가능한 모든 데이터를 광범위하게 필요로 하며 거래 실행 또는 실시간 분석 대시보드 실행과 같은 다른 작업의 속도를 늦추지 않고 실행할 수 있어야 합니다. 속도, 확장성 및 높은 수준의 동시성 지원과 같은 SingleStore 특성을 통해 이러한 위험 관리 관련 요구 사항을 원활하게 해결할 수 있습니다.
SingleStore로 성능, 확장성 및 개발 용이성 개선
Oracle 및 기타 레거시 관계형 데이터베이스(RDB)는 상대적으로 느립니다. 그것들은 OLTP 또는 OLAP 데이터베이스 역할만 할 수 있습니다(둘 다 할수 없음). 상당한 추가 비용과 복잡성 없이 높은 동시성 또는 확장성을 지원하지 않습니다. 가속을 위해 특수 하드웨어가 필요합니다. 또한, 이러한 레거시 관계형 데이터베이스들은 최신 데이터베이스에 비해 라이선스 및 운영 비용이 매우 비쌉니다.
Oracle은 고객의 요구 사항이 변경됨에 따라 이러한 많은 문제를 해결하기 위해 노력해 왔습니다. 단일 노드 아키텍처 기반에 대한 확장성 요구 사항은 스케일업(scale up)을 통해 부분적으로 충족될 수 있습니다. 비록 엄청나게 비싸고 관리하기 어려운 시스템인 Exadata이기는 하지만 말입니다. Oracle은 또한 SQL 요구 사항을 충족하므로 NoSQL 시스템에 비해 이점이 있지만, SingleStore와 같은 최신 "NewSQL" 데이터베이스에 비해 이점이 없습니다.
고객은 충분한 검토 후 분석 지원 시스템을 Oracle 데이터 웨어하우스에서 SingleStore로 이전하기로 결정했습니다.
해법: 분석을 위한 전용 데이터베이스
Oracle 중심의 레거시 아키텍처의 문제를 해결하기 위해 우리와 협력하는 한 기업은 전용 분석 데이터베이스로 이동하기로 결정했습니다. 이 접근 방식은 기업에 지속적으로 필요한 모든 데이터를 단일 데이터 저장소에 저장하고 신속하고 지속적인 의사 결정에 사용할 수 있도록 합니다.
또한, 데이터의 원래 생성부터 데이터 저장소에 반영될 때까지의 지연 시간을 줄이려고 합니다. 이러한 노력의 일환으로 데이터 소스와 데이터 저장소 간의 모든 메시징은 Apache Kafka와 같은 단일 메시징 시스템으로 이동됩니다. ETL 프로세스는 가능하면 제거되고, 그렇지 않은 경우 메시징 시스템에 로드되는 것으로 표준화됩니다.
이 데이터 저장소는 많은 작업을 수행하지만 전부는 아닙니다. 애드혹 분석 쿼리, 보고, 비즈니스 인텔리전스(BI) 툴, ML/AI 운영적 이용을 지원합니다.
모든 데이터를 항상 저장하는 것은 아닙니다. 이 데이터 저장소에 잠재적으로 관련된 전사 데이터를 보관하지 않는 것은 비용, 물류 및 속도에 이점이 있습니다.
분석에 필요하지 않은 데이터는 삭제되거나 점점 더 보편적인 대안이 되는 데이터 레이크에 일괄 로드되며, Hadoop/HDFS를 통해 데이터를 장기간 저장할 수 있으며 데이터 과학자의 필요에 따라 연결할 수도 있습니다.
또한, 데이터 레이크는 조직이 많은 양의 소스 데이터 또는 가볍게 처리된 데이터를 유지할 수 있도록 하여, 운영 요구 사항을 방해 하지 않고 가능한 가장 광범위한 데이터에 액세스할 수 있도록 감사 및 광범위한 분석 작업을 가능하게 함으로써 귀중한 거버넌스 기능을 제공합니다.
SingleStore는 전용 분석 데이터베이스로 사용하기에 적합합니다. SingleStore는 내장된 파이프라인을 통해 데이터를 빠르게 수집할 수 있습니다. 또한 파이프라인을 통해 들어오는 데이터에 대한 트랜잭션을 직접 처리하거나, 더 가벼운 처리를 위해 또는 더 복잡한 작업을 위해 스토어드 프로시저(Stored Procedure)를 사용할 수 있습니다. 스토어드 프로시저는 수집 및 변환 프로세스에 기능을 추가합니다.
SingleStore는 동시에 실행되는 데이터 수집, 트랜잭션 및 쿼리를 지원할 수 있습니다. 분산 시스템이기 때문에 SingleStore는 필요한 만큼 데이터 수집, 변환 처리 및 쿼리 트래픽을 처리하도록 스케일아웃(sacle out)할 수 있습니다.
데이터 레이크에도 별도의 SingleStore 인스턴스를 사용할 수 있지만, 이 기능은 Hadoop/HDFS 또는 명시적으로 데이터 레이크로 설계된 다른 시스템에서 처리하는 경우가 더 많습니다.
SingleStore 구축
위에서 설명한 금융 기관은 포트폴리오 위험 관리 기능뿐만 아니라, 기타 분석 기능을 크게 개선하기를 원했습니다. 그들은 또한 ML/AI의 실시간 활용과 연구 활용도 모두 지원하기를 원했습니다.
이러한 목표를 지원하기 위해 기업은 세 가지 최신 데이터 툴을 기반으로 점점 더 일반적인 아키텍처로 구축했습니다.
- Apache Kafka를 사용한 메시징. 메시징, 데이터 흐름 속도 향상 및 운영 단순화를 위해 Kafka를 표준화했습니다.
- SingleStore로 분석 데이터베이스 통합. SingleStore에서 실행되는 단일 데이터 저장소가 분석을 위한 엔진 및 정보 소스로 선택되었습니다.
- Apache Hadoop기반 독립 실행형 데이터 레이크. 데이터 레이크는 분석 흐름에서 제거되어 데이터의 상위 집합을 저장하기 위해 사용되었습니다.
보시다시피 아키텍처의 핵심은 전용 분석 데이터베이스로 SingleStore로 전환된 후 훨씬 단순해졌습니다. 아키텍처는 4개의 사일로로 구성됩니다.
입력
각 시스템, 모든 외부 데이터 소스 및 행동 데이터(사용자가 서비스를 사용하며 겪게 되는 행동을 데이터화한 것)의 내부 소스는 모두 동일한 데이터 스트리밍 클러스터(Confluent의 Kafka 기반 스트리밍 플랫폼)로 출력됩니다.
스트리밍 데이터 수집
데이터 스트리밍 클러스터는 두 개의 서로 다른 대상에 대한 모든 입력과 데이터를 수신합니다.
- 분석 데이터베이스. 대부분의 데이터는 [분석 데이터베이스]로 이동합니다.
- Data Science Sandbox. 일부 정형 및 반정형 데이터는 [Data Science Sandbox]로 이동합니다.
- Hadoop/HDFS. 모든 데이터는 장기 저장을 위해 [Hadoop/HDFS]로 전송됩니다.
데이터 저장소
SingleStore는 [분석 데이터베이스]와 [Data Science Sandbox]를 저장합니다. [Hadoop/HDFS]는 데이터 레이크를 보유합니다.
쿼리
쿼리는 애드혹(Ad-hoc) SQL 쿼리; 비즈니스 응용프로그램; 기업의 주요 BI툴 Tableau; MS 엑셀; SAS나 기타 통계 툴; 데이터 사이언스 툴등 여러 소스에서 제공됩니다.
업데이트된 데이터 플랫폼의 혜택
ETL에서 Oracle, Kafka, SingleStore 및 Hadoop으로 이동하면서 위험 관리 및 기타 분석을 구현한 고객은 광범위한 혜택을 얻었습니다.
그들은 데이터에 대한 야간 배치 로드로 시작했지만 분석 성능의 긴 대기나 지연을 일으키지 않고 보다 빈번한 업무중 업데이트로 옮겨야 했습니다. 분석을 위해서는 초당 수십 개의 쿼리에 대해 1초 미만의 응답 시간이 필요했습니다.
SingleStore를 통해 고객은 데이터가 제공되는 즉시 데이터를 로드할 수 있었습니다. 그 결과 최신 데이터가 포함된 쿼리 결과로 쿼리 성능이 향상되었습니다. 고객은 성능 향상, 가동 시간 향상, 응용프로그램 개발 간소화를 달성했습니다. 위험 관리자는 훨씬 더 최신 데이터에 액세스할 수 있습니다.
위험 관리 사용자, 분석 사용자 전체 및 데이터 사이언티스트는 다음과 같은 다양한 혜택을 폭넓게 공유합니다.
- Oracle 라이선스 비용 절감
- 서버, 컴퓨팅 코어 및 RAM의 필요성 감소로 인한 H/W 비용 절감
- 최신 데이터(훨씬 더 빠르게 사용할 수 있는 새로운 데이터) 사용 가능
- 새로운 응용프로그램을 위한 코딩 감소
- TCO 절감
- 클라우드 연결성 및 유연성
- 운영 비용 절감
- 오래된 배치 응용프로그램의 유지 관리 비용 제거
- 더 많은 분석 사용자 지원
- 더 빠른 분석 결과
- 더 빠른 데이터 사이언스 결과
- 새로운 비즈니스 기회
왜 위험 관리를 위한 SingleStore인가?
SingleStore는 빠르며 초당 최대 1조 행을 스캔할 수 있습니다. 완전히 확장 가능한 분산 SQL 데이터베이스입니다. SingleStore는 Apache Kafka와 같은 메시징 플랫폼과 함께 스트리밍을 지원하고 정확히 한 번(exactly-once) 보장을 제공합니다. SingleStore는 높은 수준의 동시성을 지원하며, 온프레미스 또는 클라우드, 컨테이너 또는 가상 머신 등 모든 곳에서 실행됩니다.
SingleStore 고객은 소프트웨어 라이선스, 하드웨어 요구 사항 및 운영 비용을 포함하여 플랫폼의 응답성, 동시성 및 비용 절감을 위해 분석의 일부 또는 전체를 SingleStore로 이전하는 것으로 시작하는 경우가 많습니다.
그러면 고객들은 SingleStore가 점점 더 많은 데이터 파이프라인으로 인수할 수 있다는 사실을 알게됩니다. 메시징을 위한 Kafka, 데이터 처리를 위한 SingleStore, 데이터 레이크로 Hadoop/HDFS, BYOBI(Bring your own BI 혹은 BI, 기타 툴)의 조합은 광범위한 데이터 분석 요구 사항에 대한 핵심 아키텍처 역할을 할 수 있습니다.
지금 무료로 SingleStore를 사용해 볼 수 있습니다. 또는 SingleStore가 귀하의 목표를 달성하는 데 어떻게 도움이 되는지 설명할 수 있는 기술 전문가와 상담하려면 저희에게 연락하시기 바랍니다.
March 5th, 2019
출처: https://www.singlestore.com/blog/case-study-improving-risk-management-performance-memsql/
Case Study: Improving Risk Management Performance with SingleStore and Kafka
Portfolio risk management is a long-standing concern for financial institutions, often supported by legacy transactional databases such as Oracle. This case study describes how one top financial institution moved to SingleStore, gaining greater responsiven
www.singlestore.com
※ www.a-platform.biz | info@a-platform.biz
'SingleStoreDB > 사례연구' 카테고리의 다른 글
| [사례 연구, Infiswift] IoT와 AI 애플리케이션의 분석 기능을 강화한 방법 (0) | 2021.08.20 |
|---|---|
| [사례 연구, 금융] 머신러닝기반 실시간 이상거래 탐지(미국 메이저 은행) (0) | 2021.08.10 |
| [사례 연구, monday.com] 엔지니어가 SingleStore의 BI 기능을 효과적으로 사용하는 방법 (0) | 2021.08.10 |
| ML 플랫폼 "MindsDB"에서 SingleStore 데이터베이스를 통한 실시간 머신 러닝 (0) | 2021.06.29 |
| [사례 연구, Teespring] 실시간 분석을 통해 전자상거래 플랫폼 개선 (0) | 2021.01.12 |
