🥇Tarantool 카트리지: Lua 백엔드를 세 줄로 분할

Mail.ru Group에는 Tarantool이 있습니다. 이것은 Lua의 애플리케이션 서버이며 데이터베이스 역할도 합니다(또는 그 반대). 빠르고 멋지지만 한 서버의 기능은 여전히 무제한이 아닙니다. 수직 스케일링도 만병통치약이 아니므로 Tarantool에는 수평 스케일링을 위한 도구인 vshard 모듈이 있습니다. [1]. 이를 통해 여러 서버에 걸쳐 데이터를 분할할 수 있지만 이를 설정하고 비즈니스 논리를 연결하려면 수정해야 합니다.

좋은 소식: 우리는 몇 가지 중요한 정보를 수집했습니다(예: [2], [3]) 그리고 이 문제에 대한 솔루션을 크게 단순화할 또 다른 프레임워크를 만들었습니다.

타란툴 카트리지 복잡한 분산 시스템을 개발하기 위한 새로운 프레임워크입니다. 이를 통해 인프라 문제를 해결하는 대신 비즈니스 로직 작성에 집중할 수 있습니다. 컷 아래에서는 이 프레임워크의 작동 방식과 이를 사용하여 분산 서비스를 작성하는 방법을 설명하겠습니다.

그리고 정확히 문제가 무엇입니까?

우리에겐 독거미도 있고, vshard도 있습니다. 무엇을 더 바랄 수 있겠습니까?

첫째, 편의성의 문제입니다. vshard 구성은 Lua 테이블을 통해 구성됩니다. 여러 Tarantool 프로세스로 구성된 분산 시스템이 올바르게 작동하려면 구성이 모든 곳에서 동일해야 합니다. 누구도 이 작업을 수동으로 수행하고 싶어하지 않습니다. 따라서 온갖 종류의 스크립트, Ansible, 배포 시스템이 사용됩니다.

카트리지 자체는 vshard 구성을 관리하며 이를 기반으로 합니다. 자체 분산 구성. 이는 본질적으로 간단한 YAML 파일이며, 그 복사본은 각 Tarantool 인스턴스에 저장됩니다. 단순화는 프레임워크 자체가 구성을 모니터링하고 모든 곳에서 동일한지 확인한다는 것입니다.

둘째, 다시 편의성의 문제입니다. vshard 구성은 비즈니스 논리 개발과 아무 관련이 없으며 프로그래머의 작업에만 방해가 됩니다. 프로젝트의 아키텍처에 대해 논의할 때 우리는 개별 구성 요소와 이들의 상호 작용에 대해 가장 자주 이야기합니다. 클러스터를 3개의 데이터 센터로 롤아웃하는 것을 생각하기에는 아직 이르습니다.

우리는 이러한 문제를 계속해서 해결했으며 어느 시점에서는 생성, 개발, 테스트, CI/CD, 유지 관리 등 전체 수명 주기 동안 애플리케이션 작업을 단순화하는 접근 방식을 개발할 수 있었습니다.

카트리지는 각 Tarantool 프로세스에 대한 역할 개념을 도입합니다. 역할은 개발자가 코드 작성에 집중할 수 있도록 하는 개념입니다. 프로젝트에서 사용 가능한 모든 역할은 하나의 Tarantool 인스턴스에서 실행될 수 있으며 이는 테스트에 충분합니다.

Tarantool 카트리지의 주요 특징:

자동화된 클러스터 조정;
새로운 역할을 사용하여 애플리케이션의 기능을 확장합니다.
개발 및 배포를 위한 애플리케이션 템플릿
내장된 자동 샤딩;
Luatest 테스트 프레임워크와의 통합
WebUI 및 API를 사용한 클러스터 관리
패키징 및 배포 도구.

안녕, 월드!

프레임워크 자체를 빨리 보여드리고 싶기 때문에 아키텍처에 대한 이야기는 나중에 하고 간단한 것부터 시작하겠습니다. Tarantool 자체가 이미 설치되어 있다고 가정하면 남은 작업은 다음과 같습니다.

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

다음 두 명령은 명령줄 유틸리티를 설치하고 템플릿에서 첫 번째 애플리케이션을 생성할 수 있게 해줍니다.

$ cartridge create --name myapp

그리고 이것이 우리가 얻는 것입니다:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

