차세대 청구 아키텍처: Tarantool로의 전환을 통한 변화

MegaFon과 같은 회사의 청구서에 Tarantool이 필요한 이유는 무엇입니까? 겉으로 보기에는 보통 판매자가 와서 일종의 큰 상자를 가져오고 플러그를 소켓에 꽂는 것 같습니다. 그러면 요금이 청구됩니다! 한때는 그랬지만 지금은 고대시대가 되었고, 그런 공룡들은 이미 멸종했거나 ​​멸종되고 있는 상황이다. 처음에 청구는 계산기 또는 계산기와 같은 송장 발행 시스템입니다. 현대 통신에서는 이것이다. 계약 체결부터 해지까지 가입자와의 상호 작용의 전체 수명주기에 대한 자동화 시스템, 실시간 청구, 결제 승인 등을 포함합니다. 통신 회사의 청구는 전투 로봇과 같습니다. 크고 강력하며 무기가 장착되어 있습니다.

Tarantool은 그것과 어떤 관련이 있습니까? 그들은 그것에 대해 이야기할 것이다 올렉 이블레프 и 안드레이 크니 제프. Oleg는 회사의 수석 설계자입니다. 메가폰 외국 기업에서 근무한 광범위한 경험을 갖춘 Andrey는 비즈니스 시스템 이사입니다. 에 대한 보고서의 기록에서 2018 타란툴 컨퍼런스 기업에서 R&D가 필요한 이유, Tarantool이 무엇인지, 수직적 확장과 세계화의 막다른 골목이 어떻게 회사에 이 데이터베이스가 등장하기 위한 전제조건이 되었는지, 기술적 과제, 아키텍처 혁신, 그리고 MegaFon의 테크노스택이 Netflix와 어떻게 유사한지에 대해 배우게 됩니다. , 구글, 아마존.

프로젝트 "통합 결제"

문제의 프로젝트는 "Unified Billing"이라고 합니다. Tarantool이 최고의 품질을 보여준 곳이 바로 여기였습니다.

Hi-End 장비의 생산성 증가는 가입자 기반 증가 및 서비스 수 증가를 따라가지 못했으며, M2M, IoT 및 지점 기능 주도로 인해 가입자 수 및 서비스 증가가 더욱 증가할 것으로 예상됩니다. 시장 출시 시기가 늦어지는 것입니다. 회사는 현재의 8가지 청구 시스템 대신 세계 최고 수준의 고유한 모듈식 아키텍처를 갖춘 통합 비즈니스 시스템을 만들기로 결정했습니다.

MegaFon은 XNUMX개의 회사가 하나의 회사입니다.. 2009년에 조직 개편이 완료되었습니다. 러시아 전역의 지점이 MegaFon OJSC(현재 PJSC)라는 단일 회사로 합병되었습니다. 따라서 회사는 자체 "맞춤형" 솔루션, 지점 기능, 다양한 조직 구조, IT 및 마케팅을 갖춘 8개의 청구 시스템을 보유하고 있습니다.

하나의 공통 연방 제품을 출시해야 할 때까지는 모든 것이 괜찮았습니다. 여기에서 많은 어려움이 발생했습니다. 일부의 경우 관세가 반올림되고 다른 일부는 반올림되며 다른 일부는 산술 평균을 기준으로 적용됩니다. 그러한 순간은 수천 번 있습니다.

빌링 시스템 버전이 하나, 공급업체가 하나뿐임에도 불구하고 설정이 너무 다양해서 하나로 묶는 데 오랜 시간이 걸렸습니다. 우리는 그 수를 줄이려고 노력했고 많은 기업에 익숙한 두 번째 문제에 직면했습니다.

수직 확장. 그 당시 가장 멋진 하드웨어조차도 요구 사항을 충족하지 못했습니다. Superdome Hi-End 라인의 Hewlett-Packard 장비를 사용했지만 두 지점의 요구 사항도 충족하지 못했습니다. 큰 운영 비용과 자본 투자 없이 수평적 확장을 원했습니다.

