새 회사에서 Redis 를 다른 서비스와 공유해 쓰게 되어 데이터베이스 번호로 공간을 분리해야 했다. 워커의 config.yml 에 redis.database: 3 을 넣고 띄웠다.
Table of contents
Open Table of contents
배경 — 넣었는데 아무 일도 안 일어났다
오류도 경고도 없이 정상으로 기동했다. 그런데 INFO keyspace 로 확인해 보니 db3 이 없었고 db0 에 그대로 쓰고 있었다.
파싱은 되는데 어디서도 읽지 않는 키였다. 읽히지 않는다는 사실을 알려 주는 신호가 아무 데도 없었다.
원인 — 이름이 비슷한 세 키
워커의 문서와 소스를 뒤지니 비슷한 키가 셋이었다. 내가 쓴 redis.database 는 조용히 무시되고 옛 이름 redis.index 는 동작하되 폐기 경고가 나오고 redis.db 가 현재 방식이었다.
옛 이름으로 넣었을 때 동작하니까 거기서 멈출 뻔했다. 경고가 나온 덕분에 더 봤고 그것이 없었으면 그대로 썼을 것이다.
막힌 지점 — 조용한 무시와 정상의 구분
셋을 나란히 놓으니 조용히 무시되는 것과 정상인 것이 겉으로 같았다. 둘 다 오류도 경고도 없고 기동도 정상이다.
그런데 하나는 되고 하나는 안 된다. 경고가 없다는 것이 맞다는 뜻이 아니었고 오히려 폐기 경고가 나오는 쪽이 신호가 있어서 나았다.
주의 — 오설정이 남기는 오염
무시된 채로 뒀으면 db0 에 쓰게 되는데 거기에는 다른 서비스의 데이터가 있다. Redis 공식 문서대로 새 연결은 언제나 0번을 쓴다. 데이터베이스는 이름이 같은 키를 따로 가질 수 있는 이름 공간이며 FLUSHDB 는 그 하나에만 걸린다. 키 이름이 겹치면 덮어쓰고 안 겹쳐도 그쪽의 FLUSHDB 에 우리 데이터가 함께 지워진다.
우리 쪽에서만 조용한 것이 아니라 남의 데이터까지 건드리는 결과가 된다. 조용한 오설정의 피해는 설정한 쪽이 아니라 옆에서 나타난다.
조치 — 관대한 파서와 확인 절차
설정 스키마가 모르는 키를 거부하게 되어 있으면 넣는 순간 알 수 있다. 관대한 파서가 조용한 실패를 만드는 구조였다. 파서를 엄격하게 고치는 대신 확인 절차를 두는 쪽을 골랐다. 이유는 그 워커가 남의 코드라 고치면 다음 판을 받을 때 다시 갈라져서다. 대신 설정을 바꿀 때마다 손으로 확인하는 단계가 하나 느는 것을 감수했다.
그래서 설정을 넣었으면 그것이 실제로 반영됐는지를 직접 조회해 보는 것을 절차로 뒀다. 이 경우에는 SELECT 3 뒤에 DBSIZE 로 채워지는지 보면 되는 것이었고 로그가 조용하다는 것을 근거로 삼지 않았다.
정리
- 같은 목적의 설정 키가 여럿이고 동작이 다를 수 있다
- 조용히 무시되는 키는 정상인 경우와 겉으로 같다
- 경고가 없다는 것은 맞다는 뜻이 아니다
- 폐기 경고가 있는 쪽이 오히려 신호가 있어 낫다
- 조용한 오설정의 피해는 옆에서 나타난다
- 설정을 넣었으면 반영됐는지 직접 조회한다
- 로그가 조용하다는 것을 근거로 삼지 않는다
- 관대한 파서가 조용한 실패를 만든다