걱정을 멈추고 단일체 없이 생활을 시작하는 방법

우리 모두는 이야기를 좋아합니다. 우리는 불 주위에 앉아 과거의 승리, 전투 또는 단순히 업무 경험에 대해 이야기하는 것을 좋아합니다.

오늘이 바로 그런 날이다. 그리고 지금 당장은 현장에 있지 않더라도 여러분을 위한 이야기가 있습니다. Tarantool에서 스토리지 작업을 시작한 이야기입니다.

옛날 옛적에 우리 회사에는 두 개의 "모놀리스"와 하나의 "천장"이 있었는데, 이러한 단일체는 천천히 그러나 확실하게 접근하여 회사의 비행과 개발을 제한했습니다. 그리고 분명한 이해가 있었습니다. 언젠가 우리는 이 한계점에 도달할 것입니다.

이제는 장비부터 비즈니스 로직까지 모든 것과 모든 사람을 분리하는 것이 널리 퍼져 있는 이념입니다. 결과적으로 예를 들어 네트워크 수준에서 실질적으로 독립적인 두 개의 DC가 있습니다. 그리고 모든 것이 완전히 달랐습니다.

오늘날에는 CI/CD, K8S 등의 형태로 변경을 수행할 수 있는 도구와 도구가 많이 있습니다. “모놀리식” 시대에는 외국어가 그렇게 많이 필요하지 않았습니다. 데이터베이스의 "저장소"를 수정하는 것만으로도 충분했습니다.

그러나 시간이 흐르면서 요청 수도 함께 늘어나 때로는 우리 능력을 넘어서는 RPS를 실행하기도 했습니다. CIS 국가가 시장에 진출하면서 첫 번째 모놀리스의 데이터베이스 프로세서에 대한 로드는 90% 이하로 떨어지지 않았고 RPS는 2400 수준으로 유지되었습니다. 그리고 이것은 단지 작은 선택기가 아니라 엄청난 쿼리였습니다. 대규모 IO를 배경으로 데이터의 거의 절반에 대해 실행할 수 있는 여러 검사 및 JOIN입니다.

본격적인 블랙 프라이데이 판매가 현장에 나타나기 시작했고 Wildberries가 러시아에서 처음으로 판매를 진행했을 때 상황은 완전히 슬퍼졌습니다. 결국 그러한 날의 부하는 세 배로 증가합니다.
아, 이 "획일적인 시대"! 나는 당신이 비슷한 일을 경험했다고 확신하며, 이것이 당신에게 어떻게 일어날 수 있는지 아직도 이해하지 못합니다.

당신은 무엇을 할 수 있습니까? 패션은 기술에 내재되어 있습니다. 약 5년 전, 우리는 사이트 자체의 모든 로직을 신중하게 저장한 .NET 및 MS SQL 서버의 기존 사이트 형태로 이러한 모드 중 하나를 다시 생각해야 했습니다. 나는 그것을 너무 조심스럽게 보관하여 그러한 단일체를 톱질하는 것이 길고 결코 쉬운 즐거움이 아니라는 것이 밝혀졌습니다.
작은 함몰.

다양한 행사에서 나는 "모놀리스를 보지 못했다면 성장하지 않은 것입니다! "라고 말합니다. 이 문제에 대한 귀하의 의견이 궁금합니다. 댓글에 적어주세요.

그리고 천둥이 치다.

우리의 "모닥불"로 돌아 가자. "모놀리식" 기능의 부하를 분산하기 위해 우리는 시스템을 오픈소스 기술을 기반으로 하는 마이크로서비스로 나누기로 결정했습니다. 왜냐하면 최소한 확장 비용이 더 저렴하기 때문입니다. 그리고 우리는 규모를 확장해야 한다는 점을 100% 이해했습니다. 결국 그 당시에는 이미 주변 국가 시장에 진출하는 것이 가능했고 등록 건수와 주문 건수가 더욱 크게 증가하기 시작했습니다.

모놀리스에서 마이크로서비스로의 첫 번째 후보를 분석한 결과, 우리는 그 글의 80%가 백오피스 시스템에서 나오고 프론트오피스에서 읽는다는 것을 깨달았습니다. 우선, 이는 사용자 데이터와 추가 고객 할인 및 쿠폰에 대한 정보를 기반으로 상품의 최종 비용을 계산하는 시스템이라는 두 가지 중요한 하위 시스템과 관련이 있습니다.

들여쓰기. 이제는 상상하기가 무섭지만 위에서 언급한 하위 시스템 외에도 제품 카탈로그, 사용자 장바구니, 제품 검색 시스템, 제품 카탈로그 필터링 시스템, 다양한 종류의 추천 시스템도 단일체에서 제거되었습니다. 각각의 작동을 위해 좁게 맞춤화된 시스템의 별도 클래스가 있지만 옛날에는 모두 하나의 "집"에 살았습니다.

