무중단 배포를 위한 Mysql Online DDL 기술

서비스가 커짐에 따라 다양한 기능들이 추가되고, 이에 따라 서비스 뒷편에서는 비즈니스 로직 뿐 아니라 DB까지 수많은 변경점들이 생겨납니다.

이 때마다 서비스 중단 공고를 내서 사용자 트래픽을 원천 차단하고 패치를 진행한다면 개발자 입장에서는 편할지 몰라도, 중단된 매 시점이 일종의 손실로 볼 수 있어 쉽게 생각할 문제는 아닙니다.

즉, 서비스의 관점에서는 피치못할 경우를 제외하면 무중단으로 기능이 추가되는 편이 더 도움이 되리라는 것은 자명합니다.

하지만 무중단 배포를 하고 싶다고 무조건 할 수 있는 것은 아닙니다. DB 레이어의 변경을 적용하다보면 당시 실행되고 있던 트랜잭션은 Blocking이 될수도, 혹은 아예 문제가 발생해 종료가 될 수 있습니다. 이러한 경우 유저의 서비스 이용에 문제가 있는 것이기 때문에, 오히려 서비스 중단을 사전에 공지하고 중단 배포를 하는 것보다 더 큰 문제가 될 수 있습니다.

따라서 DB 레벨의 변경점들을 실제 적용할 때에는 최대한 라이브 서비스에 영향이 가지 않는 방법을 알아내고 적용해야합니다.

저의 경우엔 최근 무중단 배포에서 DDL을 실행하는 도중 몇몇의 유저 트랜잭션이 다음 에러를 뱉으며 실패하는 상황을 겪었습니다.

ERROR 1412 (HY000): Table definition has changed, please retry transaction

이 문제를 겪고 난 뒤, 해당 주제에 대해 경각심을 갖게 되었고 이를 해결하기 위해 학습한 내용들을 다뤄보려고 합니다. 이 글에서는 MySQL Online DDL의 개념, 알고리즘 유형과 잠금 방식, 무중단 배포를 위한 전략, 그리고 외래 키 제약 조건 추가 시 발생할 수 있는 문제와 구체적인 해결책까지 포괄적으로 다루겠습니다.

DDL Algorithm, Lock

Mysql 8버전부터는 DDL 실행 도중에도 서비스의 중단점이 최소화될 수 있도록 Online DDL이 도입되었습니다.