가입자 수 및 서비스 증가 기대. 컨설턴트들은 오랫동안 IoT와 M2M에 대한 이야기를 통신 업계에 전해왔습니다. 모든 전화기와 다리미에 SIM 카드가 있고 냉장고에 두 개가 있는 시대가 올 것입니다. 현재는 구독자 수가 한 명이지만 가까운 시일 내에 더 많은 구독자가 생길 것입니다.

기술적 도전

이 네 가지 이유는 우리가 심각한 변화를 하도록 동기를 부여했습니다. 시스템을 업그레이드하는 것과 처음부터 설계하는 것 사이에서 선택이 있었습니다. 우리는 오랫동안 생각하고, 진지한 결정을 내리고, 입찰에 참여했습니다. 결과적으로 우리는 처음부터 디자인을 하기로 결정했고 흥미로운 도전, 즉 기술적 도전에 착수했습니다.

확장성

예전이었다면 말해보자, 말해보자 8만 명의 가입자에 대해 15번의 청구, 이제 제대로 작동했을 것입니다. 구독자 100억 명 이상 -부하가 훨씬 더 높습니다.

우리는 Mail.ru나 Netflix와 같은 대규모 인터넷 플레이어와 규모면에서 비교할 수 있게 되었습니다.

그러나 로드 및 가입자 기반을 늘리려는 추가적인 움직임은 우리에게 심각한 과제를 안겨주었습니다.

광대한 나라의 지리

칼리닌그라드와 블라디보스토크 사이 7500km 및 10개 시간대. 빛의 속도는 유한하며 그러한 거리에서는 지연이 이미 상당합니다. 가장 멋진 최신 광 채널의 150ms는 실시간 청구에 너무 많은 시간입니다. 특히 현재 러시아의 통신에서는 더욱 그렇습니다. 게다가 영업일 기준 XNUMX일 이내에 업데이트해야 하는데, 시간대가 다르면 이것이 문제가 됩니다.

우리는 단순히 가입비만 내고 서비스를 제공하는 것이 아니라 복잡한 요금제, 패키지, 다양한 수식어를 가지고 있습니다. 가입자의 대화를 허용하거나 거부할 뿐만 아니라 특정 할당량을 제공해야 합니다. 가입자가 눈치채지 못하도록 통화 및 작업을 실시간으로 계산합니다.

결함 허용

이것이 중앙화의 또 다른 측면이다.

모든 가입자를 하나의 시스템에 모으면 긴급 상황과 재난이 발생하면 비즈니스에 재앙이 됩니다. 따라서 우리는 사고가 전체 가입자 기반에 미치는 영향을 제거하는 방식으로 시스템을 설계합니다.

이는 다시 수직 확장을 거부한 결과입니다. 수평적으로 확장하자 서버 수가 수백에서 수천으로 늘어났습니다. 관리 및 상호 교환이 가능해야 하며 IT 인프라를 자동으로 백업하고 분산 시스템을 복원해야 합니다.

우리는 매우 흥미로운 도전에 직면했습니다. 우리는 시스템을 설계했고, 그 순간 우리가 얼마나 트렌드를 따르고 있는지, 첨단 기술을 얼마나 따르고 있는지 확인하기 위해 글로벌 모범 사례를 찾으려고 노력했습니다.

세계 경험

놀랍게도 글로벌 통신에서는 단 한 건의 참고 자료도 찾지 못했습니다.

유럽은 가입자 수와 규모 측면에서 떨어졌고, 미국은 관세의 균일성 측면에서 떨어졌습니다. 우리는 중국에서 일부를 살펴보고 인도에서 일부를 발견하고 Vodafone India의 전문가를 고용했습니다.

아키텍처를 분석하기 위해 우리는 IBM이 이끄는 다양한 분야의 건축가들로 구성된 드림팀을 구성했습니다. 이 사람들은 우리가 하고 있는 일을 적절하게 평가하고 특정 지식을 우리 아키텍처에 가져올 수 있었습니다.

규모

설명을 위한 몇 가지 숫자입니다.

우리는 다음을 위한 시스템을 설계합니다. 80천만 명의 가입자와 XNUMX억의 예비금. 이것이 미래 임계값을 제거하는 방법입니다. 이는 우리가 중국을 장악할 것이기 때문이 아니라 IoT와 M2M의 맹공격 때문이다.

