출력 맨 끝에 한 줄이 붙어 있었다
그날 하려던 건 백업이었다. 서비스가 돌기 시작하면 기능보다 무서운 게 데이터라, 하루를 잡고 백업 체계를 깔기로 했다.
설치는 순조로웠다. 문제는 설치 스크립트가 뱉은 출력의 맨 끝 한 줄이었다.
디스크 사용량 90%.
두 달 전에 확인했을 땐 12%였다.
100%가 되면 DB가 쓰기를 멈춘다. 백업은 데이터가 사라진 뒤에 되살리는 장치지, 서비스가 멈추는 걸 막아주지는 않는다. 백업 체계를 만들러 들어갔다가 백업으로도 못 막을 사고를 먼저 만난 셈이다.
여기서 제일 마음에 걸린 건 90%라는 숫자가 아니었다. 그 두 달 동안 아무도 안 봤다는 것이다. 디스크를 보러 들어간 것도 아니었으니, 오늘 이걸 안 것도 실력이 아니라 운이다. 백업을 깔기로 한 날이 하필 이날이었을 뿐이다.
무엇부터 셌나
원인을 짐작으로 정하면 엉뚱한 걸 지우게 된다. 그래서 후보를 몇 개 세워놓고 서버에서 직접 셌다.
배포 산출물, 시스템 로그, DB 볼륨, 그리고 DB가 변경 이력을 남기는 파일. 각각이 실제로 몇 GB인지를 하나씩 확인했다.
결과는 배포 산출물이었다. 212개. 그중 실제로 쓰이는 건 5개. 45GB. 시스템 로그도 1GB 가까이 있었지만 부차적이었고, DB 볼륨은 300MB대로 건강했다.
배포할 때마다 새 산출물이 올라가는데 옛것이 남아 있었다. 정리하는 명령은 파이프라인에 들어 있었다. 다만 그 옵션이 이름표가 안 붙은 것만 지운다. 배포 산출물에는 버전 이름표가 붙어 있으니 정리 대상이 아니었던 것으로 보인다.
"~로 보인다"고 쓰는 이유가 있다. 확실한 건 산출물이 212개 쌓여 있었다는 사실이고, 정리 옵션의 사정거리가 그 이유라는 건 가장 유력한 설명이지 실험으로 확정한 게 아니다. 다만 그 설명 위에서 고쳤고, 고친 뒤로는 안 쌓인다.
치우는 것과 안 쌓이게 하는 것
지우고 나니 90%에서 19%로 떨어졌다. 58GB 중 11GB.
여기서 끝내면 두 달 뒤에 같은 일이 난다. 그래서 배포 파이프라인의 정리 옵션을 바꿨다. 이제 사흘 지난 것은 이름표가 붙어 있어도 지운다.
부작용이 하나 있다. 이 방식은 만들어진 시점을 기준으로 지우기 때문에, 가끔씩만 쓰는 보조 도구들도 같이 지워진다. 그것들은 다음에 필요할 때 다시 받아온다. 하루에 한 번 몇백 MB를 다시 받는 셈인데, 디스크가 차서 서비스가 멈추는 것보다는 싸다고 봤다.
한 번 치우는 건 그날의 일이고, 다시 안 쌓이게 하는 게 본 수정이다.
진짜로 고친 것
이날 진짜로 고친 건 디스크가 아니다. 두 달 동안 아무도 안 보고 있었다는 것을 고쳤다.
백업이 실패하면 알려주는 감시를 붙였는데, 붙이자마자 실패 알림이 왔다. 설정을 잘못했나 싶었다. 오작동이라고 생각한 게 먼저였다. 그런데 디스크를 정리하고 나니 알림이 정상으로 돌아왔다.
정확히 무엇 때문에 그 알림이 왔는지까지 확인한 건 아니다. 다만 순서는 분명하다 — 디스크가 꽉 차 있는 동안 실패했고, 비우고 나니 통과했다.
남길 것
만드는 건 하루면 된다. 살아 있는지 확인하는 건 계속해야 한다.
디스크가 두 달 만에 12%에서 90%가 된 것도 같은 얘기다. 만들 때는 멀쩡했고, 그 뒤로 아무도 안 봤을 뿐이다. 누가 잘못한 게 아니라 보는 사람이 정해져 있지 않았던 것이다. 혼자 하는 프로젝트에서는 이게 특히 잘 생긴다. 만든 사람과 지켜볼 사람이 같은 사람인데, 만드는 동안에는 지켜볼 시간이 없다.
그래서 요즘은 뭘 만들 때 "이게 고장나면 누가 알게 되나"를 같이 정한다. 그 답이 없으면 그건 아직 안 만든 거다.
