[우테코 Level 4] 2주차

로그레벨 재조정

운영서버를 가동시킨지 어언 3주, 그동안 크고 작은 서버 이슈가 있었고 그 때마다 중요하게 작용했던 것이 로그였다. 과연 우리는 그동안의 서버 이슈들을 겪으면서 현재의 로그 방식에 불편함을 느낀 적이 없었나? 대답은 ‘아니다’라고 할 수 있었다. 미뤄왔던 팀 작업 중에 하나였기에 지원해서 하게되었다.

처음 로그 레벨을 정할 때는 기준이 모호했다. 그 당시에는 사용자가 악의적으로 요청했는가, 단지 서버내의 치명적 오류인가 이런 기준으로 warn, error를 나눴었다. 왜 모호했을까 생각해보면 로그가 어떤 상황에서 얼만큼 쌓이는지 경험이 없었기 때문이었다. 이번에 로그 레벨을 재조정하면서는 warn에 비정상적인 요청 예외를 넣으니 다른 중요한 memory, connection error 경고가 묻혔었어와 같은 경험적인 근거가 있으니 기준을 세우기 훨씬 수월했다.

결론적으로는 서버 내부 에러는 error, 사용자에 의한 예외는 모두 info, warn은 배당하지 않음으로써 시스템 경고만 warn으로 받아볼 수 있게 정했다. 역시 경험이 최고의 판단 기준이다!

flyway 적용

더불어 이번주에 DB 마이그레이션을 위한 flyway를 맡아서 적용해보았다. flyway가 왜 필요할까?

앞으로 서버를 여러 환경에서 띄울 예정이라 DB 역시 여러 환경에서 존재하게 될 것이다. 이때, 엔티티에 변경이 생긴다면 DB에서 직접 (ALTER ...) 수정해야하는데 휴먼 에러가 나기 아주 좋은 경우라고 할 수 있다. (예: prod1 db에서는 수정했는데, prod2 db에서는 수정하지 않았다든지.) 이를 방지하기 위해 DB 변경 사항을 버전별로 관리하고, 이 어플리케이션 파일을 구동하는 모든 서버, DB에 일관되게 적용할 수 있게하는 마이그레이션 툴인 flyway를 도입하기로 결정했다.

처음 보는 기술이라 약간은 막막했는데 기존 자료들을 찾아보고, 개인 레포에 실험삼아 적용해보고, 팀원들에게 의견을 물어가면서 하니 생각보다 어렵지 않았다. 다만, 초기 history 테이블을 생성하는 과정을 cd를 통해서 하려고 하니 오류가 생기는 이슈가 있었는데 다행이 dev 환경이었기때문에 좀 더 알아보고 안전하게 prod 환경에도 적용해보려고 한다! 다음주에 팀원들에게 작업 내용을 잘 공유하면 좋겠다!

뒤에서 미션이 쫓아오지만 배울 건 배우자

저번주에 다짐한대로 이번주는 팀미션에 집중했다. 로그 레벨 재조정, flyway 적용 등등… 그리고 목요일 오후부터 미션 3단계를 진행하려니 발등에 불이 떨어졌다! 리뷰어 역할로 리뷰도 남기면서, 미션까지 진행하려니 정말 빠듯했다. 어찌저찌 금요일 4시에 겨우 최종 제출을 했다. 하지만, 제출하고도 찝찝했다. 이번 미션을 통해 알아야하는 톰캣, 서블릿의 작동원리를 이해하지 못하고 미션만 구현하고 리팩토링해서 낸 기분이었다.

그래서 거꾸로 미션을 다 내고 난 뒤 6시부터 톰캣, 서블릿, coyote, catalina의 개념을 찾아보고 내 코드와 비교해봤다. 한 1시간 찾아보고 나니 내가 뭘 구현한 건지 슬슬 이해가 갔다. 순서가 어찌됐든 웹 요청을 받는 가장 겉단의 톰캣의 작동 과정을 어느정도 이해한 것 같아 뿌듯하다.

ps. 익명의 팀원 쑤O씨에게 온 쪽지