실시간 처리되는 300억 개의 문서. 우리는 80천만 명의 가입자를 보유하고 있지만 미수금 회수가 필요한 경우 잠재 고객과 우리를 떠난 사람들 모두와 협력합니다. 따라서 실제 볼륨은 눈에 띄게 더 큽니다.

2억 건의 거래 잔액은 매일 변경됩니다. 이는 결제, 청구, 통화 및 기타 이벤트입니다. 200TB의 데이터가 활발하게 변화하고 있습니다., 조금 더 천천히 변경하세요 8PB의 데이터, 이는 아카이브가 아니라 단일 청구의 실시간 데이터입니다. 데이터 센터별 확장 - 5개 사이트에 14개의 서버.

기술 스택

우리는 아키텍처를 계획하고 시스템을 조립하기 시작하면서 가장 흥미롭고 진보된 기술을 도입했습니다. 그 결과, 고부하 시스템을 만드는 모든 인터넷 플레이어와 기업에 친숙한 기술 스택이 탄생했습니다.

스택은 Netflix, Twitter, Viber 등 다른 주요 플레이어의 스택과 유사합니다. 6개의 구성요소로 구성되어 있는데, 이를 줄여서 통일하고자 합니다.

유연성은 좋지만 대기업에서는 통일 없이는 방법이 없습니다.

우리는 동일한 Oracle을 Tarantool로 변경하지 않을 것입니다. 대기업의 현실에서 이것은 유토피아, 즉 결과가 불분명한 5~10년간의 성전이다. 하지만 Cassandra와 Couchbase는 Tarantool로 쉽게 대체될 수 있으며, 이것이 바로 우리가 추구하는 것입니다.

왜 타란툴인가?

우리가 이 데이터베이스를 선택한 이유는 4가지 간단한 기준이 있습니다.

속도. MegaFon 산업용 시스템에 대한 부하 테스트를 실시했습니다. Tarantool이 승리하여 최고의 성능을 보여주었습니다.

이는 다른 시스템이 MegaFon의 요구 사항을 충족하지 못한다는 의미는 아닙니다. 현재 메모리 솔루션은 매우 생산적이어서 회사의 보유고가 충분합니다. 그러나 우리는 부하 테스트를 포함하여 뒤처진 사람이 아닌 리더를 상대하는 데 관심이 있습니다.

Tarantool은 장기적으로도 회사의 요구를 충족합니다.

TCO 비용. MegaFon 볼륨에 대한 Couchbase 지원에는 천문학적인 비용이 들지만 Tarantool을 사용하면 상황이 훨씬 더 즐겁고 기능면에서 유사합니다.

우리 선택에 약간 영향을 준 또 다른 좋은 기능은 Tarantool이 다른 데이터베이스보다 메모리에서 더 잘 작동한다는 것입니다. 그가 보여 주다 최대 효율.

신뢰성. MegaFon은 아마도 그 누구보다 신뢰성에 투자하고 있습니다. 그래서 우리는 Tarantool을 살펴보면서 그것이 우리의 요구 사항을 충족하도록 만들어야 한다는 것을 깨달았습니다.

우리는 시간과 재정을 투자했으며 Mail.ru와 함께 엔터프라이즈 버전을 만들었고 현재 다른 여러 회사에서 사용하고 있습니다.

Tarantool-enterprise는 보안, 신뢰성 및 로깅 측면에서 우리를 완전히 만족시켰습니다.

공동

나에게 가장 중요한 것은 개발자와 직접 접촉. 이것이 바로 Tarantool의 사람들이 뇌물을 준 것입니다.

플레이어, 특히 앵커 클라이언트와 함께 작업하는 플레이어에게 와서 이 작업을 수행하려면 데이터베이스가 필요하다고 말하면 그는 일반적으로 다음과 같이 대답합니다.

- 좋습니다. 요구 사항을 맨 아래에 두십시오. 언젠가는 그 요구 사항에 도달하게 될 것입니다.

많은 사람들이 향후 2~3년에 대한 로드맵을 가지고 있으며 거기에 통합하는 것이 거의 불가능하지만 Tarantool 개발자는 MegaFon뿐만 아니라 개방성에 매료되어 시스템을 고객에 맞게 조정합니다. 멋지고 우리는 그것을 정말 좋아합니다.

