Skiema를 사용한 스키마 관리

참고: 이 게시물은 SendGrid의 엔지니어링 팀에서 제공합니다. 이와 같은 더 많은 기술 엔지니어링 게시물을 보려면 기술 블로그 롤을 확인하십시오.

데이터베이스 스키마 관리는 프로덕션 프로세스에서 누구나 "실시간으로 실행"할 수 있는 황량한 서부에서부터 하나의 기름부음받은 개인만 프로덕션 데이터베이스를 만질 수 있는 폭포수 같은 다단계, 다중 팀 검토 프로세스에 이르기까지 다양합니다.

관계형 데이터베이스에 포함된 데이터가 회사에 더 가치가 있고 데이터베이스의 가용성이 비즈니스에 더 중요해짐에 따라 잠재적인 주요 스키마 변경에 대한 장벽이 나타납니다.

초기에 데이터베이스 관리자(DBA)는 나쁜 일이 발생하지 않도록 데이터베이스를 보호하기 위해 데이터베이스의 게이트키퍼가 되었습니다. 그러나 구식 DBA가 개발자와 해당 애플리케이션의 데이터베이스 사이에 있으면 애플리케이션의 개발 수명 주기가 크게 느려지고 개발 및 운영 사일로가 생성되며 팀 간에 마찰이 발생할 수 있습니다.

오늘날의 마이크로 서비스 dev-ops 지향적인 세계에서 개발자는 데이터베이스 스키마 변경 사항을 스스로 관리할 수 있어야 합니다. 왜냐하면 그것이 자신의 데이터이고 궁극적으로 애플리케이션의 성능과 가동 시간에 책임이 있기 때문입니다. DBA 및 운영 팀은 개발 팀이 데이터베이스의 소유자가 될 수 있도록 적절한 도구와 조언을 제공해야 합니다.

스키마 관리 방법

현재 스키마 관리 프로세스는 단일 Git 저장소를 사용하여 모든 데이터베이스 클러스터에 대한 초기 스키마를 저장하고 개별 테이블이 변경/생성 및 삭제될 때 해당 스키마에 대한 모든 후속 변경 사항을 포함합니다.

• 개발자는 로컬에서 스키마를 변경하고 alter/create/drop 문을 생성하고 통합 분기에 풀 요청으로 추가합니다.
• Data Operations 팀을 위한 Jira 티켓 세트는 스키마 변경 사항을 검토하고 테스트/스테이징 및 프로덕션 환경에 적용하기 위해 생성됩니다.
• 데이터 운영 팀의 구성원은 요청된 변경 사항을 검토하고 변경 사항을 테스트/스테이징 환경에 적용하고 PR을 통합 분기에 병합합니다.
• 요청하는 개발자는 테스트/스테이징 환경에서 변경 사항을 테스트하고 프로덕션으로 푸시하도록 변경 사항을 승인합니다.
• 마지막으로 데이터 작업은 통합 분기를 마스터에 병합하고 스키마 변경 사항을 프로덕션 환경에 적용합니다.

우리 데이터베이스에 저장된 데이터의 가치와 이러한 데이터베이스를 항상 잘 실행하고 싶은 욕구를 감안할 때 우리는 우리 자신을 보호하기 위해 이 비잔틴적인 일련의 사건을 결정했습니다.

데이터베이스를 보호하는 것은 한 가지이지만 이 프로세스는 안정적이고 효율적인 방식으로 스키마를 변경하는 데 몇 가지 장애물을 도입합니다.

• 스키마 변경 검토 및 변경은 주 2회 진행되며 여러 팀이 동일한 Git 리포지토리의 서로 다른 데이터베이스에서 작업하고 모두가 데이터 운영 팀의 누군가에게 의존하여 다양한 환경을 검토하고 변경하기 때문에 쉽게 탈선할 수 있습니다.
• 모든 관계형 데이터베이스 스키마에 대해 하나의 저장소가 있으면 릴리스 프로세스가 어려울 수 있습니다. 프로덕션에 푸시할 준비가 되지 않았지만 스테이징에서 추가 테스트를 기다리는 다른 스키마 변경 사항이 있는 경우 프로덕션 준비가 된 한 스키마에 대한 변경은 프로덕션으로 이동할 수 없습니다.
• 소규모 팀인 데이터 운영 팀은 어떤 변경 사항이 언제 프로덕션으로 갈 수 있고 어떤 것이 불가능한지 관리하려고 하는 병목 현상이 됩니다. 일정 충돌 및 인력 가용성으로 인해 현재 응용 프로그램에 대한 새로운 기능 또는 수정 사항의 릴리스가 실제로 느려질 수 있습니다.
• pull 요청 및 Jira 티켓의 주석을 사용하여 이러한 변경 사항을 프로덕션 시스템에 수동으로 적용하고 있습니다. 때때로 복사 붙여넣기가 끔찍하게 잘못될 수 있습니다.

