Auto increment max 때문에 주말에 6시간 일했다 - 1

사건은 주말 저녁 8시 30분에 발생했다.

 

내가 입사때부터 쭉 담당하고 있는 서비스에 이상이 발생했다는 연락을 협력사로부터 받았다. 서비스 자체가 동작하지 않는 것은 아니었으나, 정보를 표기하는 부분에 있어 특정 데이터가 갱신되고 있지 않다는 것이었다. 서비스의 일부 모듈에 문제고 특정 정보의 갱신이 되지 않는 다는 것은 협력사로부터 연락받기 3일전부터 인지를 하고 있었고 서비스의 아주 사소한 부분이라 바로 해결하지 않았다. 

 

담당하고 있는 서비스에 버그가 발생하면 슬랙으로 알람을 받도록 코드를 짜뒀었고, 에러 메세지는 Failed to read auto-increment value from storage engine 였다. 대충 구글링 하고 에러가 발생한 모듈을 보니 딱봐도 auto increment 를 PK로 사용하는 테이블이 있는데 이 테이블의 id가 max에 다달아서 발생한 문제라고 생각했고, 급한 이슈가 아니고 쿼리 한방으로 해결되는 문제라고 판단했다. 

 

하지만 나는 production 테이블에 권한이 없기에 팀장님에게 상황에 대한 공유와 해결책을 전달하고 신규 서비스 런칭이 코앞이라 거기에 집중했다. 이때 2가지 실수를 범했는데 하나는 발생한 버그에 대하여 구체적인 로그를 확인하지 않고 단순히 슬랙으로 오는 에러 메세지만 보고 문제를 판단한 것이고, 다른 하나는 DB에 접속해서 쿼리를 날릴 권한이 없다는 이유만으로 팀장님한테 상황에 대한 공유 및 해결책만 전달하고 내 할일을 했다는 것이다.

 

대충 문제가 발생한 부분은 이렇게 생겼다.

 

A 랑 B 모듈에서 각각 데이터를 수집해서 DB의 Queue Table에 Insert 를 하면

C 모듈을 Queue Table을 주기적으로 읽어서 D Table에 업데이트를 하는 방식이다.

 

나는 처음에 에러메세지를 봤을때 '아 queue table 의 id가 PK이고 unsigned int 인데 이게 42억 얼마를 넘어서 발생한 문제구나' 라고 생각해서 단순히 ALTER TABLE \'Queue Table\' AUTO_INCREMENT = 1  이렇게 id의 값을 1로 바꿔주면 해결되겠구나 라고 생각했다. A, B 모듈은 서비스의 큰 부분을 차지하고 있기 때문에 A,B 모듈이 죽었으면 서비스가 멈추기 때문에 바로 고쳤을텐데 실제로 고장나서 에러메세지가 온 것은 C 모듈로부터 왔기 때문에 당장 해결해야겠다는 생각을 하지 못했다. 

그리고 담당하고 있는 신규 서비스의 런칭이 코앞에 다가와서 자체적으로 QA를 하면서 production 배포를 위해 다른 팀원들과 협업중이였기에 정신이 없고 크게 신경을 못쓰는 상황이었기에 대충 넘겼다. 

 

그런데 협력사로부터 주말에 갑자기 연락이 왔을때 인지하고 있는 버그라서 CTO님이랑 팀장님한테 공유를 다시 드렸고, 별거 아니고 쿼리한방이면 해결될꺼다 라는 식으로 말씀을 드렸는데 이때 뭔가 쎄함을 느꼈다.

 

상식적으로 생각해봤을때 만약에 Queue Table 에 id가 max에 도달해서 에러가 발생한거면 A, B 모듈이 정지되었을꺼고 그러면 서비스가 멈췄을텐데 왜 A,B 모듈은 멀쩡하고 C모듈이 죽었다는 부분에서 의문이 생겼다. 처음 대충 생각하고 어림짐작했던 것이 틀린 것 이었다.

 

그나마 다행이었던 것은 집 맥북에 VPN 세팅을 해뒀기 때문에 argocd랑 gitlab에 접근할 수 있다는 것이었고, 신규서비스 런칭때문에 이번달말까지 git의 maintainer 권한이 허용된 것이었다. (prod 까지 배포 가능하지만 모듈들이 떠있는 pod을 수동으로 조작하거나 production DB에 접속은 못하는 상태)

 

[2부에서 계속]