Tarantool을 사용한 곳

우리는 여러 요소에 Tarantool을 사용합니다. 첫 번째는 파일럿에 있습니다., 우리는 주소 디렉토리 시스템에서 만들었습니다. 한때 저는 Yandex.Maps 및 Google Maps와 유사한 시스템이기를 원했지만 결과는 조금 달랐습니다.

예를 들어 판매 인터페이스의 주소 카탈로그입니다. Oracle에서는 원하는 주소를 검색하는 데 12~13초가 걸립니다. - 불편한 숫자. Tarantool로 전환하고 콘솔에서 Oracle을 다른 데이터베이스로 교체하고 동일한 검색을 수행하면 속도가 200배 향상됩니다! 세 번째 문자 뒤에 도시가 나타납니다. 이제 우리는 이것이 첫 번째 인터페이스 이후에 발생하도록 인터페이스를 조정하고 있습니다. 그러나 응답 속도는 초가 아닌 밀리초로 완전히 다릅니다.

두 번째 어플리케이션은 two-speed IT라는 트렌디한 테마입니다. 각지의 컨설턴트들이 기업은 그곳으로 가야 한다고 말하고 있기 때문이다.

인프라 계층이 있고 그 위에는 통신과 같은 청구 시스템, 기업 시스템, 기업 보고와 같은 도메인이 있습니다. 건드릴 필요가 없는 핵심입니다. 물론 가능하지만 편집증적으로 품질을 보장하는 것은 회사에 돈을 가져다주기 때문입니다.

다음은 운영자나 다른 플레이어를 차별화하는 마이크로서비스 계층입니다. 특정 캐시를 기반으로 마이크로서비스를 빠르게 생성하여 다양한 도메인의 데이터를 가져올 수 있습니다. 여기 실험 분야 — 문제가 해결되지 않으면 마이크로서비스 하나를 닫고 다른 마이크로서비스를 열었습니다. 이를 통해 시장 출시 기간이 단축되고 회사의 신뢰성과 속도가 향상됩니다.

마이크로서비스는 아마도 MegaFon에서 Tarantool의 주요 역할일 것입니다.

Tarantool을 사용할 계획인 경우

성공적인 청구 프로젝트를 Deutsche Telekom, Svyazcom, Vodafone India의 혁신 프로그램과 비교해 보면 놀라울 정도로 역동적이고 창의적입니다. 이 프로젝트를 구현하는 과정에서 MegaFon과 그 구조가 변형되었을 뿐만 아니라 Tarantool-enterprise도 Mail.ru에 등장했고 공급업체 Nexign(이전 Peter-Service) - BSS Box(박스형 청구 솔루션)도 나타났습니다.

어떤 의미에서 이것은 러시아 시장을 위한 역사적인 프로젝트입니다. 이는 Frederick Brooks의 "The Mythical Man-Month"라는 책에 설명된 내용과 비교할 수 있습니다. 그러다가 60년대에 IBM은 메인프레임용 새로운 OS/360 운영 체제를 개발하기 위해 5명의 인력을 고용했습니다. 우리는 000개 미만이지만 우리는 조끼를 입고 있으며 오픈 소스 사용과 새로운 접근 방식을 고려하여 더 생산적으로 작업합니다.

다음은 청구 영역, 더 광범위하게 말하면 비즈니스 시스템의 영역입니다. 기업의 사람들은 CRM을 잘 알고 있습니다. 모든 사람은 이미 개방형 API, API 게이트웨이 등 다른 시스템을 갖고 있어야 합니다.

공개 API

수치를 다시 살펴보고 현재 Open API가 어떻게 작동하는지 살펴보겠습니다. 그 부하는 초당 10건의 트랜잭션. 마이크로서비스 레이어를 적극적으로 개발하고 MegaFon 퍼블릭 API를 구축할 계획이므로 이 부분에서 향후 더 큰 성장을 기대합니다. 확실히 100건의 거래가 있을 것입니다.

SSO에서 Mail.ru와 비교할 수 있을지 모르겠습니다. 초당 1건의 트랜잭션을 처리하는 것 같습니다. 그들의 솔루션은 우리에게 매우 흥미롭고 우리는 Tarantool을 사용하여 기능적인 SSO 백업을 만드는 등 그들의 경험을 채택할 계획입니다. 이제 Mail.ru의 개발자들이 우리를 위해 이 작업을 수행하고 있습니다.

