주요글: 도커 시작하기
반응형

[3부]에 이어서

 

4월 16일 목요일. 미디어는 온통 415 총선 얘기다. 충격적인 결과 때문인지 다양한 기사가 쏟아져 나온다. 온라인 개학도 본격적으로 시작했다. 학생들이 온라인 수업에 참여해서 그런지 오전 트래픽이 줄었다. 별일 없이 하루가 지나가고 있다.

오후 4시 40분. 평온함을 깨는 전화가 온다. 발신자를 보니 감이 온다. M사에 문제가 생겼나 보다. 아니나 다를까, M사 서비스에 장애가 났으니 내일 가서 지원하라는 지시가 내려왔다. 학교 선생님과 학생이 온라인 수업 보조 도구로 M사 서비스를 사용하는데 트래픽이 몰리면서 M사 서비스가 다운된 것이다. 온라인 개학이 시작되면서 EBS를 비롯해 여러 서비스가 먹통 됐는데 M사 서비스도 그중 하나였던 것이다.

일시 정지

4월 17일 금요일. 바로 M사로 출근했다. A클라우드의 관리형 DB 성능이 저하되면서 장애를 일으켰다고 한다. 성능 문제를 일으킨 건 게시글 내용과 관련이 있다. 내용 칼럼은 MySQL MEDIUM TEXT 타입인데 어떤 이유인지 내용 칼럼을 조회하면 급격히 응답 속도가 느려진다. 기능 특성상 첫 화면부터 게시글 목록에 내용을 보여주기 때문에 게시글 내용 성능 저하가 바로 서비스 먹통으로 연결된 것이다.

M사 인프라 조직은 이대로는 서비스를 할 수 없다고 판단하고 클라우드 DB를 빼기로 결정했다. 대신 비슷한 성능의 VM을 다수 생성해서 직접 마스터/슬레이브 DB를 구성한다고 한다. DB 변경 일정은 오후 7시부터 시작해서 4월 20일 새벽까지로 예정되어 있다.

 

이번 작업의 핵심은 마스터/슬레이브를 구성해서 처리 용량을 높이는 것이므로 이를 위한 코드 작업을 먼저 진행했다. 스프링을 사용하고 있지만 @Transactional을 사용하기 어려운 구조다. 그래서 필터를 선택했다. URL 경로에 따라 마스터나 슬레이브를 선택하도록 필터를 구현했다. 세 개 정도 경로를 넣고 확인해보니 잘 동작한다. 다음 작업으로 넘어가야겠다.

 
이어서 내용 칼럼만 조회하는 코드를 분리하기 시작했다. 내용만 캐시를 적용할 수 있는 구조로 만들기 위함이다. 앞서 게시글 조회 API를 개선해 놓지 않았으면 할 수 없는 작업이었다.

 

오후 7시가 되었다. 앱에는 작업 공지가 올라왔다. J 개발자와 난 하던 작업을 멈추고 J 개발자는 모든 서버를 내렸다. DB 사용이 없어지자 인프라 조직에서 클라우드 DB 데이터 덤프를 시작한다. 우리는 하던 작업을 이어서 진행했다. 내용 조회 코드 분리를 마치니 9시가 넘어간다. 나머지는 내일 진행해야겠다.

맑은 하늘

4월 18일 토요일. 판교에 도착하니 9시다. 스타벅스에 들려 커피를 마시고 있는데 J 개발자가 들어온다. J 개발자가 커피를 들고 자리에 오더니 불안한 표정으로 아직 DB 구성 작업이 끝나지 않았다고 말한다. 당연히 끝나 있을 거라 생각했는데 실패했다는 것이다. 이유가 궁금했다.

 

J 개발자와 사무실로 들어갔다. 얼마 지나지 않아 인프라 조직장이 왔다. 얘기를 들어 보니 관리형 DB에서 덤프 받는 속도가 매우 느렸다고 한다. 시간당 수십 메가 수준이었다고 한다. 어쩌면 게시글 내용 조회 속도가 느렸던 것도 관리형 DB의 IO 성능 문제가 아니었을까 하는 의심이 들기 시작한다.

 

DB 문제를 해결하는 동안 J 개발자와 난 게시글 내용을 캐시에 담는 코드를 구현했다. 게시글 쓰기, 수정, 조회 기능에 레디스 연동 코드를 추가했다. 얼추 잘 된다. 이어서 추천 게시글 목록에도 캐시를 적용했다. 추천 게시글 목록은 양도 크지 않고 변경도 없어 카페인 캐시를 사용했다. 불필요한 카운트 쿼리 때문에 간헐적으로 응답이 느린 코드도 손을 봤다. 게시글 조회 트래픽이 전체 서버 쓰레드를 점유하는 것을 막기 위해 동시 처리 개수를 제한하는 코드도 추가했다.

 

어느덧 5시. 저녁을 먹는 동안에도 인프라 조직은 DB 관련 통화를 하느라 바쁘다. DB 덤프 속도가 오후부터 빨라져서 곧 DB 구성을 할 수 있을 것 같다고 한다. 다행이다.

 

저녁을 먹고 옥상에 올라갔다. 3월엔 어둑어둑했는데 지금은 어둡지 않다. 하늘이 참 맑다. 토요일이 그렇게 지나갔다.

 

4월 19일 일요일. DB 구성이 잘 되었다고 한다. M사 직원들은 오전부터 운영 환경 테스트를 진행하고 있다. 난 이제 할 일이 없다. 부하 테스트를 진행해서 검증하고 싶지만 지금은 진행할 수 있는 사람이 없다. 불안하다. 그저 내일 트래픽을 잘 견뎠으면 하는 마음뿐이다.

