Today I Learned ...
오늘로 최종 프로젝트가 끝났다!
🖥️ 번쩍 팀프로젝트 #28
오늘은 최종 프로젝트의 마지막 날이라 발표를 진행하고, 우리 프로젝트에 대해 여러 튜터님들께 피드백을 받았다!
사실 발표 전에는 SSE 구독에 계속 에러가 생겨서 에러 해결을 열심히 했다.
SSE 구독을 요청하면 초반에는 연결이 잘 되다가 조금 있으면 504 Gateway Time-out 에러가 생겼다.
이 에러가 로컬 환경에서는 생기지 않았었기 때문에, 원인은 클라우드 환경에 있다고 생각하고 여러가지 가설을 세워보았다.
우선은 클라우드에서 ALB를 사용하고 있기 때문에, 이 ALB에 무언가 설정이 되어있다는 것이 첫 번째 가설이고,
두 번째 가설은 SSE 자체가 HTTP 통신 프로토콜을 사용하는데, 우리 서비스에서는 HTTPS를 사용하기 때문에 연결이 안 되는 것이었다.
이때 스프링 서버에서 Redis Subcscribe 도중 timeout 되었다는 로그가 남아있었기 때문에, 우선은 Redis Pub/Sub을 삭제하여 다시 실행해보았다.
그런데,, 이러니까 갑자기 504 에러가 나지 않게 되었다..!!
하지만, 이거 자체가 504 에러에 대한 근본적인 원인은 아니라고 판단했기 때문에, 프로젝트 발표가 끝난 후에 원인을 다시 찾아보았다.
우선 ALB의 설정을 확인했다.
처음에는 기본 유휴 제한 시간(Idle Timeout)이 60초로 되어있기 때문인가 싶어서 SSE heatbeat도 추가해보고, 시간을 300초로 늘려보기도 했다.
하지만, 이게 문제의 해결책은 되지 않았다.
다음으로는 ALB에 HTTP2 옵션이 붙어있기 때문인가 했는데, 옵션을 꺼서 테스트해보고, 다시 켜서 테스트해봐도 문제 자체가 해결되지는 않았다.
다음으로는 프로토콜 문제인가 싶어 찾아봤지만, 프론트에서 HTTPS로 잘 맞춰서 주고 있고, 백에서도 잘 처리가 되고 있는 것 같았다.
사실 이 부분에 대해서는 정확히 이해하지 못해서 요청 url만 확인해보았다.
Redis Pub/Sub의 문제는 아니었다고 생각했기 때문에, 삭제한 내용들을 다시 롤백해서 재배포 해보았는데,
이번에는 이상하게 504 에러가 아니라 500 에러가 생겼다.
그리고 스프링에는 똑같이 Redis subscribe에 timeout 되었다는 로그만 남았다.
계속해서 비슷한 환경에서 테스트를 진행해봤지만, 다시 504 에러를 만날 수 없게 되어 이 트러블슈팅은 여기에서 마치게 되었다.
사실상 문제가 언제 발생하는지도 파악하지 못했기 때문에, 제대로 된 트러블슈팅을 진행할 수 없었다.
다음에 트러블슈팅을 진행하게 된다면, 가장 먼저 문제 발생 상황부터 파악해보는 습관을 가져야겠다.
프로젝트 발표를 진행한 후에 튜터님들에게 여러 피드백을 받았는데, 이 부분에 대해서는 프로젝트 회고를 통해 정리해보려고 한다.
우리 팀이 작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
이렇게 최종 프로젝트까지 모두 끝마칠 수 있었는데, 생각보다 정말 정말 재미있었다!
이렇게 하나의 서비스를 만들어본 것이 처음이었는데, 한번 만들어보니 이 다음부터는 조금 더 수월하게 진행할 수 있을 것 같다.
이번 프로젝트에 대한 더 자세하고, 구체적인 이야기는 회고를 통해 정리해봐야겠다.