이것은 미리 만들어진 "Hello, World!"가 포함된 git 저장소입니다. 애플리케이션. 이전에 종속성(프레임워크 자체 포함)을 설치한 후 즉시 실행해 보겠습니다.

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

따라서 향후 샤딩된 애플리케이션을 위해 하나의 노드가 실행됩니다. 호기심이 많은 일반인이라면 즉시 웹 인터페이스를 열고 마우스로 한 노드의 클러스터를 구성하고 그 결과를 즐길 수 있지만 아직 기뻐하기에는 이르다. 아직까지는 애플리케이션이 유용한 작업을 수행할 수 없으므로 나중에 배포에 대해 설명하겠지만 이제 코드를 작성할 차례입니다.

응용 프로그램 개발

상상해 보세요. 우리는 하루에 한 번 데이터를 수신하고 저장하고 보고서를 작성해야 하는 프로젝트를 설계하고 있습니다.

다이어그램 그리기를 시작하고 그 위에 게이트웨이, 스토리지, 스케줄러라는 세 가지 구성 요소를 배치합니다. 우리는 아키텍처를 추가로 연구하고 있습니다. vshard를 스토리지로 사용하므로 vshard-router 및 vshard-storage를 구성표에 추가합니다. 게이트웨이나 스케줄러 모두 스토리지에 직접 액세스하지 않습니다. 이것이 바로 라우터의 목적이고 그것이 만들어진 이유입니다.

이 다이어그램은 구성 요소가 추상적으로 보이기 때문에 프로젝트에서 구축할 내용을 정확하게 나타내지 않습니다. 우리는 이것이 실제 Tarantool에 어떻게 투영되는지 확인해야 합니다. 프로세스별로 구성 요소를 그룹화해 보겠습니다.

vshard-router와 게이트웨이를 별도의 인스턴스에 유지하는 것은 거의 의미가 없습니다. 이것이 이미 라우터의 책임이라면 왜 네트워크를 다시 한 번 서핑해야 합니까? 동일한 프로세스 내에서 실행되어야 합니다. 즉, 게이트웨이와 vshard.router.cfg가 모두 하나의 프로세스에서 초기화되고 로컬에서 상호 작용할 수 있습니다.

디자인 단계에서는 세 가지 컴포넌트로 작업하는 것이 편리했지만, 개발자로서 코드를 작성하는 동안 Tarnatool의 세 가지 인스턴스를 실행하는 것은 생각하고 싶지 않습니다. 테스트를 실행하고 게이트웨이를 올바르게 작성했는지 확인해야 합니다. 아니면 동료들에게 기능을 시연하고 싶을 수도 있습니다. 세 개의 복사본을 배포하는 번거로움을 겪어야 하는 이유는 무엇입니까? 이것이 역할의 개념이 탄생한 방법입니다. 역할은 카트리지에 의해 수명주기가 관리되는 일반 Luash 모듈입니다. 이 예에는 게이트웨이, 라우터, 스토리지, 스케줄러 등 네 가지가 있습니다. 다른 프로젝트에 더 많은 내용이 있을 수 있습니다. 모든 역할은 하나의 프로세스에서 실행될 수 있으며 이것으로 충분합니다.

그리고 준비 또는 프로덕션 배포의 경우 하드웨어 기능에 따라 각 Tarantool 프로세스에 고유한 역할 집합을 할당합니다.

토폴로지 관리

어떤 역할이 실행되고 있는지에 대한 정보는 어딘가에 저장되어야 합니다. 그리고 이 "어딘가"는 위에서 이미 언급한 분산 구성입니다. 가장 중요한 것은 클러스터 토폴로지입니다. 다음은 3개의 Tarantool 프로세스로 구성된 5개의 복제 그룹입니다:

우리는 데이터 손실을 원하지 않으므로 프로세스 실행에 대한 정보를 주의 깊게 취급합니다. 카트리지는 XNUMX단계 커밋을 사용하여 구성을 추적합니다. 구성을 업데이트하려면 먼저 모든 인스턴스가 사용 가능하고 새 구성을 수락할 준비가 되었는지 확인합니다. 그 후 두 번째 단계에서는 구성을 적용합니다. 따라서 하나의 사본을 일시적으로 사용할 수 없는 것으로 판명되더라도 나쁜 일은 발생하지 않습니다. 구성이 적용되지 않고 미리 오류가 표시됩니다.

