패션 관련 프로젝트를 진행하며 ... 1 (feat. 500 maker)

요즘 패션 열풍이 불다보니 회사에서도 관련 프로젝트 업무를 담당하게 되었다. 

여기서 내가 맡은 업무는 패션 스토어 조회, 최근본상품 조회, 찜하기 상품 조회 & 저장에 대한 API 생성 및 수정이었다. 근데 이것도 레거시, 최근 프로젝트 거의 n개 프로젝트를 왔다갔다 수정하다 보니 헷갈려..

여러 논의가 있었지만 거기서도 가장 중요하게 고려되어야 할점은 성능 문제였다. 이 페이지에서 얼만큼의 tps가 나올지 모르는 상황에서 위 API를 여러번 찌르게 되면 문제가 발생할 수 밖에 없었기 때문에 ... 

그러다 500 떨어질랴... 

24년이 시작된 후부터 한주간은 계속 회의를 진행한듯 싶다. 특히, 협업하는 부서가 있어서 데이터는 얼만큼 내릴건지 이런거에 대한 협의가 필요했다. 

대략적인 협의가 끝난 후에는 API 규격서를 작성했는데 이번 기회에 규격서를 깔끔하게 쓸 수 있는 방법에 대해 공부가 된듯 싶다. 

원래 일정은 임박했었는데 가장 뒷단에 있는 우리 부서가 가장 먼저 API 를 내야 하지만 상품 관리 테이블에서 수정이 필요한 터라 일정이 조금 늦춰졌다. 

본격적으로 업무를 시작한건 이번주 월요일부터 였는데 레거시 작업을 우선하기 시작했다. 여기서는 패션 상품 전용으로 쿠키를 구워야 했다.  쿠키 개념은 통신 하는 중에 사용자가 클라이언트에서 담아두고 있는 파일이다. 

레거시는 항상 느끼는건데 구조가 유연하지 못한게 아쉽다. 구조 자체가 MSA 구조이다 보니까 

A->B 로 전달해야 경우가 발생하고 항상 두 군데 프로젝트에서 값의 validation 을 확인할 수 밖에 없다. 

이게 문제점이 레거시에는 관심사 분리가 제대로 적용이 안되어 있어서 어쩔 수 없이 A에서도 체크를 해야하는게 문제인듯 하다. 

만약에 관심사를 분리할 수 있으면 쿠키만 처리하는 곳을 B에서 하고 A에서는 오로지 B로 insert 하는 역할만 추가하면 될거 같다. 

만약에 이러한 구조가 여러군데서 발생한다면 차라리 이벤트 같은것을 발행해서 처리하는게 낫지 않나 싶다. 이런 부분은 좀 더 공부해서 개선작업으로 잡는게 좋을거 같다. 

그리고 다음에는 스토어 프로젝트에서 작업을 진행했는데 처음에는 MongoDB에 바로 붙여서 데이터를 꺼내올 생각이었다. 이러한 커넥션 풀이 증가하기는 하지만... 

스토어 -> 메인 프로젝트를 Http Client Binder 로 꺼내오는게 좋은 구조가 아니라는 생각이 들었다. 

메인 프로젝트는 정말 중간 단계로 접근하는 경우가 많았는데 스토어 프로젝트는 가장 마지막에 호출되는 용으로 호출하는 케이스가 많았기 때문이다. 

이건 팀원분과 의논하여 메인 프로젝트에서 부하를 받게 하는쪽으로 가닥을 잡았다. 커넥션풀이 증가하는것이 몽고쪽 메모리 CPU 자원 사용량을 증가시킬 수 있기 때문이다. 서버 쪽에 부하를 주게 되면 어쨋든 캐싱된 데이터도 있기 때문에 비교적 몽고쪽 부하를 덜 받을 수 있을거 같다. 

최근본 상품 조회는 두 개의 프로젝트에서 작업을 했는데 두개의 프로젝트 각각  역할이 달라서 이건 비교적 다른 프로젝트에 비해 명확하게 작업을 할 수 있었다. 

찜하기 상품 조회 API는 구성하는데 크게 문제는 없었지만 저장할 때 이슈가 하나 있었다. 

찜상품인 경우 천개, 만개 저장이 가능했기 때문에 여러 조인을 걸고 있는 쿼리문에서는 당연히 성능이 떨어질 수 밖에 없었다. 

이것을 Mongo 에다 찜 상품을 차차 이관하는것으로 변경하여 더이상 쿼리에 조인 같은것을 사용하지 않아도 되었다. 

적재할 때 컬렉션에 원하는 필드를 추가하여 쿼리에 조인을 두지 않고 Mongo Collection에서 Aggregation 을 구성하는 쪽으로 변경하였다. 

아직 진행중이지만 dev 에 올려봤을 때 배포에 문제는 없었다. 

일정을 맞출까 구조를 개선할까 늘 고민스러운 부분이다.