모든 글 · 14쪽
전체 글 305편 중 157–168번째 글이다. 최신 글이 앞에 있다.
14쪽 글 목록
305편 중 157–168
트래픽이 세 배로 몰리면 일부는 빨리 거절해야 한다
트래픽이 세 배로 몰리자 서버는 살아 있는데 응답이 30초를 넘었다. 사용자는 이미 떠났는데 서버는 그 요청을 성실히 처리하고 있었다. 아무도 기다리지 않는 응답을 만드는 중이었다.
알림도 안 울린 장애, 범인은 로그만 찍는 catch
장애가 났는데 알림도 안 울리고 에러율 그래프도 평평했다. 몇 시간 뒤 사용자 문의로 알았다. 예외를 잡아 경고 로그만 남기는 코드 한 군데가 장애를 통째로 가리고 있었다.
DB 엔 있는 주문이 검색엔 없다, 아웃박스 패턴
DB 에는 있는 주문이 검색에는 안 나오는데 에러 로그는 깨끗했다. 두 곳에 따로 쓰면 언젠가 어긋난다. 그리고 그 어긋남은 아무 신호 없이 쌓인다.
정규식 한 줄에 CPU 가 100% 로 붙었다
이메일 형식을 확인하는 평범한 정규식 하나에 서버 CPU 가 100% 로 붙었다. 문자열 하나 검사하는 데 몇 분이 걸렸다. 정규식이 느린 게 아니라 패턴과 입력이 잘못 만난 거였다.
AWS 2017년 스토리지 장애, 명령 하나가 4시간이 됐다
2017년 AWS 스토리지 서비스가 약 4시간 멈추자 인터넷의 상당 부분이 함께 멈췄다. 시작은 잘못 입력한 명령 하나였다. 그런데 진짜 문제는 사람보다 구조 쪽에 있었다.
GitHub 의 43초 네트워크 단절은 왜 24시간 장애가 됐나
2018년 GitHub 은 데이터센터 사이 네트워크가 43초 끊긴 일로 24시간 넘게 정상이 아니었다. 원인은 1분도 안 돼 사라졌다. 나머지 시간은 판단과 검증에 들어갔다.
타임아웃을 걸었는데도 서비스 전체가 느려진다면
타임아웃을 걸어 뒀는데도 의존 서비스 하나가 느려지자 서비스 전체가 느려졌다. 실패할 걸 알면서 계속 기다리고 있었으니까. 그 고리를 끊는 게 서킷 브레이커다.
평균 응답 시간은 120ms 인데 왜 느리다고 할까
대시보드 평균 응답 시간은 120ms 인데 느리다는 문의가 계속 온다. 로그를 뒤지면 5초, 10초짜리 요청이 하루 수만 건 숨어 있다. 평균은 그 꼬리를 뭉개 버린다.
CDN 을 붙였더니 남의 이름이 보인다
CDN 을 붙였더니 내 계정에 다른 사람 이름이 보인다는 문의가 들어왔다. 에러는 한 줄도 없고 지표는 오히려 좋아졌다. 캐시는 주소만 보고 사람은 안 본다.
카프카 컨슈머가 리밸런싱만 반복한다, max.poll.interval.ms
카프카 컨슈머가 일하는 시간보다 파티션을 다시 나누는 시간이 더 길어질 때가 있다. 컨슈머를 늘려도 그대로다. 살아 있는 컨슈머가 처리 시간 때문에 죽은 걸로 판정받고 있어서다.
파는 건 설득이 아니라 이해다
파는 걸 못한다고 말하는 사람들 얘기를 들어 보면 대개 같은 그림을 떠올린다. 말을 잘해서 관심 없는 사람을 넘어오게 만드는 것. 그게 부담스럽고, 나랑 안 맞고, 그래서 못하겠다고 느낀다.
사람은 제품이 아니라 변화를 산다
드릴을 사는 사람이 원하는 건 드릴이 아니라 벽에 뚫린 구멍이다. 더 정확히는 그 구멍에 걸 선반이고, 그 선반이 만들어 줄 정돈된 방이다. 오래된 얘기지만 만드는 사람이 가장 자주 잊는 얘기이기도 하다.
조건에 맞는 글이 없다. 브루니가 숨었나 보다.