Will Of Rough

개요목록 화면은 어디에나 있고, 페이징은 페이지 번호에 20을 곱해서 넘기면 끝이라고 생각했었다. 사실 관리자 화면 마지막 페이지가 왜 10초씩 걸리는지, 발송 배치가 왜 절반만 나가고 멀쩡히 끝나는지 한동안 원인을 못 찾았는데, 두 문제의 뿌리가 같은 한 단어 — 건너뛴 장도 읽는다 — 라는걸 알게되었다. 가끔씩 페이징 글을 보면 OFFSET 은 느리니 커서를 쓰라고 하고 끝~인 경우가 많아, 왜 느리고 왜 빠지는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 오프셋과 커서 페이징을 비교해보려고한다. 오프셋 페이징 — 건너뛰는 게 아니라 읽고 버린다두꺼운 책의 3,001번째 장을 보고 싶은데 이 책에는 쪽수가 인쇄되어 있지 않다고 해봅시다. 사서가 할 수 있는 일은 하나, 첫 장부터 한 장씩 넘기면서 세..

개요DB 가 잠깐 죽었다 살아났는데 서버는 30분 넘게 돌아오지 않은 적이 있다. 처음엔 쿼리 타임아웃을 걸어 뒀으니 당연히 몇 초 뒤 끊길 줄 알았지만, 스레드 덤프를 뜨니 전부 DB 응답을 기다리며 멈춰 있었다. 파다 보니 타임아웃이 한 개가 아니라 세 겹이고 — 그중 실제로 전화를 끊을 수 있는 시계는 하나뿐 — 이라는걸 알게되었다. 가끔씩 타임아웃 글을 보면 옵션 이름 나열하고 끝~인 경우가 많아, 어느 시계가 무엇을 재는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 소켓·쿼리·트랜잭션 세 시계를 전화 한 통으로 공부해보려고한다.소켓 타임아웃 — 침묵을 얼마나 참을 것인가고객센터에 전화를 걸었다. 상담원이 "잠시만요, 확인해 드릴게요" 하고는 말이 없다. 1분, 5분, 10분이 지나도 소리 하나 ..

개요회사에서 알림 서버를 새로 만들게 되면서 저장소를 NoSQL 로 할지 RDB 로 할지 골라야 했다. 처음엔 알림은 한 건씩 쌓이는 쪽지니까 당연히 NoSQL 아닌가? 싶었는데, 파보니 — 어떤 DB 냐보다 알림을 어떤 모양으로 담고 어떻게 버리느냐가 먼저 — 라는걸 알게되었다. 가끔씩 둘을 비교한 글을 보면 장단점 표 하나 놓고 끝~인 경우가 많아 늘 아쉬운 부분이었다. 그렇기에 이번글은 알림 서버라는 한 장면에서 두 방식이 어떻게 다른지 공부해보려고한다.담는 모양 — 복사해서 나눠 줄까, 한 장 붙이고 표시만 받을까아파트 관리사무소가 "금요일 엘리베이터 점검" 공지를 세 집에 알린다고 해 보겠습니다. 하나는 공지를 세 장 복사해 집집마다 우편함에 넣는 방법이고, 다른 하나는 게시판에 한 장만 붙이고..

개요배포할 때 테이블도 같이 바꾸는 일은 늘 있다. 처음엔 마이그레이션 파일에 ALTER 한 줄 넣고 배포 버튼 누르면 끝 아닌가? 싶었지만, 배포 중에는 옛 코드와 새 코드가 같은 테이블을 동시에 보는 시간이 반드시 생기고 그 몇 분이 장애의 대부분이라는걸 — 바꾸지 말고 옆에 추가하고, 기다리지 말고 포기해라 — 알게되었다. 가끔씩 Flyway 글을 보면 파일 이름 규칙 설명하고 끝~인 경우가 많아, 운영 중인 테이블을 어떻게 고치는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 무중단 스키마 변경을 공부해보려고한다.롤링 배포 — 옛 사서와 새 사서가 같은 대장을 본다도서관 대출대장 한 권을 사서 셋이 함께 쓴다고 해 봅시다. 대장 서식을 바꾸기로 했는데, 사서는 한 번에 한 명씩만 교대합니다. 그러니..

