이번 포스팅은 2월 24일에 겪은 서비스 에러에 관한 간략한 회고 내용입니다.
기존의 에러는 대부분 저희 서비스내에서의 문제였다면 처음 으로 겪은 외부의 문제때문에 가장 기억에 남는 문제였습니다.
문제 발견
2월 24일 오전 11시경 관리자(admin) 서버에 특정 한글(부위명)이 포함된 요청을 하는 모든 API가 정상적인 작동을 하지 않았습니다.
부위명을 입력하지 않는 다른 API들은 전부 정상 동작 하였습니다.
한우 도매를 다루는 서비스이다 보니 소고기의 부위명이 굉장히 중요하였습니다.
APP서버 내부에서 소고기의 부위명을 TSV로 저장하여 관리하였습니다.
문제 원인 파악
위의 문제를 짐작컨데 인코딩이 문제라 생각되어 서버쪽 로그를 살펴보았습니다.
어제까지 잘되던 서버의 갑자기 인코딩이 깨졋습니다.
위 로그 사진의 마지막 두 줄을 보면, 서버 최초 실행시 로그입니다
한글로 표기되어야 할 부분이 ??로 표시되어 있는 것을 확인할 수 있습니다.
이를 통해 APP 서버 내부 인코딩 설정에 문제가 생긴 것으로 판단되었습니다.
몇 가지 정황을 고려해보았을 때, 관리자 서버가 전날 오후 8시경 재배포된 시점부터 문제가 발생한 것으로 추정했습니다.
그 전날 업무 시간 동안에는 관리자 서버가 정상 작동 중이었습니다.
하지만 APP 서버 내부의 JVM과 OS 인코딩 설정은 모두 UTF-8로 동일하였고 시스템 로그나 접근 기록을 확인해봐도 인코딩 설정의 변경 또한 없어 문제의 원인을 찾을 수 없었습니다.
범인은 CI 빌드 머신
현재 저희의 서비스는 젠킨스를 이용하여 main 브랜치에 병합이 일어나면 서버를 배포합니다.
main브랜치를 pull한 후 테스트를 돌리고 빌드하여 앱 서버의 컴퓨터에 직접 rsync로 파일을 보내 서버를 실행합니다.
위 사항을 기반으로 CI 머신의 인코딩에 문제가 생기면 서버쪽에도 영향이 갈 것이라 판단하였고 CI쪽 인코딩설정을 확인하였습니다.
예상대로 빌드하는 CI 머신의 인코딩이 변경되어있었습니다.
서버쪽 인코딩이 정상적이었더라도 이미 빌드한 결과물이 다른 방식으로 인코딩되어 서버쪽에서 실행되었습니다.
문제의 해결
해결 방법은 간단했습니다.
빌드하고 배포하는 과정에서 사용하는 gradle 스크립트에 Jvm 인코딩을 UTF-8로 고정하는 코드를 추가했습니다.
또한 CI 머신에서 실행되는 젠킨스의 환경변수에도 LC_ALL을 UTF-8로 고정했습니다.
이렇게 수정한 뒤에 다시 빌드하여 서버를 배포하니 문제가 해결되었습니다.
저는 이번에 서버 장애 상황을 마주했는데, 이전에도 비슷한 상황은 경험했었습니다.
그러나 이번에는 예상치 못한 지점에서 발생한 에러였기 때문에 문제 파악이 굉장히 어려웠습니다.
팀 내 시니어 개발자 분께서 해결 방법의 실마리를 찾아주셨는데, 그분의 경험과 문제 파악 능력에 많은 감명을 받았습니다.
문제를 해결할 때는 a-z까지 하나하나 파악하면서 해야 결국 실마리가 나온다는 것을 느꼈습니다.
