당근 서버 밋업 1회 정리

당근마켓 밋업끝나고 게더타운에서 개인적으로 궁금했던 부분들을 당근/배민분들과 나눈 이야기를 정리합니다.

질문. 데이터베이스 테스트는 어떤 형태로 진행하는지. 테이블 DROP/CREATE 및 유즈케이스별 더미데이터를 넣는작업에 시간소모가 너무 크다.
- 현재는 디비 테스트는 진행하지 않는다. 예전에는 유즈케이스별로, 예를 들어서 회원가입을 하면 어떠한 푸시알림이 가고 어떤 데이터가 저장되고 하는 일련의 행동자체를 묶어서 테스트했다. (BDD 말하는듯) 이러한 경우 테스트가 한번 돌 때 2시간 정도 걸렸다.
- 테스트 데이터는 직접 케이스별로 필요한건 직접 다 넣어줬다.
- 조회용 쿼리의 경우 생각해보면 테이블을 날리고 재구성하는 작업이 필요하지않다. 조회에 필요한 데이터가 있다면 해당 쿼리는 디비를 한번띄우고 그대로 재사용할 수 있다. (제 생각엔 이 방법이 저희가 바로 적용할 수 있는 간단하고 좋은 방법인 것 같습니다)


질문. CQRS에 대해서 찾아보면 이벤트를 모두 저장하고 나중에 리플레이해서 최종 결과를 얻어내는 이벤트 소싱패턴이 자주 엮여서 나오는 것 같다. 그런데 그 과정이 정말 필요한 지, 이벤트 소싱은 나중으로 미루고 그냥 단순히 조회용DB, 쓰기용DB로 나누고 쓰기-조회 DB간 데이터는 이벤트 드리븐으로 구성하여 최종적 일관성을 유지하면 안될지
- 요즘에는 그렇게 하는 추세이다. (라고 했던 것 같은데 잘 기억이 안나네요) 팀바팀이지만 배민같은경우에도 이벤트 소싱은 제외하고 단순히 쓰기/조회 DB만 분리하고 메시지큐를 통해 동기화를 진행하고 있다.

질문. CQRS에서 조회용 뷰가 달라지는 경우 어떻게 하나요? 예를 들어서 user_id, name 두개의 필드만 존재하는 뷰에 맞춰 설계했는데 추후 email 필드도 추가적으로 필요해지는 경우에는 기존 뷰에 저장되어있던 모든 데이터에 email을 넣어주는 일종의 마이그레이션 작업이 필요할텐데.
- 그런 경우 기존 DB?테이블? 을 건들지 않고 새롭게 하나 더 만드는 게 좋다.

질문. 조회용DB는 보통 레디스를 사용하나요?
- 레디스를 많이 사용한다. 그리고 레디스에는 같은 인터널 서비스 데이터의 결과를 담는 용도로도 많이 사용한다.

질문. DB쓰기 지연 발생 대처방법에 대해
- 케바케이다. (저희는 현재 저장한 데이터가 바로 필요한 경우 writer에 쿼리를 바로 쏜다고 했더니) 그런 방법도 사용하고 있다.

질문. Node.js -> Kotlin 전환 시 엔드포인트를 하나씩 옮겨가는 단계적 전환을 하지않고 전체를 한번에 전환하는 방식을 사용했다고 하셨다. 그렇다면 각 엔드포인트별로 많은 테스트가 필요할테고 그에 따라 오류 발생확률이 높아질텐데 이유는?
- 사실 기존 엔드포인트를 옮겨가기보다는 버전을 올리는 작업이었다. 따라서 각 API별로 유즈케이스가 기존과 다르게 동작하는 새로운 버전이라고 생각하면 된다.

질문. 전환하며 Hexagonal architecture 도입했다고 하셨다. Hexagonal이나 Clean이나 거의 동일한 패러다임 선상에 있다고 생각하는데, 관련해서 불편함을 겪은게 있었나?
- 포트랑 어댑터를 만들어야하기 때문에 중복코드가 발생하게 된다. 따라서 하나의 유즈케이스에 해당하는 API를 설계할 때 기존보다 생산속도가 떨어질 수 밖에 없기에 팀원들끼리 찬반논란이 있었다. 모든 팀에서 사용하는건 아니고 사용하는 팀이 있고 사용하지 않는 팀이 있다.
- 상황에 따라 다른 것 같다. 빠르게 개발하여 유저에게 가치를 줘야하는 작업이 우선순위라면 Hexagonal을 채택하지 않고 기존의 Layered architecture를 따를 것 같다.

질문. 위치기반 서비스를 위해 데이터베이스는 무엇을 사용하나요? PostgreSQL이면 EARTH타입을 사용해서 구현하셨나요?
- 원래 PostgreSQL을 사용하고 있었는데 우버처럼 H3로 이전했다. (한국의 경우 시군구 구분이 굉장히 명확하여 문제가 없었는데 글로벌 서비스를 하다보니 까다로운 경우가 많았기 때문)

당근마켓은 전사적으로 DDD를 도입하여 사용하고있고 모든 서비스가 MSA구조이지만 CQRS는 적용하지 않은 상태라고 합니다.