Skeema(및 몇 명의 도우미)를 입력하세요.

이러한 프로세스 장애물을 제거하고, 인적 오류가 발생하기 쉬운 스키마 변경을 줄이고, 개발자가 자체 애플리케이션의 스키마를 관리할 수 있도록 하고, 잠재적으로 개발 속도를 높이기 위해 데이터 운영 팀은 관리를 자동화하고 간소화하는 데 많은 노력을 기울였습니다. 데이터베이스 스키마.

우리는 기존 도구인 Git, Buildkite CI 및 pt-online-schema-change를 사용하여 로컬 개발에서 프로덕션으로 스키마 변경 적용을 자동화하고 Skeema를 하나 더 추가했습니다.

아이디어는 모놀리식 DB 스키마 리포지토리를 데이터베이스 클러스터당 하나씩 개별 스키마 리포지토리로 나누고 개발자가 익숙한 환경에서 자체 스키마 변경을 수행할 수 있도록 하는 것입니다. 우리는 또한 개발자가 크고 복잡하거나 잠재적으로 파괴적인 스키마 변경을 만드는 추가 지원을 찾도록 돕기 위해 정상적인 가드레일을 갖기를 원합니다.

Skeema는 SQL을 사용하여 선언적 방식으로 MySQL 스키마를 관리하는 CLI 도구입니다.

데이터베이스의 각 테이블에 대해 DDL(데이터 정의 언어)을 생성하고 Git을 통해 추적 리포지토리와 통합하기 위해 로컬 파일 시스템으로 DDL을 내보낼 수 있습니다. Skiema는 Git 저장소의 SQL 파일을 라이브 MySQL 데이터베이스와 비교하고 이러한 차이점을 DDL 문으로 출력할 수 있습니다.

Percona의 pt-online-schema-change 도구를 사용하고 실행 중인 MySQL 데이터베이스의 스키마를 Git 리포지토리에 정의된 스키마와 일치시키기 위해 필요한 pt-online-schema-change 명령의 형식을 지정하도록 구성할 수도 있습니다.

스키마는 또한 로컬, 테스트 및 프로덕션과 같은 여러 환경에서 각각 다른 구성으로 스키마를 관리할 수 있습니다. 마지막으로 pull 요청 기반 워크플로에 쉽게 적용할 수 있습니다.

개별 MySQL 데이터베이스 스키마 리포지토리를 생성하면 현재 모놀리식 db-schema Git 리포지토리가 분해되고 별도 팀의 개발자가 공유 리포지토리(db-schema) 대신 자체 리포지토리에서 애플리케이션의 MySQL 스키마를 관리할 수 있습니다.

각 데이터베이스 스키마에 대해 별도의 저장소를 갖는 것은 애플리케이션 개발 팀에 더 큰 자율성을 허용할 것입니다. 이렇게 하면 모든 스키마 변경 사항을 엄격한 일정으로 조정할 필요가 없고 애플리케이션 팀이 원하는 대로 변경 사항을 프로덕션으로 이동할 수 있습니다.

이 프로세스를 자동화하는 데 중요한 구성 요소는 Buildkite의 CI 파이프라인입니다. 다음과 같은 파이프라인을 만들었습니다.

• SQL 구문 오류 확인
• 데이터베이스 스키마의 현재 마스터 분기를 사용하여 테스트 MySQL 서버를 생성하고 풀 요청(PR)에서 변경 사항의 적용을 테스트합니다.
• 차이점을 확인하고 PR 변경 사항을 테스트 MySQL 환경에 적용
• 차이점을 확인하고 PR 변경 사항을 스테이징 환경에 적용하고 프로덕션 환경에서 일부 테이블 통계를 출력합니다.

