일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- class-transformer
- java
- 도서
- Database
- corretto
- blockchain
- nodejs
- chai
- 백엔드
- docker
- typeorm
- 글또
- 블록체인
- ChatGPT
- terraform
- mysql
- terraform cloud
- 리뷰
- IAC
- 온라인강의
- Nestia
- Redis
- Mocha
- restdocs
- gradle
- nestjs
- spring
- 유데미
- TypeScript
- 이더리움
- Today
- Total
목록nodejs (2)
끄적끄적

현재 회사의 대부분 서버는 Docker를 기반으로 배포되고 있다. 그런데 이 때 특정한 서버에서 배포 시마다 운영에는 문제 없는 에러 로그가 지속적으로 발생하는 이슈가 있었다. 물론 이 문제로 인해 다른 로직에 오류가 발생한 적은 없었기 때문에, 그 동안 다른 개발 작업에 집중하다가 최근에 조금 여유가 생겨 이 이슈를 조사해보기로 했다. 결론부터 이야기 하자면 문제의 원인은 docker stop 명령 실행 시 docker 는 컨테이너에 TERM signal (SIGTERM) 을 보내고 10 초 동안에도 종료되지 않았다면 Kill signal (SIGKILL) 을 보내 강제로 종료시키는 과정에서 발생했다. 컨테이너는 SIGTERM 시에 모든 리소스를 정리하고 종료되어야 하지만, DB 리소스는 정리되었으나 ..
한국에서 nestjs 로 개발하는 개발자라면 typia 에 대해서 한번쯤은 들어봤을 것 같다. 이 라이브러리에서 문제로 지적하는 부분이 nestjs 공식문서 예시로 제시하는 class-validator 가 성능적으로 문제가 크다는 것이다. 때문에 이러한 느린 라이브러리의 문제로 "typescript(javascript) 가 느리다" 라는 잘못된 인식까지 퍼질 수 있다고도 한다. 특히나 대부분의 nestjs 개발자라면 class-transformer + class-validator 기반으로 request 검증을 할테고, 객체 transform 액션에도 class-transformer 를 적극적으로 활용하고 있을 것이라 느리다는 인식이 더 커질 수 있을 것 같다. 여기서 성능이 느려지는 가장 큰 이유중 하나..