백엔드 시스템을 간소화 해야 하나

선요약

- 잘 안쓰는 서비스 걷어내고 싶음

- 결론을 내는게 아닌 고민의 과정임

 

백엔드 시스템에 뭐가 많다

이전에 작성 한 시스템 구성도를 다시 보게 되었다. 메인 데이터베이스, 오브젝트스토어, 검색엔진, 캐시스토어, 파일스토어, 웹서버 등...  나름 필요와 목적에 맞게 구성된 시스템이다. 아쉽게도 시장 반응이 기대에 미치지 못해, 트래픽이 낮다보니, 관리 요소만 늘어나 있는 것 같고, "이것도 있고 저겄도 있고 뭐가 많네..." 라는 느낌을 지울 수 없고다. 필요에 의해 구성되어 있는 것 보다는 필요 할 것 같아서 구성된 시스템이다.

 

비유를 하자면, 문 손잡이 고치는데  "드라이버"만 있으면 가능 하지만, 어짜피 구매 하는거 "공구 세트"를 구비한 느낌이다. 구비 해두면 언젠가는 사용 하고, 남들도 그렇게 하니까. 하지만, 중간중간 배터리 충전도 해야하고 기름칠도 해야하고, 막상 시간이 지나서 사용하기 애매한 공구들도 생기고, 더 좋은 공구가 나왔다. 결국 진짜 필요한 시점에 새로운 공구 세트를 "재구매" 할 것 같다.

 

이게 진짜 필요 한가

많은 트래픽을 대비 또는 빠른 응답 속도를 대비 하기 위해 공용 캐시 스토어가 있다. 캐시 스토어로 redis를 사용 하고 있는데, 정확히는 api cache 구현 라이브러리를 위해 redis를 올려놓은게 맞다. 그러다보니 정성껏 공부하거나 사용 하지 않고, 간단한 클러스터만 구성 할 줄만 아는거다. 하지만, redis 가 필요한 만큼 트래픽도 없고, redis없이도 메인 데이터베이스인 mysql의 성능은 충분 히 빠른 응답을 보여 주었다.

 

또한, 메인 데이터베이스에 저장 하기 불필요 하거나, 비정형 데이터는 오브젝트 스토어에 저장 하고 이는 mongodb를 사용 하고 있다. 하지만 mysql에 저장하기 불편한 비정형 데이터는 적었고, mysql json 필드는 유연 했으며, 왠만큼 많은 데이터에도 mysql의 성능을 해칠 수 없었다.

 

구성된 redis와 mongodb는 주기적인 관리가 불필요 하지만, 시스템 운영 관점에서는 명분이 부족하고 언제 쓸지 모를 짐을 계속 가지고 다니는 낌이다. 캐시 라이브러리, 캐시스토어, 오브젝트 스토어에 의존 하는것 대비 그만큼 효과가 보이지 않는다. 그러느니 당장 불필요한것은 정리 하고, 운영 및 관리요소를 가볍게, 필수 서비스를 더 깊게 사용 해보는게 좋아보인다. 추후, 높은 트래픽에 대응 하기위해 시스템을 손봐야 한다면, 이거저거 많은 시스템을 손보는 것 보다, 애초에 간단한 시스템을 손보는게 접근성도 좋고, 의존하는 서비스도 적을테니 더 합리적 일 것 같다.

 

 

러프한 대안

멀쩡히 있는 api 캐시 기능을 없애거나나, 비정형 데이터를 날려 버릴 수는 없다. 다만, 정말 필요한 기능을 다시 정리 하고, 일부 직접 구현 하거나, 다른 서비스에 통합 시킬 수는 있을 것 같다.

 

캐시가 필요한 api는 잦은 호출이 필요 하고, 데이터의 변화가 적고 유저와 연관 없는 데이터다. 그렇다면, url별로 정제된 응답 데이터를 새로운 테이블에 저장/서빙 하면 될 것 같다. 해시된 url을 pk로 하고 응답 데이터는 text 필드에 직렬화 해서 서빙 한다면 충분히 대응이 될 것 같다. 아니면, 파일로 저장 해서 cdn으로 서빙 하는 방법도 떠오른다.

 

비정형 데이터는 프론트로 서빙이 불필요하고, 변하지 않으며 배치성 업무에 필요 하다. 이는 정제한 데이터를 파일로 저장하거나, 그냥 mysql json 필드도 충분히 감당 가능 해 보인다. 왠만큼 데이터에는 집계 성능에  문제가 없고, 고성능 집계가 필요 하다면, 애플리케이션 레벨에서 구현이 가능 하다. 

 

결론

당장 뭔가를 걷어내거나 바꾸기에는, 신규 기능 구현과 버그 픽스에 치이다 그냥 유지 할 것 같다. 그래도, 지금 당장의 편의와 확장성 사이에서 고민 하다면 좋은 결정을 내릴 것 같다.