오 경험 공유 감사합니다.
하긴 어드민이나 비즈니스 판단을 위한 자료는 aggregation을 쓰다보니 부하가 많이 가겠네요. 웹개발자가 아니라서 잘은 모르겠지만 요즘 그런건 데이터 엔지니어링이랍시고 데이터를 따로 모아두는 모양이던데요.
말씀하신 대로 그런 데이터들은 별도로 분리시켜 처리하는 것이 정석이겠지만, 제가 작업했던 쇼핑몰은 불합리한 곳이 꽤나 많은 레거시 시스템이었는지라 그런 아키텍쳐상의 고려는 전혀 되어 있지 않았습니다. 굉장히 오래된 버전(InnoDB가 아니라 MyISAM이 기본 엔진이던 시절의 버전)의 MySQL이 역시 오래된 버전의 Apache 웹 서버와 함께 같은 VM 인스턴스 내에서 돌고 있었습니다. 쇼핑몰을 운영하기 위한 솔루션 또한 이미 레거시로 분류되어 패치만 나오고 있는 상황이었습니다. 작업 중에 느꼈던 솔루션의 구조적인 문제는 아예 처음부터 새로 개발한 신규 버전에서는 해결된 모양이었지만, 레거시 버전을 만지는 저에게 그 점은 아무런 영향도 주지 못했습니다. 그게 벌써 작년 일이네요.
비슷하다면 비슷한 개인 경험 하나. 프리랜서로 급히 들어온 쇼핑몰 관련 일 하나를 맡았을 때입니다.
새벽에 쇼핑몰에서 큰 작업(솔루션의 대대적인 버전업)을 실시하고, 상품 결제 등 주요 기능에 문제가 없는 것을 확인한 후 재개장하였습니다. 그런데 오후 들어서 갑자기 쇼핑몰 웹사이트가 너무 느려지더니, 급기야는 거의 멈출 지경이 되더군요. 알고 보니 원인은 쇼핑몰에 별도로 붙어 있던 판매자용 페이지 때문이었습니다. 쇼핑몰 솔루션에 커스텀 개발한 판매자용 관리페이지를 붙여 운영하고 있었는데, 거기 들어가는 순간 아주 무거운 쿼리가 실행되더군요. 쇼핑몰 재개장 후에 개별 판매자들이 판매 현황을 보려고 접속할 때마다 MySQL에 부하가 커져서 결국 쇼핑몰 자체가 느려진 것이었습니다. 보니까 관련 테이블에 어째서인지 인덱스가 제대로 안 걸려 있더군요. 결국 인덱스를 제대로 걸어주고 몇몇 파라미터를 튜닝하는 것으로 쇼핑몰 자체가 느려지는 것을 해결할 수 있었습니다.