배포 절차를 인계받았다. 문서에 이렇게 적혀 있었다.
1. 빌드
2. 파일 업로드
3. 캐시 삭제
4. 확인
그대로 따라 하면 배포는 된다. 다만 문제가 났을 때 어떻게 하는지가 없었다.
Table of contents
Open Table of contents
물어봤다
문제가 생기면 어떻게 이전 판으로 가느냐고 물었다. svn 에서 이전 리비전을 받아 다시 빌드한다고 했다.
몇 가지가 걸렸는데 빌드에 몇 분 업로드에 몇 분이면 장애 중에 십 분이다.
빌드가 재현되는지도 문제였는데 의존성을 그때그때 받아 오면 그때와 같다는 보장이 없다.
어느 리비전이었는지도 알 수 없었고 배포 기록이 없으면 지금 도는 것이 무엇인지 모른다.
급한 상황에서 방법을 찾는 것이 가장 나쁜 조합이고 나가는 길만 적힌 문서는 절반만 적힌 것이다.
조치 — 나간 것을 남겨 두기
가장 간단한 개선은 배포한 결과물을 안 지우는 것이었다.
releases/
20170906-1420/
20170905-1810/
20170905-1130/
current -> releases/20170906-1420
새 판을 releases/ 아래 새 디렉터리에 풀고 다 되면 current 를 바꾼다. 이전 판으로 가는 것은 그 링크를 옮기는 일이 된다.
몇 분 걸리던 일이 초 단위로 끝나고 releases/ 의 오래된 것은 다섯 개만 남기고 지웠다.
돌아갈 대상이 있어야 돌아갈 수 있는데 같은 자리에 덮어쓰는 방식은 그 대상을 매번 없앴다.
링크를 바꾸는 순간
이 방식에는 좋은 점이 하나 더 있는데 전환하는 순간이 원자적이라는 것이다.
파일을 하나씩 덮어쓰면 그 사이에 요청이 들어와 절반은 새 파일이고 절반은 옛 파일인 상태로 돈다.
새 디렉터리에 다 풀고 링크만 바꾸면 그 구간이 없다. 바뀌는 순간이 ln -sfn 한 번뿐이다.
다만 php-fpm 이 그 링크를 언제 다시 읽는지를 확인해야 했다. 이미 떠 있는 프로세스가 경로를 잡고 있으면 링크를 바꿔도 옛 파일을 쓴다.
realpath_cache_ttl 만큼 해석한 경로를 들고 있어서 그동안은 옛 디렉터리를 본다. 그 시간을 못 기다리는 구성이면 재기동이 필요했다.
제약 — DB 변경은 돌아가기 어렵다
파일은 링크로 돌아가는데 스키마 변경은 안 되고 DROP COLUMN 했으면 그 값이 이미 없다.
ADD COLUMN 만 한 경우는 옛 코드가 그것을 모르니 괜찮다. 문제는 지우거나 이름을 바꾼 경우다.
그래서 ADD COLUMN 은 배포와 함께 하고 DROP COLUMN 은 나중에 하는 순서로 정했다.
1차 배포: 새 컬럼 추가 + 새 코드 (옛 컬럼도 계속 씀)
2차 배포: 옛 컬럼 안 쓰는 코드
3차 (며칠 뒤): 옛 컬럼 삭제
1차와 2차는 언제든 이전 판으로 갈 수 있고 3차는 그럴 일이 없을 만큼 지난 뒤에 한다.
돌아갈 수 있는 상태를 며칠 유지하는 비용이 돌아갈 수 없는 배포보다 쌌다. 그 며칠이 판단을 다시 할 수 있는 기간이 된다.
배포 기록을 남겼다
무엇이 언제 나갔는지 한 줄씩 적었다.
2017-09-06 14:20 jhcheong 20170906-1420 a3f2c1 상품 목록 카운트 캐시
2017-09-05 18:10 jhcheong 20170905-1810 9b1e4d 검색 색인 대조 배치
svn 리비전이 있어야 배포 기록과 코드가 이어지고 디렉터리 이름만으로는 무엇이 들어갔는지 모른다.
이것이 있으면 어제 오후부터 이상하다는 제보에 그 시각 전후의 배포를 보는 것으로 바로 대응한다.
기록 한 줄이 조사의 출발점을 정해 주는데 없으면 어디서부터 봐야 하는지부터 정해야 한다.
검증 — 확인 단계를 구체적으로
원래 절차의 넷째 줄이 확인이라는 한 단어였다. 무엇을 어떻게 보는지가 없다.
4. 확인
- 주요 화면 3개 응답 200 (목록/상세/검색)
- 오류 로그에 새 항목 없음 (1분간)
- 응답 시간 p95가 평소 범위
위 중 하나라도 실패하면 즉시 이전 판으로
무엇이면 정상이고 아니면 무엇을 하는지를 함께 적었는데 확인한다만 있으면 사람마다 다르게 한다.
애매하면 그냥 넘어가기도 하고 판단을 그 자리에서 하게 두면 급할수록 느슨해진다.
무엇이면 정상인지를 미리 적어 두면 그 판단이 배포 전에 끝나 있고 배포하는 사람은 보기만 하면 된다.
정리
- 배포 절차를 물으면 대개 나가는 길만 답한다
- 급한 상황에서 돌아오는 방법을 찾는 것이 가장 나쁜 조합이다
- 배포 결과물을 안 지우고 남기면 이전 판으로 가는 것이 링크 교체가 된다
- 새 디렉터리에 풀고
ln -sfn만 하면 전환에 중간 상태가 없다 - 프로세스가 링크를 언제 다시 읽는지 확인하고 필요하면 재기동한다
- DB는 추가를 먼저 하고 삭제를 며칠 뒤에 한다
- 돌아갈 수 있는 상태를 며칠 유지하는 비용이 더 싸다
- 배포 기록에 커밋 해시를 남겨야 코드와 이어진다
- 기록 한 줄이 제보를 받았을 때 조사의 출발점을 정해 준다
- 확인 단계에 무엇이면 정상이고 아니면 무엇을 하는지 적는다