영화 '우리의 비밀우주: 세포의 숨겨진 삶' 스틸컷

투자사업은 은행계에서 가장 복잡한 분야 중 하나입니다. 대출, 차입금, 예금뿐만 아니라 증권, 통화, 상품, 파생상품 및 구조화상품 형태의 온갖 종류의 복잡성이 존재하기 때문입니다.

최근 우리는 인구의 금융 이해력이 증가하는 것을 목격했습니다. 점점 더 많은 사람들이 증권 시장 거래에 참여하고 있습니다. 개인 투자 계좌가 등장한 것은 그리 오래되지 않았습니다. 이를 통해 증권 시장을 거래하고 세금 공제를 받거나 세금 납부를 피할 수 있습니다. 그리고 우리를 찾아오는 모든 고객은 자신의 포트폴리오를 관리하고 보고 내용을 실시간으로 확인하기를 원합니다. 또한 대부분의 경우 이 포트폴리오는 다중 제품입니다. 즉, 사람들은 다양한 비즈니스 라인의 고객입니다.

또한 러시아와 외국 모두 규제 기관의 요구가 증가하고 있습니다.

현재 요구 사항을 충족하고 향후 업그레이드를 위한 기반을 마련하기 위해 우리는 Tarantool을 기반으로 투자 비즈니스 핵심을 개발했습니다.

일부 통계. Alfa-Bank의 투자 사업은 개인 및 법인에게 다양한 증권 시장에서 거래 기회를 제공하는 중개 서비스, 증권 보관을 위한 예탁 서비스, 개인 및 대규모 자본을 가진 개인을 위한 신탁 관리 서비스, 다른 회사를 위한 증권 발행 서비스를 제공합니다. . Alfa-Bank의 투자 사업에는 다양한 거래 플랫폼에서 다운로드되는 초당 3개 이상의 견적이 포함되어 있습니다. 영업일 동안 은행이나 고객을 대신하여 시장에서 300만 건 이상의 거래가 체결됩니다. 외부 및 내부 플랫폼에서 초당 최대 5건의 주문 실행이 발생합니다. 동시에 내부 및 외부의 모든 고객은 자신의 위치를 ​​실시간으로 확인하기를 원합니다.

선사 시대

2000년대 초반부터 당사의 투자 사업 분야는 외환 거래, 중개 서비스, 통화 거래, 증권 장외 거래 및 다양한 파생 상품 등 독립적으로 발전했습니다. 그 결과 우리는 기능성 우물의 함정에 빠졌습니다. 그것은 무엇입니까? 각 사업 부문에는 서로의 기능을 복제하는 자체 시스템이 있습니다. 각 시스템에는 거래, 상품, 상대방, 견적 등 동일한 개념으로 작동하지만 자체 데이터 모델이 있습니다. 그리고 각 시스템이 독립적으로 발전하면서 다양한 기술이 등장했습니다.

또한 일부 제품은 1990년대 중반에 출시되었기 때문에 시스템의 코드 기반은 이미 상당히 구식입니다. 그리고 일부 영역에서는 이로 인해 개발 프로세스가 느려지고 성능 문제가 발생했습니다.

새로운 솔루션에 대한 요구 사항

기업은 기술 혁신이 추가 개발에 필수적이라는 것을 깨달았습니다. 우리에게는 다음과 같은 임무가 주어졌습니다.

1. 모든 비즈니스 데이터를 빠른 단일 스토리지와 단일 데이터 모델로 수집합니다.
2. 우리는 이 정보를 분실하거나 변경해서는 안 됩니다.
3. 규제 당국이 언제든지 이전 연도에 대한 통계를 요청할 수 있으므로 데이터 버전을 관리하는 것이 필요합니다.
4. 우리는 단지 새롭고 세련된 DBMS를 도입하는 것이 아니라 비즈니스 문제를 해결하기 위한 플랫폼을 만들어야 합니다.

또한 우리 건축가는 자체 조건을 설정했습니다.

1. 새로운 솔루션은 엔터프라이즈급이어야 합니다. 즉, 일부 대기업에서 이미 테스트를 거쳤어야 합니다.
2. 솔루션의 작동 모드는 미션 크리티컬해야 합니다. 이는 우리가 동시에 여러 데이터 센터에 있어야 하며 하나의 데이터 센터가 중단될 때 침착하게 살아남아야 함을 의미합니다.
3. 시스템은 수평적으로 확장 가능해야 합니다. 사실 우리의 모든 현재 시스템은 수직적으로만 확장 가능하며 하드웨어 성능의 낮은 성장으로 인해 이미 한계점에 도달하고 있습니다. 따라서 생존을 위해서는 수평적으로 확장 가능한 시스템이 필요한 순간이 왔습니다.
4. 무엇보다도 우리는 솔루션이 저렴해야 한다는 말을 들었습니다.