우리는 즉시 고객에 대한 데이터를 샤딩 시스템으로 전송할 계획을 세웠습니다. 최종 상품 원가 계산 기능을 제거하려면 RPS 부하가 가장 크고 데이터베이스 구현이 가장 어려웠기 때문에(계산 프로세스에 많은 데이터가 포함됨) 읽기에 좋은 확장성이 필요했습니다.

그 결과, 우리는 Tarantool에 잘 맞는 구성표를 생각해냈습니다.

당시 마이크로서비스 운영을 위해 가상 및 하드웨어 시스템에서 여러 데이터 센터와 협력하는 방식이 선택되었습니다. 그림에서 볼 수 있듯이 Tarantool 복제 옵션은 마스터-마스터 모드와 마스터-슬레이브 모드 모두에 적용되었습니다.

건축학. 옵션 1. 사용자 서비스

현재 24개의 샤드가 있으며 각 샤드는 2개의 인스턴스(각 DC당 하나씩)를 가지며 모두 마스터-마스터 모드입니다.

데이터베이스 위에는 데이터베이스 복제본에 액세스하는 애플리케이션이 있습니다. 애플리케이션은 Tarantool Go 드라이버 인터페이스를 구현하는 맞춤형 라이브러리를 통해 Tarantool과 함께 작동합니다. 그녀는 모든 복제본을 보고 마스터와 함께 읽고 쓸 수 있습니다. 기본적으로 복제본 선택, 재시도 수행, 회로 차단기 및 속도 제한을 위한 논리를 추가하는 복제본 세트 모델을 구현합니다.

이 경우 샤드 컨텍스트에서 복제본 선택 정책을 구성할 수 있습니다. 예를 들어 라운드 로빈입니다.

건축학. 옵션 2. 최종 상품 원가 계산 서비스

몇 달 전, 상품의 최종 비용 계산에 대한 대부분의 요청은 원칙적으로 데이터베이스 없이 작동하는 새로운 서비스로 전달되었지만 얼마 전에는 Tarantool이 포함된 서비스를 통해 모든 것이 100% 처리되었습니다.

서비스 데이터베이스는 동기화 장치가 데이터를 수집하는 4개의 마스터로 구성되며, 각 복제 마스터는 읽기 전용 복제본에 데이터를 배포합니다. 각 마스터에는 대략 15개의 복제본이 있습니다.

첫 번째 방식이나 두 번째 방식에서 하나의 DC를 사용할 수 없는 경우 애플리케이션은 두 번째 DC에서 데이터를 수신할 수 있습니다.

Tarantool의 복제는 매우 유연하며 런타임에 구성할 수 있다는 점은 주목할 가치가 있습니다. 다른 시스템에서는 어려움이 발생했습니다. 예를 들어 PostgreSQL에서 max_wal_senders 및 max_replication_slots 매개변수를 변경하려면 마법사를 다시 시작해야 하며, 경우에 따라 애플리케이션과 DBMS 간의 연결이 끊어질 수 있습니다.

검색하고 찾아라!

왜 우리는 '보통 사람들처럼' 하지 않고 비정형적인 방식을 선택했을까요? 정상으로 간주되는 것이 무엇인지에 따라 다릅니다. 많은 사람들이 일반적으로 Mongo에서 클러스터를 만들어 지리적으로 분산된 XNUMX개의 DC에 분산시킵니다.

그 당시 우리에게는 이미 두 개의 Redis 프로젝트가 있었습니다. 첫 번째는 캐시였고 두 번째는 그다지 중요하지 않은 데이터를 위한 영구 저장소였습니다. 그에게는 부분적으로 우리 잘못 때문에 꽤 어려웠습니다. 때로는 상당히 많은 양이 키에 포함되어 있었고 때때로 사이트가 불편해졌습니다. 우리는 마스터-슬레이브 버전에서 이 시스템을 사용했습니다. 그리고 마스터에 무슨 일이 생겨서 복제가 중단되는 경우도 많았습니다.

즉, Redis는 상태 저장 작업이 아닌 상태 비저장 작업에 적합합니다. 원칙적으로는 대부분의 문제를 해결할 수 있지만 한 쌍의 인덱스가 있는 키-값 솔루션인 경우에만 가능합니다. 하지만 당시 Redis는 지속성과 복제가 상당히 아쉬웠습니다. 게다가 성능에 대한 불만도 있었다.

