장애처리 회고

Verser·2023년 10월 23일
0

회고록

목록 보기
1/1

이번에 런칭한 앱에서 오픈 이벤트를 진행하면서 발생한 문제와 나름의 해결과정을 되새기면서 개인프로젝트가 아닌 운영중인 실제 프로젝트이기에 소스코드나 에러로그등은 못남기는데 아쉽지만 장애처리한 경험을 기록

1. 이벤트 시작과 홍보

앱 런칭이후 오픈기념 이벤트를 활성화했지만 해가 떠 있던 낮시간대에는 홍보가 덜 되었는지 사용량이 적었다.
오후 퇴근시간 즈음 부터 이벤트 뉴스가 공개된 이후, 오후 4시경부터 문제가 시작되었다.
갑자기 회원가입하는 사용자와 로그인을 시도하는 사용자가 한번에 몰리다 보니, 여기저기서 앱 접속이 안된다는 신고가 많이 되고있었고
그 중 회원가입이 안된다는 신고가 가장 많았다, 회원가입이 불가능한 부분에 대해서는 긴급 수정으로 패치를 했지만
error.log를 확인하면서 SMS인증실패 로그와 Hikari에서 발생된 connection time out 3000ms로그가 가장 많았고, 회원가입프로세스 이후의 에러로그는 딱히 안보이던 상황 장애상황에서는 더 이상 이벤트 운영이 불가하다고 판단되어 어쩔 수 없이 이벤트를 긴급 종료후 추후에 재오픈하기로 했다.

원인 파악
앱 오픈 초기라서 안정화 기간이기에 로그를 많이 쌓고있어서도 그렇긴 하지만 장애상황에서발생된 로그만 40기가 가량되었음, 40기가 가량되는 로그 파일을 txt로 열 수도 없고, 리눅스 vim에서 열 수도 없어서, 툴의 힘을 필려 파일들을 1기가씩 잘라서 저장시켰음
에러 로그를 확인해 보니, 일부 query에서 비정상적이게 시간이 오래걸린 쿼리가 몇 가지 보였고, Hikari에서 발생한 connection time out 로그가 주기적으로 등장했다.(회원가입 프로세스 도중 발생한 에러로그에 대해서는 초기에 대응했기에 제외)
확인된 query는 특정 테이블을 리스트로 불러오면서 where조건과 서브쿼리로 작성된 부분에 밖에 특이사항이 없었음.

문제 해결 과정

  1. Hikari의 connection 증설
  • 서버에서는 연결 시간을 8시간으로 설정하고 있었으나, DB는 만료시간이 5분 설정되어있었음. 이 부분 때문에 DB의 자원을 많이 소모했고 연결이 부족하고 로그인 및 회원가입과 같은 API에서 자원을 많이 소모했음.
  • 우선적으로 Hikari의 connection 수를 150으로 늘리고 이에 맞춰 서버 사양을 업그레이드했지만. 임시적인 조치일 뿐 근본적인 원인이 해결되지않아 문제가 재발생
  • Hikari에서 Local로 설정된 maximum-connection은 10이었고, DB 쪽에서는 200으로 설정되어 있었음.
  • Hikari에서 설정한 wait-connection-timeout은 8시간이었으나, DB에서 설정한 wait-connection-timeout는 5분으로 설정되어 있었습니다. 이 문제에 대한 해결 방안을 DBA얘기를 해봤을 때 같은 서버에 여러 서비스가 물려있어 DB의 설정을 변경하기에는 다른 부분에서 영향이 있을 것 같아 DB의 설정을 변경하지 않고 Hikari에서 세션으로 wait-connection을 제어하는 방법으로 설정을 변경.
  1. 쿼리 성능 개선
  • 회원가입, 로그인 관련된 쿼리에서는 한 테이블에 update문이 많아서
    안그래도 오래걸리는 업데이트문 더 오래 걸렸음 select하고 비교하고 업데이트 하고 했던 로직을 -> 마지막 부분에 한번에 업데이트 하는 쿼리로 개선, where가 많이 걸리는 조건 부분에 인덱스 추가

  • 리스트를 불러오는 select문에서 몇 개 테이블을 조인하면서 가져오는데 unique조건이 걸려있지 않아서 인덱싱이 필요한 컬럼을 발견 이를 해결하기 위해 인덱스를 추가하고 쿼리 로직을 개선
    인덱스 쿼리 3개의 쿼리중 한개만 :

create index user_id_idx_01 ON video_watch (use_id);

결과
쿼리의 수행시간에서는 숫자가 눈에 띄게 많이 감소했음. 8000ms, 4000ms가 걸리던 API에 대해서는 1000ms
Hikari maximum-connection을 늘리고, connection-timeout의 허용시간을 늘린 후
위의 변경 사항을 적용한 후, 이벤트를 다시 오픈했고,모니터링을 했을 때 DB의 자원 사용량은 눈에띄게 감소했고, 전일과 비교해 회원 수가 증가폭이 2배 정도 더 많았지만 자원 사용률이 DB : 800%-> 200%대, API서버 : 600% -> 100%대로 많이 좋아졌다.

-결론-
앱 오픈하면서 2주동안 안정화한다고 업데이트하고, 에디터도 없는 vim으로 소스코드랑 에러코드 분석한다고 눈알빠지고 똥빠지는 줄 암
GPT한테 시켜서 문장이 좀 잘 다듬어 졌나 싶더니 왠 되도않는 문장이 많아서 처음부터 다시 쓴 느낌
그래도 희열을 느꼈고, 너무나 많은걸 배웠다.

profile
Backend

0개의 댓글