두 달 동안 관찰 모드로 돌려둔 기능이 있었다. 실제 차단은 하지 않고 “차단했을 것"만 로그로 남기는 방식이었다. 전환 시점이 되어 로그를 확인했더니 관련 로그가 한 줄도 없었다. 처음 든 생각은 “오탐이 0이구나, 안전하게 켜도 되겠다"였다. 다행히 켜기 전에 한 번 더 봤는데, 실제로는 오탐이 0이 아니라 관찰 결과가 한 시간 이상 남지 않는 상태였다. 로그를 매시간 비우는 크론이 따로 돌고 있었던 것이다. 두 달치 관찰을 했다고 믿었지만 실제로 본 것은 직전 몇십 분이었다. 그 뒤로 비슷한 유형을 몇 번 더 밟았고, 공통점이 있어서 정리해둔다. 전부 관찰 결과가 관찰 대상보다 먼저 사라지는 문제다. ...
배포 전에 지우는 로그 console.log를 잔뜩 박아두고 배포 직전에 전부 지워본 적이 있다면, 그건 로깅이 아니라 디버깅이다. 둘은 목적이 다른 별개의 활동이다. 디버깅 로깅 수명 일시적 영구적 시점 개발 중 운영 중에 더 중요 독자 사람 사람 + 기계 형식 자유 구조화 배포 시 삭제 남는다 운영에서의 로깅은 이런 요구를 만족시켜야 한다. 6개월 뒤에 누군가가 어제 새벽 2시에 무슨 일이 있었는지 검색할 수 있게 만드는 것. 그러려면 형식이 있어야 하고, 검색 가능해야 하고, 보관돼야 한다. 이 세 조건을 하나씩 짚어보려 한다. ...
1. Disk 영역 PostgreSQL의 저장 영역은 크게 Heap, Index, Toast 3개로 나뉜다. 각 테이블의 대부분의 데이터를 메인 heap 영역에 저장한고, 테이블 칼럼 중 매우 큰 데이터를 받을 수 있는 칼럼은 TOAST 영역에 별도 저장한다. TOAST 테이블에는 실제 데이터를 저장하고, 본래 테이블에는 해당 데이터를 가리키는 포인터만 남게 된다. TOAST 테이블의 유효한 인덱스는 1개뿐이고, 기준 테이블에는 더 많은 인덱스가 존재할 수 있다. 테이블과 인덱스는 각각의 디스크파일에 저장 되며 각 파일이 1G가 넘으면 별도 파일로 분리된다. ...
연초에 파일럿을 열었다. 처음 만든 결과물이라 만족스러웠는데, 열고 나서 며칠 지나니 다른 게 걸리기 시작했다. 사용자가 얼마나 들어오는지 볼 수가 없었다. 장애가 나도 알 방법이 없었다. 누가 알려주기 전까지는 몰랐다. 다음 버전을 그대로 시작할 뻔했다 파일럿 피드백을 받아서 기획팀은 2.0 준비에 들어갔고, 나도 자연스럽게 개발 계획을 잡기 시작했다. 그러다 멈췄다. 지금 이대로 기능을 더 얹는 게 의미가 있나 싶었다. 기능이 열 개에서 스무 개가 되면 확인해야 할 것도 두 배가 되는데, 확인할 방법 자체가 없는 상태다. 대량 데이터 파이프라인은 하루에도 몇 번씩 직접 들어가서 눈으로 봐야 했다. 그 방식으로 규모를 두 배로 만들면 어떻게 되는지는 뻔했다. ...