거래소 서버 다섯 대의 커널 보안 패치와 재기동을 하나의 작업 OPS-118 로 묶어서 잡았다. 전부 같은 일이니 한 번에 묶어서 하는 편이 효율적으로 보였다.
Table of contents
Open Table of contents
증상 — 한 대에서 막혀 전체가 밀렸다
그중 MariaDB 복제 주 서버가 부 서버로의 승격 순서를 확인해야 해서 이틀이 걸렸다. 그 이틀 동안 나머지 넷도 손대지 못한 채로 밀렸다.
작업이 하나로 묶여 있으므로 부분 완료라는 상태 자체가 없었다. 묶은 작업은 가장 어려운 대상의 속도로 움직이고 나머지는 그동안 대기 상태가 된다.
원인 — 같은 일로 보이던 다른 확인
대상별로 확인해야 할 것을 적어 보니 다섯이 전부 달랐다. API 서버 둘은 nginx 업스트림에서 하나씩 빼면 되지만 복제 주는 SHOW SLAVE STATUS 로 지연을 보고 승격하는 절차가 필요하고 배치 서버는 일정산 cron 시간대를 피해야 했다.
지갑 노드는 재기동 뒤 getpeerinfo 로 피어 재연결 확인이 따로 필요했다. 하는 일은 같아도 확인할 것이 다르면 그것은 다른 작업이었다.
판단 기준 — 묶는 기준과 나누는 기준
두 가지 방법이 있었다. OPS-118 하나를 그대로 두고 안에서 순서만 조정하는 것과, 성격이 다른 것을 별개 작업으로 나누는 것이다. 뒤쪽을 골랐다. 이유는 되돌리는 방법이 대상마다 달라서 하나가 실패했을 때 무엇을 되돌릴지가 한 작업 안에서는 안 갈려서다. 대신 티켓이 넷으로 늘어 관리할 것이 느는 것을 감수했다.
성격이 같고 확인할 것이 같고 하나가 막혀도 나머지를 진행할 수 있으면 묶어도 된다. 대상마다 절차가 다르거나 하나가 막히면 나머지도 못 하거나 되돌리는 방법이 다르면 나눈다. 그래서 성격이 같은 API 서버 둘만 묶어 두고 나머지 셋은 각각 별개 작업으로 나눴다.
나눈 뒤 보이는 진행 상황
나누고 나니 어디까지 진행됐는지가 Jira 보드의 OPS-118·OPS-121·OPS-122 에 그대로 드러났다. 하나로 뒀을 때는 진행 중이라는 상태가 몇 주 동안 그대로였다.
보고할 때도 다섯 중 둘 완료라는 말이 진행 중보다 훨씬 낫다. 나누되 순서가 있는 것은 어느 작업 뒤에 하는지와 그 이유를 함께 적었다.
나누는 것이 항상 낫지는 않은 자리
같은 방식으로 다른 작업도 훑어보니 전 서비스나 모든 대상이 붙은 작업이 몇 달씩 열려 있었다. 그것들도 대상별로 확인할 것이 달랐고 나누고 나니 첫 조각을 그 주에 끝냈다.
다만 Filebeat 판 올리기처럼 다섯 대가 전부 같은 확인이고 하나가 막혀도 나머지를 할 수 있는 작업은 안 나눴다. 나누는 기준은 대상의 개수가 아니라 성격이었다.
정리
- 성격이 다른 것을 묶으면 가장 어려운 것에 맞춰 전체가 멈춘다
- 묶은 작업에는 부분 완료라는 상태가 없다
- 같은 일로 보여도 대상마다 확인할 것이 다를 수 있다
- 성격과 확인 항목이 같은 API 서버 둘 같은 것만 묶는다
- 되돌리는 방법이 다르면 한 작업으로 못 다룬다
- 나누면 진행 상황이 보이고 보고할 내용도 달라진다
- 나누되 순서가 있으면 이유와 함께 적는다
- 나누는 기준은 개수가 아니라 성격이다