컨테이너 로컬 파일에 저장하던 설정을 영속화해야 했고 계획은 간단해 보였다. 다른 데이터가 이미 객체 저장소를 쓰고 있으니 그 패턴을 재사용하면 된다는 것이었다.
Table of contents
Open Table of contents
실재하지 않던 패턴
재사용하려면 기존 코드를 봐야 해서 업로드 관련 호출을 서비스 코드 전체에서 검색했는데 0건이었다. 다시 훑어보니 있는 것은 읽기뿐이었다.
def _fetch_cdn_json(path):
r = requests.get(_CDN_BASE + path, headers={'X-Report-Key': _KEY})
return r.json()이미 저장소를 쓴다고 본 그 데이터도 CDN에서 받아 오기만 하고 있었고 쓰기는 여전히 컨테이너 로컬 파일이었다. 재배포마다 휘발되는 바로 그 자리였다.
저장소에 파일을 올린 주체
저장소에 실제 파일이 있는 것은 맞아서 누가 올렸는지를 따로 확인했다. 일배치가 올리는 것과 사람이 수동으로 올린 것이 섞여 있었다.
서비스 코드가 올린 것이 아니었고 내가 기존 패턴이라고 본 것은 다른 프로세스의 일이었다. 파일의 존재가 그것을 만든 주체를 말해 주지 않는다는 것이 이 확인의 요지다.
신규 쓰기 경로의 네 조각
가정이 뒤집히면서 작업 성격이 기존 코드 복사에서 신규 구현으로 바뀌었다. 무엇이 필요한지 정리하니 넷이 나왔다.
클라이언트 쓰기 호출을 넣어야 하고 의존성이 없으면 그것부터 추가해야 한다. 실행 역할에 쓰기 권한이 없어서 권한을 붙여야 하고, 버킷 정책이 현재 읽기만 허용하며 CDN 출처 제한이 걸려 있어서 정책도 바꿔야 한다. CDN이 앞에 있으니 올려도 바로 안 보이므로 캐시 무효화까지 필요했다.
정적 검증에 안 걸리는 실패
넷을 정리하고 나니 작업 성격이 코드 변경 한 건에서 코드와 권한과 정책과 캐시 운영으로 한 단계 무거워졌다. 규모가 다르므로 일정도 다시 잡아야 했다.
권한과 정책을 빠뜨리면 배포 후 런타임에서만 실패한다는 점이 특히 걸렸다. 코드 리뷰를 통과하고 로컬에는 권한이 있어서 테스트도 통과하며 배포까지 되고 나서 첫 쓰기에서 권한 오류가 난다. 정적 검증으로 안 잡히는 유형이므로 코드 리뷰만으로는 이 누락을 못 거른다.
전부 새로 짜야 하는 것은 아니어서 읽기는 기존 패턴 재사용이 된다고 나눠 적었다. CDN 경유 읽기 함수가 이미 있으므로 그것을 그대로 쓴다.
남의 선택을 설명한 제약
정리하다 보니 같은 영역에서 다른 사람이 그 개념을 통째로 제거하는 방향으로 간 커밋이 이해됐다. 처음에는 왜 없애는지 의아했는데 이 쓰기 경로 부재로 설명이 됐다.
영속화하려면 넷이 필요하고 그것이 무거우니 기능 자체를 없애는 편이 낫다고 판단했을 수 있다. 남의 선택이 이상해 보이면 내가 모르는 제약이 있는 경우가 많다.
조사 방법으로는 둘을 썼다. 로컬 체크아웃이 아니라 배포 중인 리비전의 파일을 직접 검색했고 코드에서 안 보이는 권한과 정책은 인프라 기록과 교차 확인했다. 코드만 보면 권한과 정책과 캐시가 안 보이는데 그것은 코드에 없기 때문이다.
정리
- 기존 패턴 재사용이라고 가정하기 전에 그 패턴이 실재하는지 검색한다
- 읽기는 있고 쓰기는 아예 없을 수 있다
- 저장소에 파일이 있다고 그 서비스가 올린 것이 아니다
- 신규 쓰기 경로는 코드와 권한과 정책과 캐시가 같이 간다
- 권한과 정책을 빠뜨리면 배포 후 런타임에서만 실패한다
- 읽기 재사용과 쓰기 신규를 나눠 적는다
- 남의 선택이 이상해 보이면 내가 모르는 제약이 있을 수 있다
- 코드에 없다는 것이 필요 없다는 뜻은 아니다