이전까지는 이 상황에서 ptosc와 같은 기술을 이용하여 이 문제들을 풀었으나, 이제는 대부분의 케이스에서 Mysql이 직접 이 문제를 해결할 수 있게 된 것입니다. (Mysql Online DDL이 문제를 해결하지 못하는 케이스: https://medium.com/daangn/mysql-online-ddl-faf47439084c)

Mysql Online DDL에서는 ALTER TABLE 문이 발생하면, 최소한의 서비스 영향도를 갖는 DDL 알고리즘, 락을 선택하는 과정을 거칩니다.

이 때 적용될 수 있는 알고리즘과 락의 종류는 아래와 같습니다.

• Algorithm
  • INSTANT
    • Mysql 8버전에서 신규 도입되었으며 목표 테이블 내 데이터에는 전혀 영향을 미치지 않고, 해당 테이블의 메타데이터만을 변경한 뒤 종료되는 방식으로 동작
    • 실행 속도가 매우 빠르며 서비스에 거의 영향을 주지 않음
    • 다만 매우 제한적으로 사용 가능 (ex. 테이블의 끝부분에 칼럼 추가, 칼럼 기본값 수정, 테이블 이름 변경)
  • INPLACE
    • 목표 테이블에 대해, DDL 시작 페이즈와 종료 페이즈에 짧게 락이 걸리지만 그 외 실행 도중에는 읽기 작업과 쓰기 작업이 모두 가능한 방식
    • 원본 테이블을 복제하고 복제본에 수정을 가하는 COPY 방식과는 달리, INPLACE 방식은 원본 테이블 자체에 Mysql 페이지 단위로 접근하여 스키마 수정을 가함
    • DDL 동작 중 발생하는 DML은 우선 online_alter_log에 저장되고, 스키마 수정이 완료된 직후에 실제 테이블에 반영
    • 이 때 online_alter_log 저장소가 가득찰 경우, DDL이 실패하기 때문에 이 경우엔 128MB로 기본 설정된 innodb_online_alter_log_max_size 값을 키워야 함. (세션 별 수정 가능)
  • COPY
    • 스키마 변경점이 적용된 테이블을 새로 생성하고 기존 데이터를 일괄 복제 후 최종적으로 RENAME하여 새로운 원본 테이블이 되도록 하는 방식
    • 이 경우 DDL 실행 중 읽기 작업만 허용됨
• Lock
  • NONE
    • 아무런 잠금이 발생하지 않음
  • SHARED
    • 읽기 작업만 허용하는 잠금 발생
  • EXCLUSIVE
    • 읽기, 쓰기 모두 불가능한 잠금 발생

무중단 배포를 위해서라면?

무중단 배포를 보장하기 위해서는 SELECT, INSERT, UPDATE 문을 모두 보장하는 Algorithm = INPLACE, Lock = NONE 조합으로 DDL을 수행할 수 있어야 합니다.

현재 적용해야하는 DDL이 어떤 알고리즘과 락을 필요로 하는지 모르겠다면 우선 ALTER TABLE ~ , Algorithm = INSTANT 로 테스트 환경에서 실행해보고, 해당 알고리즘으로 DDL을 수행하는 것이 불가능하다고 에러가 난다면 그 후 ALTER TABLE ~ , Algorithm = INPLACE, Lock = NONE 으로 실행해보면 됩니다. 만약 이조차도 불가능하다면 중단 배포를 고려해봐야 합니다.

물론 Mysql 공식문서에서도 각 DDL이 어떤 알고리즘으로 동작하는지와 Online DDL을 위해 고려해야할 부분들을 정리하고 있습니다. (https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl-operations.html 참조)

무중단으로 FK 추가하기 (Feat. ERROR 1412 (HY000): Table definition has changed, please retry transaction)

다시 서론에서 언급한 에러로 돌아와, 이 문제를 현재는 어떻게 해결했는지 설명하며 해당 글을 마치겠습니다.

에러가 발생한 당시의 상황을 조금 더 설명하자면, 라이브 Mysql DB에 신규 기능을 위한 일련의 DDL들을 실행해야하는 상황이었습니다. 여기에는 신규 테이블의 추가 및 기존 테이블로의 FK 참조 추가가 포함되어 있었습니다. 저는 DDL을 실행했고 이는 얼마 안가 성공했지만, 막상 저희 서버 로그에는 몇몇의 요청이 해당 에러를 뱉으며 실패한 것을 확인했습니다.

이전에도 해당 에러를 본 적이 이미 있었어서, 저는 당시에도 어떤 DDL이 실행되었는지 확인해보았고 그 때에도 '신규 테이블 추가 > 기존 테이블에 대한 FK 참조 제약 생성'의 패턴이 존재했었다는 것을 알 수 있었습니다.

FK를 추가하는 작업은 기본적으로 Algorithm = COPY, LOCK = SHARED로 동작하기 때문에 필연적으로 별도의 테이블이 새로 생겨나고, 이로 인해 트랜잭션에서 최초 참조하던 테이블의 구조와는 달라져버리기 때문에 발생합니다.

여기까지 파악한 뒤 '그럼 FK가 추가되는 상황에는 매번 중단 배포를 해야하는건가'라는 생각을 잠깐 했지만, 제가 현재 개발하고 있는 서비스의 생명 주기를 생각했을 때 그러기엔 쉽지 않다고 판단했고 다른 방법을 강구했습니다.

최종적으로 발견한 해결책은 DDL 세션에 한정해서 foreign_key_checks 옵션을 꺼버리는 것입니다. Mysql 공식문서에는 아래처럼 설명하고 있습니다. (결국 공식문서에 답이 있다니...)

The INPLACE algorithm is supported when foreign_key_checks is disabled. Otherwise, only the COPY algorithm is supported.

물론 혹자는 FK 체크 제약을 꺼버리면 무슨 의미가 있느냐고 할 수 있지만 foreign_key_checks 옵션은 세션 레벨에서 제어가 가능해서 라이브 서비스에서는 여전히 FK 제약이 잘 동작할 것이며 '신규 테이블을 생성하고 이를 기존 테이블과 연결하는 상황'에서는 애초에 서버 로직이 배포되기 전까지는 신규 테이블에 데이터가 존재하지 않을 것이기 때문에 문제가 없다고 판단했습니다. (다만 기존에 존재하던 테이블들 간의 FK 제약 추가 케이스에서는 사용할 수 없는데, 이 경우는 애초에 테이블 설계 레벨에서 잘못된 케이스이기도 하고 거의 존재하지 않는 케이스이기 때문에 어느정도 배제되었습니다. 이 땐 어쩔 수 없이 중단 배포를 해야되지 않을지...)

실제 실행되는 쿼리는 아래와 같습니다.

SET SESSION foreign_key_checks = 0;
ALTER TABLE ... ADD FOREIGN KEY ..., Algorithm = INPLACE, LOCK = NONE;
SET SESSION foreign_key_checks = 1;

Mysql Online DDL Checker (250324 추가)

해당 글을 작성한 뒤, Mysql Online DDL의 알고리즘과 락을 확인하는 방법이 너무 번거롭다는 생각을 떨칠 수 없었습니다. 그래서 그냥 직접 개발하여 오픈소스로 배포해보면 어떨까 생각하고 아래 프로젝트를 진행했습니다.

https://github.com/One-armed-boy/mysql-ddl-checker

해당 패키지를 npm을 통해 내려받았다면, 루트 경로에 설정 파일을 세팅하고 아래처럼 명령어를 수행하기만 하면 됩니다. (파일 세팅법은 리드미를 참조해주세요.)

npx mysql-ddl-checker "ALTER TABLE users ADD COLUMN email VARCHAR(255)"

(급하게 작성해본 프로젝트라 부족한 부분도 많고 아직 모든 DDL을 커버하지 못할 수 있어서 편하게 이슈 제보나 기여해주셔도 됩니다.)