안녕하세요. LINE Plus에서 Global E-Commerce Platform 개발을 맡고 있는 서종현입니다. 저희 팀은 작년에 주문 DB를 Oracle에서 MySQL로 이관하라는 미션을 받아서 성공적으로 완료했습니다. DB를 이관하면서 DB 모델도 변경해 읽기와 쓰기 양쪽 성능을 모두 향상시켰는데요. 이번 글에서는 그 과정을 공유드리고자 합니다.저희는 DB를 이관하기 전에 MySQL에서 사용할 DB 모델을 재정의했습니다. DB 이관과 함께 DB 모델을 변경한 이유는, 기존에 Oracle에서 사용하던 모델로는 조회 성능이 잘 나오지 않았기 때문입니다. 기존 모델로는 주문 데이터를 확인하기 위해 총 17개의 테이블을 조인해야 했습니다. 이로 인해 DB와 애플리케이션 서버 인스턴스 모두에 부하가 발생해, 하나의 주문에서 100개 정도의 상품을 구매한 경우 해당 주문을 조회하는 데 최대 5초 이상 소요됐습니다. 이 문제를 MySQL에도 가져갈 수는 없다고 판단해 DB 모델을 재정의했습니다.신규 DB 모델을 정의할 때의 주 관심사는 '어떻게 하면 조인을 줄일 수 있을지'였습니다. 팀 내 논의 결과 조인을 줄일 수 있는 방법으로 두 가지 안이 나왔습니다. 첫 번째는 일부 테이블을 JSON 문자열로 저장해 역정규화하는 안이고, 두 번째는 정규화 테이블과 비정규화 테이블 두 쌍을 운용하는 안입니다.첫 번째 안은, 저희 테이블 간 관계에 One-to-Many 관계가 많았기 때문에 컬럼으로는 역정규화할 수 없어서 JSON Object 혹은 JSON Array로 역정규화하자는 아이디어에서 나온 안입니다. 이 안의 경우 JPA를 사용하고 있기 때문에 코드 작성에는 큰 어려움이 없지만, JSON 문자열로 저장한 필드로 검색해야 할 경우 테이블 구조를 다시 변경해야 할 수 있다는 위험이 있습니다.두 번째 안은 첫 번째 안의 문제점을 해결하기 위해 검색용 모델과 조회용 모델을 분리해서 운용하자는 아이디어에서 나온 안 입니다. 이 안의 경우 두 개의 모델을 관리하기 때문에 작성해야 하는 코드의 양과 DB에 저장되는 데이터의 양이 증가한다는 문제가 있지만, 검색이 유연하고 첫 번째 안보다 조회 성능이 뛰어나다는 장점이 있습니다.성능 테스트 결과, 두 번째 안을 선택했습니다. 첫 번째 안이 두 번째 안에 비해 읽기와 쓰기 성능 모두 떨어지는 것을 확인했기 때문입니다. 첫 번째 안의 읽기 성능이 떨어지는 것은 이해할 수 있었지만 쓰기 성능이 떨어지는 것은 이해할 수 없었습니다. 성능을 테스트할 때 JPA의 Batch Insert를 사용했다고 하더라도 데이터가 더 많은 두 번째 안이 더 느릴 것으로 생각했기 때문입니다. 이에 Pinpoint 등을 이용해 원인을 분석했고, JPA의 변경 감지와 Jackson의 특성 때문인 것을 확인했습니다. 다음은 저희가 얻은 Pinpoint의 타임라인 그래프를 간소화한 그림입니다.위 그림에서 먼저 주목해야 할 부분은 Jackson의 호출 횟수입니다. 첫 번째 안에서 사용하는 모델이 Jackson을 여러 번 호출하는 구조이긴 하지만,