우리는 표준 경로를 따랐습니다. 요구 사항을 공식화하고 구매 부서에 연락했습니다. 거기에서 우리는 일반적으로 우리를 위해 이 작업을 수행할 준비가 되어 있는 회사 목록을 받았습니다. 우리는 모두에게 문제에 대해 설명했고, 그 중 XNUMX명으로부터 해결책에 대한 평가를 받았습니다.

은행에서는 다른 사람의 말을 받아들이지 않고 모든 것을 직접 테스트하는 것을 좋아합니다. 따라서 입찰 경쟁의 필수 조건은 부하 테스트를 통과하는 것이 었습니다. 우리는 부하 테스트 작업을 공식화했으며, XNUMX개 회사 중 XNUMX개 회사는 이를 테스트하기 위해 자체 비용으로 인메모리 기술을 기반으로 한 프로토타입 솔루션을 구현하는 데 이미 동의했습니다.

모든 것을 테스트하는 방법과 시간이 얼마나 걸렸는지는 말씀드리지 않겠습니다. 간단히 요약하겠습니다. 로드 테스트에서 최고의 성능은 Mail.ru Group 개발 팀의 Tarantool 기반 프로토타입 솔루션에서 나타났습니다. 협약을 체결하고 개발을 시작했습니다. Mail.ru 그룹에는 XNUMX명이 있었고 Alfa-Bank에는 개발자 XNUMX명, 시스템 분석가 XNUMX명, 솔루션 설계자, 제품 소유자 및 스크럼 마스터가 있었습니다.

다음으로 우리 시스템이 어떻게 성장했는지, 어떻게 진화했는지, 우리가 무엇을 했는지, 왜 이런 일이 발생했는지에 대해 말씀드리겠습니다.

Разработка

우리가 스스로에게 던진 첫 번째 질문은 현재 시스템에서 데이터를 얻는 방법이었습니다. 현재의 모든 시스템은 HTTP를 통해 XML 또는 JSON을 전송하여 서로 통신하기 때문에 HTTP가 우리에게 매우 적합하다고 결정했습니다.

SSL 세션을 종료할 필요가 없고 성능도 충분하기 때문에 Tarantool에 내장된 HTTP 서버를 사용합니다.

이미 말했듯이 우리의 모든 시스템은 서로 다른 데이터 모델에 존재하며, 입력 시 우리가 설명하는 모델에 개체를 가져와야 합니다. 데이터를 변환할 수 있는 언어가 필요했습니다. 우리는 명령형 Lua를 선택했습니다. 우리는 모든 데이터 변환 코드를 샌드박스에서 실행합니다. 이는 실행 코드가 더 이상 이동하지 않는 안전한 장소입니다. 이를 위해 필요한 코드를 로드스트링하여 아무것도 차단하거나 삭제할 수 없는 기능이 포함된 환경을 만듭니다.

변환 후에는 데이터가 우리가 만들고 있는 모델과 일치하는지 확인해야 합니다. 우리는 모델이 무엇이어야 하는지, 그리고 이를 설명하기 위해 어떤 언어를 사용해야 하는지 오랫동안 논의했습니다. 언어가 간단하고 Tarantool의 지원을 받기 때문에 Apache Avro를 선택했습니다. 새로운 버전의 모델과 사용자 정의 코드는 부하가 있든 없든 하루 중 언제든지 여러 번 작동할 수 있으며 변경 사항에 매우 빠르게 적응할 수 있습니다.

확인 후 데이터를 저장해야 합니다. 우리는 vshard를 사용하여 이 작업을 수행합니다(지역적으로 분산된 샤드 복제본이 있음).

더욱이, 우리에게 데이터를 보내는 대부분의 시스템은 우리가 데이터를 받았는지 여부를 신경 쓰지 않을 정도로 특이성이 있습니다. 이것이 바로 우리가 처음부터 수리 대기열을 구현한 이유입니다. 그것은 무엇입니까? 어떤 이유로 객체가 데이터 변환 또는 검증을 거치지 않는 경우에도 수신을 확인하지만 동시에 수리 대기열에 객체를 저장합니다. 이는 일관성을 유지하며 기본 비즈니스 데이터 웨어하우스에 위치합니다. 우리는 이에 대한 관리자 인터페이스, 다양한 측정항목 및 경고를 즉시 작성했습니다. 결과적으로 데이터가 손실되지 않습니다. 소스가 변경되더라도 데이터 모델이 변경된 경우 즉시 이를 감지하고 적응할 수 있습니다.

