DOing
RDB에서 무중단 스키마 변경 툴 도입기 (Online DDL) -1 본문
"엄격한 스키마", RDB의 장점이자 단점으로 꼽히는 특징이다.
이 특징으로 인해 안정적으로 서비스를 할 수 있다는 장점을 얻을 수 있다.
하지만 한 분기에도 수십개의 기능을 만들어내고 또 그 중 대부분을 다시 롤백해야하는 스타트업에서는
데이터베이스의 스키마를 변경할때마다, 트래픽을 제일 적은 시간에 수행해야하고, 그럼에도 일정 시간동안 장애를 감내야하는 상황은 크리티컬하게 다가왔다.
모든 스타트업이 그렇다는 것은 아니지만, 적어도 내가 현재 재직하고 있는 회사에서는 그랬었다. 이러한 문제 상황을 해결하고자 데이터 마이그레이션을 도와줄 수 있는 툴을 조사했었다. Prod과 비슷한 테스트 환경을 만들어 모의 테스트를 하고, 이를 바탕으로 다른 백엔드 엔지니어들에게 공유하고, 설득하여 도입했었다. 현재는 무사히 도입에 성공하여, 실제 서비스 중인 75,000,000 rows 이상의 테이블에 대하여 DDL을 서비스 중단이나 장애없이 수행하고 있다. 이번 포스팅에서는 이를 바탕으로 Online-DDL 도입기에 대해서 이야기해보려고 한다.
[ Online DDL의 원리, 알고리즘 ]
Instant > InPlace > Copy 순으로 효율적이며 따라서 Mysql 8에서는 Instant가 default로 설정되어 있으나 해당 알고리즘 사용 부분이 매우 제한적이다. Instant가 만약 적용이 안된다면 InPlace, Copy 순으로 적용한다. [1]
1. Copy
- 임시 테이블을 생성하여 DDL을 반영하고, 기존 테이블의 데이터를 복사한 후 기존 테이블과 이름을 변경하는 방식이다.
- ALTER TABLE 작업 동안 SHARED LOCK Select는 가능하지만, DML(inserts,updates,delete)은 차단된다.
2. inplace
- 기존 테이블에 변경 내용을 직접 반영하여 임시테이블이나 테이블 재생성을 피하는 방식이다.
- ALTER TABLE 중 들어오는 DML 쿼리는 Online Alter Log buffer에 쌓이고 테이블 변경이 완료 후 반영한다.
- 단점
1. 너무 긴 DDL 수행은 레플리카 지연을 발생시킬 수 있다.
: DDL이 수행이 마스터에서 실행을 완료 하고, 이어 슬레이브에서 DDL 연산이 완료된후에야 슬레이브에서 DML 수행이 될 수 있기 때문이다. (문제는 이게 거의 몇시간 가량까지 넘어가는 경우들이 있다.)
2. innodb_online_alter_log_max_size의 값을 넘어가게 되면 오류가 발생한다.
3. 많은 데이터를 가진 table을 변경할 시, 높은 I/O 사용량을 유발할 수 있다.
3. Instant
- MySQL 8.0.12 버전에 추가된 알고리즘으로 메타 정보만 수정하여 변경 사항을 반영한다.
- Data dictionary의 metadata만 변경하기 때문에 Table에 metadata lock을 걸지 않는다.
- Table data에도 영향을 받지 않기 때문에 바로 반영한다.
- 제한 사항이 많다라는 단점이 있다. (컬럼 추가시 위치 지정 불가, FULLTEXT 인덱스를 포함하는 테이블에는 사용 불가 등)
[ MySQL에서 지원하는 Online DDL의 성능 확인 ]
DDL 마다 수행시간이 모두 다르다. 때문에 큰 테이블에서 DDL을 실행하기전에 다음을 수행해야 한다. [2]
( 참고 : )
1. 테이블 구조를 clone
2. clone한 테이블에 소량의 데이터를 넣는다.
3. DDL을 수행해본다.
4. “rows affected”가 0인지 아닌지 체크한다.
: "만약 0이 아니라면, special planning이 필요하다. 예를 들어, 예정된 downtime시간에 수행하거나, replica server에 하나씩 수행한다." 라고 공식 문서에서 제안하고 있다. 바로 이런 경우에 대해서 별도의 Online Schema Change Tool이 필요한 것이며, 이에 대해서는 앞으로 알아보도록 하겠다.
[ MySQL 에서 지원하는 Online DDL 제한사항 ]
대형 테이블의 온라인 DDL 작업에 적용된다. [3]
- Online DDL 작업을 일시 중지하거나 Online DDL 작업에 대한 I/O 또는 CPU 사용량을 조절하는 메커니즘이 없다.
: 때문에 많은 데이터를 가진 table을 변경할 시, 해당 DDL이 매우 높은 I/O 사용량을 유발할 수 있다.
- 온라인 DDL 작업의 롤백 비용이 많이 들 수 있다.
- 장기 실행 온라인 DDL 작업으로 인해 복제 지연(replication lag)이 발생할 수 있다.
: DDL이 수행이 마스터에서 실행을 완료 하고, 이어 슬레이브에서 DDL 연산이 완료된후에야 슬레이브에서 DML 수행이 될 수 있기 때문이다.
[ Online Schema Change Tool 의 등장 ]
위에서 알아본 것처럼, 데이터가 많은 테이블에 대해서 Online DDL을 수행할 시에 문제가 발생할 수 있다. 하나의 DDL 작업이 너무 오래걸리기 때문에 슬레이브가 밀리고, 높은 I/O와 CPU 사용량을 유발하게 된다. 이 문제를 해결하는 방법은 단순하다. DDL 작업을 분해하고, 대규모 작업을 여러개의 작은 작업으로 분할하여 단일 작업 시간을 줄이는 것이다. MySQL online DDL 도구( Pt OSC, Facebook OSC, oak online alter table, GH OST 등 )는 일반적으로 DDL 작업을 분해하는 데 사용된다. 이러한 도구들의 큰 아이디어는 사실 비슷하다. 원본 테이블의 미러 테이블을 만들고 먼저 테이블 구조 변경을 수행한 다음, 원본 테이블의 전체 데이터와 변경된 데이터를 동기화한다. 동기화가 완료되면 이 두 테이블을 swap 한다. 따라서 단일 DDL 작업으로 인한 레플리카 지연을 피할 수 있다. 주요 차이점이자 핵심 과제는 "이 과정 동안 발생하는 DML(update, delete, insert 요청)들을 어떻게 처리할 것이냐?"다.
Ref.
[1] https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl.html
[2] https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html
[3] https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-limitations.html
[4] Online DDL 진행 상태와 Row log buffer 사용량 확인 : https://small-dbtalk.blogspot.com/search?q=online+ddl