모든 글 · 25쪽
전체 글 305편 중 289–300번째 글이다. 최신 글이 앞에 있다.
25쪽 글 목록
305편 중 289–300
고흐는 검은 물감 없이 밤을 그렸다
고흐는 검은 물감 하나 없이 밤의 카페 테라스를 그렸다. 아를의 침실이 삐뚤어 보이는 것도 꼭 서툴러서는 아니었다. 그 방의 벽부터가 반듯하지 않았다.
밀레 「만종」의 감자 바구니는 아기 관이었을까
밀레의 만종에서 감자 바구니 자리에 원래 아기 관이 있었다는 이야기가 있다. 그 소문에 매달린 달리는 루브르에 엑스레이 촬영까지 요청했다. 정말 관이었을까?
고흐는 「별이 빛나는 밤」을 실패작이라 여겼다
지금은 뉴욕 현대미술관에서 가장 붐비는 그림인데, 고흐는 별이 빛나는 밤을 실패작으로 여겼다. 누구나 아는 명화일수록 이런 뒷사정이 하나씩 붙어 있다.
1초짜리 ALTER TABLE 이 서비스를 몇 분 세웠다
1초면 끝나는 컬럼 추가 마이그레이션을 돌렸는데 서비스 전체가 몇 분간 멈췄다. 마이그레이션은 시작도 못 한 상태였다. 락을 기다리는 줄 뒤에 평범한 조회까지 서 있었다.
타임아웃을 안 걸었다면 무한대로 건 것이다
외부 API 가 에러도 없이 응답만 안 주자, 우리 서버 스레드가 하나씩 묶이더니 몇 분 만에 서비스가 멈췄다. CPU 는 한가했다. 스레드는 전부 잠들어 있었다.
다른 상품을 샀는데 왜 서로 기다릴까, SELECT FOR UPDATE
재고를 잠그는 쿼리가 개발 DB 에선 멀쩡했다. 그런데 프로모션 날 주문 API 가 통째로 멈췄다. 서로 다른 상품을 산 사람끼리 줄을 서고 있었다.
DB 는 몇 초 만에 살아났는데 서비스는 왜 계속 죽어 있을까
DB 가 몇 초 느려졌을 뿐인데 서비스가 무너졌고, 원인이 사라진 뒤에도 회복이 안 됐다. 범인은 「실패하면 세 번 재시도」라는 지극히 상식적인 설정이었다.
100페이지만 가면 타임아웃, OFFSET 페이지네이션
목록 1페이지는 10ms 인데 100페이지쯤 가면 타임아웃이 난다. 그 깊이까지 넘기는 건 사람이 아니라 크롤러다. OFFSET 은 건너뛰는 척하면서 사실 다 읽고 있다.
운영에서만 느린 목록 API, 범인은 ORM N+1
목록 API 가 로컬에선 50ms 인데 운영에선 1.5초가 걸렸다. 느린 쿼리는 하나도 없었다. 범인은 쿼리 하나가 아니라 101번이라는 개수였다.
MySQL 의 utf8 은 UTF-8 이 아니다
닉네임에 이모지를 넣었더니 500 에러가 났다. 인코딩은 분명 utf8 로 맞췄는데도. MySQL 의 utf8 은 이름만 UTF-8 이고, 문자 하나에 3바이트까지만 담는다.
인덱스를 걸었는데 LIKE '%검색어%' 가 느리다
검색을 LIKE '%키워드%' 로 만들었더니 데이터가 늘면서 몇 초씩 걸렸다. 인덱스를 걸어 뒀는데도. 앞이 열린 패턴 앞에서는 B-tree 가 손쓸 방법이 없다.
한 번 눌렀는데 두 번 결제됐다면, 멱등성
사용자는 결제 버튼을 한 번 눌렀는데 청구는 두 번 나갔다. 응답을 못 받았다고 다시 보낸 게 원인이었다. 그런데 보낸 쪽은 처리가 됐는지 안 됐는지 알 길이 없다.
조건에 맞는 글이 없다. 브루니가 숨었나 보다.