프로덕션 출력 통계는 디스크의 테이블 크기 및 예상 행 수입니다. 이러한 통계는 스키마 변경으로 인해 일정 수준의 서비스 중단이 발생하고 특별한 처리가 필요한지 여부를 결정하는 데 도움이 될 수 있습니다. PR이 마스터에 병합되면 buildkite 파이프라인은 마스터 분기와 프로덕션에서 실행 중인 항목 간의 차이점을 확인합니다.

차이점이 PR에서 예상되는 변경 사항인 경우 개발자는 이 마지막 단계의 차단을 해제할 수 있으며 Skema는 프로덕션 MySQL 데이터베이스 클러스터에 변경 사항을 적용합니다. 이러한 각 단계는 다음 단계로 이동하기 전에 요청된 변경을 담당하는 엔지니어링 팀의 승인이 필요한 차단 단계입니다.

가드레일에 관한 한 우리는 기본적으로 프로덕션에서 파괴적인 스키마 변경을 허용하지 않도록 스키마를 구성했습니다.

테스트 및 준비 환경에서는 파괴적인 변경이 허용됩니다.

또한 pt-online-schema-change를 사용하여 스키마를 변경하도록 스키마를 구성했습니다. 이것은 DataOps 팀이 친숙하고 SendGrid에서 수년간 사용해온 동일한 스키마 변경 도구입니다. 복제가 뒤처지거나 데이터베이스의 활성 스레드가 과도해지면 변경 사항을 롤백하기 위해 pt-online-schema-change에 대한 합리적인 옵션 세트를 개발했습니다.

이러한 방식으로 스키마를 구성하면 DataOps 팀 구성원이 pt-online-schema-change 명령을 수동으로 코딩하고 애플리케이션에 대한 수동 단계를 수행해야 하는 잠재적 오류가 제거됩니다.

프로그래밍 방식의 가드레일을 추가하면 개별 팀이 MySQL 데이터베이스 스키마를 관리하고 이러한 변경 사항을 사전 프로덕션 및 프로덕션 환경에 상대적으로 안전하게 적용할 수 있습니다. 가드레일이 적중되면 스키마 변경이 실패하고 롤백됩니다. 스키마 변경 실패 이유는 추가 검토를 위해 빌드 로그에 출력됩니다.

개발자가 랩톱에서 로컬 테스트에서 프로덕션으로 변경 사항을 관리할 수 있도록 하면 개발자의 자율성과 애플리케이션을 지원하는 데이터베이스의 소유권이 크게 향상됩니다. MySQL 데이터베이스 관리 프로세스에 대한 Skema의 자동화 및 통합은 일반적인 스키마 변경 관리 작업의 약 90%를 쉽게 처리합니다.

대부분의 스키마 변경은 열 추가, 열거 필드 변경, 기본값 변경 및 인덱스 추가를 위한 것입니다. 스키마 변경의 나머지 10%는 큰 테이블, 매우 활동적인 데이터베이스 또는 분할된 테이블의 특수한 경우를 다룹니다. 이 게시물 현재 Skeema는 분할된 테이블에 대한 스키마 변경을 아직 다루지 않지만 자주 요청되는 추가 기능이며 Skema의 개발자는 해당 기능을 구현하는 데 도움을 적극적으로 요청하고 있다고 들었습니다.

Git, pt-online-schema-change, Skeema 및 Buildkite CI 파이프라인을 결합하면 MySQL 데이터베이스 스키마 변경에 안정적이고 반복 가능한 프로그래밍 방식의 프로세스가 제공됩니다. 이를 통해 개발자는 데이터베이스 스키마를 안전하게 관리하고 기능 및 수정 사항이 프로덕션으로 롤아웃되는 속도를 제어할 수 있습니다.

Skeema 및 pt-online-schema 변경을 위한 구성 파일에 적절한 가드레일을 포함하면 스키마 변경을 구현하는 개발자에게 확신을 줄 수 있으며 이러한 가드레일이 적중될 경우 스키마 변경을 진행할 수 있는 방법에 대한 귀중한 피드백을 제공합니다.

데이터 운영 팀은 이 프로세스를 적용할 수 없는 나머지 10%의 사례를 지원할 수 있으며 앞으로 이 프로세스를 향상시키기 위한 추가 도구를 개발할 것입니다.