이제 저장된 데이터를 검색하는 방법을 배워야 합니다. 우리는 시스템을 주의 깊게 분석한 결과 Java 및 Oracle의 클래식 스택에는 데이터를 관계형에서 객체로 변환하는 일종의 ORM이 반드시 포함되어 있다는 것을 확인했습니다. 그렇다면 즉시 그래프 형태로 시스템에 객체를 제공하는 것은 어떨까요? 그래서 우리는 모든 요구 사항을 충족하는 GraphQL을 기쁘게 채택했습니다. 그래프 형태로 데이터를 받아 지금 당장 필요한 것만 뽑아낼 수 있습니다. 상당히 유연하게 API 버전을 지정할 수도 있습니다.

우리는 거의 즉시 우리가 추출하는 데이터가 충분하지 않다는 것을 깨달았습니다. 우리는 모델의 개체(기본적으로 계산된 필드)에 연결할 수 있는 함수를 만들었습니다. 즉, 예를 들어 평균 견적 가격을 계산하는 특정 기능을 필드에 연결합니다. 그리고 데이터를 요청하는 외부 소비자는 이것이 계산된 필드인지조차 모릅니다.

인증 시스템을 구현했습니다.

그런 다음 우리는 결정에 몇 가지 역할이 구체화되어 있음을 발견했습니다. 역할은 일종의 기능 집합체입니다. 일반적으로 역할마다 장비 사용 프로필이 다릅니다.

• T-Connect: 들어오는 연결 처리, CPU 제한, 낮은 메모리 소비, 상태 비저장.
• IB-Core: Tarantool 프로토콜을 통해 수신한 데이터를 변환합니다. 즉, 테이블과 함께 작동합니다. 또한 상태를 저장하지 않으며 확장 가능합니다.
• 저장소: 데이터만 저장하고 논리를 사용하지 않습니다. 이 역할은 가장 간단한 인터페이스를 구현합니다. vshard 덕분에 확장 가능합니다.

즉, 역할을 사용하여 클러스터의 서로 다른 부분을 서로 분리하여 서로 독립적으로 확장할 수 있습니다.

그래서 우리는 관리 인터페이스를 사용하여 비동기 트랜잭션 데이터 흐름 기록과 복구 대기열을 만들었습니다. 기록은 비즈니스 관점에서 비동기식입니다. 어디에 있든 우리 자신에게 데이터를 쓸 수 있다는 것이 보장된다면 우리는 이를 확인할 것입니다. 확인되지 않으면 문제가 발생한 것이므로 데이터를 전송해야 합니다. 이것은 비동기 녹음입니다.

테스트

프로젝트 초기부터 우리는 테스트 중심 개발을 구현하기로 결정했습니다. tarantool/tap 프레임워크를 사용하여 Lua에서 단위 테스트를 작성하고, pytest 프레임워크를 사용하여 Python에서 통합 테스트를 작성합니다. 동시에 통합 테스트 작성에 개발자와 분석가 모두를 참여시킵니다.

테스트 주도 개발을 어떻게 사용하나요?

새로운 기능을 원하면 먼저 이에 대한 테스트를 작성하려고 합니다. 버그를 발견하면 먼저 테스트를 작성한 다음 수정합니다. 처음에는 이렇게 일하기 힘들고, 직원들 사이에서는 “이제 빨리 고치고, 새로운 일을 하고, 테스트로 덮자”라는 오해가 생기고, 방해 행위까지 하기도 한다. 이 "나중"만이 거의 오지 않습니다.

그러므로 먼저 스스로 테스트를 작성하도록 강요하고 다른 사람에게 테스트를 요청해야 합니다. 저를 믿으십시오. 테스트 중심 개발은 단기적으로도 이점을 제공합니다. 당신은 당신의 삶이 더 쉬워 졌다고 느낄 것입니다. 이제 코드의 99%가 테스트에 포함되었다고 생각합니다. 이것은 많은 것처럼 보이지만 아무런 문제가 없습니다. 모든 커밋에서 테스트가 실행됩니다.

그러나 우리가 가장 좋아하는 것은 부하 테스트이며, 이를 가장 중요하게 여기고 정기적으로 수행합니다.

첫 번째 버전 중 하나에 대한 로드 테스트의 첫 번째 단계를 어떻게 수행했는지에 대한 간단한 이야기를 들려드리겠습니다. 우리는 개발자의 노트북에 시스템을 설치하고 로드를 켰으며 초당 4건의 트랜잭션을 수신했습니다. 노트북에 대한 좋은 결과입니다. 우리는 프로덕션보다 약한 XNUMX개의 서버로 구성된 가상 로드 벤치에 설치했습니다. 최소한으로 배포됩니다. 우리는 그것을 실행하고 하나의 스레드에서 랩톱보다 더 나쁜 결과를 얻습니다. 충격적인 내용.

