두 팀이 한 DB를 쓸 때

한 DB를 두 시스템이 함께 쓰고 있었다. 각각 다른 팀이 만들고 같은 표를 양쪽에서 읽고 썼다.

Open Table of contents

같은 표를 양쪽에서 쓰는 구조

처음에는 편해 보인다. 자료를 주고받을 것 없이 같은 자리를 보면 된다.

그런데 무언가를 바꾸려고 할 때 이 구조의 성격이 드러났다. 우리 쪽만 보고 판단할 수 있는 것이 거의 없었다.

ALTER TABLE로 컬럼을 하나 지우려고 했는데 그것을 상대 팀이 쓰는지 알 수 없었다. 우리 코드에 grep을 걸어 안 쓴다는 것은 확인했지만 그것으로는 부족하다.

물어보면 되는데 그쪽도 전부를 기억하지는 못한다. 결국 확신이 안 서니 안 지우게 되고 그런 컬럼이 계속 쌓였다. 영향 범위를 모르면 못 바꾸고 못 바꾸니 정리가 안 된다.

더 곤란한 것은 같은 컬럼을 서로 다른 뜻으로 쓰기 시작하는 것이었다. 상태 값 하나에 우리가 안 쓰는 값이 들어오고 있었다.

그쪽에서 자기 용도로 값을 하나 추가한 것이다. 우리 코드는 그 값을 모르니 처리에서 빠뜨린다.

그 컬럼이 VARCHAR라 아무 값이나 들어갈 수 있었던 것도 한몫했다. ENUM으로 두면 값을 늘리는 것 자체가 ALTER TABLE이 되어 양쪽에 드러난다. 당장 바꾸지는 못해서 값 목록을 공유하고 추가할 때 알리기로 했다.

양쪽이 큰 갱신을 돌리는 시간이 겹치면 서로를 막았다. 우리 배치가 느려질 때 원인이 우리 안에 없는 경우가 생긴다.

그래서 대량 작업 시간표를 서로 공유했다. 겹치지 않게 옮기는 것만으로 즉시 효과가 있었다. 조회 부하는 복제본으로 옮겨서 쓰기와 부딪히지 않게 했는데 Seconds_Behind_Master만큼 늦는 것을 감수해야 했다.

근본적인 해결은 DB를 나누는 것이었다. 다만 그것은 큰 작업이라 당장은 못 했다.

그래서 지금 공유하는 것을 더 늘리지 않는 것부터 시작했다. 새로 생기는 자료는 상대 쪽에 필요하면 표를 직접 보게 하지 않고 API를 하나 열어 주기로 했다. 나누는 것을 못 하더라도 늘어나는 것을 멈추면 나중에 나누기가 쉬워진다.