Socket.IO에서 GeoRedis 모듈을 이용해 반경 안에 있는 사용자 조회기능을 구현하였습니다.
EC2 Ubuntu 18.04 서버에서 Redis 설치 및 설정하였습니다.
대화방 확정 및 리스트 검색 기능 구현 및 논리 구조를 작성하였습니다.
View를 기반 Posts 조회 및 모임 입장, 퇴장 기능을 구현하였습니다.
Https Socket Server에 연결되지 않던 오류를 수정하였습니다.
Cloud Front에서 배포된 서버가 갱신되지 않던 오류를 수정하였습니다.
MySQL 서버의 통신이 되지 않던 max allowed packet 오류를 수정하였습니다.
이메일을 사용하지 않고 핸드폰 번호를 이용해 로그인하도록 DB 구조를 변경하였습니다.
AB180 협력사 발표
8/18 (수) 19:00 ~ 20:30 : AB180 협력사 발표가 진행되었습니다.
CTO, Back End, Front End 순서대로 발표가 진행되었습니다.
AB180에서 데이터 분석 방식과 사내 아키텍처 구조를 발표하였습니다.
AB180의 사내 스터디, 멘토링 문화, 인재상에 대해 발표하였습니다.
입사 지원 시 코딩테스트와 리드 면접, 가치면접이 진행된다고 하였습니다.
디자이너 회의
8/19 (목) 20:30 ~ 22:00 : 디자이너 회의를 진행하였습니다.
현재까지 구현된 프로젝트의 진행 상황을 공유하였습니다.
UI/UX의 수정해야 할 부분에 대한 피드백을 공유하였습니다.
남아있는 CSS의 수정 사항에 대해 공유하였습니다.
모임 구하기, 대화방 목록의 UI 문제점을 피드백 받았습니다.
팀장 주간 회의
8/20 (금) 13:30 ~ 14:00 : 팀장 주간 회의가 진행되었습니다.
이범규 대표님이 회의를 진행하였습니다.
9, 16, 18 저희 팀과 React 팀장 2분으로 진행되었습니다.
사용자 지정 반경 안에 있는 실시간 유저 조회기능과 모임 초대하기, 대화방 확정하기를 시연하였습니다.
프로젝트의 주요 고객 타겟팅과 광고를 어떤 방식으로 할지 기획을 발표하였습니다.
이범규 대표님께서 4가지의 프로젝트의 피드백을 주셨습니다.
1. 사용자들이 접속하고 있지 않더라도 마지막 종료 위치에 마커가 일정 시간 남아있도록 구현
2. 초대하기, 호출 기능을 이메일이 아닌 핸드폰 문자로 구현
3. 특정 지역에서 사용자를 많이 모을 수 있도록 광고할 것
4. 우리 서비스가 무엇인지 1줄로 설명할 멘트 정의할 것
다음 주 팀장 주간 회의는 고객 피드백을 정리해 가져와야 할 것 같습니다.
실전 프로젝트 5주 차 이야기
MySQL의 모임을 자동 삭제하는 Event scheduler를 구현하였습니다. 저희 프로젝트의 핵심 컨셉은 모임이 종료될 경우 대화방이 사라지며 깔끔한 헤어짐을 목표로 하고 있습니다. 이처럼 종료 시간이 지난 모임을 삭제하기 위해 매번 Query를 입력해 모임을 삭제하는 것보다 자동으로 삭제하는 기능이 있으면 편할 것 같아 MySQL Document를 찾아보았고, 특정 이벤트가 발생할 경우 Trigger가 실행되는 것처럼 일정 시간이 되었을 경우 실행되는 Event Scheduler를 확인하였습니다. 여기서 문제점은 MySQL 서버 입장에서는 정기적으로 실행되는 것이 결국 주기적으로 서버에 부하를 주는 것이므로 적절한 실행 시간을 설정할 수 있어야 하고, Event Query가 비효율적이라면 서버 입장에서는 독이 될 수도 있을 것 같기 때문에 실행되는 Query를 최적화시키는 노력이 필요할 것 같습니다.
Event Scheduler 등록 현황
프로젝트의 로그인 방식을 이메일에서 핸드폰 번호로 변경하였습니다. 기존에는 알람, 로그인, 비밀번호 찾기를 AWS SES를 이용해 메일로 통신하는 것을 생각하고 있었지만 이번 팀장 주간 회의에서 이범규 대표님께서 피드백 주신 내용처럼 이메일은 사용자에게 직관적으로 알람을 전달하기 힘들 것이라는 생각을 하지 못하였고, 기획에 관해 깊게 생각하지 못한 잘못이었습니다. 회의가 끝나고 오후 2시 팀 내 정기회의를 진행하면서 프로젝트의 방향성과 기획의 문제점에 관해 이야기를 나누었고, 모든 이메일의 기능을 핸드폰 번호로 변경하도록 결정하였고, 핸드폰 문자를 보내는 API를 Naver Cloud SENS를 사용하기로 결정하였습니다.
Naver Cloud Sens의 문자 발송 테스트
실전 프로젝트 API Document에 MySQL TRIGGER, PROCEDURE, EVENT, VIEW를 추가 작성하였습니다. 해당하는 기능들은 Node.js 서버 내부에서 Sequelize를 Migration 하는 부분에서 Raw Query로 생성되기 때문에 확실한 논리 구조를 이해하지 못한다면 갑작스럽게 데이터 변경 또는 삭제되는 현상을 겪을 수 있을 것 같았습니다. 그리고 프로젝트를 되돌아볼 때 어떤 기능들이 숨겨져 있는지 매번 코드를 확인하게 된다면 불필요한 시간적 소모를 할 것 같았고, 코드를 이해하는 시간을 줄일 수 있도록 API Document를 작성하였습니다.
MySQL Trigger API Document
GeoRedis모듈을 이용해 사용자의 일정 범위 내부에 있는 유저 정보를 조회하도록 구현하였습니다. 현재 모든 사용자의 정보가 Redis 캐시 메모리에 Geometry 데이터 형식으로 저장되어 있습니다. Geometry 데이터 타입은 지정한 좌표를 기준으로 일정 거리 내부에 있는 다른 유저의 좌표 및 거리를 반환해주는 GEORADIUSBYMEMBER 함수를 사용할 수 있습니다. 해당하는 기능을 이용해 Node.js 서버에서 소켓 데이터로 유저의 데이터가 전달될 경우 Geometry 데이터 형식으로 Redis에 저장하고, 3,000ms마다 GRADIUSBYMEMBER 함수를 이용해 접속한 유저의 5km 범위의 최대 50명까지 조회할 수 있습니다. 현재는 다른 사람과의 거리를 서버에서 5km를 명시하고 있지만, 추후 사용자가 500m, 1km, 5km 순으로 조회하는 범위를 선택할 수 있도록 개선하면 좋을 것 같습니다.
Socket Redis 통신 구조
MySQL 서버와 Node.js Sequelize 가 통신 되지 않던 max allowed packet 오류를 수정하였습니다. 목요일 오전 갑작스럽게 사용자의 일정 정보를 불러오는 것에서 오류가 발생한다고 프론트 엔드 팀원에게 이야기를 들었습니다. 문제 확인을 위해 pm2로 실행 중인 서버에서 발생하는 오류가 어떤 것인지 확인해보았고, max allowed packet 오류인 것을 확인했습니다. 에러 메시지의 내용은 Sequelize 에서 MySQL로 보내는 Query의 길이가 길어서 발생하는 문제라고 하였고, 해결방법을 찾아보았을 때 MySQL 서버에서 packet 크기를 늘린다면 해결할 수 있다고 하였습니다. 하지만 단순히 MySQL 서버에서 수신하는 packet을 확장하면 해결할 수 있겠지만 받는 부하는 동일하게 크기 때문에 적절한 방법이라 생각하지 않았고, Node.js 서버에서 작성되어있던 코드를 확인해보았습니다. 코드는 전혀 최적화가 되어있지 않은 Raw Query였고 즉시 수정이 필요한 상태였습니다. 서브쿼리를 순서대로 분해하고 해당하는 기능에서 공통된 부분을 찾아 Sequelize로 일괄 조회하도록 수정하였고, 데이터 가공을 MySQL이 아닌 Node.js 서버에서 담당하도록 변경하여 정상적으로 동작할 수 있었습니다.
max allowed packet 오류가 발생한 Raw Query
트러블 슈팅 문서를 작성하였습니다. 팀장 주간 회의에서 기능 구현의 목표 날짜를 다음 주 월요일로 정하였고, 화요일부터는 사용자 피드백을 받기 위해 기획 정비 및 광고를 시작해 사용자를 유치할 수 있어야 합니다. 회의가 진행된 금요일부터 월요일까지 3일이란 시간이 남았고, 현재 프로젝트의 문제점을 확실하게 인식하고 순차적인 해결 하기 위해 트러블 슈팅 문서를 작성하였습니다.
월요일까지 구현해야 할 배포 트러블 슈팅 문서
백 엔드 구현 목록
Socket GeoRedis 적용 ☆ 21.8.17
Jenkins CI CD 파이프라인 구현 21.8.18
Sequelize Seed 기능으로 DB 데이터 관리 21.8.18
Sequelize.Seeder 작성 후 테스트 코드 post, room, friend, user 수정 21.8.18
MySQL DB 구조 변경 21.8.21
배운 점
API 문서 작성 방법
Redis-cli, GeoRedis
Socket.IO
AWS Route 53, Cloud Front
MySQL View, Event Scheduler
Naver Cloud SENS
트러블 슈팅 문서 작성 방법
나의 생각과 이야기
중간 발표의 후유증 때문에 월요일이 상당히 힘들었습니다. 무언가를 완료했다는 안도감과 성취감은 다음 목표가 남아있음에도 사람을 늘어지게 만드는 것 같습니다. 시간이 지날수록 의욕이 점차 회복되기는 했지만, 다시 되돌아보았을 때 월요일을 열심히 보냈다고 느껴지지 않았습니다. 다음부터는 이런 상황이 발생했을 때 마음을 다잡을 수 있도록 마인드 컨트롤(?)을 해야 할 것 같습니다.
MySQL, Redis의 새로운 기능들을 많이 사용해본 일주일이었습니다. SQL 튜닝을 위해 사용한 VIEW, 정기 이벤트를 위해 사용한 Event Scheduler, 일정 반경 내부의 좌표를 출력하는 GEORADIUSBYMEMBER 등 알고 있기는 했지만 실제로 프로젝트에 적용해본 적 없는 기능들에 대해 상세하게 배운 것 같습니다.
이번 팀장 주간 회의에서 많은 기획이 수정되었습니다. 이메일 기능을 삭제하고 핸드폰 번호로 대체하거나, 초대 알람을 문자로 전송하거나, 사용자가 서비스를 종료하더라도 마커가 남아있거나 등 변경되어야 할 기능들이 많이 생겼습니다. 기획에 관해 확실한 생각을 하고 있었다면 많은 피드백을 받지 않았겠지만, 기능 구현에 많은 힘을 쏟아붓고 있었기 때문에 기획을 등한시한 것 같습니다. 남아있는 일요일, 월요일에 모든 기능을 수정하고 화요일 사용자 피드백을 받기 위한 준비를 할 수 있으면 좋을 것 같습니다.
이번 주부터 코딩테스트를 연습하고 있습니다. 기존에는 Python을 이용해 백준에서 공부하였지만, Javascript를 이용해 코딩테스트를 준비해야 할 것 같아 프로그래머스에서 매일 1문제씩 풀고 있습니다. 마지막 코딩테스트 문제를 푼지 2달이 지난 상태에서 새롭게 Javascript로 문제를 풀고 있는데, 상당히 많은 부분에서 막히고 있습니다. Array를 가공하거나, Math 함수에서 사용할 수 있는 기능을 순수하게 코드로 구현한다거나, Int, String을 변경하는 등 논리 구조에 대해서는 이해를 하고 있지만, Javascript로 코드를 구현하는 부분에서 막힘이 많이 발생하는 것 같습니다. 실전 프로젝트가 종료되기 2주 정도의 시간이 남았는데, 꾸준하게 연습해서 실력을 쌓을 수 있도록 노력해야겠습니다.
