티스토리 뷰
안녕하세요 VI Engineering 팀 김윤제입니다.
Gmarket Mobile Web Vip(View Item Page = 상품 상세)를 담당하고 있는 Backend Engineer 입니다.
이번 블로그는 개발자를 잠 못 들게 만드는 코드 (잠 못 드는 밤 Feat: 내 전화를 받아 by Noc) 편입니다.
Noc란 지마켓에서 관제 시스템 쪽에 근무하시는 분들입니다. (항상 감사합니다.)
저는 지마켓에서 실시간 트래픽을 맞으며 결제 지표에 영향을 주는 도메인을 맡고 있어서 장애와 아주 가까이에 있습니다.
그렇기 때문에 관제 시스템 측으로부터 연락을 많이 받습니다.
심지어 장난으로 저의 별명은 인간 SWAT이며 개인 프로필 사진입니다.
과연 어떤 코드가 개발자를 잠 못 들게 만드는지 알아보도록 하겠습니다.
try-catch 무시
// catch를 비워두면 예외는 무시된다.
public Result getItem() {
try {
}
catch(Exception ex) {
// 아무일도 하지 않는다.
}
}
이거 어디서 많이 본 코드 일 것입니다.
Java 개발자라면 이펙티브 자바를 읽어 보신 분들이 많을 것입니다.
혹시 77장 기억하실까요? 네 맞습니다.
바로 'catch 블록을 비워두지 말자'입니다
예외는 문제 상황에 대처하기 위해 존재하는데 catch 블록을 비워두면 예외가 존재할 이유가 사라집니다.
비유하자면 화재경보를 무시하는 수준이 아니라 아예 꺼버려, 다른 누구도 화재가 발생했는지 모르게 하는 것과 같습니다.
이러한 상황은 끔찍한 참사로 이어질 수 있으니 예외를 무시해야 하는 상황이 아니라면 catch 블록은 비워두지 말아야 합니다.
대규모 트래픽 환경에서 API Timeout
public Result getItem() {
try {
result = ApiHelper.CallAPI<Result>(
"GET",
ApiHelper.MakeUrl("v1/api/getItem"),
5000
);
}
catch(Exception ex) {
logger.error(ex.getMessage());
}
}
VIP(View Item Page)는 상품 상세 페이지를 고객에게 빠르게 보여줘야 하는 도메인입니다.
느리게 보여줄수록 고객이 떠나갈 확률은 점점 높아집니다.
트래픽이 문제가 없어서 현재처럼 Timeout이 5초가 설정되었을 때는, 해당 API를 처리해 주는 곳에서
아무 이슈 없이 빠르게 응답을 줄 수 있습니다.
문제는, 트래픽이 집중될 때입니다.
VIP(View Item Page) 도메인 특성상 봇들이 많이 유입이 될 때 트래픽 상승으로 인하여 API 호출이 자연스럽게 많아지면
해당 API를 처리해 주는 곳에서 트래픽 부하에 따른 지연이 발생 한다는 점입니다.
그렇다면 점점 고객에게는 상품 상세 페이지를 느리게 보여준다는 큰 문제가 발생합니다.
상품 상세 페이지가 2초만 넘어서도 고객의 이탈률은 높아집니다.
ex)
API를 처리해주는 곳에서 5초에 응답을 주면 catch에 걸리지 않고 정상 응답으로 처리되기 때문에 고객은 5초를 더 기다려야 함
API를 처리해 주는 곳에서 6초에 응답을 주면 catch에 걸리게 되고 잘못된 응답으로 처리되기 때문에 고객은 6초를 기다려놓고 상품 정보도 못 보는 상황
결과 => 고객 이탈 => 매출 하락 => Noc 전화 => 긴급 Conferrence Call
오늘 너의 잠은 여기 까지야!!
정말 최악의 케이스는 이런 상황입니다.
public Result getItem() {
try {
result = ApiHelper.CallAPI<Result>(
"GET",
ApiHelper.MakeUrl("v1/api/getItem),
5000
);
}
catch(Exception ex) {
// 아무일도 하지 않는다.
}
}
만약 위와 같은 코드가 존재한다면 어떤 상황이 발생이 발생할 지를 상상해 봅시다.
네 트래픽이 없으면 문제가 되지 않을 수도 있습니다.
그런데 고객이 들어옵니다. 봇도 들어옵니다.
트래픽이 상승합니다.
API 응답속도가 느려집니다.
네트워크 지연이 발생해요.
고객은 떠나갑니다.
또한 다음과 같은 일이 벌어집니다.
바로 NOC에게 전화가 옵니다. (Feat: 고요한 새벽 0시 30분)
이제는 swatop의 전화를 받으면 바로 윤제님이라고 시작합니다. (친해진 것 같다)
핸드폰 전화번호 기록엔 NOC밖에 없습니다.
이 글을 쓰며 다시 한번 눈물을 흘립니다.
응답 그래프를 보니 딱 봐도 api지연이 발생한 것 같습니다.
원래 장애가 나면 주황색의 짙은 표시가 발생합니다.
헌데 파란색 아닌가? 이것은 네트워크 지연입니다.
왜냐하면? 저는 수많은 시간 동안 평일 주말 밤 낮 없이 모니터링을 함으로써 이것을 체득했기 때문입니다.
관심법으로 보아하니 이제는 장애 전화만 와도 무엇이 문제인지 알 것 같습니다. (궁예가 된 기분..)
but 로그가 무시가 되어서 장애를 기록하는 DB에 검색 시 깨끗합니다. (만약 타임아웃이 2초로 설정되어 있었다면 엄청나게 타임아웃 로그가 올라와야 정상입니다.)
원인을 찾을 수가 없습니다. (지옥의 고통)
로그가 안 남으니 원인이 무엇인지 파악이 힘듭니다.
저는 잠을 잘 수가 없습니다.
이때부터 탐정이 됩니다
- 코드의 문제인가? (가장 유력 후보)
- 위에서 응답 그래프로 네트워크 지연으로 보였을 때 유력 후보로 떠올랐습니다.
- 최근 개발된 형상 또는 예전에 개발이 되었지만 로그가 없거나 타임아웃이 긴 코드를 전부 찾았습니다.
- 인프라의 문제인가?
- 혹시나 네트워크 문제는 아닐까?
구세주 등장
그렇습니다. 정확히 5초입니다.
위와 같은 코드는 대규모 트래픽 도메인에서 개발자를 잠 못 들게 만드는 아주 위험한 코드입니다.
끝으로
우선 위 코드는 제가 개발한 내용은 아닙니다.
(굉장히 오래전에 개발된 Legacy System이라 유물급 코드가 아직도 숨겨져 있습니다.)
아마 그때 당시에는 코드 리뷰 문화가 없었기 때문에 발견이 안되지 않았을까 싶습니다.
개발을 하다 보면 정말 자신도 모르게 놓치는 부분이 있습니다.
남에 눈엔 잘 보이는데 꼭 제눈엔 보이지 않는 경우가 있는 법이죠.
또한 자신이 만든 코드에 확신을 가지는 사람은 몇 없을 것이라고 생각이 듭니다.
저는 매일 개발을 하면서 제가 만든 코드에 대해서 이 코드는 괜찮은가?라는 불안감에 쌓여 살고 있습니다.
이 때문에 코드 리뷰 문화는 반드시 필요한 것 같습니다.
코드 리뷰 문화를 통해 내가 놓친 실수가 있다면 동료들의 도움으로 캐치해 내고
서로 좋은 피드백을 주며 성장해 나가는 것은 어떨까요?
긴 글 읽어주셔서 감사합니다.
'Backend' 카테고리의 다른 글
설계란 고민의 연속이다 2편 (1) | 2024.04.04 |
---|---|
설계란 고민의 연속이다 1편 (1) | 2024.03.14 |
쿠버네티스 오퍼레이터를 Golang으로 개발해보기 (5) | 2024.02.15 |
Gmarket Mobile Web Vip 레거시 성능 개선기 (0) | 2023.12.06 |
Kotlin에서 리스트 추출하기 : subList, slice, take, drop (0) | 2023.11.22 |