또한 토폴로지 섹션에는 각 복제 그룹의 리더와 같은 중요한 매개 변수가 표시됩니다. 일반적으로 이는 녹음 중인 복사본입니다. 나머지는 예외가 있을 수 있지만 대부분 읽기 전용입니다. 때때로 용감한 개발자는 충돌을 두려워하지 않고 여러 복제본에 데이터를 병렬로 쓸 수 있지만, 무슨 일이 있어도 두 번 수행해서는 안되는 작업이 있습니다. 이를 위해 지도자의 표시가 있습니다.

역할의 삶

그러한 아키텍처에 추상적인 역할이 존재하려면 프레임워크가 이를 어떻게든 관리해야 합니다. 당연히 Tarantool 프로세스를 다시 시작하지 않고도 제어가 이루어집니다. 역할을 관리하기 위한 4개의 콜백이 있습니다. 카트리지 자체는 분산 구성에 기록된 내용에 따라 이를 호출하여 특정 역할에 구성을 적용합니다.

function init()
function validate_config()
function apply_config()
function stop()

각 역할에는 기능이 있습니다. init. 역할이 활성화되거나 Tarantool이 다시 시작될 때 한 번 호출됩니다. 예를 들어 box.space.create를 초기화하는 것이 편리합니다. 그렇지 않으면 스케줄러가 특정 시간 간격으로 작업을 수행하는 일부 배경 파이버를 시작할 수 있습니다.

하나의 기능 init 충분하지 않을 수 있습니다. 카트리지를 사용하면 역할이 토폴로지를 저장하는 데 사용하는 분산 구성을 활용할 수 있습니다. 동일한 구성에서 새 섹션을 선언하고 여기에 비즈니스 구성의 일부를 저장할 수 있습니다. 내 예에서는 스케줄러 역할에 대한 데이터 스키마 또는 일정 설정이 될 수 있습니다.

클러스터 호출 validate_config и apply_config 분산 구성이 변경될 때마다. XNUMX단계 커밋으로 구성이 적용되면 클러스터는 각 역할이 이 새 구성을 수락할 준비가 되었는지 확인하고 필요한 경우 사용자에게 오류를 보고합니다. 모든 사람이 구성이 정상이라고 동의하면 apply_config.

또한 역할에는 방법이 있습니다 stop, 이는 역할의 출력을 정리하는 데 필요합니다. 이 서버에 스케줄러가 더 이상 필요하지 않다고 말하면 사용을 시작한 파이버를 중지할 수 있습니다. init.

역할은 서로 상호 작용할 수 있습니다. 우리는 Lua에서 함수 호출을 작성하는 데 익숙하지만 특정 프로세스에 필요한 역할이 없을 수도 있습니다. 네트워크를 통한 통화를 용이하게 하기 위해 Tarantool에 내장된 표준 넷박스를 기반으로 구축된 rpc(원격 프로시저 호출) 보조 모듈을 사용합니다. 예를 들어 게이트웨이가 하루를 기다리지 않고 지금 바로 작업을 수행하도록 스케줄러에 직접 요청하려는 경우 유용할 수 있습니다.

또 다른 중요한 점은 내결함성을 보장하는 것입니다. 카트리지는 SWIM 프로토콜을 사용하여 상태를 모니터링합니다. [4]. 간단히 말해서 프로세스는 UDP를 통해 서로 "소문"을 교환합니다. 각 프로세스는 이웃에게 최신 뉴스를 알리고 이에 응답합니다. 갑자기 대답이 오지 않으면 타란툴은 뭔가 잘못되었다고 의심하기 시작하고, 잠시 후 죽음을 외우고 이 소식을 주변 사람들에게 알리기 시작합니다.

이 프로토콜을 기반으로 카트리지는 자동 실패 처리를 구성합니다. 각 프로세스는 해당 환경을 모니터링하고 리더가 갑자기 응답을 멈 추면 복제본이 해당 역할을 대신할 수 있으며 카트리지는 이에 따라 실행 중인 역할을 구성합니다.

