개발일지

프로젝트 진행하면서 멘토링 시간에 개발자는 우리 서비스가 언제 고장이 날지를 알고 있어야 한다는 말을 들은 적이 있다. 그래서 Jmeter도 설치하고, 이것저것 값도 넣어보고, 구글링도 열심히 해봤는데 사실 잘 와닿지는 않았다. 사실 중간발표 때 테스트를 할 때는 목적이 있어야 된다는 말이 더 인상적이었다. 어떤 목적을 가지고, 서비스의 어떤 지점을 개선하기 위한 목적에서 테스트를 하는 지에 따라 테스트 방법도, 시나리오도 달라질 것이다. 그런데 이번에 배포하고 에러를 수정하면서 우리 서비스에서도 부하가 오는 지점이 있다는 것을 알았다. 바로 메인페이지에서 방 정보를 업데이트 하기 위해 1초에 한번씩 api 요청을 보내는 부분이다. 프론트에서 작업하시면서 이전에 걱정된다고 언급하시기도 했었는데, 이번에 ..

드디어 배포했다!! 원래 30일에 배포하려고 했는데, 마지막에 테스트하다가 에러를 발견해서 수정 후 31일 새벽 1시쯤에 다시 배포하고 슬렉에 홍보글을 올렸다. 정말정말 놀란게, 새벽임에도 불구하고 엄청나게 많은 분들이 접속해주셨다!!! spring서버는 EC2에서 CPU를 확인했을 때 90%까지 올라갔었고, DB에서 유저 수도 계속 20여명을 유지했다. DB에 유저수는 방을 만들거나 참여한 순간에 생성이 되서 실제 메인페이지에 접속한 수는 구글 애널리틱스를 참고할 때 40명이 넘었던 것 같다(해당 시간 피크가 60명 정도?!) 그리고 오류제보와 만족도 조사도 정말 우르르 들어왔는데 ㅋㅋㅋㅋㅋ 퀴즈를 안풀었는데 스코어가 올라가거나 찬스가 무한으로 사용되는 경우(찬스가 -1이 안되서), 다른 방과 보이스 ..

다른 팀원이 GitActions를 진행하면서 우리 백엔드 GitHub의 Setting이 모두에게 보여지지 않는다는 것을 알았다. setting은 해당 Repository를 만든 사람만 접근이 가능하고, Collaborator로 초대된 다른 팀원들은 setting을 변경할 수 없다. 그래서 알아보던 중에 GitHub에 organization 기능이 있다는 것을 알았다!! 전에 이전 기수 깃허브를 보던 중에 팀으로 묶여있는 GitHub를 보면서 어떻게 했지, 궁금했던 기능인데(당시에는 아무리 검색해도 못찾았다!!) 이번에 알게 되었다. organization을 하나 만들고, 거기로 repository를 transfer하면 해당 organization 안에 repo로 등록된다. 그래서 우리 팀을 새로운 org..

nodeJS 쪽 CI/CD는 내가 진행을 했는데 설정할 게 많지 않아서 반나절 만에 끝났다! 근데 Spring은 다른 팀원 분이 맡고 계셨는데 HTTPS나 properties 관련해서 설정 파일 문제도 있었고, 특히 nginx를 적용하는 과정이 매우 어려워 보였다... 먼저 성공하신 다른 팀원분이 정말 옆에 완전 붙어서 같이 해결해주셔서 실마리를 좀 찾은 것 같다. 정말정말 너무 감사하다!!! 다행히 주말 사이에 nginx까지 성공하셔서 행복한 월요일을 맞이했다(그런줄 알았다...ㅜㅜ) 지난 주에 spring쪽에 로그를 설정하고, EC2에 배포한 상태에서도 로그 파일이 잘 저장되는 것을 확인했는데, nginx로 돌리고 나서부터는 로그 파일이 저장되지 않았다. 찾아보니 nginx 에서도 PM2처럼 로그파일..

NodeJS에서 무중단 배포를 구현하기 위해 PM2를 사용하였는데, 로그가 저장된다는 사실을 알았다! error log와 내가 console.log로 설정해놓은 로그들이 파일로 저장된다! PM2 logrotate를 사용해서 매일매일 저장하게 설정해놓았다. 그리고 log에 timestamp를 찍어놨는데.... 문제는 이게 한국시간으로 저장이 안된다는 거다!! (TIL을 밀려쓰고 있는 지금도 심지어 해결하지 못했다....) 서버 시간은 분명 KST인데 로그는 계속 UTC로 기록되고 있다... nodeJS에서는 이제 최소한 오류 로그는 확인할 수 있으니, 다음으로 Spring에서 로그를 찍는 법을 찾아봤다. Springboot에서는 기본으로 제공하는 Logback을 사용할 수 있다. Springboot쪽에는 ..