CRM

CRM은 우리가 80억으로 늘리고 싶은 300천만 명의 가입자와 동일합니다. 왜냐하면 XNUMX년 간의 기록을 포함하는 문서가 이미 XNUMX억 개 있기 때문입니다. 우리는 새로운 서비스를 정말 기대하고 있습니다. 성장 포인트는 연결된 서비스. 점점 더 많은 서비스가 제공될 것이기 때문에 이것은 성장할 공입니다. 따라서 우리에게는 이야기가 필요하며 이에 걸려 넘어지고 싶지 않습니다.

송장 발행과 관련하여 자체 청구, 고객 미수금 작업 별도의 도메인으로 변경됨. 성능을 향상시키기 위해, 적용된 도메인 아키텍처 아키텍처 패턴.

시스템은 도메인으로 분할되고 부하가 분산되며 내결함성이 보장됩니다. 또한 우리는 분산 아키텍처를 사용해 작업했습니다.

다른 모든 것은 엔터프라이즈 수준의 솔루션입니다. 통화저장소에서 - 하루 2억, 월 60 억. 때로는 한 달 안에 계산해야 하는데, 빨리 하는 것이 더 좋습니다. 재무 모니터링 - 이것은 지속적으로 성장하고 성장하는 것과 정확히 동일한 300억입니다. 가입자는 종종 사업자 간에 이동하여 이 부분을 늘립니다.

이동통신의 가장 큰 통신 구성요소는 온라인 청구. 전화를 걸거나 전화를 걸지 않고 실시간으로 결정을 내릴 수 있는 시스템입니다. 여기서 부하는 초당 30건의 트랜잭션이지만 데이터 전송 증가를 고려하여 계획합니다. 250건의 거래, 따라서 우리는 Tarantool에 매우 관심이 있습니다.

이전 사진은 Tarantool을 사용할 도메인입니다. 물론 CRM 자체는 더 광범위하므로 핵심 자체에서 사용할 예정입니다.

100억 명의 가입자로 추정되는 TTX 수치는 건축가로서 저를 혼란스럽게 합니다. 만약 101억 XNUMX백만 명이라면 어떨까요? 모든 것을 다시 다시 실행해야 하나요? 이러한 일이 발생하는 것을 방지하기 위해 우리는 캐시를 사용하는 동시에 접근성을 높입니다.

일반적으로 Tarantool을 사용하는 방법에는 두 가지가 있습니다. 첫 번째 - 마이크로서비스 수준에서 모든 캐시 구축. 내가 아는 한, VimpelCom은 이 경로를 따라 클라이언트 캐시를 생성하고 있습니다.

우리는 공급업체에 대한 의존도를 낮추고 BSS 코어를 변경하므로 기본적으로 단일 클라이언트 파일을 갖게 됩니다. 하지만 우리는 그것을 확장하고 싶습니다. 따라서 우리는 약간 다른 접근 방식을 취합니다. 시스템 내부에 캐시 만들기.

이렇게 하면 동기화가 줄어듭니다. 하나의 시스템이 캐시와 기본 마스터 소스를 모두 담당합니다.

이 방법은 업데이트, 즉 데이터 변경과 관련된 부분만 업데이트하는 트랜잭션 뼈대를 갖춘 Tarantool 접근 방식과 잘 맞습니다. 다른 모든 것은 다른 곳에 저장할 수 있습니다. 거대한 데이터 레이크, 관리되지 않는 글로벌 캐시는 없습니다. 캐시는 시스템, 제품, 클라이언트를 위해 설계되거나 유지 관리가 더 쉬워지도록 설계되었습니다. 가입자가 전화를 걸어 서비스 품질에 대해 불만을 표시할 때 귀하는 고품질 서비스를 제공하고 싶을 것입니다.

RTO 및 RPO

IT에는 두 가지 용어가 있습니다. RTO и RPO.

복구 시간 목표 장애 발생 후 서비스를 복구하는 데 걸리는 시간입니다. RTO = 0은 문제가 발생하더라도 서비스가 계속 작동함을 의미합니다.

