AWS ElastiCache로 Redis의 데이터를 이관하였습니다. 기존에는 EC2 서버에서 관리되고 있었던 모든 Redis 데이터들을 BGSAVE 명령어로 백그라운드 백업을 진행해 dump.rdb 파일로 저장하였습니다. AWS S3에 업로드한 dump.rdb 파일을 이용해 ElastiCache를 생성하였고 정상적으로 데이터 이관을 마쳤습니다. 하지만 데이터 복구를 진행하던 중 S3에 저장된 백업 파일을 읽지 못해 데이터 복구가 정상적으로 이루어지지 못했습니다. S3에서 권한을 설정하지 않아 발생한 오류였고, AWS Document에서 설명한 대로 백업파일에 권한을 설정하고 다시 생성해본 결과 정상적으로 데이터를 복구할 수 있었습니다.
dump.rdb 파일 위치와 Failed된 ElastiCache Redis
AWS CloudWatch를 설정하였습니다. MySQL을 RDS로 변경하고 Redis를 ElastiCache로 변경한 후 매번 원격으로 CLI를 접속하여 모니터링을 진행하였지만, 번거롭고, 한눈에 모든 서버의 상황이 보이지 않았기 때문에 직관적이지 않아 불편하였습니다. 어떤 방법으로 해결할 수 있을지 고민해보았고, AWS에서 CloudWatch라는 기능을 확인하였습니다. 프로젝트를 생성하여 모든 AWS의 인스턴스 속성을 확인할 수 있었고, EC2, RDS, ElastiCache의 모든 상태를 그래프 또는 차트로 위젯을 생성해 볼 수 있었습니다. 5분 간격으로 서버의 상태를 확인할 수 있도록 설정하였고, 부하 테스트를 진행할 때 수치화된 그래프가 조회되었고, 서버의 상황을 확실하게 이해할 수 있게 되었습니다.
대화방 API 부하 테스트
더미 소켓 클라이언트를 자체 제작하였습니다. Artillery 모듈을 이용해 부하 테스트를 진행할 때 Express API는 확인할 수 있지만, Socket.io-v3의 경우 extraHeaders에 데이터를 넣지 못하는 상황이 발생하였습니다. 사용자 인증을 Headers를 통해 진행하는 Location Socket 서버에서 인증 자체를 하지 못해 부하 테스트를 진행할 수 없었고, 비효율적이지만, DB 서버에 테스트 유저를 인원수만큼 생성함과 동시에 userId를 가지는 jwt 토큰을 인원수에 맞게 생성하였습니다. 그리고 별도의 Socket 접속 코드를 생성해 하나의 Socket마다 extraHeaders에 jwt 토큰을 삽입해 서버에 접속하였고, setInterval로 1초마다 한 번씩 고정된 위치를 서버에 전송하도록 설정하였습니다. 단일 파일에서 너무 많은 Socket을 접속해 1,000명을 테스트하던 도중 Socket 데이터 전송이 끊기거나 실패하던 상황이 발생하였지만, 최대 인원 테스트는 정상적으로 진행되었던 것 같습니다.
1,000명 Socket 부하 테스트
Redis의 Geometry 데이터 타입의 Expire를 설정하는 ZSET을 생성하였습니다. Redis Enterprise를 구매하였을 때만 사용 가능한 Member의 Expire를 설정하는 기능을 Node.js와 연동해 사용자 위치와 함께 생성 시간을 생성하도록 설정하였고, Kakao Map에서 사용자를 클릭해 조회할 때 생성 시간을 반환하도록 설정해 접속 시간을 표기할 수 있도록 구현하였습니다. 그리고 Socket.js에서 Setinterval를 설정해 1시간마다 만료 시간이 지난 사용자의 위치를 삭제하도록 설정하였고, 7일이 지날 경우 해당하는 만료 시간과 사용자의 위치가 자동으로 삭제되도록 구현하였습니다. 하지만 초기에 사용자들이 많이 없었기 때문에 해당 기능을 비활성화시켰고, 사용자가 삭제되지 않도록 변경하였습니다.
접속 시간 조회
Github Readme를 수정하였습니다. 기존에는 사용하는 모듈과 홈페이지 링크만 걸어두었다면, 수정하고 난 이후 한눈에 프로젝트를 볼 수 있도록 아키텍처, DB ERD, 트러블 슈팅 등 다양한 내용을 추가하였습니다. Readme를 업로드 할 때마다 부족한 부분이 보여 계속 수정하게 되는데 최대한 읽는데 방해되지 않도록 노력하고 있습니다.
헤쳐모여 Readme
최종 발표회를 위한 PPT를 작성하였습니다. 프로젝트 목차를 소개, 아키텍처, 트러블 슈팅, 고객피드백, 최종 성과로 구성하였고, 아키텍처를 설계하게 된 이유와 부하 테스트를 설명하는 것을 핵심으로 잡았습니다.
헤쳐모여 PPT 메인 페이지
10분 정도의 최종 발표회 영상을 촬영하였습니다. 작성한 최종 발표회 PPT를 기반으로 촬영을 진행하였는데 대본 작성과 영상 편집으로 인해 새벽 5시까지 작업이 진행되었습니다. 3일간 제대로 잠도 못 자고 발표 준비만 하였지만, 퀄리티있는 최종 발표회를 위해 노력하였고, 항해99의 소개 페이지에 최종 프로젝트를 업로드 하는 성과를 얻었습니다.
2기 최종 프로젝트 전시장
최종 발표회
9/3 (금) 15:00 ~ 18:00 : 최종 발표회가 진행되었습니다.
1조~18조까지 10분씩 라이브 스테이지에서 발표를 진행하였습니다.
Q&A 부스에서 실시간으로 협력사 분들에게 헤쳐모여 서비스를 설명하였습니다.
헤쳐모여 Q&A 부스
최종 발표회 이야기
라이브 스테이지에서 10분간 발표를 진행하였습니다. 발표의 내용은 이전 날 제출한 영상과 동일하게 진행하였고, 많은 협력사 분들에게 발표를 진행한다는 점에서 상당히 긴장하였지만, 대본을 작성한 대로 진행하면 된다고 생각해 마음을 다잡았습니다. 발표 도중 PPT 페이지가 이동할 수 없는 상황이 발생했지만, 큰 문제 없이 진행되었습니다.
많은 분이 Q&A 부스에 찾아와 프로젝트에 대해 질문해주셨습니다. 스파르타 소속의 개발자분들, 1기 졸업생, 협력사 분들 등 다양한 분들이 부스에 찾아와 주셨고, 단순히 프로젝트가 궁금해 부스에 방문하신 분과 프로젝트의 소스 코드를 읽으시고 질문을 정리해 방문해주신 분도 계셨습니다.
Q&A 부스에 방문해주신 분들이 다양한 질문을 주셨습니다.
프로젝트를 기획한 이유가 무엇인지
테스트 코드는 어떤 방식으로 관리하였는지
서버의 아키텍처를 어떻게 구현하였는지
Socket 통신의 부하 테스트를 어떤 방식으로 진행하였지
부하 테스트 진행 시 서버에서 발생한 부하는 어느 정도인지
실시간 유저의 상한선은 몇 명인지
만약 AWS에서 오류가 발생해 며칠간 사용할 수 없다면 어떻게 대응할 것인지
개발자가 된 이유가 무엇인지
많은 질문이 있었지만, 가장 많이 궁금하셨던 것은 '서버의 부하 테스트 진행 방식'과 '부하 테스트 진행 시 서버에서 발생한 부하는 어느 정도인지'였습니다. 실시간 통신이 프로젝트의 핵심 컨셉이었고, 그로 인해 서버의 부하량에 대해 확실한 답변을 필요하였기 때문에 가장 많은 질문을 받았던 것 같습니다.
최종 지원 주간
9/4 ~ 9/10 : 최종 지원 주간이 시작되었습니다.
이력서 및 자기소개서를 작성하는 방법에 관해 설명해주었습니다.
일요일까지 1차 피드백을 위해 이력서를 제출했습니다.
최종 지원 주간 이야기
1차 피드백을 위해 이력서를 작성하였습니다. 마지막으로 이력서를 작성한 지 2년이 넘었던 것 같은데, 상당히 오랜만에 다시 작성했었던 것 같고, 최대한 항해99를 진행하면서 있었던 일에 대해서만 작성하도록 구성하였습니다. 이력서를 제출하기 위해 수많은 사람에게 피드백을 받았고, '0000 한 문제가 있었고 그래서 0000 방법을 사용해서 개선했고 그래서 뭐가 얼마만큼 좋아졌다.' 같은 3단 구성으로 작성하기 위해 노력하였습니다.
일요일도 쉬지 않고 이력서 수정에 매달려있었습니다. 항해의 99일 동안 진행된 시간에 대한 최종 결과물인 이력서를 확실하게 작성하지 않으면 이후에 많은 후회를 할 것 같았고, 자신에 대한 이야기를 최대한 읽기 편하게 작성하기 위해 노력하였습니다. 1차 피드백 최종 제출 시간인 다음날 오전 6시 전까지 제출하기 위해 새벽 5시까지 남아서 작성하였습니다.
월요일 새벽 4시경 갑작스럽게 튜터님이 방문해 포트폴리오 첨삭을 진행하였습니다. 멍하니 이력서를 읽으면서 잘못된 부분은 없는지 확인하던 도중 갑작스럽게 튜터님이 Gather에 방문하셨고, 남아있는 5명의 다른 크루원들이 함께 첨삭을 받기 위해 하나의 테이블로 모여들기 시작하였습니다. 이력서 첨삭은 1시간 30분 정도 진행되었고, 이력서를 구성하는 방식부터 자기소개서를 작성할 때 강점인 단어는 어떤 것인지까지 상당히 다양한 부분에서 첨삭을 진행해주셨습니다.
후회 스러운점 (팀의 성장)
최종 발표회를 마치고 6주간의 실전 프로젝트를 회고하던 중 과연 '모든 팀원이 성장할 수 있었던 기회를 제공했을까?'라는 생각을 해보았습니다. 백 엔드의 업무 중 핵심적인 부분을 제가 도맡아 진행하였고, 다른 백 엔드 팀원들은 사이드 업무를 중심적으로 프로젝트를 진행하였습니다. 챌린지한 업무를 진행하지 못한 다른 팀원들의 경우 '6주간의 시간 동안 후회 없이 성장할 수 있었는가?' 라고 물어보았을 때, 긍정적인 답변을 얻지 못할 것이라고 생각합니다. 모든 업무를 진행하면서 시간이 생길 때마다 코드리뷰를 진행하고, 프로젝트의 아키텍처 부분에 대해 설명하는 것을 주기적으로 진행하였지만, 그것만으론 프로그래밍 실력이 늘지 않았을 것으로 생각합니다. 프로젝트의 결과만을 추구하다 주변 팀원들의 상황을 직시하지 못한 점은 모든 팀원의 성장을 추구한다는 저의 핵심가치를 제대로 지키지 못한 것이라 생각합니다. 조금 더 진중한 이야기를 하기 위한 분위기를 만드는 노력을 했었다면 어떨까 후회스럽고, 상당히 반성하게 되었습니다.
프로젝트의 결과는 후회 없이 구현하였지만, 진행하던 6주간의 과정에서 상당히 많은 반성을 하게 되었습니다. 실전 프로젝트를 진행하면서 많은 팀이 부서지고, 항해를 하차하셨는데, 저희 팀은 그것을 묵묵히 내색하지 않고 버텼기 때문에 여기까지 올 수 있었던 것 같습니다.
배운 점
주변 상황을 되돌아보는 법
PPT 작성법
OBS Studio
Socket.IO
AWS RDS, ElastiCache, CloudWatch
Artillery
나의 생각과 이야기
최종 프로젝트를 마무리 짓기 위해 발표 영상을 찍는 부분에서 상당히 많이 힘들었습니다. 발표의 구성은 어떻게 진행해야 하는지, 내용은 어떻게 구성해야 하는지 알 수 없는 부분이 상당히 많았고, 항해톡을 진행하면서 얻었던 경험들이 많은 도움은 되었지만, 발표하는 프로젝트의 규모가 달랐기 때문에 모든 부분에서는 도움을 받을 순 없었습니다. 그리고 리허설을 진행하던 도중 AI가 말하는 것 같다는 피드백을 받았었고... 발표를 진행할 때는 최대한 듣기 편하도록 발음 교정을 하던 부분에서도 많은 시간을 사용했던 것 같습니다. 상당히 많은 부담감을 안고 발표를 준비한 것 같습니다.
최종 발표회 전까지 매일 2~3시간씩밖에 잠을 못 잤던 것 같습니다. 프로젝트를 성공적으로 마무리 지어야 한다는 부담감과 팀장의 책임감이 같이 공존하면서 1주일의 모든 시간을 프로젝트 발표 준비에 몰두했던 것 같습니다.
6주간의 실전 프로젝트가 종료되었습니다. 매주 챌린지한 업무들이 있었고, 그런 업무들을 구현하면서 재미를 느꼈던 것 같습니다. 그리고 프로젝트를 진행하면서 성공적인 결과를 얻기 위해 프론트 엔드 팀원들을 닦달했었던 것과 프로젝트 구현 기간을 지키지 못해 화를 냈던 것까지 다양한 일들이 있었고, 프로젝트 기간을 회고해 보았을 때 기억에 남는 일들이 많은 것 같습니다. 모든 프로젝트 기간이 끝났다는 게 믿기지 않고, 지금도 프로젝트를 계속해야 할 것 같은 부담감은 아직 사라지지 않은 것 같습니다.
최종 지원 주차도 상당히 힘듭니다. 최종 발표회가 끝난 이후 일요일까지 1차 이력서를 제출해야 한다는 청천벽력 같은 이야기가 나왔고, 프로젝트가 끝나면 하루 정도는 휴식을 취할 수 있겠지라는 저의 생각을 발로 차버렸습니다. 일요일까지 이력서 작성을 끝마치기 위해 최종 발표회를 준비하던 것처럼 잠을 줄이고 이력서 작성에 몰두했습니다.
