두 체계를 하나로 합치는 작업이 진행 중이었다. 항목 요청서를 보다가 같은 화면인데 주소가 둘로 잡혀 있는 것을 발견했다.
Table of contents
Open Table of contents
상황 — 화면 하나에 잡힌 두 주소
사용자에게는 화면 하나로 보이는데 그 안에서 탭을 옮기면 URL이 바뀌는 구조였다. 탭마다 다른 체계의 MySQL이 자료를 대고 있었다.
이렇게 되어 있는 이유는 자료를 아직 안 합쳤기 때문이다. 옛 체계에 있는 것과 새 체계에 있는 것을 각각 그 체계에서 보여 주고 있었다.
옮기지 않고 나란히 두기
이 방식의 장점은 자료를 옮기지 않고도 새 체계를 쓰기 시작할 수 있다는 점이다. 새로 들어오는 것부터 새 체계에 쌓으면 된다.
자료를 전부 옮기고 나서 시작하려고 하면 그 이관이 끝날 때까지 아무것도 못 한다. 나란히 두면 그 기다림 없이 시작한다. 대신 사용자가 두 탭을 오가야 하고 두 쪽을 UNION ALL로 붙여 COUNT(*)를 내거나 ORDER BY 하는 것을 못 한다.
전환이 되고 있는지를 숫자로 본다
이 불편은 전환이 끝나면 없어지는 것이라 견딜 만하다. 다만 전환이 실제로 진행되고 있어야 그 말이 성립한다.
진행이 멈추면 불편만 영구히 남는다. 그래서 두 탭의 COUNT(*)를 각각 내서 옛 쪽이 줄고 새 쪽이 느는지를 볼 수 있게 했다. 임시 상태를 만들 때는 그것이 끝나가는지를 보는 숫자가 함께 있어야 했다.
라벨의 두 축
요청서의 항목 이름을 보니 어떤 동작인지와 어느 체계인지가 함께 들어 있었다. 두 가지를 한 이름에 담으면 어느 쪽으로도 모아서 볼 수 있다.
동작별로 모으면 사용자가 무엇을 많이 하는지가 나오고 체계별로 모으면 전환이 얼마나 됐는지가 나온다. 다만 축이 하나 더 늘 때 그것을 이름의 어디에 붙일지가 항목마다 갈리면 나중에 자르는 규칙이 복잡해진다. 순서를 미리 정해 두면 자르기는 쉬운 대신 이름이 길어졌다.
선행 조건을 문서에 적어 둔다
요청서에 이 항목을 넣으려면 먼저 무엇이 되어 있어야 하는지가 적힌 것들이 있었다. 그것이 적혀 있으면 시작하기 전에 확인하게 된다.
안 적혀 있으면 착수했다가 중간에 막힌다. 그리고 문서 안쪽에 갱신 일자가 적혀 있는 것도 눈에 띄었는데 파일 이름에만 있으면 복사하면서 사라진다. 안쪽에 있으면 어디로 옮겨져도 그 문서가 언제 것인지가 남는다.
정리
- 두 체계를 합치는 동안 같은 화면에 주소가 둘씩 잡힌다
- 자료를 옮기지 않고 나란히 두면 전환을 먼저 시작할 수 있다
- 대신 두 쪽을
UNION ALL로 붙여 세거나ORDER BY할 수 없다 - 전환이 진행되고 있는지를 두 쪽의
COUNT(*)로 본다 - 임시 상태에는 끝나가는지 보는 숫자가 함께 있어야 한다
- 이름을 동작과 체계로 나누면 두 축 어느 쪽으로도 모인다
- 선행 조건을 문서에 적어 두면 착수했다 막히는 일이 준다
- 문서 안쪽 갱신 일자는 복사해도 남는다