복구 지점 목표 - 이는 데이터 복구 시간, 즉 특정 기간 동안 손실될 수 있는 데이터의 양입니다. RPO = 0은 데이터가 손실되지 않음을 의미합니다.

Tarantool 작업

Tarantool의 문제를 해결해 보겠습니다.

주어진: 예를 들어 Amazon이나 다른 곳에서 모두가 이해할 수 있는 애플리케이션 바구니입니다. 필요 장바구니는 일주일 내내 24시간, 즉 7%의 시간 동안 작동합니다. 가입자의 연결을 무작위로 켜거나 끌 수 없기 때문에 우리에게 오는 주문은 순서대로 유지되어야 합니다. 모든 것이 엄격하게 일관되어야 합니다. 이전 구독이 다음 구독에 영향을 미치므로 데이터가 중요합니다. 아무것도 누락되어서는 안 됩니다.

결정. 정면으로 해결해 보고 데이터베이스 개발자에게 물어볼 수도 있지만 문제를 수학적으로 해결할 수는 없습니다. 정리, 보존 법칙, 양자 물리학을 기억할 수 있지만 그 이유는 DB 수준에서 해결할 수 없습니다.

좋은 오래된 아키텍처 접근 방식이 여기서 작동합니다. 주제 영역을 잘 알고 이를 사용하여 이 퍼즐을 해결해야 합니다.

우리의 솔루션: 지리적으로 분산된 클러스터인 Tarantool에서 애플리케이션의 분산 레지스트리 생성. 다이어그램에는 세 개의 서로 다른 데이터 처리 센터가 있습니다. 두 개는 Urals 이전에 하나는 Urals 뒤에 있으며 모든 요청은 이 센터에 분산됩니다.

현재 IT 분야의 리더 중 하나로 여겨지는 Netflix는 2012년까지 데이터 센터가 단 하나뿐이었습니다. 가톨릭 성탄절 전날인 24월 XNUMX일에 이 데이터 센터가 다운되었습니다. 캐나다와 미국의 사용자는 자신이 좋아하는 영화를 볼 수 없었고 매우 화가 나서 소셜 네트워크에 이에 대해 글을 썼습니다. Netflix는 현재 서동부 해안에 XNUMX개의 데이터 센터를, 서유럽에 XNUMX개의 데이터 센터를 보유하고 있습니다.

우리는 처음에 지리적으로 분산된 솔루션을 구축하고 있습니다. 내결함성은 우리에게 중요합니다.

클러스터가 있는데 RPO = 0이고 RTO = 0은 어떻습니까? 주제에 따라 해결책은 간단합니다.

응용 프로그램에서 중요한 것은 무엇입니까? 두 부분: 바구니 던지기 ~까지 구매 결정을 내리고, 후에. 통신의 DO 부분은 일반적으로 주문 캡처 또는 주문 협상. 통신에서는 온라인 상점보다 훨씬 더 어려울 수 있습니다. 왜냐하면 클라이언트에게 서비스를 제공하고 5가지 옵션을 제공해야 하며 이 모든 것이 한동안 발생하지만 바구니가 채워져 있기 때문입니다. 현재로서는 실패가 가능하지만 인간의 감독 하에 상호작용적으로 발생하기 때문에 두렵지 않습니다.

모스크바 데이터 센터에 갑자기 장애가 발생하면 자동으로 다른 데이터 센터로 전환하여 계속 작업하겠습니다. 이론적으로는 하나의 제품이 장바구니에서 없어졌을 수도 있지만, 이를 보고 다시 장바구니에 추가한 후 작업을 계속하세요. 이 경우 RTO = 0입니다.

동시에 두 번째 옵션이 있습니다. “제출”을 클릭하면 데이터가 손실되지 않기를 바랍니다. 이 순간부터 자동화가 작동하기 시작합니다. 이는 RPO = 0입니다. 이 두 가지 서로 다른 패턴을 사용하면 전환 가능한 마스터가 하나 있는 단순히 지리적으로 분산된 클러스터일 수도 있고, 일종의 쿼럼 레코드일 수도 있습니다. 패턴은 다를 수 있지만 문제는 해결됩니다.

