[채팅 서비스 마이그레이션] 백엔드 직무 체험 2주차회고

 

📌 직무부트캠프 채팅 마이그레이션 백엔드 직무 체험 2주차 회고

2주차 부터는 본격적으로 프로젝트를 분석하고, 마이그레이션 계획을 세우는 것 이었다.(두근두근)

 

 

 

 

📌 어떤 테이블을 마이그레이션 해야할까?

# 마이그레이션 테이블 선정

마이그레이션 테이블 선정함에 있어서 말도 안되는 실수를 저질렀다.

"그냥 데이터 많이 쌓이는 테이블을 옮기면 되는거 아니야?"

부끄러운 수준의 생각이다.. 그냥 같은 건 없다. "데이터가 많이 쌓이는 테이블을 옮겨야한다" 라는건 맞는 말이겠지만 조금 더 구체적인 기준과 이유가 정리되어야 한다.

 

최종적으로 나는 chat, chat_like, user 테이블을 선정하였고, chat과의 연관관계(join을 통한 결합 등)를 근거로 제시하였다.

chat데이터 응답이 user, chat_like를 포함하고 있었기 때문에, 위의 3개의 테이블이 서로 다른 DB에 있으면 join연산해오기 번거롭다고 생각했기 때문이었다.(쿼리문이 더 많이 사용되어 성능상 우려가 있음)

-> 이러한 선택에 대한 결과는 피드백에서 설명하겠다.

 

# 테이블 구조의 변경점 확인

chat, chat_like, user 테이블을 마이그레이션 하겠다고 결정했기 때문에, 어떤 점이 기존 코드에서 변경되어야 하는지 확인해야 했다. 현재 NestJS의 TypeORM을 통해서 데이터를 사용해주고 있었는데, 테이블이 분리되어야 하기 때문에 기존의 연관관계를 제거해줘야 한다. 엔티티를 엔티티가 가지는 관계가 아닌, 엔티티간에 ID참조를 통해서 관리되도록 변경해야 했다. 추가적으로 분리되는 테이블간에 join연산은 더 이상 사용할 수 없기 때문에 별도로 쿼리문을 추가해주는 작업도 필요 할 것이라고 생각했다.

 

 

 

 

📌 피드백

# 테이블 분리에 대한 고려 기준 선정

나는 테이블을 분리함에 있어서 비용효율, 쿼리문/join관계에 따른 성능만을 고려하였다. 하지만 실제로 고민해봐야 하는 고려사항은 더욱 많았다. 비용 효율과, 성능, 비즈니스, 보안, 장애대응 등 여러가지 고민해봐야 하는 사항들이 존재하였다.

이러한 기준은 백엔드 개발자들이 항상 생각하고 고민해보야 하는 개념들과 같은 것 같다.

사실 직무 부트캠프의 첫 OT에 백엔드 개발자는 어떤 일을 하는가? 에 대한 세션이 있었는데 모두 한번씩 언급되었던 내용이라 기본을 놓치게 된 것 같아 아쉬움이 있었다.

• 비용 효율화 -> chat 테이블의 경우 데이터가 급속도로 증가해 비용을 많이 차지한다. 반면에 chat_room, chat_join, chat_like테이블은 데이터 증가속도가 높지는 않다.
• 성능 -> chat_like와 chat테이블이 다른테이블에 있으면 메세지별로 좋아요 검사가 필요하다. 성능에 저하가 우려됨.
• 비즈니스 고려 -> chat_room, chat_join은 비즈니스에 지속적을 필요할 수 있음(홍보, 여러 서비스 활용 등) 그러므로 core 데이터베이스에서 관리. chat_like 데이터는 비즈니스 활용도가 떨어짐. core에서 관리할 필요가 없음.
• 보안 -> 민감한 개인 정보는 내부 직원들도 접근이 불가능 하도록 해야한다. 이런 측면에서 chat데이터는 접근을 막아야하는 민감한 정보이다. 그러므로 분리를 고려한다. chat_room, chat_join은 내부 개발자들이 접근해도 괜찮은 정보들이다.(비즈니스 등으로 활용할 수 있어야 한다.)
• 장애 대응 -> 메세지 트래픽이 높아져 채팅 메세지를 사용할 수 없더라도 다른 기능은 동작해야한다. 대표적으로 char_room, chat_join, user는 채팅 데이터베이스 장애가 발생해도 이용할 수 있도록 해야한다. 

위의 측면들을 다방면으로 분석하고 비교를 해서 마이그레이션 테이블을 정해야 한다. 그렇게 chat, chat_like 테이블이 선정되었다. 내가 선택한 user테이블은 비즈니스 로직에 가까운 테이블이므로 core데이터베이스에서 관리되는게 좋다. 또한 user 테이블에는 개개인의 민감한 정보가 들어갈 수 있는 중요한 테이블이므로 core데이터베이스에서 안전하게 관리해주는 것이 좋다.

추가적으로 chat응답데이터의 user(sender)정보는 id참조를 통해서 가져오고, redis같은 캐시를 활용한다면 성능을 보완할 수 있다.

분리 기준 예시

 

 

 

# 기준에 따른 trade-off 분석

2주차 피드백을 받고 가장 크게 깨달았던 점이 있었다. 모든 선택지에 정답은 없고 trade-off만이 있을 뿐..!

각각의 기준에 대해 분석된 결과를 바탕으로 어떠한 선택을 할지, 왜 이러한 선택을 했는지에 대한 고민이 정말 중요하다고 느꼈다. 계획을 선택함에 있어서 완벽한 정답은 존재하지 않는다. 각각의 장/단점이 분명히 존재하고, 어떤 우선순위에 중점을 둘 지는 개발자의 선택에 달려있다.

"어떻게 마이그레이션 해야할까?" 라는 스스로에 대한 막연한 질문으로 인해 고생을 했던 것 같다. 가장 기초적인 것 부터 하면 되는데..!

2주차 이후로 나는 항상 어떠한 선택이 주어지면 여러 관점에서 어떻게 될지 결과를 예측/분석하고 정리 보려고한다.(이렇게 보니 당연한걸 왜 안했나 싶은...)

멘토님의 피드백이 너무 인상깊어서 조금 충격을 받았습니다..두두둥..