최근 새롭게 알림 서비스개편 작업을 맡게 되었다.
회사 서비스에서는 php를 사용하고있었지만,
TPS 최대 1만 트래픽을 php 싱글 스레드로 할 수 없기에 처음으로 Node를 사용하게 되었다.........
첫관문 부터 고민이었는데 npm과 yarn 둘 중 어느것을 선택하냐의 문제였다.
결과적으로 yarn(yarn berry)을 선택하게 되었다.
선택한 이유에는 크게 3가지정도된다.
1. CI/CD 배포 성능 최적화
- 가뜩이나 느린 CI/CD를 빠르게 하고싶었다. npm 같은 경우 배포할때마다 매번 npm install을 진행할텐데, 이 시간을 기다리고 싶지 않았다.(node_modules 다운으로 네트워크 I/O가 엄청 발생하니 느림.) 그래서 Zero-install 개념을 가지고 있는 yarn을 사용하고 싶었다.(npm처럼 node_moudles가 모두 올라가있는게 아닌, yarn/cache > .zip 파일로 프로젝트 안에 들어가있어 해당 zip파일을 가져오기만 하면 되니 빠르니깐.)
2. require 탐색 시간 개선
- npm으로 하는 순간 module.paths의 경로를 모두 뒤지며 패키지를 찾는다. 폴더가 많을 수록 만들지도 않은 node_modules 경로를 모두 뒤지기에 불필요 하다 느꼈다. yarn은 pnp 개념이므로, pnp.cjs를 보고 .zip파일에서 코드를 바로 읽어오기에 오히려 성능이 좋다 생각했다.
3. MSA 구조에서의 호이스팅 이슈
- 알림 서비스는 세미(?)MSA 구조의 아키텍쳐로 이루어져 있는데, node_moudles의 호이스팅으로 인해 공용의 패키지를 가지게되면, 추후에 각 서비스에서 사용 안하게 되어 삭제되었을때 예측 못한 이슈 발생하여 대참사가 발생할 수 있음. yarn(berry)는 package.json에 명시되지 않은 의존성 접근을 원천 차단하여 서비스간 독립성을 유지가 가능함.
나중에 알게 된 pnpm, 하지만 "굳이?"라는 생각이 들었던 이유
개발 도중에 pnpm이라는 대안도 알게 되었다. 하지만 yarn을 사용하고 있는 나의 상황에서는 "굳이?"라는 의문이 들었다.
pnpm은 하드링크를 생성하는 과정이 존재하는데 만약 패키지가 1만 개라면, 배포할 때마다 1만 개의 연결 고리를 만드는 I/O 작업이 수반되어야 한다. 설치가 빨라진 것이지 yarn 처럼 설치가 사라진 것은 아님.
그리고 결국 node_moudules 자체가 해결된건 아니고, 서버가 구동 될떄마다 node_modules에 대해 경로탐색이 이루어져야한다. 굉장한 네트워크 또는 하드디스크 I/O가 발생하게된다.
그래서 yarn으로 개발을 쭉 진행하게되었다!!