IE 11 과 svg 포맷
IE 는 좀 사라지면 좋겠지만 여전히 웹 개발자에게 고려 대상이 되고 있어 힘들게 한다. 눈에 띄는 부분은 스케치 등에서 익스포트한 파일의 투명 영역에 대한 고려가 브라우저마다 다를 수 있다는 점이다. (그래 봐야 IE 뿐이지만...)
팀의 프론트엔드 엔지니어 '종이' 님이 우회할 수 있는 팁을 리포트 한 내용이다.
몇몇 디자인 프로그램에서 (특히 Sketch) 페이지의 일부분을 내보낼 때 페이지 전체 크기의 투명 사각형 같은 걸 남겨두는 경우가 있습니다. IE만 아니면 svg의 overflow가 기본으로 hidden이라 상관이 없지만 이런 문제가 반드시 한번쯤 더 생길거같아서 적어둡니다...
- 편집 시 아이콘을 캔버스에서 그대로 내보내지 말고, 심볼로 만들어서 내보낸다
- Illustrator로 svg를 열어서 한 번 다듬는다
(주의: 일러스트레이터는 svg 그림자 떨구기를 처리 못 합니다 비트맵으로 박아버림) - svg에 overflow: hidden을 건다 (우리는 이 방법을 통해 처리했음)
- export된 svg를 직접 확인
- svgo removeHiddenElems
(이번 문제를 일으킨 Sketch의 경우 fill="transparent"를 먹여서 던집니다)
pm2 와 좀비 프로세스
node.js 프로젝트 클러스터링 매니저로 보통 pm2 를 많이 사용하고 있는데 우리도 베어본(도커 아닌)에 pm2 를 바탕으로 노드 프로세스를 클러스터링 하고 있다.
오늘 배포 후 신기한 경험을 했는데 관련 기록을 남겨 본다.
서비스 배포 후 새로운 코드가 아닌 과거의 코드가 실행되는 경우를 확인했다.
처음에는 이것도 몰랐는데 당연히 데이터 문제일거라 생각하고 데이터를 정리했다.
데이터 정리 후에도 문제는 여전히 발생해 이슈에 올리고 피드백을 받았다.
express 라우터 레벨에서 문제가 되고 있는 느낌을 받았지만 좀 더 살펴 보기에는 퇴근 시간이...
아무튼, 팀 백엔드 엔지니어의 리포트에 따르면 서비스가 배포되면서 pm2 가 좀비 프로세스를 남긴 것 때문이었다.
54|www | 08:21:14 slug /online_challenge --> page 2354
_old_44|www | 08:21:18 slug /online_challenge --> course 202853
56|www | 08:21:19 slug /online_challenge --> page 2354
_old_44|www | 08:21:19 slug /online_challenge --> course 202853
55|www | 08:21:28 slug /online_challenge --> page 2354
54|www | 08:21:29 slug /online_challenge --> page 2354
54|www | 08:21:30 slug /online_challenge --> page 2354
56|www | 08:21:34 slug /online_challenge --> page 2354
55|www | 08:21:39 slug /online_challenge --> page 2354
_old_44|www | 08:21:40 slug /online_challenge --> page 2354로그를 보면 course 로 바인딩하는 부분은 과거 코드고 page 로 대응하는 것은 새로 배포된 코드인데 우리는 두 대의 서버에 총 8개의 www 인스턴스를 구동하고 있었고 이 8개 외 1건의 좀비가 request 를 대응하는 경우 과거 코드가 수행되었다고 볼 수 있다.
'실제로 10 번 리프레시 하면 한 번 이상하게 나와요...' 라는 리포트를 받고 있었다.
_old_xxx 는 pm2 가 남기는 프로세스 리로딩 컨벤션으로 보인다.
ubuntu@prod-02:/fc/www$ ps -ef | grep 'node'
ubuntu 1304 10809 4 05:39 00:07:29 node /fc/api/index.js
ubuntu 1310 10809 4 05:39 00:07:24 node /fc/api/index.js
ubuntu 1329 10809 4 05:39 00:07:39 node /fc/api/index.js
ubuntu 1335 10809 4 05:39 00:07:48 node /fc/api/index.js
ubuntu 6105 10809 0 08:08 00:00:11 node /fc/worker/index.js
ubuntu 6116 10809 3 08:08 00:01:03 node /fc/worker/index.js
ubuntu 7239 10809 2 08:37 00:00:05 node /fc/www/index.js
ubuntu 7245 10809 2 08:37 00:00:03 node /fc/www/index.js
ubuntu 7264 10809 2 08:37 00:00:04 node /fc/www/index.js
ubuntu 7270 10809 2 08:37 00:00:05 node /fc/www/index.js
ubuntu 18303 10809 2 Jun30 03:54:04 node /fc/www/index.js ← 🔪
ubuntu 31781 10809 0 04:45 00:00:51 node /fc/callback/index.js
ubuntu 31793 10809 0 04:45 00:00:52 node /fc/callback/index.js
ubuntu@prod-02:/fc/www$ kill -9 18303프로세스를 리스팅하고 오래된 프로세스를 죽여서 해결을 보긴 했다.
RDB 에서 인덱스는 필수
단순히 엑셀 대응 용도의 데이터 저장이 아니고 join 이 일어날 가능성이 1% 라도 있으면 키가 되는 필드에 무조건 인덱스를 추가하는 것이 좋다.
임시로 사용하는 테이블이더라도 연계된 SQL 연산 작업이 있으면 인덱스를 해야 한다.
임시로 만든 테이블에 index 걸었더니 100ms 안에 처리됐어요.
팀 백엔드 엔지니어의 리포트;
