목차
- 느낀 점
- 진행 내용
- 문제 및 해결 방법
느낀 점
- 기술 스택을 선택할 때, 명확한 기준을 통한 비교를 할 필요성을 체감
- 당장 수요에 맞는 가벼운 기술을 선택하되, 규모가 커질 것을 대비하여 확장성을 고려해야 함.
- MVP(Minimum Viable Product)를 정의 내리고 이를 기준으로 기존 기술 스택 선택이 타당성을 검토해야 함.
- 결론:
- MVP: postgresql, redis, rabbitMQ, golang - gin
- 확장: mysql, memcached, kafka, mongodb
진행 내용
- 설계도에서 서비스별 사용하기로 한 기술스택에 대한 대안 검토
문제 및 해결 방법
[1] 기술 스택 선택에 대한 명백한 근거 부족
- 기술 스택 선택에 대한 명백한 근거가 부족.
- 현재 기술 스택의 장단점을 명확히 파악하지 못하고 있음.
- 단순히 유명하고 핫하기 때문에 선택한 경우가 많음.
- 기술 스택의 장점을 활용하지 못하고 있음.
- 이에 따라 이미 사용 가능한 기술을 충분히 활용하지 못하고 있음.
- 프로젝트가 진행되기보다 새로운 기술을 학습하는 데 더 많은 시간을 할애하고 있음.
[1] 해결 방법
-
모듈 혹은 서비스 별로 사용되는 기술스택의 대안을 조사하고, 이에 대한 비교를 통해 명확한 기준을 세움.
- 웹서버
- 현재 사용중인 기술 스택: golang - gin
- 대안: node.js - express, java - spring boot, python - fast api
- 기존 기술 선택 이유: golang이 가진 웹서버 성능 및 동시성 처리에 대한 장점.
- 의문점
- 다른 기술 스택에 비해 golang은 어떤 점에서 동시성 처리에 더 유리하다고 말할 수 있는가?
- 데이터베이스
- 현재 사용중인 기술 스택: postgresql
- 대안: mysql
- 기존 기술 선택 이유: 사용 경험이 있음
- 조사 결과 PostgreSQL은 mySQL에 비해 복잡한 동작을 필요로 할 때 사용하는 기술 스택으로 알려져 있다.
- 팀원들도 mysql에 경험이 더 많은 편이므로, mysql로 이전하도록 생각하고 있다.
- NoSQL
- 현재 사용중인 기술 스택: mongodb
- 대안: 유저 정보 저장에 사용하는 SQL 데이터베이스에서의 통합
- 기존 기술 선택 이유: 문서형 데이터베이스로서 가지는 장점이 있다는 점.
- 문제점
- 그 장점이 뭔지 모름
- 문서형 데이터베이스가 무엇인지도 잘 모름
- mongoDB의 장점
- 데이터 형태에 구애를 덜 받으므로 이모티콘과 같은 string 외 다양한 데이터를 처리하는 데에 용이하다
- 채팅 방 단위로 데이터를 구현시에 기존 데이터를 신규 입장자에게 제공하기 유리하다
- RDBMS의 장점
- string만 사용할 경우 table과 로직을 통해서 기초적인 채팅을 빠르게 구현할 수 있다.
- 선택: RDBMS(mysql/postgresql) 중에 하나로 채팅의 interface를 구현하고, string에 한정한 뒤 방 입장시에 접속 이전 데이터를 제공하지 않는 방향으로 mvp를 구성한 뒤에 기능을 확장하는 과정에서 mongoDB 도입을 고려한다.
- 추가적인 mongoDB 및 문서형 데이터베이스에 대한 연구 필요
- 세션
- 현재 사용중인 기술 스택: redis
- 대안: memcached, 세션이 아닌 토큰(JWT 등)을 사용
- 기존 기술 선택 이유
- 사용해 본 적이 있는 기술 스택
- 유명해서 자료를 구하는 것이 용이
- 참고 자료
- Memcached
- 장점
- 적은 메모리 사용량 - 적은 메타 데이터
- 안정적인 응답 시간
- 데이터 변경이 적은 경우 메모리 파편화가 적음
- 수평적 확장이 쉬움 - multi-threading 지원
- 단점
- 적은 데이터 타입과 API
- 데이터 변경이 잦은 경우에 파편화가 많이 발생
- 장점
- Redis
- 장점
- 다양한 데이터 타입과 기능
- 많은 사용자
- 디스크에 저장 가능
- Key에 저장할 수 있는 데이터의 크기가 큼
- pub/sub을 지원해서 메시지 큐로도 사용 가능
- 단점
- 메모리 사용량이 많음(실제 필요량보다 2배 가까이 사용하는 구조)
- 트래픽이 많은 경우 응답 시간이 불안정 - 발생 가능성 낮음
- 장점
- 선택
- MVP의 관점에서 더 빠르게 시작할 수 있는 것은 Redis이다. 이는 기능 및 데이터 타입을 여럿 이미 구현돼 있기 때문이다.
- 트래픽이 많은 경우에 응답 시간이 얼마나 불안정해지는지 측정할 방법을 마련해두고, 그에 따라 Memcached로 전환할지 여부를 결정한다.
- Redis를 사용하면 다른 기술 스택 없이 메시지 큐를 처리할 수 있을 지도 모름
- 메시지 큐
- 현재 사용 예정이었던 기술 스택: kafka
- 대안: RabbitMQ, ActiveMQ
- 기존 기술 선택 이유
- 메시지 큐 기술들 중 가장 유명해서.
- 추가적으로 따로 글을 파서 고민해봐야 할 듯
- 참고 자료
- kafka의 장점
- 분산 처리 기능을 가장 잘 활용할 수 있음.
- 메모리가 아니라 파일 시스템을 이용한다.
- TPS가 높고 대용량 실시간 로그 처리에 유리하다
- broker가 push하는 것이 아니라 pull하는 방식
- activeMQ vs rabbitMQ
- rabbitMQ가 더 다양한 프로토콜을 지원하고, activeMQ는 java에 더 특화된 모양이라 이 부분은 연구 필요
- 선택
- RabbitMQ로 MVP를 구현하고, 확장성이 필요할 경우 Kafka로 전환하는 방향으로 진행한다.
- RabbitMQ가 kafka에 비해 보다 기능이 간단하고 빠르게 구현할 수 있을 것으로 예상되기 때문
2024-03-19