우리는 MySQL과 PostgreSQL에 대해 생각했습니다. 하지만 첫 번째 제품은 왠지 우리의 관심을 끌지 못했고, 두 번째 제품은 그 자체로 다소 정교한 제품이어서 간단한 서비스를 구축하는 것은 부적절할 것입니다.
우리는 RIAK, Cassandra, 심지어 그래프 데이터베이스도 사용해 보았습니다. 이것들은 모두 서비스 생성을 위한 일반적인 범용 도구의 역할에 적합하지 않은 상당히 틈새 솔루션입니다.

결국 우리는 Tarantool을 선택했습니다.

버전 1.6이었을 때 우리는 이를 사용했습니다. 우리는 키-값의 공생과 관계형 데이터베이스의 기능에 관심이 있었습니다. 보조 인덱스, 트랜잭션 및 공간이 있습니다. 이들은 테이블과 비슷하지만 단순하지는 않으며 다양한 수의 열을 저장할 수 있습니다. 그러나 Tarantool의 가장 큰 특징은 키-값 및 트랜잭션성과 결합된 보조 인덱스였습니다.

채팅으로 도움을 줄 준비가 되어 있는 반응형 러시아어 커뮤니티도 한몫했습니다. 이를 적극적으로 활용하고 채팅으로 직접 라이브를 진행합니다. 그리고 명백한 실수나 실수 없이 괜찮은 끈기를 잊지 마세요. Tarantool의 이력을 보면 복제 작업에 많은 어려움과 실패가 있었지만 결함으로 인해 데이터가 손실된 적은 한 번도 없습니다!

구현이 험난한 시작을 맞이했습니다.

당시 우리의 주요 개발 스택은 .NET이었고 Tarantool용 커넥터가 없었습니다. 우리는 즉시 Go로 뭔가를 시작했습니다. Lua에서도 잘 작동했습니다. 그 당시 가장 큰 문제는 디버깅이었습니다. .NET에서는 이것으로 모든 것이 훌륭했지만 그 후에는 로그 외에 디버깅이 없을 때 임베디드 Lua의 세계로 뛰어들기가 어려웠습니다. 게다가 어떤 이유로 복제가 주기적으로 끊어져서 Tarantool 엔진의 구조를 자세히 조사해야 했습니다. 채팅이 도움이 되었고, 문서도 어느 정도 도움이 되었으며, 때때로 우리는 코드를 살펴보았습니다. 당시 문서는 그저 그랬습니다.

그래서 몇 달에 걸쳐 저는 Tarantool을 사용하여 작업하면서 정신을 차리고 괜찮은 결과를 얻었습니다. 우리는 새로운 마이크로서비스 형성에 도움이 되는 참조 개발을 git에서 편집했습니다. 예를 들어, 또 다른 마이크로서비스를 생성해야 하는 작업이 발생했을 때 개발자는 저장소에 있는 참조 솔루션의 소스 코드를 살펴봤고, 새 마이크로서비스를 생성하는 데는 일주일도 채 걸리지 않았습니다.

특별한 시간이었습니다. 일반적으로 다음 테이블의 관리자에게 가서 "가상 머신을 주세요."라고 물어볼 수 있습니다. 약 XNUMX분 후에 차는 이미 당신과 함께 있었습니다. 귀하가 직접 연결하고 모든 것을 설치했으며 트래픽이 귀하에게 전송되었습니다.

현재는 더 이상 작동하지 않습니다. 서비스에 모니터링 및 로깅을 추가하고, 테스트를 통해 기능을 다루며, 가상 머신을 주문하거나 Kuber에 전달하는 등의 작업이 필요합니다. 일반적으로 이렇게 하면 시간이 더 오래 걸리고 번거롭기는 하지만 이 방법이 더 좋습니다.

나누어서 통치하라. 루아랑 무슨 사이야?

심각한 딜레마가 있었습니다. 일부 팀은 Lua의 많은 로직을 사용하여 서비스에 대한 변경 사항을 안정적으로 출시할 수 없었습니다. 이는 종종 서비스가 작동하지 않는 것과 함께 발생했습니다.

즉, 개발자들은 일종의 변화를 준비하고 있습니다. Tarantool이 마이그레이션을 시작하지만 복제본에는 여전히 이전 코드가 남아 있습니다. 일부 DDL이나 다른 것이 복제를 통해 도착하고 코드는 고려되지 않기 때문에 단순히 분리됩니다. 결과적으로 관리자를 위한 업데이트 절차는 A4 시트에 정리되었습니다. 복제 중지, 업데이트, 복제 활성화, 여기에서 끄기, 여기에서 업데이트. 악몽!