데이터 관리 방식을 변경하면서 관련 로직 수정은 모두 끝났고, 아직 MySql에서 S3로 옮기는 부분은 구현하지 못했다. 그런데 데이터 옮기는 것은 우선 데이터만 잘 쌓아놓으면 나중에 진행해도 될 것 같고, 다음주에 정식 배포하기 전에 배포 쪽 문제를 먼저 마무리해야할 것 같아서 먼저 시작하기로 했다. spring쪽은 다른 팀원이 진행하고 있고, github actions+codedeploy+nginx 조합으로 할 것 같다. nodeJS도 처음에 같은 조합으로 생각하고 github actions을 시작했는데 생각보다 자료가 없었다. 그리고 찾아보다 보니 github actions를 쓰지 않고 codedeploy+codepipeline으로 하는 것도 괜찮은 것 같아서 이렇게 시도했다. 주로 참고한 블로그 ..

데이터 부분은 수정이 끝났다! 생각보다 수정해야 하는 부분이 많았는데, 다행히 오래걸리지는 않았다. 게임 종료 후에 User와 Clue는 삭제하기로 하고, Room과 Quiz만 남기기로 했다. 그리고 Room에는 State와 Pass라는 값을 주어서, 게임이 종료되거나 게임 종료 api가 오기 전에 disconnect로 방이 사라지면 State를 CLOSE로 바꾸어서 비활성화된 정보라는 것을 표시해주고, 메인페이지에서 방을 조회할 때도 데이터가 내려가지 않도록 하였다. 그리고 나중에 S3로 데이터를 옮길 때, CLOSE된 Room과 해당 RoomId를 가지고 있는 Quiz 정보들이 그 대상이 될 것이다. 처음에는 Quiz에도 State를 만들고 게임 종료 시 업데이트를 해주려고 했는데, Room만 sta..

중간발표를 무사히 마쳤다. 지난 주 내내 중간발표때문에 조급했었는데, 다행히 잘 끝났다. 생각하지 못한 부분에서 질문을 많이 받았고, 앞으로 남은 3주 동안 어떻게 할 것인지에 대해서도 얘기해봤다. 백엔드가 비교적 기능 구현이 빨리 끝났고, 이후에 기능 추가나 성능 개선하는 부분에서 선택지가 너무 많아서 어떤 걸 해야할 지 계속 고민이 많았다. 중간발표 때 받은 피드백을 중심으로 기본적인 부분에서 미흡한 부분을 개선하기로 했고, 깃허브의 기능들도 더 적극적으로 써보기로 했다. 그리고 백엔드에서는 다음의 3가지에 초점을 맞추기로 했다. - 배포 자동화와 무중단 배포 - 테스트 코드 작성 - DB 배포 자동화와 무중단 배포는 프로젝트에 도입해보고 싶었던 기능이기도 하고, 정식 배포 전에 기능을 구현해놓으면 ..

중간발표 자료를 금요일 저녁까지 제출해야해서 오늘부터 자료를 만들기 시작했다. 화요일에 중간발표 발제가 있었고, 발표시간은 5분이라서 생각보다 짧았다. 발표내용은 프로젝트 시연, 서비스 아키텍처, 트러블 슈팅, 추후 개발 계획으로 구성되었다. 중간발표 전에도 이런 내용을 하면 되지 않을까, 생각했던 부분이라 발표자료를 구성하는 건 어렵지 않았다. 어차피 사전에 발표자료를 공유하는 걸로 알고 있어서 프로젝트 주요 기능 페이지를 추가하고, 발표 때는 생략하기로 했다. 트러블 슈팅에 어떤 걸 써야할지가 좀 고민이 됬는데 회의에서 금방 결정이 됬다. 그동안 이슈들은 팀노션에 간단하게라도 정리해뒀었는데 그게 도움이 된 것 같다. #유저의 disconnect 문제 정말정말 고민이 많았던 문제다. 이렇게(https:..

오늘은 마지막 기획멘토링이 있었다. 이번주에 중간발표가 예정되어있는만큼 오늘은 그간 진행 상황과 함께 중간발표 때 어디까지 구현이 가능한지 확인하는자리였다. 우리조는 MVP는 마무리가 된 상태이고, 마지막 기획멘토링이기 때문에 이후에 어떤 기능에 집중할지에 대해서도 간단히 정리를 해갔다. 프로젝트의 성격이 다른 조와는 많이 다르고, 사용하는 기술도 기존에 항해 실전프로젝트에서는 잘 다루지 않은 기술이라서 다른 분들도 진행상황을 궁금해하시는 것 같았다. 멘토링 때 간단히 진행 상황을 보여드렸는데 일단 괜찮은 것 같았다...! (사실 나는 좋은 반응인가 했는데, 같이 들은 분들 얘기를 들어보니 괜찮았던 것 같다!!) 나중에 포토폴리오를 만들 때 프로젝트의 설명만 들어서는 어떤 방식으로 구현을 한건지 잘 상상..