태풍

4월 20일 월요일. 잠이 잘 안 와 일찍 깼다. 판교에 도착하니 7시 30분이다. 과연 잘 될까?

8시 15분. 서버가 출렁인다. 스카우터를 보니 레디스 연동에서 시간이 오래 걸린다. 젠장! 이것 때문에 게시글 목록 응답 시간이 느리다. 응답이 느려지자 동시 처리 개수 제한에 걸려 503 응답을 주기 시작했다. 아침부터 긴박하다.

 

잠시 후 J 개발자가 출근해서 급하게 레디스 연동을 제거하고 다시 배포했다. 레디스 설정을 쳐다볼 때가 아니다. 일단 살고 봐야 한다. 게시글 목록 조회는 돌아오기 시작했지만 여전히 느린 응답이 있다. 로그인하자마자 불리는 API에 풀스캔을 타는 쿼리가 있다. 뭐지? 쿼리를 보니까 조건이 빠져있다. 왜?

 

한참 만에 원인을 찾았다. 리플리케이션이 밀린 것이다. 그 망할 모듈 때문에 문제가 심해졌다. 리플리케이션이 밀리면 데이터가 안 나오면 그만인데 이 모듈은 where 절에서 조건이 빠진다. 그러면서 풀스캔이 발생한 것이다. 아 씨땡이다. 하지만 이 족보 없는 모듈을 붙이고 간 사람을 욕하고 있을 시간이 없다. 트래픽 태풍을 어떻게든 방어해야 한다. 풀스캔이 발생하는 기능을 찾아서 방어 코드를 넣었다. where 절에 조건이 빠지는 상황이면 아무 값이나 설정해서 조건이 빠지지 않도록 했다. 배포하니 서버가 나아진다.

 

여전히 느린 API가 있다. J 개발자에게 물어보니 아직 오픈하지 않은 기능이란다. 앱과 서버에 선반영 했는데 화면에는 노출되는 곳이 없단다. 이 API는 서버에서 다시 P 서비스를 호출하는데 이 P 서비스가 응답을 늦게 주는 것이다. P 서비스는 타 팀 서비스라 손을 댈 수 없다. 고민하다 일단 P 서비스에 대한 연동을 끊기로 했다. 앱에서 API를 호출하면 빈 응답을 주도록 코드를 바꾸고 배포했다. 드디어 느린 응답이 사라졌다!

 

벌써 오후다. 이번에는 업로드가 말썽이다. 사용자가 몰린 것이다. 그래도 전반적인 서비스는 안정적이다. 업로드만 조치하면 된다. 업로드 서버를 2대에서 4대로 늘려서 급한 불을 껐다.

 

안정

4월 21일 화요일. 8시 40분, 9시, 10시, 11시.... 오후 5시. 평온하다. 간헐적인 오류도 있긴 했지만 비교적 하루가 무사히 지나갔다. 고생한 J 개발자에게 수고했다고 슬랙 메시지를 보냈다. 모든 게 평화롭다. 긴장이 풀리면서 피로가 밀려온다.

 

다시 에러

4월 22일 수요일. 오전 10시. 갑자기 응답 시간이 느려진다. 9시도 잘 넘겼는데 10시에 왜? 원인을 모르겠다. J 개발자는 점진적으로 서버를 재시작했다. 문제가 사라졌다. 뭐지?

4월 23일 목요일. 오전 10시. 또 응답 시간이 느려진다. 원인을 모르겠다. 급하니까 일단 재시작이다. 잠시 후 신기하게 멀쩡해졌다. 어제와 증상이 동일하다. 증상만 보면 해당 시점에 마스터 DB로 연결을 구하지 못해 에러가 발생했다. J 개발자와 통화를 해서 몇 가지 조치를 취했다. 슬레이브를 사용하는 URL을 더 늘렸다. 설마 이 정도까지 했는데 마스터 연결이 안 될까?

 

4월 24일 금요일. 오전 10시가 다가온다. 젠장! 또 같은 증상이다. 평균 응답 시간, TPS를 계산했을 때 이 정도로 무너지면 안 된다. 게다가 피크 시간은 8시 30분에서 9시 사이다. 9시를 잘 넘겨 놓고 10시에 왜 이 모양이냐? 원인을 모르겠다. 이번에도 급하게 재시작이다.

10시 15분. 메시지가 하나 왔다. 차마 남들에겐 언급할 수 없는 이유로 10시부터 약 10~15분 정도 마스터 DB로의 연결이 잘 안 되었다고 한다. 아... J 개발자와 난 상상조차 하지 못했다.

 

이젠 괜찮겠지 했는데 오후에 메신저가 시끄럽다. 파일 업로드가 안 된다. CDN이 업로드 트래픽을 견디기 힘들어 M사 서비스에 대한 업로드를 차단했단다. 정말 다양한 일이 벌어지는구나! 속도를 늦추는 것도 아니고 업로드 일시 차단이라니. M사는 재발을 막기 위해 CDN 관련 작업을 4월 25일에 진행했다.

 

4월 27일 월요일 오후 6시. 오늘 하루가 고요하다. 이제 끝인가 보다. 마침 J 개발자가 다른 일로 서울 사무실에 왔다. 저녁 시간도 다 됐고 겸사겸사 술 한잔 기울이며 서로를 다독인다.

+ Recent posts