기능 확장을 위한 테이블 설계 변경
RDB 에서 필드 추가하는 걸 좀 주저하는 편인데, CTO 님과 얘기 해본 결과로는 굳이 죄의식을 가질 필요는 없어 보인다. 다만 String 필드에 , 로 값을 구분해 쓰는 건 찬성하지 않음.
지금 쿠폰 상품을 판매하려고 준비 중인데 당연히 쿠폰은 같은 타입이 여러 장이 될 수 있고 다른 타입의 쿠폰이 여러장 발급될 수 있어야 한다.
단순하게 쿠폰과 상품을 1:1 로 매칭하고 지금 우리가 가지고 있는 번들 타입을 활용해 다중 쿠폰을 발급할 수 있도록 개선하는 것이 가장 적절한 확장이 되겠다.
Docker 의 쉘 환경 사용
개발 중인 데이터베이스 서비스의 데이터를 동기화 시키기 위해 백업된 덤프(그래봐야 SQL)를 로컬 환경에 저장하고 보통 GUI 툴을 이용해 도커 내부에 있는 데이터베이스 서버에 복구하는 과정을 진행해 오고 있었다.
GUI 툴 보다 로컬 도커에서 bash 들어가는 방법으로 mysql restore 하면 좀 더 빨라질까 생각에 잠깐 고민해 본다.
- 외부 → 내부로 통신 들어가는게 일단 차이가 있지 않을까?
- 내부에서는 마운트된 디스크만 영향이 있으니 좀 더 낫지 않을까?
docker exec it 옵션
docker exec -it bash 에서 -it 는 -i 와 -t 의 줄임 표현인데
i 는 interactive; 표준 입력 채널을 유지하는게 목적
t 는 TTY; 가상터미널을 제공하는 기능
따라서 쉘 환경에 들어가려면 두 옵션 모두 필요로 한다.
기본 mysql alpine 서버의 초기 패스워드는 root 이다.
mysql -u root -p dbname < db-dump-file인증 테이블과 개인 정보 테이블 분리
RDB 기준으로 개인 정보를 담은 회원 테이블과 회원의 인증과 권한을 담당하는 테이블을 분리하는 것이 좋다.
예전 blititor 때도 그랬고 지금도 마찬가지.
auth 테이블은
- authId, encryptPassword, userId, externalId(socialLink) 정도만 담는 편이 좋다.
따로 테이블을 다른 디비에 둘 경우를 대비해 완전히 분리하는 것도 좋다.
동영상 시청 기록 데이터
동영상 시청 기록 데이터는 실시간으로 처리해야할 데이터 시나리오 짜기에 매우 적당해 보인다.
Rate Limiter 를 만드는 샘플
지난 번 사용자 접속 폭주로 API 가 과도하게 호출되어 데이터베이스 서버가 망가지는 것을 막기 위해 API 리미트 미들웨어를 도입할 생각을 했다.
leaky bucket 관련해 검색하면 이와 관련한 더 상위 레벨의 논의를 구경할 수 있다.
내가 생각한 제안은 요청을 일정 부분 보관하고(버퍼링) 리미트 이하의 요청은 순차적으로 처리하고 버퍼링이 오버되었을 때는 API 콜을 대기 또는 우회 시키는 패턴이었다. 제너레이터 사용하면 싱글스레드로도 처리 할 수 있을 것 같은데 나중에 구현해봐야겠다.
기존의 패키지를 사용하는 샘플과 redis 서버를 기반으로 직접 만드는 샘플이 있다. LogRocket 의 블로그에 NodeJS 관련 좋은 글이 좀 있는 편이다.
링크들
