Project - Community Issue Keyword 개편 및 진행

---

title: Project - Community Issue Keyword 개편 및 진행
date: 2022-12-28
tags:

• Project

---

Introduction

재학 중인 학교 커뮤니티에서 학생회와 연계하여 한달간 현업에 계신 분들과 함께 프로젝트인 Devcamp 행사에 참여하였다.
행사 이후, 기존 멤버들과 프로젝트를 개선하고자 진행 중이다.

Devcamp 피드백

Devcamp 당시 많은 피드백을 받았다.
다행히 긍정적인 피드백도 존재하였으나, 개선 방향에 대한 피드백은 예상 이상으로 많았다.

• Architecture가 간소화 부분 및 자세한 부분으로 나누었는데, 두 부분이 연결되어 오해가 생길 수 있다.
• 프로젝트를 진행하는 당사자들은 Architecture를 쉽게 이해하겠으나, 처음 보는 사람은 이해가 어려울 수 있다.
• Blind를 추출하였는데, Blind의 게시글은 구어체 + 일기장 느낌이기에 잘못된 언어 사용이 많아 키워드 추출이 어렵다.
• 기존 Model이 추출한 키워드를 제공하던 중, 개선된 Model이 생기면 기존에 추출한 키워드를 그대로 제공하는 상황인데 과연 맞는 방향인가?
• DB가 Public Subnet에 노출이 되어 있어 보안 문제가 발생할 수 있다.

이 외에도 Engineering 및 Modeling 부분에 대한 피드백을 받았다.
그러한 내용들은 프로젝트의 일부 파트에 대한 피드백이고 너무 많아지기에 적지는 않는다.
이러한 내용들을 기반으로 팀원들과 미팅 및 논의를 진행하였으며, 종강 시기가 되어 다시 프로젝트를 진행하고자 한다.

Project Configuration

피드백을 기반으로 키워드 추출 도메인을 Blind -> Everytime으로 변경하였다.
멘토님께서 작업하신 Model이 존재하기도 하며, 데이터는 적어지더라도 학교라는 주제에 한정되어 있기에 키워드 추출이 용이하다.
또한 데이터가 적어지기에 실시간 키워드 대신 일간, 주간, 월간 키워드를 제공하게 되었다.
기존 Blind에 비해 Modeling에 대한 난이도가 낮아졌다고 볼 수 있다.

팀원 구성 및 일부 역할이 바뀌었다.
기존에 DB를 담당하시던 분과 Modeling 담당하시던 분이 바쁘셔서 프로젝트를 함께 진행하실 수 없게 되었다.
DB에 대한 부분은 필자가 담당하게 되었으며, Modeling은 한 분이 나가셨기에 남은 한 분께서 담당하게 되셨다.

Architecture

Architecture

현재 Architecture는 위와 같이 바뀌었다.
우선 상단의 간소화 부분과 하단의 자세한 부분을 격리하였다.
Service Component에서 Web을 띄울 예정이었으며, DB가 함께 존재하던 상황이었다.
Architecture에 대한 잘못된 이해 + 늦은 정보 공유로 인하여 생긴 문제이다.
우선 Web을 띄워 유저와 Interaction을 하는 부분을 하단의 Public Component로 격리하였다.
서비스가 방대해지면 DB를 별도의 Component로 나누어야 할 수도 있으나, 현재 문제가 없기에 Main Component로 옮겼다.
또한 기존에는 AWS RDS를 이용하였는데, 단일 Table이며 Select 작업이 주를 이루며, Insert 작업은 하루에 1~3번밖에 이루어지지 않기에 운영 비용 절감을 위해 MySQL을 직접 띄우기로 하였다.

Scheduler

기존에는 Airflow를 이용하고자 하였으나, ALB 문제로 인하여 Cronjob을 이용하여 마무리하였다.
업데이트 시각이 되면 많은 유저가 키워드를 요청할 것이다.
Cronjob에는 DAG에 대한 Dependency를 설정할 수 없는 상황이기에 여러 DAG를 이용할 수 없다.
이를 해결하기 위해 두 가지 방안을 고민하고 있다.
우선 Scheduler를 이용하되, Dependency를 설정할 수 있으며 적은 DAG만 운영하기에 가볍게 이용할 수 있는 Celery Beat를 검토 중이다.
또 하나는 Coroutine, await를 이용하는 것이다. 이전의 작업이 끝나야 다음 작업을 진행할 수 있으며, 여러 DAG이 하나의 DAG로 줄어든다고 볼 수 있다. 다만 프로그램의 결합도가 높아지는 단점이 존재한다.
위 두 가지 방안에 대해 검토 중이며, 정리한 후 팀원분들과 논의하여 정할 예정이다.

Discussion

Model이 서비스 도중 개선이 될 경우, 최신 정보와 DB 정보가 맞지 않는 문제가 발생할 수 있다.
이를 실시간으로 업데이트할 경우, 많은 유저가 동시에 키워드를 요청하는 동시성 문제가 발생할 수 있다.
Message Queue + 추가 Table + Model에 Version을 추가하여 이 문제를 해결하고자 하였다.
다만 이를 제안하는 과정에서, 팀원분들께서 해당 방식에 공감을 하지 못하셨다.

• MQ를 써야만 동시성 해결이 가능한 상황인가요?
• MQ때문에 Overhead가 발생하여 키워드 서비스가 더 오래 걸리지는 않을까요?
• 업데이트 대신 기간 + Version을 PK로 지정, Insert로 작업하고 나중에 오래된 정보를 Delete하는 방식은 어떤가요?

이러한 의견을 받게 되었고, 우선 MQ를 이용한 동시성 문제 해결은 보류하게 되었다.
서비스 특성상 전날의 키워드, 주간 및 월간 키워드에 대한 요청이 많이 들어올 것이다.
개선된 Model을 다음날부터 이용하면 많은 요청에 대해서는 동시성 문제를 고민하지 않아도 된다.
팀원들을 설득하는 과정에서 자세한 설명 및 동시성 처리 예시가 부족하여 설득에 실패하였다.
팀원분들께서 피드백하신 내용들을 종합적으로 고민하여 더 많은 근거를 준비하고자 한다.

Conclusion

행사 마감 이후, 프로젝트를 진행하지 못하는 기간 동안 많은 고민을 하였다.
긴 시간 동안 고민한 덕분에 생각하지 못한 문제도 발견하였으며, 기존에 존재하던 문제를 다양한 시각에서 바라볼 수 있었다.
오래 준비한 만큼, 성공적으로 프로젝트를 마무리하기 위해 노력할 것이다.