Medium Rare design

[KumKeeHyun]

프로젝트 이름인 Medium Rare는 요즘 아주 애용하고 있는 사이트인 Medium을 흉내내보자 해서 이렇게 지었다. 즉 이 프토렉트는 Medium의 사용자 관리, 아티클 관리, 핫 게시물 관리, 사용자의 마이 리스트 관리 등을 아주 레어하게 구현할 예정이다.

마이크로서비스 아키텍처에 따라서 서비스를 만들어보는 것이 목표이기 때문에 서비스를 여러개로 나누어서 개발한다.

• User : 사용자 정보 관리, 인증 서비스(로그인/로그아웃)
• Article : 글, 댓글, 대댓글 관리 서비스
• ReadingList : 사용자가 최근 읽은 아티클 관리, 사용자가 저장했던 아티클 관리 서비스
• Trend : 아티클의 조횟수, 추천수를 참고하여 핫게시물을 관리하는 서비스
• Email : 사용자에게 각종 알림을 보내는 이메일 서비스

Medium의 장점은 추천서비스라고 생각하지만 나는 ML을 모르기때문에 사용자의 활동에 따라 원하는 아티클을 추천해주는 것 대신 에브리타임의 핫게시물처럼 다른 사용자가 많이 읽었던 것을 보여주는 느낌으로 대체해서 진행할 예정이다.

[KumKeeHyun]

느슨한~ 결합을 위해 이벤트 기반 비동기 통신(Kafka)를 최대한 활용할 예정이고 나중에 쿠버네티스에 올릴 것을 대비해서 API Gateway(krakenD)로 묶어볼 예정이다.

[KumKeeHyun]

마이크로서비스 한 개당 데이터저장소 한 개

각 마이크로서비스가 각각의 데이터저장소를 가져야 하지만 난 컴퓨터가 많지 않기 때문에 DB를 MariaDB로 1개만 실행하고 데이터베이스를 활용해서 각 서비스를 의미적으로 분리해서 진행해야 할 것 같다. Trend 서비스의 경우 쓰기 연산이 많아서 NoSQL을 사용하는 것이 적절하지만 여러가지 DB를 실행할 컴퓨터가 없다..

얼마나 완성도 있게 만들지

user-service를 먼저 구현하다 보니 너무 세부적인 기능을 구현하려 하면 복잡도가 너무 올라가서 프로젝트를 다 끝내지 못하고 군대에 갈것같다.. 몇가지 기능은 포기하고 진행하려 한다. 이 프로젝트는 쿠버네티스를 공부하기 위해 시작한 것이다. 2월 초까지는 끝내는 것을 목표로 하자

• 사용자에 대해서 회원탈퇴, 사용자 정보 변경은 고려 안함
  • 사용자 정보에 관한건 데이터 무결성을 관리하는게 너무 힘들 것 같다
• 사용자 role 계층 구현 안함
  • 예시서비스인데 너무 복잡도만 올리는 것 같다
• email 서비스 구현 안하는 쪽으로

[KumKeeHyun]

Kafka Consumer Group 이벤트 핸들러 구현

• sarama의 consumer group을 이용해서 구현
• 여러개의 토픽을 consume하고 각 토픽에 따라 지정된 이벤트 핸들러를 호출할 수 있도록 구현

type EventHandlerFunc func(key, value []byte) // 이벤트 핸들러 타입

er := erouter.NewEventRouter("trend", logger) // set groupID and zap logger
er.SetHandler("read-article", func(key, value []byte) {
    // handle 'read-article' topic
})
er.SetHandler("create-user", func(key, value []byte) {
    // handle 'create-user' topic
})
er.StartRouter()

Result

문제점

등록한 이벤트 핸들러마다 고루틴을 폴링해두고 먹스에서 각 고루틴의 채널로 카프카 데이터를 전달해주는 방식인데 만약 한 핸들러에서 처리속도가 느려서 채널이 꽉차면 라우터 전체가 병목현상이 생길 수 있다. 그렇다고 컨슘한 데이터 하나당 고루틴을 생성하려 하는 건 너무 낭비같다. 일단 컨슈머 인스턴스를 늘리는 쪽은 열려있으니까 그걸 가정하고 진행하려 한다