20220321 개발일지 #남은 3주 동안에는..

중간발표를 무사히 마쳤다.

지난 주 내내 중간발표때문에 조급했었는데, 다행히 잘 끝났다.

 

생각하지 못한 부분에서 질문을 많이 받았고, 앞으로 남은 3주 동안 어떻게 할 것인지에 대해서도 얘기해봤다.

백엔드가 비교적 기능 구현이 빨리 끝났고, 이후에 기능 추가나 성능 개선하는 부분에서 선택지가 너무 많아서 어떤 걸 해야할 지 계속 고민이 많았다.

 

중간발표 때 받은 피드백을 중심으로 기본적인 부분에서 미흡한 부분을 개선하기로 했고, 깃허브의 기능들도 더 적극적으로 써보기로 했다.

그리고 백엔드에서는 다음의 3가지에 초점을 맞추기로 했다.

 

- 배포 자동화와 무중단 배포

- 테스트 코드 작성

- DB

 

배포 자동화와 무중단 배포는 프로젝트에 도입해보고 싶었던 기능이기도 하고, 정식 배포 전에 기능을 구현해놓으면 이후에도 서비스 중단없이 계속 코드를 수정할 수 있을 것 같아서 우선적으로 작업하기로 했다.

 

테스트코드는 이전에 생각하던 성능테스트와 관련이 있다.

DB에 Redis를 도입해서 조회 성능이 개선되는지를 확인하고, 성능테스트를 통해 개선 후에 더 많은 요청에도 서버가 잘 작동하는지 확인하려고 했다.

그런데 성능테스트로 Jmeter를 설치하고 테스트를 해보면서 테스트 시나리오를 어떻게 짜야하는지 전혀 감이 잡히지 않았다.

중간발표 때 다른 조 피드백을 들으면서, 이런 식의 성능테스트를 진행하기 위해서는 먼저 유저들이 어느 시간에 어느 정도 규모로 요청을 보내는지 데이터가 먼저 필요하다는 것을 알게되었다.

먼저 현재 서비스를 파악한 뒤에, 개선할 부분에 목표를 세우고 그 결과를 성능테스트를 해야하는 것이다.

그런데 현재는 이런 데이터가 전혀 없고, 단순히 Redis 도입으로 조회 시간이 개선되는 걸 확인하는 것은 postman으로도 충분히 확인 가능하다.

 

그래서 우선은 성능테스트 부분은 제외하기로 했다.

그리고 중간발표 때 들은 것처럼 서비스의 안정성과 신뢰도 측면에서 기본적인 테스트 코드를 작성하기로 했다.

지속적인 수정이나 변경 상황에서 지금처럼 postman으로 확인할 것이 아니라 테스트 코드를 작성해놓고 확인하면 DB를 건드리지 않고 수정 후에도 코드가 정상적으로 작동하는지 확인할 수 있다.

퀴즈와 관련한 부분에서 코드가 너무 하드코딩에 가깝다는 지적이 있었고, Random이나 +를 사용한 부분은 개선할 수 있을 것 같아서 테스트 코드 작성 후에 이런 부분들도 함께 수정하기로 했다.

 

그리고 DB!!

계속 고민이 많았던 부분이다.

중간발표 전에는 인메모리 DB로 Redis를 도입하는 것을 시도하고 있었다.

그런데 중간발표에서 전혀 고려하지 못했던 부분에서 피드백을 받았다.

필요없는 데이터라고 하더라도 데이터를 삭제하는게 좋은 선택은 아닐 수 있다는 것이다.

데이터를 삭제하는 대신 컬럼을 하나 추가해서 inactive한 데이터라는 조건만 줘서 필터링해주고, 쌓인 데이터는 나중에 이용자를 분석하고 서비스를 개선하기 위한 데이터로 사용할 수 있다.

 

솔직히 전혀 생각하지 못한 부분이었다.

프로젝트를 진행하면서 서비스 자체의 기능 구현에만 초점을 맞추었지, 이렇게 서비스 과정에서 쌓인 데이터를 분석한다던가, 이를 활용해서 서비스를 개선한다는 생각은 하지 못했다.

서비스를 하면서 꼭 필요한 부분이라고 생각했고, 그래서 DB와 관련된 부분을 바꾸기로 했다.

 

멘토링에서 필요없는 데이터를 바로 삭제하지 않고 모아놨다가 스케줄에 따라 다른 데이터 저장소로 옮길 수 있다는 것을 알았다.

찾아보니 데이터 엔지니어링과 관련해서 자세히 언급되는 분야인 것 같다.

관련해서 Data Lake라는 개념이 있다.

 

Data Lake는 현재 정의된 용도가 없는 비정형 원시 데이터를 저장하는 저장소로, 데이터 레이크에 있는 데이터는 쿼리전까지 정의되지 않으며 분석에 사용되거나 사용되지 않을 수 있다.

데이터 웨어하우스와 대비되는 개념이다.

 

모두 빅데이터와 관련되는 개념으로 등장한 것 같다. 

 

우리 서비스에 데이터 분석에 대해서까지 자세하게 진행하지는 못할 것 같지만, 현재 서비스에서 만들어지는 데이터들을 어떻게 관리할 것인지 어느 정도 틀은 잡을 수 있을 것 같다.

그래서 현재 삭제하던 데이터들 모두 삭제하는 것이 아니라 이용자 분석에 사용될 수 있는 부분이 있는지 검토하였다.

그리고 데이터 관리 전략은 나중에 정리 후에 github Wiki에 올리기로 했다.

 

일부 데이터는 게임 종료 후에 필요가 없다고 생각되어 삭제를 하기로 했고, 남기는 데이터들은 게임 종료 후에는 따로 처리를 하기로 했다.

그리고 github 이슈에 milestone을 새로 만들어서 관련된 이슈들을 관리하기로 했다.

 

Mysql을 일정한 스케줄에 따라 S3로 옮기는 방법은 AWS의 data pipeline이나 glue를 사용하여 가능한 것 같다.

그런데 data pipeline은 서울 region에서는 아직 서비스되지 않고 있고(현재 사용하는 EC2나 RDS는 모두 서울 리전이다), 서비스 지역이 제한되어서 인지 생각보다 자료가 많지 않았다.

glue는 비교적 자료는 많은데 단순히 데이터 이동보다는 분석 쪽에 더 초점을 맞춘 것 같고, 원하는 기능은 glue에서 아주 일부분이라 glue를 쓰는게 맞는지 잘 모르겠다.

그리고 aws 설정하는 부분이 생각보다 어려운 것 같아서 우선은 데이터 관리 전략을 설정하고 이에 따라 로직들을 수정하는 것에 초점을 맞추기로 했다.

 

스케줄에 따라 S3로 데이터를 옮기는 부분은 구현까지 하면 좋겠지만, 안되더라도 어떤 방식으로 데이터들을 관리할 것인지만 정해주어도 좋을 것 같다.

 

사실 찾아보면서 확인한것은 클라이언트 쪽에서 로그를 통해서도 유저가 어떻게 서비스를 이용하는지 정보를 확인할 수 있다.

그런데 현재 우리 서비스에서는 로그를 따로 관리하고 있지 않고, 우선 이용할 수 있는 정보들은 모두 모아놨다가 나중에 분석할 수 있도록 쌓아놓으면 좋을 것 같다고 생각했다.

추가로 서버 쪽 로그같은 경우에는 나중에 에러가 떴을 때 확인하기 위해서 확인하는 경우가 많은 것 같다.

 

서버 로그 정보도 따로 저장해서 S3에 저장할 수 있게 관리가 되면 더 좋을 것 같다.