문제 발생

현재 프로젝트는 학교 내 물리적 가상 서버에 올라가 있는 상태이다.
주말동안 학교 통신망 점검으로 인해 주말동안 학교는 정전상태였다.
점검이 끝나고 서버를 다시 실행시키니 외부 api 연동에 문제가 생겼다.
분명 로컬환경에서는 잘 작동하는데 서버에서는 돌아가지 않았다.

다른 외부 api는 작동을 잘 하지만 날씨를 받아오는 api에 대해서는 통신은 성공했지만,
HTTP 라우팅 에러와 통신은 성공했지만 데이터가 없다는 응답만 반복하며 들어왔다.
api 제공 문서를 읽어보고 구글링도 해봤지만 해당 문제에 대한 해결책을 찾을 수 없었다.
다른 외부 api는 잘 작동했지만 날씨 api만 작동을 안했기에,
내 ip가 블랙리스트에 올랐거나, 해당 api 서버의 문제라고 생각했다.

새로운 문제 발생

api 문제는 뒤로 미루고, 곧 출시할 서비스에 대한 테스트를 진행하고있었다.
글 작성 테스트를 하는데 3가지의 새로운 문제가 발생하였다.

1. 작성일은 2024년 8월 31일인데 게시글에는 9월 1일로 시간이 저장되는 문제
2. 카테고리의 선택 문제(프론트)
3. 글 등록 과정에서 네트워크 오류로 인해 같은 글이 6번 등록된 문제

2번 문제의 경우에는 프론트에서 해결도 하고 서버에서는 유효성 검사를 추가해야겠다는 생각이 들었다.
사실 프론트에서 체크 박스로 한정적인 선택지에서 골라서 서버로 넘겨주면 서버에서의 유효성 검사는 필요 없다 생각했었는데, 프론트에서는 모든 것이 오픈되어있기 때문에 프론트를 통한 요청이 아닌 서버로의 다이렉트 요청에 대해서는 대처 방법이 없기 때문이다.

3번 문제의 경우는 문제 해결을 위한 새 로직을 고민해봐야 할 것 같다.

문제 해결

먼저 날짜의 오류에 대한 해결 방법을 생각했다.
날짜의 경우 JpaAuditing을 통해 자동으로 생성시간과 수정시간을 저장하게 만들었다.
찾아본 결과 JpaAuditing을 통해 저장되는 시간은 엔티티를 저장하는 데이터베이스의 서버 시간으로 저장된다고 한다.
그래서 MySQL 서버를 들어가 MySQL서버 시간을 확인해 보니 KST로 저장되 있었고 시간은 현재 시점보다 22시간 정도 미래였다. 또한 이 시간은 시스템의 시간을 받아오는 로직이었다.
그래서 서버의 시간을 확인해 보니 역시 현재 시점보다 23시간 미래였다.

여기서 처음 생겼던 api 오류에 대한 생각이 났다. 날씨의 api의 경우 api 요청 파라미터에 현재 날짜와 시간을 담는 로직이 있었다.
즉, api 서버에 23시간 미래의 날짜와 시간이 들어갔기에 데이터가 없었던 것이었다.

그래서 rdate를 통해 서버시간을 현재 한국시간과 동기화 시킨 후 앞에 발생했던 오류 2개가 정상화된 것을 확인할 수 있었다.

결론

1. 잘 작동하던 코드가 서버에서 돌아가지 않는다면, 서버에 무슨 이슈가 생겼는지, 환경이 어떤지 확인하자

2. JpaAuditing을 통해 기록되는 시간은 스프링 서버가 아닌 데이터베이스 서버의 시간을 딴 것이다.

3. 시간 동기화는 어디서든 필수