개발자의 실수 중 가장 경계하는 건 over-engineering.
피해가 크고 잔해가 오래 남기도 하지만, 개인적인 감정을 담아 조심하는 까닭은 신입 시절 맡게된 첫 프로젝트 때문이다.
서비스 A를 두 개로 쪼개는 과정에서 서비스 B가 만들어졌고, 나는 A에 있는 데이터를 B로 옮기는 프로젝트를 맡았다.
수행을 위해 공부 중 Downtime 없이 서비스에 데이터를 옮기는 "Dual-Write"와 "Change Data Capture" 같은 디자인 패턴에 알게되었고, 이 프로젝트에 사용하는 게 적절할거라 판단했다.
그 후 약 두 달 동안
• 서비스 A의 DB와 서비스 B의 API 동시에 저장하는 Dual-Write 시스템
• 서비스 B로 옮기는 과정에 들어오는 API 콜을 임시 저장 후 처리 하는 시스템
• 옮긴 데이터를 검증하는 시스템
등 열심히 개발을 진행하였다.
프로젝트가 얼추 완성되고 데이터를 옮기는 날이 정해졌다.
나의 계획은:
• 유저가 적은 늦은 밤 11시 접속
• Dual-Write 시스템을 개방
• 서비스 A → 서비스 B로 옮기는 스크립트 시작
• 검증 시스템으로 모니터링
일단 근무 시간 동안 QA 서비스 환경에서 연습을 해보기로 했다.
QA 환경으로 연결 했다.
• Dual-write API 서비스 개방
서비스 A와 서비스 B 두 곳 모두 데이터가 잘 쌓이고 있는걸 검증 시스템으로 확인.
• 서비스 A→서비스 B
스크립트 시작 15초 만에 모든 데이터가 옮겨졌다.
조금 놀랐지만 QA 환경엔 데이터가 별로 없기 때문이라 생각했다.
예감이 좋다.
그날 저녁 11시. Prod 환경에 데이터 옮기는 과정을 시작했다.
• Dual-write API 서비스 개방
하려고 하는데... 어라? 벌써 개방이 되어있다?
검증 시스템으로 모니터링을해보니... 이미 데이터가 서비스 B에 옮겨져 있었다.
그렇다. 나는 QA가 아닌 Prod 환경에서 연습을 했던 것이다.
어처구니없는 실수가 큰 실책으로 이어지지 않은건 정말 운이 좋았다.
하지만 이때 나는 서비스 A의 데이터는 끽 해봐야 15GB 정도 밖에 없다는 것을 깨달았다.
"Zero downtime"에 매달려 두 달이나 넘게 개발했던 시스템은 사실 "15초 downtime"을 수응할 수 있었다면 대부분 필요하지 않았다.
다음날 PM이 "데이터는 잘 옮겼어?" 물어보았다. 나는 잘 옮겨졌다고 대충 얼버무렸다.
PM은 기뻐하며 나에게 맛잇는 점심을 사주었다. 나는 시킨 음식을 다 먹지 못했다.