여기서 주의해야 할 점은 전환을 자주 반복하면 복제 중에 데이터 충돌이 발생할 수 있기 때문입니다. 물론 자동 장애 조치를 무작위로 활성화해서는 안 됩니다. 우리는 무슨 일이 일어나고 있는지 명확하게 이해하고 리더가 복원되고 왕관이 그에게 반환된 후에도 복제가 중단되지 않도록 해야 합니다.

이 모든 것에서 역할이 마이크로서비스와 유사하다는 느낌을 받을 수 있습니다. 어떤 의미에서는 Tarantool 프로세스 내부의 모듈일 뿐입니다. 그러나 근본적인 차이점도 많이 있습니다. 첫째, 모든 프로젝트 역할은 동일한 코드 베이스에 있어야 합니다. 그리고 모든 Tarantool 프로세스는 동일한 코드 베이스에서 시작되어야 합니다. 그래야 스케줄러를 초기화하려고 할 때와 같은 놀라운 일이 발생하지 않지만 단순히 존재하지 않습니다. 또한 이러한 상황에서 시스템의 동작을 예측하고 디버그하기가 매우 어렵기 때문에 코드 버전의 차이를 허용해서는 안 됩니다.

Docker와 달리 우리는 "이미지" 역할을 다른 머신으로 가져와 그곳에서 실행할 수는 없습니다. 우리의 역할은 Docker 컨테이너만큼 고립되어 있지 않습니다. 또한 하나의 인스턴스에서 두 개의 동일한 역할을 실행할 수 없습니다. 역할은 존재하거나 존재하지 않습니다. 어떤 의미에서는 싱글톤입니다. 셋째, 전체 복제 그룹 내에서 역할이 동일해야 합니다. 그렇지 않으면 터무니없기 때문입니다. 데이터는 동일하지만 구성이 다릅니다.

배포 도구

저는 카트리지가 애플리케이션 배포에 어떻게 도움이 되는지 보여주겠다고 약속했습니다. 다른 사람들의 삶을 더 쉽게 만들기 위해 프레임워크는 RPM 패키지를 패키지합니다.

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

설치된 패키지에는 애플리케이션과 설치된 종속성 등 필요한 거의 모든 것이 포함되어 있습니다. Tarantool은 RPM 패키지의 종속성으로 서버에 도착할 예정이며 서비스를 시작할 준비가 되었습니다. 이는 systemd를 통해 수행되지만 먼저 약간의 구성을 작성해야 합니다. 최소한 각 프로세스의 URI를 지정하십시오. 예를 들어 XNUMX개면 충분합니다.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

여기에는 흥미로운 뉘앙스가 있습니다. 바이너리 프로토콜 포트만 지정하는 대신 호스트 이름을 포함한 프로세스의 전체 공개 주소를 지정합니다. 이는 클러스터 노드가 서로 연결하는 방법을 알기 위해 필요합니다. Advertising_uri 주소로 0.0.0.0을 사용하는 것은 좋지 않습니다. 소켓 바인드가 아닌 외부 IP 주소여야 합니다. 이것이 없으면 아무 것도 작동하지 않으므로 카트리지는 잘못된 광고_uri를 사용하여 노드를 시작할 수 없게 합니다.

이제 구성이 준비되었으므로 프로세스를 시작할 수 있습니다. 일반 시스템 장치에서는 둘 이상의 프로세스 시작을 허용하지 않으므로 카트리지의 응용 프로그램은 소위 설치됩니다. 다음과 같이 작동하는 인스턴스화된 단위:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

구성에서 Cartridge가 웹 인터페이스(8080)를 제공하는 HTTP 포트를 지정했습니다. 해당 포트로 이동하여 살펴보겠습니다.

프로세스가 실행 중이지만 아직 구성되지 않은 것을 볼 수 있습니다. 카트리지는 아직 누가 누구와 복제해야 하는지 모르고 스스로 결정을 내릴 수 없으므로 우리의 조치를 기다리고 있습니다. 하지만 선택의 여지가 많지 않습니다. 새 클러스터의 수명은 첫 번째 노드의 구성으로 시작됩니다. 그런 다음 클러스터에 다른 항목을 추가하고 역할을 할당하면 이 시점에서 배포가 성공적으로 완료된 것으로 간주할 수 있습니다.

긴 일주일의 일을 마치고 좋아하는 음료 한 잔을 따르며 휴식을 취하세요. 응용 프로그램을 사용할 수 있습니다.