결과적으로 이제 우리는 Lua에서 아무것도 하지 않으려고 하는 경우가 가장 많습니다. iproto(서버와 상호작용하기 위한 바이너리 프로토콜)를 사용하면 됩니다. 아마도 이것은 개발자들의 지식 부족일지도 모르지만, 이러한 관점에서 볼 때 시스템은 복잡합니다.

우리는 항상 이 대본을 맹목적으로 따르지는 않습니다. 오늘날에는 흑백이 없습니다. 모든 것이 Lua에 있거나 모든 것이 Go에 있습니다. 우리는 나중에 마이그레이션 문제가 발생하지 않도록 이들을 결합하는 방법을 이미 이해하고 있습니다.

타란툴은 지금 어디에 있나요?
Tarantool은 "Promoter"라고도 알려진 할인 쿠폰을 고려하여 상품의 최종 비용을 계산하는 서비스에 사용됩니다. 앞서 말했듯이 그는 이제 은퇴하고 있습니다. 가격이 미리 계산된 새로운 카탈로그 서비스로 대체되고 있지만 XNUMX개월 전에 모든 계산은 Promotizer에서 이루어졌습니다. 이전에는 논리의 절반이 Lua로 작성되었습니다. XNUMX년 전 서비스가 저장 시설로 바뀌었고, 할인 메커니즘이 약간 바뀌었고 서비스 성능이 부족했기 때문에 Go에서 로직을 다시 작성했습니다.

가장 중요한 서비스 중 하나는 사용자 프로필입니다. 즉, 모든 Wildberries 사용자는 Tarantool에 저장되어 있으며 약 50천만 명 정도가 사용자 ID별로 샤딩되어 Go 서비스에 연결된 여러 DC에 분산된 시스템입니다.
RPS에 따르면 Promoter는 한때 6건의 요청에 도달한 리더였습니다. 한때 우리는 50~60개의 사본을 가지고 있었습니다. 이제 RPS의 선두주자는 약 12명의 사용자 프로필입니다. 이 서비스는 사용자 ID 범위로 나누어진 맞춤형 샤딩을 사용합니다. 이 서비스는 20대 이상의 머신을 제공하지만 이는 너무 많습니다. 4~5대의 머신이면 충분하므로 할당된 리소스를 줄일 계획입니다.

세션 서비스는 vshard 및 Cartridge에 대한 첫 번째 서비스입니다. vshard를 설정하고 카트리지를 업데이트하려면 약간의 노력이 필요했지만 결국 모든 것이 잘 진행되었습니다.

웹사이트와 모바일 애플리케이션에 다양한 배너를 표시하는 서비스는 Tarantool에서 직접 출시된 최초의 서비스 중 하나였습니다. 이 서비스는 6~7년이 된 서비스인데도 여전히 작동 중이며 재부팅한 적이 없다는 점에서 주목할 만합니다. 마스터-마스터 복제가 사용되었습니다. 아무것도 깨지지 않았습니다.

어떤 경우에는 정보를 신속하게 다시 확인하기 위해 창고 시스템의 빠른 참조 기능에 Tarantool을 사용하는 예가 있습니다. 이를 위해 Redis를 사용하려고 시도했지만 Tarantool보다 메모리의 데이터가 더 많은 공간을 차지했습니다.

대기자 명단, 고객 구독, 현재 유행하는 스토리 및 이연 상품 서비스도 Tarantool에서 작동합니다. 메모리의 마지막 서비스는 약 120GB를 차지합니다. 이는 위의 서비스 중 가장 포괄적인 서비스입니다.

결론

키-값 및 트랜잭션성과 결합된 보조 인덱스 덕분에 Tarantool은 마이크로서비스 기반 아키텍처에 매우 적합합니다. 그러나 Lua에서 많은 로직을 사용하여 서비스에 변경 사항을 적용할 때 어려움에 직면했습니다. 서비스가 작동을 멈추는 경우가 많았습니다. 우리는 이를 극복할 수 없었고 시간이 지나면서 Lua와 Go의 다양한 조합에 이르렀습니다. 우리는 한 언어를 어디에 사용해야 하는지, 다른 언어를 어디에 사용해야 하는지 알고 있습니다.

주제에 대해 더 읽을 내용

• Tarantool을 사용하여 처음부터 고부하 애플리케이션 만들기 habr.com/ru/company/mailru/blog/510440
• Tarantool 카트리지의 신뢰할 수 있는 리더 선택 habr.com/ru/company/mailru/blog/513912
• 제품에 대한 소식이 담긴 텔레그램 채널 Tarantool t.me/tarantool_news
• 커뮤니티 채팅에서 Tarantool에 대해 토론하세요 t.me/tarantoolru

출처 : habr.com