Node.js 백 엔드 2명, React.js 프론트 엔드 3명, 총 5명의 팀원으로 진행되었습니다.
회원가입 오류가 수정된 배포된 서버를 제공 및 시연하였습니다.
지인들에게 수집한 고객 피드백을 정리하여 제공하였습니다.
이범규 대표님에게 피드백을 받았습니다.
모든 사람을 보여주는 기능을 추가하면 좋을 것
사용자 학습을 위해 처음 접속 시 튜토리얼이 있으면 좋을 것
지인들을 모으고, 사람들이 많이 모였을 경우 이후에 광고를 진행할 것
실전 프로젝트 6주 차 이야기
서버 배포를 진행했습니다. 첫 배포 날짜를 월요일로 예정했지만, 배포 후 디버깅을 진행하였을 때 단순히 CSS 깨지는 현상부터 가장 중요한 회원 가입 및 로그인의 분기가 정상적으로 동작하지 않아 사용자에게 광고할 수 없는 상황이었습니다. 가장 중요한 회원 가입 오류를 수정하고 배포를 진행하였을 때 화요일 저녁이었지만, 단순한 트러블은 남아 있어 광고하기엔 부족한 상황이었습니다. 모든 트러블을 해결하고, 간신히 금요일 팀 회의 전 배포에 성공하였고, 지인들에게 피드백을 받을 수 있었습니다.
지인 고객 피드백
회원 가입 기능을 핸드폰 번호로 연동하였습니다. 기존에는 AWS SES를 사용해 이메일 인증으로 회원가입을 구현하였지만, 알림 기능 및 1인 1계정만 허용하기 위해 Naver Cloud SENS를 이용해 핸드폰 인증으로 변경하였습니다. MySQL 서버의 DB의 사용자 및 인증 테이블 구조를 변경하고, Procedure를 변경하는 등 많은 수정이 있었지만, 큰 문제 없이 EC2 서버에 배포할 수 있었습니다.
디버깅하면서 발생한 핸드폰 인증
서버 아키텍처를 모노리틱에서 마이크로 서비스로 변경하고 있습니다. 이전에는 Redis, MySQL, Node.js Exprss 서버를 단일 AWS EC2로 구성하였습니다. 하지만 테스트를 진행하면서 갑작스럽게 EC2 서버가 중단되며 MySQL의 모든 DB가 초기화되거나, Redis의 데이터가 사라지는 등 단일 서버를 사용한 모노리틱 아키텍처의 문제점을 경험하였습니다. 현재 상황을 해결하기 위해 Cloud 서버를 분리하기 위해 별도의 EC2 서버를 생성하는 것을 생각하였지만, AWS RDS를 이용해 별도의 서버를 구현하기로 결정하였습니다. RDS를 설정하는 과정에서 데이터 이관, 어드민 권한 설정, 파라미터 설정 등 다양한 문제점이 발생하였지만, 이전에 DB를 백업 및 관리하던 경험을 바탕으로 정상적으로 MySQL 서버를 분리할 수 있었습니다.
AWS RDS의 MySQL 5.7 서버
Redis의 Multi Transaction을 이용해 Geometry 데이터 타입의 만료 기간을 설정하였습니다. Redis Enterpirse를 이용할 경우 사용할 수 있었던 Member 만료 기간 설정을 별도의 ZSET을 구성해 Socket.io 서버에서 일정 시간마다 사용자의 위치 정보를 삭제할 수 있도록 구현하였습니다. 하지만 여기서 발생하는 문제점이 만료 기간을 설정하는 ZSET과 Geometry 데이터가 동시에 작성되지 않고, ZSET이 작성되지 않는 오류가 발생하게 될 경우 데이터의 일관성이 깨지며 삭제되지 않는 현상이 발생할 수 있었습니다. 어떤 방식으로 해결할 수 있을까 고민하고 있을 때 Transaction이라는 기능에 관해 확인하였고, Multi Transaction을 사용해 두 건의 명령을 한 번에 작성 할 수 있도록 구현하였습니다.
Multi Transaction 예시
Socket 모임 핀 생성 및 삭제가 정상적으로 출력되지 않는 오류를 수정하였습니다. 모임 작성, 입장, 초대수락, 추방 등 모임 핀이 제어되기 위한 이벤트 구성이 정상적으로 구현되어 않았고, Git으로 관리하던 도중 코드가 덮어 써진 상황인 것 같았습니다. 오류를 수정하기 위해 Socket API 문서를 참조해 어떤 Method에서 모임 핀이 제어되어야 하는지 확인해보았고, 백 엔드 코드리뷰를 진행하면서 오류가 발생하는 이벤트를 찾아 수정하였습니다.
사라져버렸던 Socket 모임 생성 이벤트
Artillery 모듈을 사용해 부하 테스트를 진행하였습니다. 마이크로 서비스 아키텍처로 구조를 변경하면서 DB와 Cache 서버가 어느 정도의 부하를 버틸 수 있는지, 특정한 SQL이 부하를 일으키는 것은 아닌지 등 서버의 성능과 신뢰성을 담보하기 위해 진행하였습니다. 대표적으로 사용되는 모든 모임을 조회하는 기능부터 대화방에 메시지를 작성 및 조회하는 기능까지 다양한 API에 대해 테스트해 보았고, 서버가 죽거나 데이터가 초기화가 되는 등 큰 문제는 발생하지 않았습니다. 남은 5일의 기간 동안 모든 서비스에 대해 테스트 할 수 있도록 노력해야 할 것 같습니다.
AWS RDS CPU 사용량과 Artillery 테스트 결과
배운 점
트러블 슈팅 문서 작성 방법
Naver Cloud SENS
Redis, GeoRedis
Socket.IO
AWS RDS, ElastiCache, CloudWatch
Artillery
나의 생각과 이야기
새롭게 적용해야 할 기능이 너무 많습니다. 모노리틱 아키텍처에서 마이크로 서비스 아키텍처 구성으로 변경하면서 MySQL 서버는 AWS RDS로, Redis는 AWS ElastiCache로 변경해야 하고, 이전에 구현했던 Jenkins 기반 CI/CD를 현재 Node.js 서버와 연동을 해야 합니다. 단순히 프로젝트에 의미 없는 모듈을 접목하는 것이 아닌 서버의 아키텍처 구성을 완벽하게 구현하기 위해 적용해야 하는 기능만 남아있어 상당히 까다로울 것 같습니다.
서비스를 출시하기 직전 급작스럽게 출시 일자를 연기하는 상황을 저도 겪은 것 같습니다. 프론트 엔드 서버를 배포하기 전 디버깅을 완벽하게 진행하지 못해 배포 직전 발견된 오류들이 상당히 많았습니다. CSS가 깨지는 단순한 오류부터 회원가입이 되지 않는 크리티컬한 문제까지 다양한 문제가 동시다발적으로 발생하다 보니 단순히 서버 배포를 하고 관망할 수는 없는 상황이었습니다. 가장 문제가 된 회원가입 오류를 제일 먼저 수정하고 프론트 엔드 서버를 배포하였고, 많은 피드백을 받기 위해 모든 오류를 수정하기 전까진 팀원의 지인들에게 피드백을 받았습니다. 서비스를 구현하는데 상당히 많은 시간을 사용하다 보니 디버깅을 미리 하지 못해 프로젝트의 안전성을 제대로 보장하지 못한 것 같습니다. 다음부터 이런 상황이 발생하지 않도록 프로젝트를 배포하기 전 팀 내 기능 리뷰를 진행해야 할 것 같습니다.
프로젝트의 완성이 눈앞에 도달해 있는 것 같습니다. 프로젝트를 기획할 때 단순히 주변 사용자들의 위치를 표시하는 Marker가 실시간으로 움직이는 모습을 보고 싶다는 생각으로 진행한 프로젝트였지만, 처음 상상하던 것보다 더 많은 기능이 들어갔습니다. 사용자를 초대하면 알람 문자가 발송되는 기능부터 친구 관계, 일정 관계 등 다른 사용자와의 관계가 바뀔 때마다 변경되는 아이콘까지 단순히 점으로 표기될 줄 알았던 사용자들의 Marker가 각기 다른 모습으로 보여주는 것에서 상당한 희열을 느꼈습니다.
실전 프로젝트를 진행한 지 어느덧 5주라는 시간이 흘렀습니다. 5주 동안 팀장으로서 많은 스트레스도 받고, 모든 팀원에게 화를 내기도 하였지만, 지금까지 따라와 준 모든 팀원에게 감사하다는 말을 드리고 싶습니다. 남은 1주일 동안 최종 발표 준비를 열심히 하고 후회 없는 완벽한 발표가 될 수 있도록 노력하겠습니다.