우리는 매우 슬펐습니다. 서버 로드를 살펴보았지만 유휴 상태인 것으로 나타났습니다.

우리는 개발자들에게 전화를 걸어 Java 세계에서 온 사람들에게 Tarantool이 단일 스레드라고 설명합니다. 로드 중인 하나의 프로세서 코어에서만 효과적으로 사용할 수 있습니다. 그런 다음 각 서버에 가능한 최대 개수의 Tarantool 인스턴스를 배포하고 로드를 켰으며 이미 초당 14,5개의 트랜잭션을 받았습니다.

다시 설명하겠습니다. 리소스를 다르게 사용하는 역할로 분할됨에 따라 연결 처리 및 데이터 변환을 담당하는 역할은 프로세서에만 로드되었으며 로드에 엄격하게 비례했습니다.

이 경우 메모리는 들어오는 연결과 임시 개체를 처리하는 데에만 사용되었습니다.

반대로 스토리지 서버에서는 프로세서 로드가 증가했지만 연결을 처리하는 서버보다 속도가 훨씬 느렸습니다.

그리고 메모리 소비는 로드된 데이터 양에 정비례하여 증가했습니다.

서비스

특히 애플리케이션 플랫폼으로 새 제품을 개발하기 위해 서비스와 라이브러리를 배포하기 위한 구성 요소를 만들었습니다.

서비스는 일부 분야에서 작동하는 단순한 코드 조각이 아닙니다. 클러스터의 일부이고, 참조 데이터를 확인하고, 비즈니스 로직을 실행하고, 응답을 반환하는 매우 크고 복잡한 구조일 수 있습니다. 또한 서비스 스키마를 GraphQL로 내보내면 소비자는 전체 모델에 대한 자체 검사를 통해 데이터에 대한 범용 액세스 지점을 받습니다. 매우 편안합니다.

서비스에는 더 많은 기능이 포함되어 있으므로 자주 사용되는 코드를 이동할 라이브러리가 있어야 한다고 결정했습니다. 우리는 이전에 그것이 우리에게 아무 것도 손상시키지 않는다는 것을 확인한 후 안전한 환경에 추가했습니다. 이제 라이브러리 형태로 기능에 추가 환경을 할당할 수 있습니다.

우리는 스토리지뿐만 아니라 컴퓨팅을 위한 플랫폼을 갖고 싶었습니다. 그리고 이미 많은 복제본과 샤드가 있었기 때문에 일종의 분산 컴퓨팅을 구현하고 이를 맵 축소라고 불렀습니다. 원래의 맵 축소와 유사하다는 것이 밝혀졌기 때문입니다.

오래된 시스템

프로토콜을 지원하지만 모든 레거시 시스템이 HTTP를 통해 우리를 호출하고 GraphQL을 사용할 수 있는 것은 아닙니다. 따라서 우리는 데이터를 이러한 시스템에 복제할 수 있는 메커니즘을 만들었습니다.

무언가 변경되면 저장소 역할에서 고유한 트리거가 트리거되고 변경 사항이 포함된 메시지가 처리 대기열에 들어갑니다. 별도의 복제자 역할을 사용하여 외부 시스템으로 전송됩니다. 이 역할은 상태를 저장하지 않습니다.

새로운 개선 사항

기억하시겠지만, 비즈니스적인 관점에서 우리는 비동기 녹음을 했습니다. 그러나 그들은 작업 상태에 대한 응답을 즉시 받아야 하는 시스템 클래스가 있기 때문에 그것만으로는 충분하지 않다는 것을 깨달았습니다. 그래서 우리는 GraphQL을 확장하고 돌연변이를 추가했습니다. 이는 데이터 작업의 기존 패러다임에 유기적으로 적합합니다. 우리에게 이것은 다른 클래스의 시스템에 대한 읽기 및 쓰기의 단일 지점입니다.

또한 하루, 일주일, 한 달에 한 번씩 작성해야 하는 보고서가 상당히 많기 때문에 서비스만으로는 충분하지 않다는 것을 깨달았습니다. 이 작업은 시간이 오래 걸릴 수 있으며 보고서에서 Tarantool의 이벤트 루프를 차단할 수도 있습니다. 따라서 우리는 스케줄러와 실행자라는 별도의 역할을 만들었습니다. 러너는 상태를 저장하지 않습니다. 그들은 즉석에서 계산할 수 없는 무거운 작업을 실행합니다. 그리고 스케줄러 역할은 구성에 설명된 이러한 작업의 시작 일정을 모니터링합니다. 작업 자체는 비즈니스 데이터와 동일한 위치에 저장됩니다. 적절한 시간이 오면 스케줄러는 작업을 수행하고 일부 실행자에게 이를 전달하며 실행자는 이를 계산하고 결과를 저장합니다.

