웹 애플리케이션에서 자바스크립트 프로파일링 해보기

[Marak Squires](https://github.com/marak)라는 개발자가 만든 두 개의 유명한 패키지 [colors.js](https://github.com/Marak/colors.js/)와 [faker.js](https://github.com/Marak/faker.js)가 개발자에 의해 고의로 손상되는 사건이 일어났다.

- https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d13d28632bd8a049ff136fb6
- https://github.com/Marak/faker.js/commit/2c4f82f0af819e2bdb2623f0e429754f38c2c2f2

faker.js의 경우 레포에 아무것도 남아나지 않고 멀쩡한 5.5.3 버전에서 6.6.6 버전으로 major 업데이트를 하는 귀여운(?) 수준이었지만, faker에 비해 쓰는 패키지가 더 많았던 colors.js의 경우 1.4.0에서 무한루프가 삽입되어 있는 1.4.1 버전으로 패치 업데이트를 하는 치밀함을 통해 `^.1.4.0`으로 선언이 되어 있는 많은 노드 패키지를 골로 보내는 쾌거를 이뤄낼 수 있었다. 덕분에 [요런 식의 수정](https://github.com/aws/aws-cdk/pull/18324/commits/9802d23b0359d3089dadc1b75e20db3b97a09921)을 추가하느라 연초부터 많은 개발자들이 바빴을 것이다.

대충 사건을 파악해보니 [2020년 쯤에 아파트에 불이 나서 전재산을 날려먹은 듯한 모양](https://twitter.com/marak/status/1320465599319990272) 이다. 근데 불의의 사고로 불이 난 것 은 아니고, 집에서 사제폭탄을 만들다가 집을 다 태워먹은 모양이다.

- https://nypost.com/2020/09/16/resident-of-nyc-home-with-suspected-bomb-making-materials-charged/
- https://abc7ny.com/suspicious-package-queens-astoria-fire/6425363/

어쨌건, 이 분의 의도는 돈 많이 버는 회사들이 내 오픈소스를 공짜로 쓰는데 아무런 보상이 없자 경각심을 주기 위해 한 행동이라고 하는데, 이해가 될 듯 안될 듯 공감이 되는듯 안되는 듯 하다 🤔

오픈소스를 매일매일 사용하는 사람, 또는 기업이 어떤 자세를 가져야 할지, 또 기부를 하는게 맞는지, 해야한다면 얼마를 해야하는 건지(?) 등 어려운 문제는 차치하고, 오픈소스를 매일 사용하는 node 개발자들이 이 사태를 사전에 어떻게 막아야할지 고민해보도록 하자.

먼저 패키지 개발자 관점에서 생각해보자. 잘못된 버전이 우리가 모르는 새 배포되었다. 이 패키지를 의존하는 패키지가 이로 인해 오작동 한다는 것은, 사보타주된 패키지를 `npm install` 등으로 설치하는 것을 시작으로 설치한 이후에도 호환성 등의 테스트가 전혀 이뤄지지 않았다는 것을 의미한다.

그리고 이 패키지를 사용하는 일반적인 개발자 입장에서 판단해보자. npm은 패키지에 나열된 요구사항에 따라 의존성 버전을 선택해서 설치한다. `package.json`에 나열된 의존성 뿐만 아니라, 현자 선언되어 있는 모든 의존성에서 가능한 최신 버전의 사용을 선호하게 된다. 패키지 개발자의 의존성에서는 최신버전을 사용하도록 선언되어 있었고, 그것을 조금도 의심하지 않고 설치했다. 그리고 결국에는 아래와 같은 이슈 리포팅을 남기게 된다.

- https://github.com/aws/aws-cdk/issues/18322
- https://github.com/hexojs/hexo/issues/4865
- https://github.com/facebook/jest/issues/12226
- https://github.com/netlify/cli/issues/3981

npm 사용자들은 굉장히 화가 날 법한 일이지만, 적어도 무한루프를 생성하고 이상한 내용을 출력하는 수준에서 그쳤다는 것을(?) 다행으로 생각해야 한다. 해킹과 같은 더 나쁜 일이 있을 수도 있고, 이런 의도적인 파괴가 앞으로 없을 거라고 가정하더라도 이와 비슷한 결과를 만들 수 있는 버그도 발생할 수 있다. 기본적으로 모든 오픈소스 소프트웨어 라이센스 코드는 특별한 보증 (warranty) 없이 사용하기 때문이다. 따라서 패키지 관리자는 이러한 위험이 있을 수 있음을 항상 예상하고 이에 따른 피해가 최소화 될 수 있도록 설계해야 한다.

npm 패키지 관리자들은 새 패키지를 설치할 때 모든 의존성의 최신 버전을 선호하도록 하는 버저닝을 중지하는 것이 좋다. (`^` 나 `~`) 대신 패키지가 실제로 테스트 된 버전이나, 가능한 안전한 버전을 선택한 것이 좋다.

npm은 [npm shrinkwarp](https://docs.npmjs.com/cli/v8/commands/npm-shrinkwrap)과 [npm ci](https://docs.npmjs.com/cli/v8/commands/npm-ci) 명령어를 통해 의도치 않은 종속성 업데이트를 방지한다. 그러나 이 명령어가 할 수 있는 일은 제한적이므로, 근본적으로 패키지 관리자의 고민을 덜기엔 부족하다.

[이전에 포스팅에서 이야기한 것처럼 `node_modules`도 git으로 관리하여 패키지의 변화를 눈치채는 것도 한가지 방법](/2021/12/add-node_modules-in-git)이 될 수는 있다. 그러나 어디까지나 사람의 눈으로 캐치해야 하기 때문에 100% 안전한 방법이라고 할 수는 없다.

가장 중요 한 것은, 모던 프로덕션 시스템을 운영하는 사람이라면 [점진적이고 단계적인 롤아웃](https://sre.google/sre-book/reliable-product-launches/#gradual-and-staged-rollouts-yDsrIPFV) 정책에 대해서 인지하고 적용해야 한다는 것이다. 이를 바탕으로 한 테스트를 활용하여, 한번의 실수로 모든 것이 망가지는 것을 미연에 방지해야 한다. 테스트롤 통해 변경사항이 다른 시스템에 영향을 미친다는 것을 확인한다면, 예상치 못한 문제를 사전에 발견하고 배포를 중지할 수 있는 시간을 충분히 벌 수 있을 것이다. (그러나 아쉽게도 npm은 정반대 정책으로 운영되고 있다. 최신버전의 패키지는 누구도 테스트할 기회를 얻기도 전에 모든 의존성 내부에서 널리 사용되도록 퍼져나가버렸다.)

## 참고: 점진적이고 단계적인 롤 아웃

시스템 관리자의 격언 중 하나는 '실행 중인 시스템을 절대로 바꾸지 말라' 라는 말이다. 어떠한 형태로든 변화는 위험을 나타내며, 시스템의 신뢰성을 위해서 위험은 최소화 되어야 한다. 어떤 작은 시스템에라도 작은 변화가 일어난다면, 구글의 고도로 복제되고 전세계로 분산되어 있는 시스템에도 엄청난 큰 위험으로 적용된다.

구글에서 전세계에가 사용할 수 있도록 특정시간에 신제품을 출시하는 '버튼' 을 누르는 경우는 없다. 시간이 지남에 따라 구글은 제품과 기능을 점진적으로 출시하여 위험을 최소화 할 수 있는 패턴을 개발했다. https://sre.google/sre-book/service-best-practices/

구글 서비스에 대한 거의 모든 업데이트는 정해진 프로세스에 따라 적절한 검증 단계를 거쳐서 점진적으로 진행된다. 하나의 데이터 센터에 있는 몇개의 시스템에 새 서버가 설치되고, 이는 사전에 정의된 기간에서 관찰할 수 있다. 모든 것이 정상으로 확인되면, 서버는 한 데이터 센터의 모든 시스템에 설치되고, 그 다음 다시 상태를 살펴본 다음 모든 시스템에 설치된다. 이러한 롤아웃의 첫단계를 'canaries'라고 부른다. 이는 탄광에 위험한 가스가 있는지 확인하기 위해 보내는 새 카나리아에서 따온 말로, 여기서 canaries는 실제 사용자 트래픽에서 새로운 소프트웨어 동작으로 인해 위험한 영향을 감지하는 것을 의미한다.

이 테스팅은 환경설정을 변경하는 시스템 뿐만 아니라 자동화된 변경을 위해 사용되는 구글의 많은 내부도구에 도입되니 개념이다. 새 소프트웨어 설치를 관리하는 도구는 일반적으로 새로 시작하나 서버를 잠시 관찰하여 서버가 충돌하거나 잘못된 동작을 하지 않도록 한다. 변경된 내용이 유효기간을 지나지 않으면 자동으로 롤백 된다.

이러한 점진적 롤아웃의 개념은 구글의 서버에서 실행되지 않는 소프트웨어에도 적용된다. 새로운 버전의 안드로이드 앱은 점진적으로 롤아웃 될 수 있으며, 업데이트 된 버전이 점차 업그레이드 되기 위해 점차 그 범위를 늘리는 방법을 채택했다. 업데이트 된 인스턴스의 비율이 100%에 되기 까지 시간이 지남에 따라 점차 증가한다. 이러한 원격 설치 유형은 새 버전으로 인해 구글 데이터 센터의 백엔드 서버에 트래픽이 추가되는 경우에도 유용하다. 이렇게 하면 새로운 버전을 점차 출시하고, 문제를 조기에 발견하면서 버서에 미치는 영향을 점진적으로 관찰할 수 있다.

> https://sre.google/sre-book/reliable-product-launches/#gradual-and-staged-rollouts-yDsrIPFV


colors.js와 faker.js 사태가 준 교훈

2019년에 회고를 작성하고 (지금은 숨김처리 되어 있다.) 2020년은 스킵한뒤로 2021년 회고를 작성한다. 회고를 작성하는 이유는 여러가지가 있겠지만, 내가 회고를 작성하는 이유는 2022년에는 시행착오를 덜 하고 더 좋은 개발자로 성장하기 위함이다. 따라서 굳이 내가 무엇을 잘했는지는 남겨두지는 않으려고 한다. (굳이 내가 잘한 사실을 공개된 장소에 업로드 하는 것이 좀 이상하고 오그라든다. 무엇보다 남들에게 자랑할 만큼 잘한 건 없는 것 같고.) 무엇을 잘못했고, 실수했고 부족했으며 나아가 2022년에는 무엇을 할지 정리해보려고 한다.

## 2021년에 한 것

2021년은 4번째 회사에서 온전히 한 해를 보낸 해다. 2021년에 한 것은 다음과 같다.

### 팀 내부에서 공통으로 사용할 frontend library 제작

- 주요기술: rollup, typescript, npm workspace, storybook
- 아쉬웠던 점: babel이나 next와 같은 다른 mono repository 처럼 버저닝도 잘 지키고, 앞으로 개발해 나갈 기능들도 잘 스케쥴링해서 개발해 나갔으면 좋았을 텐데 그러지 못해서 아쉬웠다. 변명 아닌 변명을 해보자면 그때 그때 필요한 기능 추가/수정 요청을 빠르게 대응하다 보니 기능 개발이 약간 두서 없이 될 수 밖에 없는 상황이긴 했다. (진짜 변명이네) 하지만 그 와중에도 버저닝은 칼같이 지키려고 노력했다. 그리고 지나고보니 이렇게 했음 좋았을 텐데 하는 것들이 생각났고, 그걸 이와 중에 적용하자니 major version 업데이트가 되어서 굉장히 망설여졌다. 현재 v2를 계획중에 있는데 이번에 확실히 개편해보고자 한다. 사실 내가 v1을 하든, v2를 하든 별로 신경 안쓰시는 분들이 더 많겠지만 일종의 사명감 내지는 애착이 생긴 것 같기도 하다.

### legacy 서비스를 nextjs로 전환

- as-is: javascript, react, react-router-dom, mobx
- to-be: typescript, nextjs, react (+context api)
- 아쉬웠던 점: 나름 nextjs의 열렬한 팬으로써, 그리고 이전 회사에서 nextjs를 한바탕 써본 경험자로써 산전수전 다 경험해봤다고 생각했는데 그럼에도 모르는 것들이 조금씩 있었다. 그리고 자신있게 nextjs의 장점과 써야하는 이유를 설파할 수 있을 줄 알았는데, 모든 사람을 설득하지는 못한 것 같다.

### 마이데이터

- 주요기술: typescript, nextjs, mobx
- 아쉬웠던 점: 좋았던 점을 더 찾기 힘들었던 프로젝트. 저 멀리서 점지해서 내려져온 스펙과 일정은 여러가지로 숨막히게 만들기에 충분했다. 다시는 하고 싶지 않았던 경험. 😑

다음은 회사 밖에서 내가 공부하고 겪은 내용이다.

### 블로그 운영

![git-contribution-graph](./images/git-contribution-graph.png)

- 아쉬웠던점: 1day 1commit 이라는 대 전제 아래 블로그를 운영했다. 덕분에 아름다운(?) 그래프를 만들 수 있었다만,,, 아쉬웠던 점은 회사와 개인업무가 바쁜 와중에도 지키려고 하다보니 낮은 퀄리티의 commit 이 추가되었다는 점이다. 그럼에도 1day 1commit 덕분에 회사일에서 10분이라도 벗어나서 무언가를 공부할 수 있었다는 것은 좋았다. 블로그 글도 연말에 유례없이 바빠지면서 점점 퀄리티가 낮아진 것도 부정할 수 없는 사실. 개인적으로 2021년에 한 일 중에 가장 좋으면서도, 가장 아쉬웠던 일이다.

### 비영리 회사 업무 지원

- 주요기술: nextjs, react, typescript, google cloud platform, firebase, python
- 아쉬웠던 점: 빠른 시간 내에 매니저분들이 원하는 솔루션 및 서비스를 만들어 드린 것 은 좋았지만, 계속해서 그때 그때 땜빵식으로 처리한다는 느낌을 지울 수가 없었다. 은퇴하기전에 꼭 제대로된 시스템을 구축해야겠다.

## 2022 TODO

### Rust

프론트엔드 개발자로서, Rust 붐이 올 것 만 같은 느낌이다. 슬금슬금 Rust가 웹 개발 영역에 들어오고 있다. **내가 인생에서 마지막으로 배우는 언어**라는 각오로 rust 공부를 시작할 예정이다. 아쉽게도, 배민 스터디 그룹에서는 떨어졌지만 (떨어질 거라 생각하지 못하고 지원서를 대충 써낸 잘못이 크다), 독학이라도 해서 올해에는 rust를 정복하고자 한다.

- https://www.youtube.com/watch?v=R0qbMTGgJn4&ab_channel=HarryWolff
- https://leerob.io/blog/rust

뭐 호들갑일 수도 있지만, 저수준 언어를 알아두는 것도 길게 보면 도움이 되지 않을까.

### k8s

k8s의 중요성은 계속해서 말해봐야 입이 아프지만, 학습의욕과 노력에 비해서 많이 늘지 못하고 있다. 인프라쪽 공부가 원래 이런가 싶기도한데, 아무튼 이번에는 이 블로그를 k8s로 전환해보면서 제대로 공부해보려고 한다.

### 네트워크에서부터 브라우저까지

2021년에 글을 조금씩 쓰면서 공부하고 있다. 그러나 조금은 부족한 것 같아서 더 공부하려고 한다. 프론트엔드를 둘러싼 환경을 미리미리 공부해야할 필요성을 계속해서 느끼고 있다.

### 블로그

- 1day 1commit은 계속 유지
  - 커밋의 퀄리티를 떠나서, 매일 업무 외에 다른 것을 한다는 것 자체에 의미가 있는 것 같다.
- 일주일에 한 개씩 퀄리티 있는 글 작성
  - 글 올리는 빈도를 조금 줄이고, 퀄리티에 조금 더 힘쏟으려고 한다.
- 블로그 구조 개편 (컴포넌트 정리, 마크다운 serializer 개편 등)
  - 저번 개편 때 하다 만 것들을 마저 완성
- vercel 플랫폼에서 벗어나서 직접 구축하기
  - K8S도 공부하고, bandwidth 초과 때문에 조만간 과금을 당할 것 같아 조치해야 한다.

## 커리어

4번째 회사쯤 되니 이제 회사에 대한 기대는 크게 안하게 되는 것 같다. 그래도 직장인으로서 기대하는 점이 있다면 돈은 많이 주고 일은 재밌는 그런 곳. 그런데 재택이 곁들여진.

## 달리기

2021년은 거의 대부분의 주중에 15k달리기를 했다. 재택 덕분에 출퇴근 시간을 아끼면서 운동을 할 수 있었던게 너무 좋았다. 체중도 감량하고, 젊음도 (간신히) 유지할 수 있었다.

![running](./images/2021_running.jpeg)

이래저래 일이 있을 때 못뛴 날 제외하고는 열심히 달렸는데 나름 뿌듯하다. 올해에는 42k도 달려보는게 목표다. (버추얼 마라톤은 재미가 없더라)


2022년은 더 좋은 개발자가 되길 바라며

2021년 회고

## Table of Contents

## Introduction

nextjs를 본격적으로 쓴 것은 2~3년 전부터이지만, 이 정도로 대규모 프로젝트에 써본 것은 처음이었다. 이전까지는 nextjs에 대해 어느정도 알고 있다고 자부했었지만, 본격적으로 쓰고 보니 굉장히 모르는 사실들이 많았다는 것을 꺠달았다. 다시는 시행착오를 겪지 않기 위해 nextjs를 쓰면서 배운 것들을 몇가지 정리해두려고 한다.

## shallow routing은 page 리렌더링을 야기한다.

nextjs에서 routing이 일어나면 `getServerSideProps`, `getStaticProps`, `getInitialProps` 를 야기한다. https://nextjs.org/docs/routing/shallow-routing 그러나 이를 실행시키지 않고 현재 URL을 업데이트 하는 것이 shallow routing이다.

```javascript
import { useEffect } from 'react'
import { useRouter } from 'next/router'

function Page() {
  const router = useRouter()

  useEffect(() => {
    // Always do navigations after the first render
    router.push('/?counter=10', undefined, { shallow: true })
  }, [])

  useEffect(() => {
    // The counter changed!
  }, [router.query.counter])
}

export default Page
```

단순히 URL을 업데이트 하는 용도로 잘 쓰고 있었는데, 알고 보니 `router.push` 든 `router.relace`든 일어나면 해당 페이지가 리렌더링 된다는 사실을 알게 됐다.

https://github.com/vercel/next.js/discussions/18072

사실 이는 조금만 깊게 생각해보면 당연한 사실이다. `next/router`는 Context API를 내부적으로 사용하고 있고, `router.*`을 실행하는 순간 내부의 상태 값을 바꾸기 때문에 필연적으로 리액트의 리렌더링을 발생시킬 것이다. ~~내가 생각이 짧았다.~~

### 해결책

해결책은 `window.history.replaceState`를 사용하는 것이다. history에 replaceState를 하는 것은 리액트의 상태를 건드는게 아니고 리액트와 별개인 페이지의 히스토리를 건드는 것이 기 때문에 리렌더링이 발생하지 않을 것이다.

```javascript
window.history.replaceState(
  window.history.state,
  '',
  window.location.pathname + '?' + `whatever=u_want`,
)
```

## getServerSideProps와 \_app.getInitialProps와의 관계

`getServerSideProps`는 무조건 서버에서 실행되는 코드로, 서버사이드 렌더링 시에 필요한 데이터를 미리 필요한 데이터를 불러올 때 쓰인다. `_app.getInitialProps`는 최초에 앱이 렌덜이되거나, 클라이언트 라우팅이 일어나는 순간에 실행된다. https://nextjs.org/docs/advanced-features/custom-app

- Persisting layout between page changes
- Keeping state when navigating pages
- Custom error handling using componentDidCatch
- Inject additional data into pages
- Add global CSS

그런데, `getServerSideProps` 가 수행되면, `_app.getInitialProps`가 실행된다는 사실을 알게되었다.

### app

```javascript
import App from 'next/app'
import '../styles/globals.css'

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}

MyApp.getInitialProps = async (appContext) => {
  const appProps = await App.getInitialProps(appContext)

  console.log('getInitailProps!')

  return { ...appProps }
}

export default MyApp
```

### index

```javascript
import { useRouter } from 'next/dist/client/router'

export default function Home() {
  const router = useRouter()

  function handleClick() {
    router.replace(router.asPath)
  }

  return <button onClick={handleClick}>Replace!</button>
}

export function getServerSideProps() {
  console.log('getServerSideProps')
  return {
    props: {}, // will be passed to the page component as props
  }
}
```

버튼을 누르면

```
getInitailProps!
getServerSideProps
getInitailProps!
getServerSideProps
getInitailProps!
getServerSideProps
```

`getInitialProps`가 실행되는 것을 알 수 있다. 이는 의도한 동작인 걸까? 그냥 나는 `getServerSideProps`만 재 호출하고 싶은 건데, (새로고침 등을 이유로) `getInitialProps`까지 호출해야 할까? 사실 지금 생각해보니 이것도 어떻게 보면 당연한 것 같기도하다. 🤔 의도야 어쩄든 라우팅이 일어나는 행위고, 라우팅에는 `getServerSideProps`가 수반되어야 하니까...?

아무튼, 이 상황을 막고 싶다면 아래와 같은 조건문을 추가해주면 된다.

```javascript
import App from 'next/app'
import '../styles/globals.css'

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />
}

MyApp.getInitialProps = async (appContext) => {
  const appProps = await App.getInitialProps(appContext)
  const {
    ctx: { req },
  } = appContext

  if (req?.url.startsWith('/_next')) {
    // serverSideProps로 호출된 경우 URL이 /_next로 시작함.
    // EX: /_next/data/development/index.json
  }

  return { ...appProps }
}

export default MyApp
```



## 환경변수 쓰기 전에 잘 점검하기

| Method              | Set at    | Available in Next.js client side rendered code (browser) | Available in Next.js server side rendered code | Available in Node.js               | Notes                                                       |
| ------------------- | --------- | -------------------------------------------------------- | ---------------------------------------------- | ---------------------------------- | ----------------------------------------------------------- |
| .env                | both      |                                                          | ✔️                                             | `process.env`를 구조분해할당하거나 | `process.env`를 구조분해할당하거나 동적으로 접근할 수 없음. |
| NEXT*PUBLIC* .env   | buildtime | ✔️                                                       | ✔️                                             |                                    | `process.env`를 구조분해할당하거나 동적으로 접근할 수 없음. |
| env next.config.js  | buildtime | ✔️                                                       | ✔️                                             |                                    | `process.env`를 구조분해할당하거나 동적으로 접근할 수 없음. |
| publicRuntimeConfig | runtime   | ✔️                                                       | ✔️                                             |                                    | `SSR`을 사용하는 페이지에 필요                              |
| serverRuntimeConfig | runtime   |                                                          | ✔️                                             |                                    |                                                             |
| process.env         | runtime   |                                                          |                                                | ✔️                                 |                                                             |

환경 변수에 대한 설정도 잘 확인해야 한다. https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration

`publicRuntimeConfig`를 사용하기 위해서는 `_app.getInitialProps`를 꼭 사용해야 한다. 초기 환경 세팅 할때, 혹은 배포 준비를 할 때 이것 때문에 헷갈리는 경우가 많으므로 주의를 요한다.

## SWC?

SWC가 러스트로 작성되어 타입스크립트나 자바스크립트를 굉장히 빠르게 컴파일한다는 사실 때문에 많은 주목을 받고 있었는데, 이번에 nextjs 12에 swc가 도입되면서 많은 관심을 끌고 있는 것 같았다. 실제로 도입을 해볼까 하고 고민을 했었는데, 결론적으로 도입하지는 않았다.

본격적으로 적용하기에 앞서, 일단 돌아가고 있는 코드 베이스로도 안되는 문제가 많았고, 여러 다른 개발자로 부터도 이런저런 이슈가 많다는 이야기를 들어서 선뜻 적용하기 망설이고 있었다. (이 블로그는 적용되어 있다.)

- https://github.com/swc-project/swc/releases 패치가 123까지 있을 정도로 살벌하게 수정중,,
- https://github.com/vercel/next.js/issues?q=label%3A%22area%3A+SWC+transforms%22+ SWC는 아직도 이슈가 계속 나오고 있는듯,,

결론은 아직 시기상조 인 것 같다는 생각이다. 그러나 개발자 분이 워낙 능력도 출중하시고, 또 전폭적인 지원도 받고 계시니 내년 이맘 때 쯤이면 아마 babel을 걷어내고 모두가 SWC를 쓰고 있을지도 모른다.

## 잘 알고 있는 줄 알았는데..

nextjs로 블로그도 만들고, 실제 서비스 되고 있는 애플리케이션도 개발하면서 어느 정도 잘 알고 있다고 생각했었는데 대규모 애플리케이션을 만들면서, 그리고 여기에 mobx + k8s를 얹으면서 나도 몰랐던 이슈들이 터지는 것을 볼 수 있었다. (그러면서 어느정도 nextjs에 대한 신뢰도 깨지기도 했고,,)

개인적으로 서버사이드 렌더링 프레임워크를 만들어보자라는 계획이 있었는데, react 18이 나오면 해야지 하면서 차일피일 미루고 있었는데 내년에는 꼭 다시 시도해봐야겠다. (라고는 하지만 또 18 나올때까지 뭉개고 있겠지,,,)

nextjs를 적용하면서 알게 된 사실들

## V8 가비지 콜렉션

힙은 메모리 할당이 필요한 곳이고, 이는 여러 `generational regions`로 나뉜다. 이 `region`들은 단순히 `generations`이라고 불리우고, 이 객체들은 라이프 사이클 동안 같은 세대 (generation)을 공유한다.

여기에는 `young generation`과 `old generation`이 있다. 그리고 `young generation`의 `young objects`는 또다시 `nursery`(유아)와 `intermediate`(중간) 세대로 나뉜다. 이 객체들이 가비지 컬렉션에서 살아남게 되면, `older generation`에 합류하게 된다.

![generation](https://v8.dev/_img/trash-talk/02.svg)

이 `generation` 가설의 기본 원리는 대부분의 객체가 older로 넘어가기 전에 죽는다. (가비지 콜렉팅 당한다)는 것이다. V8 가비지 컬렉터는 이러한 기본적인 가정을 기반으로 설계 되어 있으며, 여기에서 살아남은 객체만 승격하게 된다. 객체는 살아남으면서 다음 영역으로 복사되고, 그리고 결국엔 `old generation`이 되는 것이다.

node에서 메모리가 소비되는 영역은 크게 세군데로 볼 수 있다.

- code
- call stack: 숫자, 문자열, boolean 과 같은 primitive values 또는 함수
- heap memory

우리는 여기에서 힙 메모리를 중점적으로 볼 것이다.

가비지 콜렉터에 대해 간단히 알아봤으니, 힙에 메모리를 할당해보자.

```javascript
function allocateMemory(size) {
  // Simulate allocation of bytes
  const numbers = size / 8
  const arr = []
  arr.length = numbers
  for (let i = 0; i < numbers; i++) {
    arr[i] = i
  }
  return arr
}
```

지역 변수는 함수 호출이 call stack에서 끝나는 즉시 `young generation`에 있다가 사라지게 된다. 숫자와 같은 기본형 변수들은 힙에 도달하지 못하고 대신 호출 스택에서 할당된다. `arr`의 경우 힙에 들어가서 가비지 콜렉션에서 살아남을 수 있다.

## 힙 메모리에 제한이 있을까?

이제 노드 프로세스를 최대 용량으로 밀어넣고, 힙 메모리가 언제쯤 고갈되는지 살펴보자.

```javascript
const memoryLeakAllocations = []

const field = 'heapUsed'
const allocationStep = 10000 * 1024 // 10MB

const TIME_INTERVAL_IN_MSEC = 40

setInterval(() => {
  const allocation = allocateMemory(allocationStep)

  memoryLeakAllocations.push(allocation)

  const mu = process.memoryUsage()
  // # bytes / KB / MB / GB
  const gbNow = mu[field] / 1024 / 1024 / 1024
  const gbRounded = Math.round(gbNow * 100) / 100

  console.log(`Heap allocated ${gbRounded} GB`)
}, TIME_INTERVAL_IN_MSEC)
```

위 코드는 40ms 간격으로 10메가바이트를 계속 할당하므로, 가비지 콜렉팅에 필요한 시간이 남아있는 객체들을 `old generation`으로 빠르게 승격시킬 수 있다. `process.memoryUsage`는 현재 힙 사용률에 대한 지표를 수집할 수 있는 도구다. 힙 할당량이 커지면, `heapUsed` 필드에서 현재 힙 사이즈를 추적한다.

결과는 실행환경에 따라 다르다. 16gb 메모리가 있는 내 맥에서는 다음과 같은 결과가 나왔다.

```
...
Heap allocated 3.95 GB
Heap allocated 3.96 GB
Heap allocated 3.97 GB
Heap allocated 3.98 GB
Heap allocated 3.99 GB
Heap allocated 4 GB

<--- Last few GCs --->

[88809:0x130008000]    23137 ms: Scavenge (reduce) 4085.6 (4094.2) -> 4085.6 (4094.2) MB, 1.6 / 0.0 ms  (average mu = 0.855, current mu = 0.691) allocation failure
[88809:0x130008000]    23449 ms: Mark-sweep (reduce) 4095.4 (4104.0) -> 4095.3 (4104.0) MB, 274.1 / 0.0 ms  (+ 138.5 ms in 153 steps since start of marking, biggest step 6.2 ms, walltime since start of marking -558038699 ms) (average mu = 0.740, current m

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
```

여기에서 가비지 콜렉터는 `heap out of memory` 예외를 던지기 전에 마지막 수단으로 메모리 압축을 시도하는 것을 볼 수 있다. 이 프로세스는 4.1gb까지 도달했고, 23.1초 정도가 소요 되었다.

## 메모리 할당량 늘리기

`--max-old-space-size` 파라미터를 사용하면 크기를 늘릴 수 있다.

```bash
node index.js --max-old-space-size=8000
```

위 커맨드에서는 최대 제한을 8gb로 설정했다. 이 크기를 설정할 때는 조심해야 한다. RAM에 물리적으로 사용가능한 공간을 설정해두는 것이 좋다. 물리적 메모리가 부족하면, 프로세스는 가상 메모리를 통해 디스크 공간을 확보하기 시작한다. 이 제한을 너무 높게 설정하면 PC가 손상될 수 있다.

```
...
Heap allocated 7.8 GB
Heap allocated 7.8 GB
Heap allocated 7.81 GB

<--- Last few GCs --->

[89239:0x148008000]    51777 ms: Mark-sweep (reduce) 7992.0 (8006.7) -> 7991.8 (8006.7) MB, 2770.5 / 0.0 ms  (+ 106.4 ms in 97 steps since start of marking, biggest step 8.0 ms, walltime since start of marking -558036240 ms) (average mu = 0.302, current m[89239:0x148008000]    54751 ms: Mark-sweep (reduce) 8001.7 (8016.5) -> 8001.6 (8016.5) MB, 2968.3 / 0.0 ms  (average mu = 0.171, current mu = 0.002) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
```

프로덕션에서는 메모리가 부족해지는 데에는 1분도 채 걸리지 않을 수 있다. 이것이 메모리 소비량을 계속해서 모니터링하고 파악해야 하는 이유 중 하나다. 메모리 소비량은 시간이 지남에 따라 점차 느리게 증가할 수 있고, 문제가 있다는 것을 알 때 까지 며칠이 더 걸릴 수 잇다. 프로세스가 계속 충돌하고, 메모리 부족 예외가 로그에 표시되면 코드에서 메모리 누수가 발생한 것일 수 있다.

또한 프로세스는 더 많은 데이터로 작업 하기 때문에 더많은 메모리를 소비할 수 있다. 리소스 사용량이 계속 증가하면 이를 마이크로서비스로 분리해야 할 수도 있다. 마이크로 서비스로 분리하면 메모리 부담을 줄이고, 노드를 수평으로 확장할 수 있다.

## nodejs의 메모리 누수를 추적하는 방법

`process.memoryUsage` 함수내 `heapUsed` 변수는 유용하다. 메모리 누수를 디버깅하는 한가지 방법은 메모리 지표를 다른 도구에 넣어두는 것이다. 그러나 이 구현은 정교하지 않아서 분석을 할 때는 수동으로 해야 한다.

```javascript
const path = require('path')
const fs = require('fs')
const os = require('os')

const start = Date.now()
const LOG_FILE = path.join(__dirname, 'memory-usage.csv')

fs.writeFile(LOG_FILE, 'Time Alive (secs),Memory GB' + os.EOL, () => {}) // fire-and-forget
```

힙 할당 지표를 메모리에 저장하지 않기 위해 데이터를 쉽게 사용할 수 있도록 csv 파일에 쓰도록 처리한다. 만약 점진적으로 메모리 지표를 가져오기 위해서는 위 테스트 코드 `console.log` 상단에 아래 코드를 붙여 두면 된다.

```javascript
const elapsedTimeInSecs = (Date.now() - start) / 1000
const timeRounded = Math.round(elapsedTimeInSecs * 100) / 100

s.appendFile(LOG_FILE, timeRounded + ',' + gbRounded + os.EOL, () => {}) // fire-and-forget
```

이 코드를 사용하면 시간이 지남에 따라, 힙 사용이 증가한다면 메모리 누수를 디버깅할 수 있다.

### index.js

```javascript
function allocateMemory(size) {
  // Simulate allocation of bytes
  const numbers = size / 8
  const arr = []
  arr.length = numbers
  for (let i = 0; i < numbers; i++) {
    arr[i] = i
  }
  return arr
}

const path = require('path')
const fs = require('fs')
const os = require('os')

const memoryLeakAllocations = []

const field = 'heapUsed'
const allocationStep = 10000 * 1024 // 10MB

const TIME_INTERVAL_IN_MSEC = 40

setInterval(() => {
  const allocation = allocateMemory(allocationStep)

  memoryLeakAllocations.push(allocation)

  const mu = process.memoryUsage()
  // # bytes / KB / MB / GB
  const gbNow = mu[field] / 1024 / 1024 / 1024
  const gbRounded = Math.round(gbNow * 100) / 100

  const start = Date.now()
  const LOG_FILE = path.join(__dirname, 'memory-usage.csv')

  const elapsedTimeInSecs = (Date.now() - start) / 1000
  const timeRounded = Math.round(elapsedTimeInSecs * 100) / 100

  s.appendFile(LOG_FILE, timeRounded + ',' + gbRounded + os.EOL, () => {})
  console.log(`Heap allocated ${gbRounded} GB`)
}, TIME_INTERVAL_IN_MSEC)
```

![memory-usage](./images/memory-usage.png)

메모리 누수 감지 코드를 재사용할 수 있게 만드는 방법 중 하나는, 이 누수 감지 코드가 메인 루프 내부에 존재할 필요가 없으므로 이 코드를 자체 간격으로 실행될 수 있도록 래핑하는 것이다.

```javascript
setInterval(() => {
  const mu = process.memoryUsage()
  // # bytes / KB / MB / GB
  const gbNow = mu[field] / 1024 / 1024 / 1024
  const gbRounded = Math.round(gbNow * 100) / 100

  const elapsedTimeInSecs = (Date.now() - start) / 1000
  const timeRounded = Math.round(elapsedTimeInSecs * 100) / 100

  fs.appendFile(LOG_FILE, timeRounded + ',' + gbRounded + os.EOL, () => {}) // fire-and-forget
}, TIME_INTERVAL_IN_MSEC)
```

이는 운영용 코드로는 쓸 수 없지만, 적어도 로컬 에서 메모리 누수를 디버깅하는 방법을 보여주었다.실제 구현에서는 서버 디스크 공간이 부족하지 않도록 하는 설정, 비주얼, 알림, 로그 rotate 등이 필요하다.

## 프로덕션 코드에서 메모리 누수 추적하기

위 코드를 프로덕션에서 쓰는 것은 무리 일 것이다. 프로덕션에서는 [PM2와 같은 데몬 프로세스](https://pm2.keymetrics.io/docs/usage/restart-strategies/)를 활용하여 추적할 수 있을 것이다.

```bash
pm2 start index.js --max-memory-restart 8G
```

또다른 도구로는 [node-memwatch](https://github.com/lloyd/node-memwatch)가 있다. 이 라이브러리는 메모리 누수가 발생하면 특정 코드를 실행시킬 수 있다.

```javascript
const memwatch = require('memwatch')

memwatch.on('leak', function (info) {
  // event emitted
  console.log(info.reason)
})
```


어디서 새고 있을까 내 메모리는

Latest

웹 애플리케이션에서 자바스크립트 프로파일링 해보기

colors.js와 faker.js 사태가 준 교훈

2021년 회고

nextjs를 적용하면서 알게 된 사실들

nodejs의 메모리 제한