개요결제 버튼을 만들면서 재시도는 보내는 쪽이 알아서 하는 거라고 생각했었다. 처음엔 응답이 안 오면 그냥 한 번 더 보내면 되는거 아닌가? 싶었지만, 응답을 못 받았다는 건 실패했다는 뜻이 아니라 성공했는지 실패했는지 모른다는 뜻이고 그 상태에서 다시 보내면 결제가 두 번 나갈 수 있다는걸 알게되었다. 그러니까 — 다시 보내는 건 손님이지만, 한 번만 일어나게 하는 건 가게의 기억이다 — 라는게 이 글의 축이다. 가끔씩 멱등성 글을 보면 "요청에 키를 붙이고 저장하면 끝~"인 경우가 많아, 같은 키에 다른 내용이 오면 어떻게 되는지, 만드는 도중에 다시 오면 어떻게 되는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 멱등성 키를 분식집 전화 주문과 장부 이야기로 공부해보려고한다.재시도 — 응답이 없다는 ..

개요운영 서버를 컨테이너로 옮긴 다음 날, 주문 시각이 전부 9시간씩 밀려 있었다. 처음엔 DB 가 이상한가? 싶었지만 코드도 DB 도 그대로였고, 바뀐 건 서버가 보는 시계 하나였다는걸 알게되었다 — 시간은 하나인데 그걸 읽는 시계가 셋(프로그램·통역사·서랍) 이라는 얘기였다. 가끔씩 시간대 글을 보면 설정 한 줄 넣고 끝~인 경우가 많아, 왜 밀리는지는 늘 아쉬운 부분이었다. 그렇기에 이번글은 시각과 시계를 구분하는 것부터 시작해서, 시간 값이 프로그램에서 DB 까지 가는 길을 따라가보려고한다.시각과 벽시계 — 순간은 하나, 시계는 도시마다 다르다런던으로 출장 간 동료가 "내일 3시에 통화하자" 고 메시지를 보냈다. 서울의 3시인지 런던의 3시인지 묻지 않으면 둘 중 하나는 빈 전화기 앞에 앉아 있게..

개요서버가 느려졌다는 말을 들으면 보통 로그를 먼저 뒤지고, 그걸로 안 되면 스레드 덤프를 몇 장 뜬다. 사실 프로파일러라는건 로컬에서 IntelliJ 에 붙여서 돌려보는 개발용 도구 정도로만 이해하고 있었다, 운영 서버에 붙이면 느려질게 뻔하고 어차피 장애는 재현이 안 되는데 뭘 재냐 싶기도 했고 스레드 덤프를 시간차로 몇 장 뜨면 어디서 멈춰있는지 대충 보이니까 그걸로 충분하다 싶었다. 하지만 JDK 안에는 이미 상시로 켜 두라고 만든 기록 장치가 들어있고, 그 기록의 절반은 "지금 어느 코드가 돌고 있는지 주기적으로 찍은 사진" 이며 — 그 사진을 어떤 시계로 언제 찍느냐가 답을 바꾼다 — 는걸 알게되었다. 가끔씩 JFR 글을 보면 옵션 나열하고 JMC(JDK Mission Control, JFR ..

개요Spring Boot 4 로 올리고 나서 IDE 에 노란 밑줄이 갑자기 늘었다. 처음에는 Spring 이 자기네 @Nullable 을 JSpecify 라는 걸로 갈아탄 것 정도로만 이해하고, import 만 바꿔주면 끝 아닌가? 싶었지만, Object @Nullable [] 처럼 대괄호 앞에 붙은 어노테이션을 보고 나서야 이게 단순한 라이브러리 교체가 아니라 — null 을 값이 아니라 타입의 일부로 취급하기 시작했다 — 라는걸 알게되었다. 사실 자바를 오래 쓰면서 null 체크는 습관의 문제 정도로 생각했고, 어노테이션은 컴파일러가 봐주지도 않는 문서 대용인데 굳이 붙일 이유가 있나 싶었다, 그런데 Spring 팀이 프레임워크 전체 코드에 이걸 붙이고 빌드에서 검사까지 돌린다는 걸 보니 뭔가 내가 ..