모든 작업을 일정에 따라 실행할 필요는 없습니다. 일부 보고서는 요청 시 읽어야 합니다. 이 요구 사항이 도착하자마자 샌드박스에 작업이 생성되어 실행을 위해 실행기로 전송됩니다. 잠시 후 사용자는 모든 것이 계산되었으며 보고서가 준비되었다는 비동기 응답을 받습니다.

처음에 우리는 모든 데이터를 저장하고 버전을 관리하며 삭제하지 않는다는 패러다임을 고수했습니다. 하지만 인생에서 때때로 무언가를 삭제해야 하는 경우가 있습니다. 대부분 원시 또는 중간 정보입니다. 만료된 데이터를 기반으로 우리는 오래된 데이터로부터 스토리지를 정리하는 메커니즘을 만들었습니다.

우리는 또한 조만간 메모리에 데이터를 저장할 공간이 충분하지 않지만 그럼에도 불구하고 데이터를 저장해야 하는 상황이 올 것임을 이해합니다. 이러한 목적을 위해 우리는 곧 디스크 스토리지를 만들 예정입니다.

결론

우리는 단일 모델에 데이터를 로드하는 작업부터 시작하여 이를 개발하는 데 30개월을 보냈습니다. 우리는 XNUMX개의 데이터 공급 시스템을 갖고 있었습니다. 단일 모델로의 전체 변환 코드는 루아에서 약 XNUMX만 라인 정도이다. 그리고 대부분의 작업은 아직 진행 중입니다. 때로는 주변 팀의 의욕이 부족하기도 하고, 업무를 복잡하게 만드는 상황도 많습니다. 유사한 작업에 직면한 경우 해당 구현에 일반적으로 걸리는 시간을 XNUMX배 또는 XNUMX배로 늘리십시오.

또한 비즈니스 프로세스의 기존 문제는 새로운 DBMS, 심지어 매우 생산적인 DBMS를 사용하여 해결할 수 없다는 점을 기억하십시오. 내 말은? 프로젝트가 시작될 때 우리는 고객들 사이에서 이제 새로운 빠른 데이터베이스를 가져와 살아갈 것이라는 인상을 받았습니다! 프로세스가 더 빨라지고 모든 것이 잘 될 것입니다. 실제로 기술은 비즈니스 프로세스가 안고 있는 문제를 해결하지 못합니다. 왜냐하면 비즈니스 프로세스는 사람이기 때문입니다. 그리고 기술이 아닌 사람과 협력해야 합니다.

테스트 기반 개발은 초기 단계에서 고통스럽고 시간이 많이 걸릴 수 있습니다. 그러나 회귀 테스트를 수행하기 위해 아무것도 할 필요가 없는 단기적인 경우에도 긍정적인 효과가 눈에 띄게 나타납니다.

개발의 모든 단계에서 부하 테스트를 수행하는 것은 매우 중요합니다. 아키텍처의 결함을 빨리 발견할수록 수정하기가 더 쉬워지며, 이는 앞으로 많은 시간을 절약해 줄 것입니다.

루아에는 아무런 문제가 없습니다. Java 개발자, JavaScript 개발자, Python 개발자, 프런트엔드 또는 백엔드 등 누구나 글쓰기를 배울 수 있습니다. 심지어 우리 분석가들도 이에 대해 글을 씁니다.

SQL이 없다는 사실에 대해 이야기하면 사람들이 겁을 먹습니다. “SQL 없이 어떻게 데이터를 얻나요? 그게 가능합니까? 틀림없이. OLTP 클래스 시스템에서는 SQL이 필요하지 않습니다. 문서 지향 보기로 즉시 돌아가는 일종의 언어 형태의 대안이 있습니다. 예를 들어 GraphQL입니다. 그리고 분산 컴퓨팅 형태의 대안이 있습니다.

확장이 필요하다는 것을 이해했다면 수십 개의 Tarantool 인스턴스에서 병렬로 실행될 수 있도록 Tarantool에서 솔루션을 설계하십시오. 이렇게 하지 않으면 Tarantool이 하나의 프로세서 코어만 효과적으로 사용할 수 있기 때문에 나중에 어렵고 고통스러울 것입니다.

출처 : habr.com