extra 테이블에 대한 단상
주요 테이블에 extra 테이블을 두어서 긴급 상황에 대응하는 것은 유용한 방법임에 틀림 없고 RDB 의 정규화에 발목 잡히지 않는 좋은 기법이지만 어디까지 적용해야 하는지 고민이 되기도 한다.
실제 구현 중 *_extra 테이블의 운용은 비즈니스 모델에 쓰는 게 아니라 내부 시스템 레벨에서 처리할 것들에 대해 사용하는 게 나은 방법인가에 대해 고민하고 CTO 님께 문의를 드렸다.
그렇다. 비즈니스 모델에 extra 테이블을 넣기 위해 만든 건 아니다.
Extra 의 데이터는 메인 테이블과 같은 RDB 에 쓰는게 아니라 별도의 디비를 사용한다고 가정하고 설계 및 구현하는 것이 도움이 될 듯 하다. 특히, 쿼리 캐시 등을 고려했을 때도 extra 의 데이터를 늘 가져오는 것은 별로 도움이 안된다. (join 이 캐시를 타지 않으니까)
MySQL 레플리카의 낮은 응답성으로 인한 장애
작년 프로젝트 시작할 때는 데이터베이스가 이중화가 되어 있지 않았고 모든 트랜젝션은 마스타 디비 하나를 사용했다. 작년 말인가 올해 초인가 이중화 작업을 하고 읽기 전용의 서비스에 대응하는 데이터베이스와 쓰기 중심의 마스터로 코드를 분리했다.
일부 중요 트랜젝션은 마스타만 보는 걸로 코드를 작성했지만 누락된 부분이 있는지 가끔 replica 에서 레코드를 찾지 못하는 문제가 있는 듯 하다.
레플리카가 피크 뜨는 경우 보통 일부 레코드를 찾지 못하는 문제(주로 주문 정보를 찾지 못함), 트랜젝션 lock 으로 인한 장애가 발생하는 듯 하다.
레플리카를 더 늘릴 필요가 있는 것일까? 레플리카 서버 스펙을 올려야 할까?
WWW 서비스 프론트 변천사
jQuery 기반
급한 일정으로 투입되어 Vue 기반으로 일정을 맞출수 없어 (올드비인 나는) Express + Mustache 랜더링된 마크업을 대상으로 jQuery 기반의 DOM 작업을 진행했다.
주문/결제, 마이페이지의 각종 피처들이 jQuery 기반으로 작성되었다. 결제 대행 모듈(iamport)이 jQuery 를 필요로 했다. 어짜피 필수 dependency 인 거 jQuery 달렸다.
Vue runtime 기반
일부 Vue 코드를 도입했다. 웹팩을 통해 모든 코드를 컴파일하지 않고 일부 컴포넌트만 Vue 로 전환을 하게되어 Vue runtime 을 내장하고 프론트엔드에서 vue 템플릿을 처리했다.
Vue + Webpack 번들링
웹팩에 Vue 템플릿 처리 프로세스를 추가하여 Vue runtime 을 걷어냈다.
커스텀 글로벌 스토어
vuex 적용 전 단일 스토어를 통해 데이터 관리
Veux 적용
vuex 를 적용하머 스토어 패턴 단일화
백엔드 코드와 분리 (WIP)
백엔드 코드에서 webpack 을 분리하고 www-front 모듈로 분리(WIP)
Go 의 바이너리 패키지 모델
Fat 바이너리라고 부르는 형태로 각종 패키지/모듈 등을 스태틱하게 실행 파일에 넣는다.
하지만 FFI 를 사용하게 되면 외부 의존성 버전 불일치로 인한 문제는 여전히 존재함.
파이썬의 salary 의존성
파이썬 프로젝트에 salary 가 뜬금없이 자주 보이는데 이는 싱글 스레드 락으로 인한 (GIL) 병목을 해결하기 위해 왠만하면 셀러리를 기술 스택에 넣는다고 한다.
링크들
