최고 품질의 상품들을 지금보다 더 많은 소비자들이 여러 유통 채널에서 더욱 폭 넓고 쉽게...
자유양식
[끊임없는 배움과 다양한 이해를 위해]
디프만 11기 프로젝트 백엔드를 완성한 후, 운영을 위해 새로운 인원들과 기존 프로젝트의 내용을 다시 파악했습니다.
이 때에 기존 제가 공부했던 방식과는 많이 다른 방식을 배우게 되었습니다.
- 연관관계의 제거
기존의 프로젝트는 여러 데이터들이 연결될 때에 FK로 연결하였고 이들을 DB에 매번 연결하여 가져왔습니다.
그리고 변경된 내용에서는 FK를 제거하게 되었습니다.
그 이유는 총 두 가지가 제안되었는데,
1. FK자체가 갖는 성능 저하 이슈
2. 설계 변경에 따라 데이터의 유지보수 간략화
이었습니다.
그동안 연관관계를 설정하여 데이터 간의 정합성을 맞추는 것이 매우 중요한 것으로 알고 있었기 때문에 위와 같은 내용을 확인하였을 때에 제안된 내용을 신뢰하지 못했습니다.
또한, 이외에도 FK의 오버헤드가 성능 저하를 유발한다고 하지만 JPA상에서 데이터를 호출할 때에 외래키와 조건을 동시에 사용하면 더 오히려 빠르게 데이터를 가져올 수 있으니 이 방식이 옳다고 생각하여, 이 연관관계 제거를 반박하기 위해 다양한 레퍼런스를 참고하여 공부해 보았습니다.
- 캐싱 서버와 정합성 검증 로직
그리고 여러 글이나 기존 서비스를 참고하여 확인해 보았는데, 다양한 서비스에서 FK를 실제로 쓰지 않는다는 이야기를 듣고 놀랐습니다.
여기에는 Redis와 같은 NoSql을 통한 캐싱이 큰 도움을 주었다고 하는데, 미리 데이터를 저장해 놓고 정합성을 잘 검증하기만 하면 매번 DB와의 통신을 하지 않고도 쌓여 있는 데이터에서 필요한 것을 뽑아 사용할 수 있다고 했습니다.
즉 미리 모든 데이터를 캐싱시켜 두고, 이 데이터들을 상황에 맞추어 쓰기만 하면 되기 때문에 자체적으로도 오버헤드도 있고 최근 IT의 발전에 따라 다양한 DB상의 변화가 이루어 지는데, 이로 인한 데이터의 변경이 생겼을 때에 여러 부분에서 적용이 힘든 FK를 제거할 수 있다는 내용이었습니다.
그동안 알고 있던 내용 외에 다양한 이유로 새로운 페러다임이 제시되었다는 것이 신기했고, 또 재미있는 내용이었어서 이에 관한 공부를 추가로 진행해 보았습니다.
- 실제로 적용하고, 확인해 보며
이 때에 배운 FK제거와 Redis사용을 통한 DB부하 제거에 관한 다양한 스터디 중에 있습니다.
그리고 저희의 상황에 맞추어 내용을 조금씩 변경하고 이에 따른 Trade-off를 살펴 보는 중입니다.
예를 들어 캐싱 서버를 따로 두는 것은 예산에서 처리하기 힘들 것이라 생각하여 Spring boot 서버에서 Redis를 붙이거나 FK는 ERD상에서는 적용하고 실제로는 제거하는 등의 부분입니다.
현재는 개발 참여 인원들이 해당 내용에 대해 잘 알지 못하는 상황이라 이전에 내용을 공부한 제가 스터디를 진행하고 있고, 매 주 공부한 내용을 서로 발표하고 토론하고 있습니다.
이를 통해 기존에 제대로 알고 있다고 생각한 것도 금방 바뀔 수 있다는 것을 알았고, 지금보다 더 열심히 공부하고 새로운 것을 익히고 싶다는 생각을 갖게 되었습니다.