또한 애플리케이션의 분산 레지스트리를 사용하면 모든 것을 확장할 수도 있습니다. 이 레지스트리에 액세스하는 많은 디스패처와 실행자가 있습니다.

카산드라와 타란툴이 함께

또 다른 경우가 있습니다 - "균형 쇼케이스". Cassandra와 Tarantool을 공동으로 사용하는 흥미로운 사례는 다음과 같습니다.

하루에 2억 개의 호출이 제한이 아니고 더 많아질 것이기 때문에 우리는 Cassandra를 사용합니다. 마케팅 담당자는 소스별로 트래픽에 색상을 지정하는 것을 좋아하며, 예를 들어 소셜 네트워크에 점점 더 많은 세부 정보가 표시됩니다. 이 모든 것이 이야기에 추가됩니다.

Cassandra를 사용하면 어떤 크기로든 수평으로 확장할 수 있습니다.

우리는 Cassandra에 대해 편안함을 느끼지만 한 가지 문제가 있습니다. 읽기에 능숙하지 않다는 것입니다. 녹음상 모든 것이 정상입니다. 초당 30도 문제가 되지 않습니다. 읽기 문제.

따라서 캐시가 있는 주제가 나타 났고 동시에 다음 문제를 해결했습니다. 온라인 청구 스위치의 장비가 Cassandra에로드하는 파일에 들어오는 오래된 전통적인 사례가 있습니다. 우리는 IBM 관리자 파일 전송의 조언을 사용하더라도 이러한 파일을 안정적으로 다운로드하는 문제로 어려움을 겪었습니다. 예를 들어 TCP가 아닌 UDP 프로토콜을 사용하여 파일 전송을 효율적으로 관리하는 솔루션이 있습니다. 이것은 좋지만 아직 몇 분이 소요되고 아직 모든 것을 로드하지 않았습니다. 콜센터 교환원은 고객에게 잔액에 무슨 일이 일어났는지 답변할 수 없습니다. 기다려야 합니다.

이런 일이 발생하지 않도록 우리는 우리는 병렬 기능 예비를 사용합니다. Kafka를 통해 Tarantool로 이벤트를 보내면 예를 들어 오늘의 집계를 실시간으로 다시 계산하면 다음과 같은 결과를 얻습니다. 현금 잔고, 예를 들어 초당 100만 건의 거래와 동일한 2초의 속도로 잔액을 전송할 수 있습니다.

목표는 전화를 걸고 2초 이내에 개인 계정에 변경된 잔액뿐만 아니라 변경된 이유에 대한 정보가 표시되는 것입니다.

결론

Tarantool을 사용한 예입니다. 우리는 Mail.ru의 개방성과 다양한 사례를 고려하려는 의지를 정말 좋아했습니다.

BCG, McKinsey, Accenture 또는 IBM의 컨설턴트가 새로운 것, 즉 그들이 제공하는 것의 대부분을 우리가 이미 수행했거나 수행했거나 수행할 계획으로 우리를 놀라게 하는 것은 이미 어렵습니다. 나는 Tarantool이 우리의 기술 스택에서 정당한 자리를 차지하고 많은 기존 기술을 대체할 것이라고 생각합니다. 우리는 이 프로젝트의 활발한 개발 단계에 있습니다.

Oleg와 Andrey의 보고서는 작년 Tarantool 회의에서 최고 중 하나이며 17월 XNUMX일 Oleg Ivlev가 다음에서 연설할 예정입니다. T+ 컨퍼런스 2019 보고서와 함께 “Enterprise에서 Tarantool을 사용하는 이유”. Alexander Deulin은 MegaFon에서도 프레젠테이션을 진행합니다. "Oracle의 Tarantool 캐시 및 복제". 무엇이 변경되었는지, 어떤 계획이 구현되었는지 알아 보겠습니다. 참여 - 회의는 무료입니다. 귀하가 해야 할 일은 다음과 같습니다 레지스터. 모든 보고서가 승인됨 새로운 사례, Tarantool 사용에 대한 새로운 경험, 아키텍처, 기업, 튜토리얼 및 마이크로서비스 등 컨퍼런스 프로그램이 구성되었습니다.

출처 : habr.com