-
Node.js & mongoose 히스토리 관리 2편프로젝트/개발자 지름길 2021. 12. 6. 15:31반응형
히스토리 관리를 위해서 mongo.watch를 활용했다. 계속 의문이 생겨서 조금 더 공부하면서 고수분들에게 조언을 얻기 위해서 커뮤니티를 돌아다녀봤다. 그 결과, mongo.watch를 사용할 때 또 다른 단점이 있음을 알게 되었다. scale out할 때, 각 서버마다 똑같은 이벤트가 생겨난다는거다.
가장 큰 문제는 스케일 아웃할 경우, 동일한 이벤트가 모든 서버들에서 발생한다. 또한, 해당 스트림은 라운드로빈 방식으로 스케줄링이 안되는 이벤트 기반이라서 스케일 관리가 어렵다. 만약 스트림에서 이벤트 받아서 처리할 경우, 트래픽이 많아져서 속도가 느려지기 시작하면 곤란해진다.
몽고에서 공식 지원하고 사용을 추천하는 CDC 기능이기에 나쁘지는 않다. 하지만 트래픽이 많이 몰릴 가능성이 있는 컬렉션이라면 change stream -> queue stream -> 도메인에 따라 분배하는 작업이 필요하다. 사용할 때, resume token은 꼭 같이 활용해야하며, stream이 죽으면 failover에서 change stream도 결국 oplog 기반이라 oplog 데이터 저장 기간을 함께 잘 고려해야 한다.
change stream -> queue stream 관련하여 구현하려면 아래 링크를 찾아보면 된다.
https://docs.mongodb.com/kafka-connector/current/
https://docs.mongodb.com/kafka-connector/current/sink-connector/fundamentals/change-data-capture/
결론
흠... 현재 내가 구현한게 틀린 방법은 아니며, 대규모 트래픽에서 문제가 될 수 있다는거다. 트래픽이 많아지면 그에 맞는 처리 방법이 별도로 필요하다는게 가장 큰 문제다. 특히나 scale out을 하기 시작하면 그렇다. 아마 내 서비스가 scale out을 하려면 오랜 시간 걸릴 것으로 예상된다. 그렇기에 지금 소스코드를 그대로 활용해도 괜찮을거라고 본다. 훗날 서비스가 커진다면 개이득인 부분이니까... 그때쯤 되서 지금 이 글을 읽으면서 하나씩 수정해나갈거 같다.
만약에 대규모 트래픽 처리를 요구하는 회사에 취업한다면, 당장에 이런 기술들을 공부하는게 중요할지 모른다. 그래도 지금은 이러한 키워드가 있음을 알게 되었다는거 자체가 중요하다. 나중에 문제가 생길 경우, 내가 어떻게 나아갈지 알게 되었다는 의미다.
솔직히 지금도 소스코드를 뜯어 고치고 싶은 욕구가 생기고, 더 깊게 공부하고 싶다. 하지만... 이런 내 욕심을 이루려면 서비스 만드는 기간을 1년으로 잡아도 모자를거다. 그러니 서비스 오픈과 운영에 있어서 당장 2~3년 뒤까지 바라보면서 소스코드를 작성해나가면 될거 같다. 어쨌든 결론은 수정하지 않겠다는거다. 나중에 여유가 생기면 조금 더 깊게 파보면서 이와 관련하여 처리할 수 있도록 하자.
반응형'프로젝트 > 개발자 지름길' 카테고리의 다른 글
퍼블리싱... (0) 2021.12.17 AWS EC2 인스턴스 HTTPS 서버 설정 (인증서 자동 갱신) (0) 2021.12.08 aws ec2 인스턴스를 활용한 서비스 오픈 (feat. git, Node.js) (0) 2021.12.04 REST API 적용 (0) 2021.12.03 알람 기능 구현 (Node.js) (0) 2021.12.03