** 주의: 제가 하고 있는 프로젝트의 방향성과는 다를 수 있습니다

로깅은 서버사이드에서 중요한 처리 중 하나다. 서버에서 어떤 일들이 일어나고 있는지 알 수 있고, 의도치 않은 동작이나 버그가 발생했을 경우 재빠르게 원인을 찾을 수 있다. 본문에서는 nodejs에서 로깅을 남기는 몇가지 좋은 사례를 알아본다.

## Table of Contents

## 0. 시작하기전에

한가지 알아둬야 할 것은, 모든 정보를 로깅으로 남겨서는 안된다는 것이다. 로깅이 성능과 데이터 용량에 영향을 미치는 것도 있지만, 그것보다도 더 중요한 것은 주민등록번호, 카드번호, 암호와 같은 민감한 정보는 절대로 남겨서는 안된다. 

## 1. console.log로 시작하기

자바스크립트를 배운 순간부터 지금까지 (...) 가장 많이 사용하 있는 `console.log`다. 개인적으로도 급한 프로젝트를 휙휙 처리하다보면 로깅을 `console.log`로 남기곤 했다 (죄송합니다). 조금 더 나아가서 `console.error` `console.group` 등을 사용하는 경우도 있다. `console.log`는 코드 자체가 없어보이는 것은 둘째치고 [자바스크립트의 성능에 안좋은 영향을 미친다.](https://stackoverflow.com/a/11426318) 따라서 본격적으로 로깅을 원한다면, 진짜 로깅에 사용되는 라이브러리를 사용하는 것이 좋다.

## 2. 로그 라이브러리 사용하기

node 진영에서 가장 많이 사용되는 로깅 라이브러리는 크게 다음과 같다.

- [winston](https://github.com/winstonjs/winston): 로그를 별도의 데이터베이스 등에 저장하고 싶을 때. 내가 거친 프로젝트가 대부분 이걸 썼던 것 같다.
- [bunyan](https://github.com/trentm/node-bunyan): CLI가 기가막히다
- [log4js](https://github.com/log4js-node/log4js-node): 로그 스트림, aggregator 등 지원

```javascript
const winston = require('winston');
const config = require('./config');

const enumerateErrorFormat = winston.format((info) => {
  if (info instanceof Error) {
    Object.assign(info, { message: info.stack });
  }
  return info;
});

const logger = winston.createLogger({
  level: config.env === 'development' ? 'debug' : 'info',
  format: winston.format.combine(
    enumerateErrorFormat(),
    config.env === 'development' ? winston.format.colorize() : winston.format.uncolorize(),
    winston.format.splat(),
    winston.format.printf(({ level, message }) => `${level}: ${message}`)
  ),
  transports: [
    new winston.transports.Console({
      stderrLevels: ['error'],
    }),
  ],
});

module.exports = logger;
```

로깅 라이브러리는 일반적인 `console.log`을 사용하는 것보다 여러 측면에서 좋다. 성능에도 더 좋고, 기능도 다양하고, 쉽게 알록달록하게 만들수도 있다.(?)

## 3. Morgan으로 node내 http 요청 로깅하기

또 다른 좋은 습관 중 하나는 nodejs 애플리케이션 내 http 요청을 로깅하는 것이다. 이를 위한 좋은 라이브러리가 바로 [morgan](https://github.com/expressjs/morgan) 이다. 이 도구는 서버 로그를 가져와서 체계화 시켜 읽기 쉽게 만들어 준다.

```javascript
const morgan = require('morgan');
app.use(morgan('dev'));
```

이미 정의된 문자열 포맷을 사용하려면

```javascript
morgan('tiny')
```

를 쓰면 된다.

### winston + morgan

```javascript
const morgan = require('morgan');
const config = require('./config');
const logger = require('./logger');

morgan.token('message', (req, res) => res.locals.errorMessage || '');

const getIpFormat = () => (config.env === 'production' ? ':remote-addr - ' : '');
const successResponseFormat = `${getIpFormat()}:method :url :status - :response-time ms`;
const errorResponseFormat = `${getIpFormat()}:method :url :status - :response-time ms - message: :message`;

const successHandler = morgan(successResponseFormat, {
  skip: (req, res) => res.statusCode >= 400,
  stream: { write: (message) => logger.info(message.trim()) },
});

const errorHandler = morgan(errorResponseFormat, {
  skip: (req, res) => res.statusCode < 400,
  stream: { write: (message) => logger.error(message.trim()) },
});

module.exports = {
  successHandler,
  errorHandler,
};
```

위 예제에서 보이는 것처럼, 두 라이브러리를 함께 쓰기 위해서는 단순히 winston에 morgan에서 나온 결과물을 넘겨주면 된다.

## 4. 로그레벨 정의하기

로그의 이벤트를 구분하기 위해서 로그 수준을 체계적으로 정리하는 것이 중요하다. 이를 잘 정리해두면, 필요한 정보만 빼다가 쉽게 알아낼 수 있다. 로그 수준에는 여러개가 있지만, 다음과 같이 나누는 것이 일반적이다.

- error
- warning
- info
- debug

## 5. 로그 관리 시스템 사용하기

애플리케이션의 크기에 따라서 별도로 로그를 관리하는 시스템을 가져다 쓰는 것이 좋을 수도 있다. (물론 그냥 cat grep 할 수도 있겠지만) 로그 관리 시스템을 사용하면, 실시간으로 로그를 추적하고 분석할 수 있으므로 코드를 개선하는데 용이하다. 주로 사용하는 프로그램은 다음과 같다.

- [Sentry](https://sentry.io/welcome/) 사실 이거밖에 안써봄
- [Loggly](https://www.loggly.com/)
- [McAfee Enterprise Log Search](https://www.mcafee.com/enterprise/ko-kr/products/enterprise-log-search.html)
- [Graylog](https://www.graylog.org/)
- [Splunk](https://www.splunk.com/)
- [Logmatic](https://logmatic.com/)
- [Logstash](https://www.elastic.co/kr/logstash) 생각해보니 엘라스틱 서치 쓰느라 이것도 써본듯


## 6. 상태 모니터링 도구

상태 모니터링 도구는 서버 성능을 추적하고, 애플리케이션 충돌 또는 다운타임의 원인을 식별해 낼 수 있는 좋은 방법이다. 대부분의 도구는 오류 스택 추적과, 성능 모니터링 기능을 제공한다. Nodejs에서 유명한 도구는 다음과 같다.

- [PM2](https://pm2.keymetrics.io/): 가장 유명한 도구 
- [Sematext](https://sematext.com/)
- [Appmetrics](https://www.app-metrics.io/)
- [ClinicJS](https://clinicjs.org/)
- [AppSignal](https://appsignal.com/)
- [Express Status Monitor](https://github.com/RafalWilinski/express-status-monitor)

## 7. 결론

로그도 확인 할 필요 없이 24/365로 잘돌아가는 서비스가 있다면 좋겠지만, 사실 그런 인프라는 존재 하지 않는다. 운영환경을 모니터링하고, 오류를 줄이기 위해서 로깅은 개발자들에게 필수다. 

어쩌다 보니 nodejs도 하고 있🤣

Nodejs에서 로깅하기

[이 전 블로그 포스팅](https://yceffort.kr/2021/01/brotli-better-html-compression)을 통해서 brotli가 무엇인지, 왜 좋은지, 왜 써야 하는지에 대해서 알아봤다. 그러나 한 가지 더 궁금한 것이 있다. 과연 비단 IE 에서 지원하지 않는다는 이유만으로 쓰지 않는 것일까? 시스템 엔지니어들이 게을러서 brotli 지원을 안해주는 것일까?

Gzip은 웹 압축에 있어서 일종의 디 팩토 같이 자리잡고 있다. 대충 모든 웹사이트의 80% 정도가 gzip으로 서빙되고 있는 것으로 알려져 있다. [참고](https://almanac.httparchive.org/en/2019/compression) 근데 압축이 안되있는 사이트가 60% 쯤 정도 된다. (허허)

아무튼 지간에, Gzip도 충분히 효과적인 압축 알고리즘이지만, brotli가 gzip보다 더 크게 압축해 주는 알고리즘으로 등장했다.

![gzip-vs-brotli](https://csswizardry.com/wp-content/uploads/2020/04/react-dom-brotli.png)

그리고 이전에 말했듯이, IE에서는 brotli를 지원하지ㄷ 않지만, 현재 사이트의 93%가 IE외의 환경에서 서비스 되므로 대부분의 사용자에게 brotli를 이용하여 서비스 할 수 있다. 6%는 무시하라는 말처럼 들릴 수도 있지만(?) brotli를 받아줄 수 없는 브라우저의 경우 gzip으로 fallback 되게 할 수 있다. 이는 나중에 다룬다.

그런데 왜, 많은 사이트들이 brotli를 사용하지 않는 것일까? brotli로 전환하는 것은 얼마나 중요한 것일까?

## 작다는 것이 반드시 더 빠르다는 것은 아니다.

물론, 일반적으로는 작은 파일이 더 빠르게 도착하는 것이 사실이다. 그렇다고 파일 크기를 20% 줄였다고 20% 더 빠르게 도착하는 것은 아니다. 다시 말해 파일 크기는 웹 성능을 측정하는 한가지 측면일 뿐, 이 외에도 리소스 대기시간, 패킷손실과 같은 다른 많은 요소와 상수가 웹 성능에 영향을 미친다. 크기를 절약하는 것은 데이터를 더 빠르게 도착하게 하는 것에 도움이 되지만, latency 에 제한이 있는 경우에는 데이터 청크가 도달하는 속도에 영향을 미치지 않는다.

## TCP, Packet, Round trip

먼저 tcp에 대해 알아보자. 서버에서 파일을 받을 때는 한번에 전체 파일을 가져오지 않는다. HTTP가 위치한 TCP는 파일을 세그먼트 또는 패킷으로 나눈다. 이러한 패킷은 순서대로 클라이언트에 전송된다. 패킷은 클라이언트가 모든 패킷을 가질 때 까지, 다음 패킷을 전송하기 전에 각 패킷을 확인하고 전송하며, 클라이언트가 이러한 패킷을 조립하여 하나의 파일로 조립하게 된다. 이러한 일련의 패킷은 라운드 트립 방식으로 전송된다.

각각의 새로운 TCP 연결은 현재 사용 가능한 대역폭이 무엇인지, 연결을 얼마나 신뢰할 수 있는지를 알 수 있는 방법이 없다. (예: 패킷 손실 등) 만약 서버가 한 연결당 1메가 비트 짜리 연결을 통애 메가바이트급 전송을 시도한다면, 서버 연결 요청이 쇄도하여 혼잡이 발생하게 될 것이다. 만약 1메가 바이트의 사용가능한 연결을 바탕으로 1메가 비트의 데이터를 전송하려고 한다면, 용량이 낭비되고 말 것이다.

이를 해결하기 위해 [TCP는 slow start를 사용한다.](https://ko.wikipedia.org/wiki/%ED%98%BC%EC%9E%A1_%EC%A0%9C%EC%96%B4) 각각의 새로운 TCP연결은 첫번째 왕복에서 데이터 패킷 10개만 사용하도록 제한된다. (약 14kb) 10개가 성공적으로 도착한다면, 그 다음에는 20개의 패킷을, 그다음에는 40, 80, 160 으로 기하급수적으로 증가하는데 이 증가는 다음 수준에 다다를 때 까지 발생한다.

1. 패킷손실이 발생. 이 지점에서 서버는 마지막 패킷 수를 절반으로 줄이고 다시 시도
2. 대역폭 최대에 다달아서 최대 용량을 사용가능한 경우

이러한 전략은 웹 애플리케이션이 만드는 모든 새로운 TCP연결에 활용된다.

다시 브라우저로 돌아와서, 새 TCP 연결의 초기 대역폭 용량은 14kb다. 리액트로 예를 들어서, 아래의 표를 보자.

| Round Trip | TCP Capacity (kb) | Cumulative Transfer (kb) | React DOM               |
| ---------- | ----------------- | ------------------------ | ----------------------- |
| 1          | 14                | 14                       |                         |
| 2          | 28                | 42                       | Gzip(37kb) Brotli(33kb) |
| 3          | 56                | 98                       |                         |
| 4          | 112               | 210                      | Uncompressed (119kb)    |
| 5          | 224               | 434                      |                         |

(둘다 최대 치로 압축)

**압축은 brotli가 4kb나 더 되었지만, TCP 작동 원리에 따라서 모두 두 번째 왕복에 다운로드가 완료 되었다. 따라서, 모든 왕복시간이 거의 균일하다면, Gzip이나 brotli나 모두 전송시간에 차이가 없다는 결론이 나오게 된다.**

따라서 요점은 파일 크기가 아니라, TCP, 즉 패킷 및 왕복에 관한 것이다. 파일을 더 작게 만드는 것이 문제가 아니고, 파일을 의미있게 작게 만들어서 더 낮은 왕복 버킷에 집어 넣어야 한다. 결과적으로, brotli가 gzip보다 더욱 효과적이라면 파일을 왕복 임계값 아래로 (위의 예제에서는 14kb급으로), 더욱 공격적으로 압축을 할 수 있어야 한다.

이 규칙은 또한 새로운 TCP 연결에만 적용되며, primed TCP 연결로 가져온 파일은 영향을 받지 않는다. 이는 두가지 중요한 점을 제시한다.

1. 정적자산을 자체 호스팅 하는것이 중요하다. 이렇게 하면 이미 워밍업되어 있는 (새로 연결되어 있는) TCP에 연결 할 수 있으므로, 시작속도가 느려지는 것을 방지할 수 있다.
2. 기하 급수적으로 패킷이 커지면 얼마나 거대한 대역폭에 빠르게 도달할 수 있다. 연결을 더 많이 쓰고 재사용할 수록 용량이 빠르게 늘어난다.

| Round Trip | TCP Capacity (kb) | Cumulative Transfer (kb) |
| ---------- | ----------------- | ------------------------ |
| 1          | 14                | 14                       |
| 2          | 28                | 42                       |
| 3          | 56                | 98                       |
| 4          | 112               | 210                      |
| 5          | 224               | 434                      |
| 6          | 448               | 882                      |
| 7          | 896               | 1778                     |
| 8          | 1792              | 3570                     |
| 9          | 3584              | 7154                     |
| 10         | 7168              | 14322                    |
| ...        | ...               | ...                      |
| 20         | 7340032           | 14680050                 |

10 회 왕복정도면, TCP는 7168kb이고, 14322kb를 전송했다. 이는 일반적인 웹 브라우징에 적합하다. 여기서 말하는 `일반적인`이라는 것은 대역폭 한계에 도달하기 전에 전체 웹페이지와 모든 하위 리소스를 로드 하는 것이다. 따라서, 1gbps 급 속도는 대부분 사용하지 않기 때문에 일상적인 브라우징이 더 빨라졌던가 하는 것은 느끼지 못하게 된다.

## 실제 세계에서의 실험

brotli로 제공되는 사이트에 brotli 사용을 중지하면 된다. https://www.webpagetest.org/ 에서 `content-encoding`에 `gzip`을 명시해주면 된다.

- 압축을 완전히 비활성화: `accept-encoding: 랜덤문자열`
- brotli비활성화 및 gzip: `accept-encoding: gzip`
- brotli: 비워 둔다.

결과: https://docs.google.com/spreadsheets/d/18A_dP1DuavmMjmFnHXf4gdw6ThTne5e6UyzUUgxKI5s/edit#gid=0

- gzip 크기 감소 vs 비압축: 73% 감소
- gzip fcp vs 비 압축: 23 % 감소
- brotli 크기 감소 vs gzip: 5%
- brotli fcp vs 5zip: 3%

gzip은 비 압축 대비 약 72% 정도의 크기 감소를 이뤄 냈고, 이에 더해 brotli는 gzip 대비 5.7%를 더 감소 시켰다.

## 결론

gzip에 비해 brotli가 갖는 이점은 미미하다.

brotli를 활성화 하는 것이 CDN 관리자 메뉴의 버튼 하나를 누르는 것 만큼 간단하다면 지금 바로 실행하는 것이 좋다. 최소한의 개선이라도 없는 것보단 낫고, fallback 제공도 잘 되어 있다.

가능한 경우 정적 자산의 경우 가능한 가장 큰 압축 수준을 사용하며, 동적인 요소에 대해서는 중간 정도의 압축을 해주는 것이 좋다. 만약 nginx 를 사용중이라면, 현재 압축수준이 1로 (기본값으로) 되어 있는지 확인해보는 것이 좋다.

brotli를 구현하기 위해 너무 애쓸 필요는 없다. 압축할 수 있는 모든 항목에 대해 gzip이 제공되고 있다면, 그것만으로도 충분할 수 있다.

출처: https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/#smaller-doesnt-necessarily-mean-faster


항상 왜 그럴까를 고민해 봐야 하는 것 같다

그런데 왜 brotli를 사용하지 않는 것일까? 🤔

<p><a href="https://yceffort.kr/2021/01/brotli-better-html-compression">이 전 블로그 포스팅</a>을 통해서 brotli가 무엇인지, 왜 좋은지, 왜 써야 하는지에 대해서 알아봤다. 그러나 한 가지 더 궁금한 것이 있다. 과연 비단 IE 에서 지원하지 않는다는 이유만으로 쓰지 않는 것일까? 시스템 엔지니어들이 게을러서 brotli 지원을 안해주는 것일까?</p>
<p>Gzip은 웹 압축에 있어서 일종의 디 팩토 같이 자리잡고 있다. 대충 모든 웹사이트의 80% 정도가 gzip으로 서빙되고 있는 것으로 알려져 있다. <a href="https://almanac.httparchive.org/en/2019/compression">참고</a> 근데 압축이 안되있는 사이트가 60% 쯤 정도 된다. (허허)</p>
<p>아무튼 지간에, Gzip도 충분히 효과적인 압축 알고리즘이지만, brotli가 gzip보다 더 크게 압축해 주는 알고리즘으로 등장했다.</p>
<p><img src="https://csswizardry.com/wp-content/uploads/2020/04/react-dom-brotli.png" alt="gzip-vs-brotli"></p>
<p>그리고 이전에 말했듯이, IE에서는 brotli를 지원하지ㄷ 않지만, 현재 사이트의 93%가 IE외의 환경에서 서비스 되므로 대부분의 사용자에게 brotli를 이용하여 서비스 할 수 있다. 6%는 무시하라는 말처럼 들릴 수도 있지만(?) brotli를 받아줄 수 없는 브라우저의 경우 gzip으로 fallback 되게 할 수 있다. 이는 나중에 다룬다.</p>
<p>그런데 왜, 많은 사이트들이 brotli를 사용하지 않는 것일까? brotli로 전환하는 것은 얼마나 중요한 것일까?</p>
<h2 id="작다는-것이-반드시-더-빠르다는-것은-아니다">작다는 것이 반드시 더 빠르다는 것은 아니다.</h2>
<p>물론, 일반적으로는 작은 파일이 더 빠르게 도착하는 것이 사실이다. 그렇다고 파일 크기를 20% 줄였다고 20% 더 빠르게 도착하는 것은 아니다. 다시 말해 파일 크기는 웹 성능을 측정하는 한가지 측면일 뿐, 이 외에도 리소스 대기시간, 패킷손실과 같은 다른 많은 요소와 상수가 웹 성능에 영향을 미친다. 크기를 절약하는 것은 데이터를 더 빠르게 도착하게 하는 것에 도움이 되지만, latency 에 제한이 있는 경우에는 데이터 청크가 도달하는 속도에 영향을 미치지 않는다.</p>
<h2 id="tcp-packet-round-trip">TCP, Packet, Round trip</h2>
<p>먼저 tcp에 대해 알아보자. 서버에서 파일을 받을 때는 한번에 전체 파일을 가져오지 않는다. HTTP가 위치한 TCP는 파일을 세그먼트 또는 패킷으로 나눈다. 이러한 패킷은 순서대로 클라이언트에 전송된다. 패킷은 클라이언트가 모든 패킷을 가질 때 까지, 다음 패킷을 전송하기 전에 각 패킷을 확인하고 전송하며, 클라이언트가 이러한 패킷을 조립하여 하나의 파일로 조립하게 된다. 이러한 일련의 패킷은 라운드 트립 방식으로 전송된다.</p>
<p>각각의 새로운 TCP 연결은 현재 사용 가능한 대역폭이 무엇인지, 연결을 얼마나 신뢰할 수 있는지를 알 수 있는 방법이 없다. (예: 패킷 손실 등) 만약 서버가 한 연결당 1메가 비트 짜리 연결을 통애 메가바이트급 전송을 시도한다면, 서버 연결 요청이 쇄도하여 혼잡이 발생하게 될 것이다. 만약 1메가 바이트의 사용가능한 연결을 바탕으로 1메가 비트의 데이터를 전송하려고 한다면, 용량이 낭비되고 말 것이다.</p>
<p>이를 해결하기 위해 <a href="https://ko.wikipedia.org/wiki/%ED%98%BC%EC%9E%A1_%EC%A0%9C%EC%96%B4">TCP는 slow start를 사용한다.</a> 각각의 새로운 TCP연결은 첫번째 왕복에서 데이터 패킷 10개만 사용하도록 제한된다. (약 14kb) 10개가 성공적으로 도착한다면, 그 다음에는 20개의 패킷을, 그다음에는 40, 80, 160 으로 기하급수적으로 증가하는데 이 증가는 다음 수준에 다다를 때 까지 발생한다.</p>
<ol>
<li>패킷손실이 발생. 이 지점에서 서버는 마지막 패킷 수를 절반으로 줄이고 다시 시도</li>
<li>대역폭 최대에 다달아서 최대 용량을 사용가능한 경우</li>
</ol>
<p>이러한 전략은 웹 애플리케이션이 만드는 모든 새로운 TCP연결에 활용된다.</p>
<p>다시 브라우저로 돌아와서, 새 TCP 연결의 초기 대역폭 용량은 14kb다. 리액트로 예를 들어서, 아래의 표를 보자.</p>
<table>
<thead>
<tr>
<th>Round Trip</th>
<th>TCP Capacity (kb)</th>
<th>Cumulative Transfer (kb)</th>
<th>React DOM</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>14</td>
<td>14</td>
<td></td>
</tr>
<tr>
<td>2</td>
<td>28</td>
<td>42</td>
<td>Gzip(37kb) Brotli(33kb)</td>
</tr>
<tr>
<td>3</td>
<td>56</td>
<td>98</td>
<td></td>
</tr>
<tr>
<td>4</td>
<td>112</td>
<td>210</td>
<td>Uncompressed (119kb)</td>
</tr>
<tr>
<td>5</td>
<td>224</td>
<td>434</td>
<td></td>
</tr>
</tbody>
</table>
<p>(둘다 최대 치로 압축)</p>
<p><strong>압축은 brotli가 4kb나 더 되었지만, TCP 작동 원리에 따라서 모두 두 번째 왕복에 다운로드가 완료 되었다. 따라서, 모든 왕복시간이 거의 균일하다면, Gzip이나 brotli나 모두 전송시간에 차이가 없다는 결론이 나오게 된다.</strong></p>
<p>따라서 요점은 파일 크기가 아니라, TCP, 즉 패킷 및 왕복에 관한 것이다. 파일을 더 작게 만드는 것이 문제가 아니고, 파일을 의미있게 작게 만들어서 더 낮은 왕복 버킷에 집어 넣어야 한다. 결과적으로, brotli가 gzip보다 더욱 효과적이라면 파일을 왕복 임계값 아래로 (위의 예제에서는 14kb급으로), 더욱 공격적으로 압축을 할 수 있어야 한다.</p>
<p>이 규칙은 또한 새로운 TCP 연결에만 적용되며, primed TCP 연결로 가져온 파일은 영향을 받지 않는다. 이는 두가지 중요한 점을 제시한다.</p>
<ol>
<li>정적자산을 자체 호스팅 하는것이 중요하다. 이렇게 하면 이미 워밍업되어 있는 (새로 연결되어 있는) TCP에 연결 할 수 있으므로, 시작속도가 느려지는 것을 방지할 수 있다.</li>
<li>기하 급수적으로 패킷이 커지면 얼마나 거대한 대역폭에 빠르게 도달할 수 있다. 연결을 더 많이 쓰고 재사용할 수록 용량이 빠르게 늘어난다.</li>
</ol>
<table>
<thead>
<tr>
<th>Round Trip</th>
<th>TCP Capacity (kb)</th>
<th>Cumulative Transfer (kb)</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>14</td>
<td>14</td>
</tr>
<tr>
<td>2</td>
<td>28</td>
<td>42</td>
</tr>
<tr>
<td>3</td>
<td>56</td>
<td>98</td>
</tr>
<tr>
<td>4</td>
<td>112</td>
<td>210</td>
</tr>
<tr>
<td>5</td>
<td>224</td>
<td>434</td>
</tr>
<tr>
<td>6</td>
<td>448</td>
<td>882</td>
</tr>
<tr>
<td>7</td>
<td>896</td>
<td>1778</td>
</tr>
<tr>
<td>8</td>
<td>1792</td>
<td>3570</td>
</tr>
<tr>
<td>9</td>
<td>3584</td>
<td>7154</td>
</tr>
<tr>
<td>10</td>
<td>7168</td>
<td>14322</td>
</tr>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
<tr>
<td>20</td>
<td>7340032</td>
<td>14680050</td>
</tr>
</tbody>
</table>
<p>10 회 왕복정도면, TCP는 7168kb이고, 14322kb를 전송했다. 이는 일반적인 웹 브라우징에 적합하다. 여기서 말하는 <code>일반적인</code>이라는 것은 대역폭 한계에 도달하기 전에 전체 웹페이지와 모든 하위 리소스를 로드 하는 것이다. 따라서, 1gbps 급 속도는 대부분 사용하지 않기 때문에 일상적인 브라우징이 더 빨라졌던가 하는 것은 느끼지 못하게 된다.</p>
<h2 id="실제-세계에서의-실험">실제 세계에서의 실험</h2>
<p>brotli로 제공되는 사이트에 brotli 사용을 중지하면 된다. <a href="https://www.webpagetest.org/">https://www.webpagetest.org/</a> 에서 <code>content-encoding</code>에 <code>gzip</code>을 명시해주면 된다.</p>
<ul>
<li>압축을 완전히 비활성화: <code>accept-encoding: 랜덤문자열</code></li>
<li>brotli비활성화 및 gzip: <code>accept-encoding: gzip</code></li>
<li>brotli: 비워 둔다.</li>
</ul>
<p>결과: <a href="https://docs.google.com/spreadsheets/d/18A_dP1DuavmMjmFnHXf4gdw6ThTne5e6UyzUUgxKI5s/edit#gid=0">https://docs.google.com/spreadsheets/d/18A_dP1DuavmMjmFnHXf4gdw6ThTne5e6UyzUUgxKI5s/edit#gid=0</a></p>
<ul>
<li>gzip 크기 감소 vs 비압축: 73% 감소</li>
<li>gzip fcp vs 비 압축: 23 % 감소</li>
<li>brotli 크기 감소 vs gzip: 5%</li>
<li>brotli fcp vs 5zip: 3%</li>
</ul>
<p>gzip은 비 압축 대비 약 72% 정도의 크기 감소를 이뤄 냈고, 이에 더해 brotli는 gzip 대비 5.7%를 더 감소 시켰다.</p>
<h2 id="결론">결론</h2>
<p>gzip에 비해 brotli가 갖는 이점은 미미하다.</p>
<p>brotli를 활성화 하는 것이 CDN 관리자 메뉴의 버튼 하나를 누르는 것 만큼 간단하다면 지금 바로 실행하는 것이 좋다. 최소한의 개선이라도 없는 것보단 낫고, fallback 제공도 잘 되어 있다.</p>
<p>가능한 경우 정적 자산의 경우 가능한 가장 큰 압축 수준을 사용하며, 동적인 요소에 대해서는 중간 정도의 압축을 해주는 것이 좋다. 만약 nginx 를 사용중이라면, 현재 압축수준이 1로 (기본값으로) 되어 있는지 확인해보는 것이 좋다.</p>
<p>brotli를 구현하기 위해 너무 애쓸 필요는 없다. 압축할 수 있는 모든 항목에 대해 gzip이 제공되고 있다면, 그것만으로도 충분할 수 있다.</p>
<p>출처: <a href="https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/#smaller-doesnt-necessarily-mean-faster">https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/#smaller-doesnt-necessarily-mean-faster</a></p>

디자인 패턴에는 세가지 유형이 있다.

- Creational: 객체 인스턴스 생성
- Structural: 객체 설계 방식
- Behavioural: 객체가 상호 작용하는 방식

## Singleton

클래스의 단일 인스턴스만을 원할 때 이 패턴을 사용한다. 즉, 여러개의 인스턴스를 생성하는 것이 아니라 하나만 생성하는 것이다. 인스턴스가 없다면 새 인스턴스를 생성한다. 인스턴스가 있는 경우에는, 해당 인스턴스를 사용한다.

```javascript
class DatabaseConnection {
  constructor() {
    this.databaseConnection = 'dummytext'
  }

  getNewDBConnection() {
    return this.databaseConnection
  }
}

class Singleton {
  constructor() {
    throw new Error('Use the getInstance() method on the Singleton object!')
  }

  getInstance() {
    if (!Singleton.instance) {
      Singleton.instance = new DatabaseConnection()
    }

    return Singleton.instance
  }
}

module.exports = Singleton
```

위에서 보이는 것 처럼, 싱클턴을 구축할 수 있는 많은 예제가 있다. 이 외에 이 설계 패턴을 구현하는 더 짧은 방법이 있다.

```javascript
class DatabaseConnection {
  constructor() {
    this.databaseConnection = 'dummytext'
  }

  getNewDBConnection() {
    return this.databaseConnection
  }
}

module.exports = new DatabaseConnection()
```

이것이 작동할 수 있는 이유는 module caching system 이다. [module caching system이란, 모듈이 처음 로딩 된 이후에 캐싱이 되는 것을 의미한다.](https://nodejs.org/api/modules.html#modules_caching) 즉, 위의 예제에서는, 새롭게 exported된 인스턴스는 캐싱이 되며, 이것이 재 사용될 때마다 이 캐쉬댄 내용을 불러온다는 뜻이다.

따라서,Nodejs에서 싱글턴을 구현하는 방법은 위 처럼 두가지로 볼 수 있다.

### 요약

- 싱클턴 방식은 단 하나의 클래스 인스턴스가 필요할 때 유용하다.
- Nodejs에서는, module caching system을 활용해서 export한 모듈을 바로 쓸 수 있다.

## 팩토리

팩토리 디자인 패턴은, 객체를 생성하는데 사용되는 인터페이스 또는 추상 클래스를 정의 하는 것이다. 이렇게 생성된 인터페이스 및 추상클래스를 사용하여 다른 객체를 초기화 한다. 아래의 예를 살펴보자.

```javascript
import Motorvehicle from './Motorvehicle'
import Aircraft from './Aircraf'
import Railvehicle from './Railvehicle'

const VehicleFactory = (type, make, model, year) => {
  if (type === car) {
    return new Motorvehicle('car', make, model, year)
  } else if (type === airplane) {
    return new Aircraft('airplane', make, model, year)
  } else if (type === helicopter) {
    return new Aircraft('helicopter', make, model, year)
  } else {
    return new Railvehicle('train', make, model, year)
  }
}

module.exports = VehicleFactory
```

이렇게 각 클래스 인스턴스를 별개로 만드는 대신에, `VehicleFactory`를 활용해서 타입을 명시하는 방법을 택할 수 있다. 위 예제를 활용해서, `car` 인스턴스를 만들려면 아래처럼 실행하면 된다.

```javascript
// 첫번째 매개변수에서 타입을 지정하고, 나머지는 그대로 변수를 넘긴다.
const audiAllRoad = VehicleFactory('car', 'Audi', 'A6 Allroad', '2020')
```

팩토리 디자인 패턴을 사용하면 객체의 구조가 객체 그 자체 사이를 디커플링 시킬 수 있다는 장점이 있다. 기존 코드를 손상시키지 않더라도 새 객체를 응용프로그램에 사용할 수 있다. 마지막으로, 인스턴스 생성과 관련된 모든 코드가 한 곳에 있으므로 코드를 더 잘 꾸밀 수 있다.

### 요약

- 팩토리 디자인 패턴은 객체 생성을 위한 인터페이스 및 추상 클래스를 제공한다.
- 동일한 인터페이스 및 추상 클래스를 사용하여 다른 객체를 만들 수 있다.
- 코드의 구조를 개선하고 유지관리가 더 쉬워 진다.

## 빌더

빌더 디자인 패턴 또한 마찬가지로 객체 구조와 객체를 분리할 수 있다. 따라서 복잡한 객체를 생성하는 코드를 단순화 한다. 단순한 객체를 만들 때는 과한 기능일 수 있지만, 복잡한 객체를 만들 때는 단순화 하는데 도움을 준다.

```javascript
class Car {
  constructor(make, model, year, isForSale = true, isInStock = false) {
    this.make = make
    this.model = model
    this.year = year
    this.isForSale = isForSale
    this.isInStock = isInStock
  }

  toString() {
    return console.log(JSON.stringify(this))
  }
}

class CarBuilder {
  constructor(make, model, year) {
    this.make = make
    this.model = model
    this.year = year
  }

  notForSale() {
    this.isForSale = false

    return this
  }

  addInStock() {
    this.isInStock = true

    return this
  }

  build() {
    return new Car(
      this.make,
      this.model,
      this.year,
      this.isForSale,
      this.isInStock,
    )
  }
}

module.exports = CarBuilder
```

위 패턴을 사용하면 `Car` 대신에 `CarBuilder`를 사용하여 객체를 만들 수 있다.

```javascript
const CarBuilder = require('./CarBuilder')

const bmw = new CarBuilder('bmw', 'x6', 2020).addInStock().build()
const audi = new CarBuilder('audi', 'a8', 2021).notForSale().build()
const mercedes = new CarBuilder('mercedes-benz', 'c-class', 2019).build()
```

만약에 이런 빌더 패턴 없이 복잡한 객체를 만들게 되면 에러를 발생할 가능성이 커진다.

```javascript
const bmw = new CarBuilder('bmw', 'x6', 2020, true, true)
```

뒤 이어 있는 `true`가 각각 무엇을 의미하는지 알아야 하기 때문에 객체 생성이 복잡해 지고, 에러를 만들어낼 가능성이 커진다. 따라서 빌더 디자인 패턴은 복잡한 객체 생성과 사용을 분리하는데 도움을 준다.

## 프로토타입

자바스크립트는 프로토타입 기반 언어이기 때문에, 프로토타입으로 상속이 구현되어 있다. 이 말인 즉슨, 모든 객체는 어떤 객체를 상속하고 있다는 뜻이다.

따라서 이른바 예제 객체 라고 불리우는 프로토타입 객체의 값을 복제 하여 새로운 객체를 만든다. 이는 프로토 타입이 새 객체의 일종의 청사진 역할을 하는 것이다. 이 설계 패턴을 활용하면 객체에 정의된 함수가 참조에 의해 생성된다는 이점을 얻을 수 있다. 즉, 모든 객체가 해당 기능의 복사본을 보유하는 것이 아니라 동일한 기능을 가르키게 된다. 간단히 말해, 프로토타입 기능은 프로토타입에 상속된 모든 객체에 사용할 수 있다.

```javascript
const atv = {
  make: 'Honda',
  model: 'Rincon 650',
  year: 2018,
  mud: () => {
    console.log('Mudding')
  },
}

const secondATV = Object.create(atv)
```

프로토타입에서 새로운 객체를 생성하기 위해서는, `Object.create()`를 활용하면 된다. 두번째 객체인 `secondATV`는 첫번째 객체인 `atv`와 같은 값을 가지게 된다. `mud()`를 호출해보면 같은 값을 찍는 것을 알 수 있다.

프로토타입 디자인 패턴을 활용하는 다른 방법은 클래스 안에 프로토타입을 명시하는 것이다.

```javascript
const atvPrototype = {
  mud: () => {
    console.log('Mudding')
  },
}

function Atv(make, model, year) {
  function constructor(make, model, year) {
    this.make = make
    this.model = model
    this.year = year
  }

  constructor.prototype = atvPrototype

  let instance = new constructor(make, model, year)
  return instance
}

const atv1 = Atv()
const atv2 = Atv('Honda', 'Rincon 650', '2018')
```

마찬가지로 두 인스턴스 모두 `atv` 객체에 정의된 항목에 액세스 할 수 있다.

결론적으로, 프로토타입 설계 패턴은 객체가 동일한 기능 또는 속성을 공유하기를 원할 때 유용하다.

### 요약

- 자바스크립트는 프로토타입 기반 언어다.
- 프로토타입 기반 상속을 사용한다.
- 각 객체는 다른 객체로 부터 상속된다.
- 새 객체는 프로토타입이라는 일종의 청사진에 따라 생성된다.
- 프로토타입에 정의된 함수는 모든 새 클래스에서 상속된다.
- 새 클래스는 개별 복사본을 갖는 대신 동일한 기능을 가리킨다.
- 


옛날 스타일의 가능한 객체 지향 프로그래밍

개발자가 알아야 하는 4가지 nodejs 디자인 패턴

가비지 컬렉션은 모든 언어에서 굉장히 중요한 프로세스다. C와 같은 언어에서 수동으로 처리하고, 다른 언어에서는 이를 자동으로 처리한다. 이를 자바스크립트 내부에서는 어떻게 처리할까?

## 자바스크립트 메모리 라이프 사이클

거의 모든 프로그래밍 언어의 메모리 라이프 사이클은 다음과 같이 작동한다.

1. allocate (할당)
2. use (사용)
3. release (해제)

차이 점은 이를 수행하는 방식 (사용하는 알고리즘)과 각 단계를 처리하는 방식(수동인지, 자동인지 여부)에 있다.

자바스크립트의 경우, 할당 및 해제는 자동으로 이루어 진다. 그렇다고 해서 개발자가 이에 대해 관심을 갖지 말라는 것은 아니다. 무한 루프, 잘못된 재귀처리, 콜백 지옥 등은 메모리 낭비를 이르켜 메모리 누수로 이어진다. 따라서 코딩을 잘해서 이러한 시나리오가 발생하지 않도록 하는 것이 중요하다.

자바스크립트의 경우, 새로운 변수가 선언되면 메모리에 공간이 할동 된다.

```javascript
var bar = 'bar'
```

그리고 메모리가 더이상 사용되지 않는다면, [변수 스코프](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var) 제한을 고려하여 메모리 공간 해제가 이루어진다.

하지만 어떻게 자바스크립트에서 더이상 메모리가 사용되지 않는다는 것을 알까? 그것은 바로 가비지 콜렉를 통해서 이루어진다.

## 가비지 콜렉션 전략

자바스크립트는 두개의 유명한 가비지 콜렉션 전략을 사용한다.

- Reference-counting
- Mark-and-sweep

[레퍼런스 카운팅](https://en.wikipedia.org/wiki/Reference_counting)은 파일, 소켓, 메모리 슬롯등 할당된 각 리소스를 가리키는 참조의 수를 계산하는 것이다.

메모리에 할당된 각 객체에 연결된 count 필드가 포함되어 있다고 생각해보자. 객체에 더이상 가리키는 참조가 없을 때 자동으로 가비지 콜렉팅 된다.

```javascript
var bar = {
  name: 'bar',
}
bar = ''
```

위 예제에서 `bar`와 `name`이 존재한다. `bar`는 새로운 값을 받았기 때문에, `name`은 가비지 콜렉팅 된다.

좀 더 복잡한 아래 예제를 살펴보자.

```javascript
var bar = {
  name: 'bar',
}
var bar = 'foo'

function check() {
  var bar = {}
  var foo = {}
  bar.name = foo
  foo.name = bar

  return true
}
check()
```

자바스크립트는 객체에 대한 참조 기반의 언어로, 이는 즉 객체 명이 매모리 내 인스턴스화 된 값을 가리키는 것을 의미한다. 이 예제에서는, 자식의 객채/변수는 부모가 자동으로 참조한다.

위 예제에서는 순환 참조를 만들고 있다. `check`함수내의 `bar`는 `foo`를 참조하고 있으며 그 반대 경우도 마찬가지다.

일반적으로 함수가 실행을 마치면 내부 요소는 가비지 컬렉팅이 된다. 그러나 이경우에는 객체가 여전히 서로 참조되고 있기 때문에 가비지 컬렉팅 되지 않는다.

여기에서 이제 자바스크립트의 두번째 작전인 `mark-and-sweep` 알고리즘이 동작한다.

이 알고리즘은 자바스크립트의 최상위 객체인 `global`(`window`)에 도달할 수 없는 객체를 찾는 방식으로 작동한다.

![mark-and-sweep1](https://d33wubrfki0l68.cloudfront.net/eff15dde3b4a6db32945c32b8b04047bc9ec9b8a/47eba/images/blog/2020-10/figure2.png)

보시다시피, 자바스크립트는 `name` 객체를 최상위에서 쉽게 찾을 수 있다.

만약 다음 코드가 실행되면 어떻게 될까?

```javascript
var bar = 'foo'
```

![mark-and-sweep2](https://d33wubrfki0l68.cloudfront.net/ad95ba131dc543352e80b6b34d48cf2003c7011b/3160a/images/blog/2020-10/figure3.png)

이제 더이상 `name`은 root에서 접근할 수 없는 객체가 된다.

나머지 프로세스는 굉장히 직관적이다. 알고리즘은 루트에서 하단의 객체까지 각각 루트에서 접근할 수 있는 객체인지, 혹은 `name`처럼 더이상 접근할 수 없는 객체인지를 별도로 표시해둔다.

이 과정은 자바스크립트의 GC만 알고 있는 몇몇 내부 조건을 통해 반복되고 있는데, 이는 대부분의 언어의 GC에서도 동일하게 동작한다.

## Node.js의 가비지 콜렉션

Node.js의 가비지 콜렉션이 어떻게 동작하는지 이해하기 전에, heap과 stack에 대해서 알아두어야 한다.

heap은 참조유형에 해당하는 데이터들이 나타나는 곳이다. 여기서 참조 유형이라 함은 객체, string, 클로져 등을 의미한다.

따라서 자바스크립트에서 객체가 만들어지면, 객체는 heap에 위치하게 된다.

```javascript
const myCat = new Cat('Joshua')
```

반면에, stack은 heap에서 생성된 객체에 대한 참조가 저장되는 곳이다. 예를 들어 함수의 argument는 stack에 존재하는 참조의 좋은 예다.

```javascript
function Cat(name) {
  this.name = name
}
```

그리고 힙은 `new space`와 `old space`로 나누어진다.

![heap](https://d33wubrfki0l68.cloudfront.net/0c2c3b1c7345423b26f87fa469dac4b20ec11d16/5db77/images/blog/2020-10/figure4.png)

`New space`는 새로운 객체와 변수를 할당하는 메모리 영역이며, 이름 그대로 새로운 것들이기 때문에 GC 처리가 빠르다. 이름에서 알 수 있듯이, 이영역은 비교적 이르게 할당된 객체들이 존재한다.

`Old space`는 `new space`에서 수집되지 않는 객체들이 얼마 후에 이동하는 곳이다. 사이즈가 큰 객체나, V8로 컴파일된 코드와 같은 것들이 존재한다.

Node.js는 GC가 `old space`로 가지 않도록 최선을 다한다. 왜냐하면 `old space`는 GC를 하는데 더 많은 비용이 들기 때문이다. 따라서 전체 대상의 20% 정도만 `old space`로 이동한다.

- `Scavenge`: 이 가비지 컬렉터는 실행될 때마다 메모리의 작은 부분을 청소하여 `young generation`을 처리한다. 매우 빠르다.
- `Mark-and-sweep`: 아까 언급했던 알고리즘으로, 느리지만 `old generation`에서 유용하게 동작할 수 있다.

## Node.js의 메모리 누수 예제

자바스크립트가 Nodejs 에서 메모리를 다루는 방법을 보는 좋은 예제는 아주 클래식한 메모리 누수 예제를 보는 것이다. 메모리 누수는 모든 GC전략이 루트 객체와의 연결을 잃어서 객체를 찾지 못할 때 발생한다. 그 외에도, 객체가 항상 다른 객체에 의해 참조되면서 동시에 크기가 커지는 경우에도 발생할 수 있다.

예를 들어 간단한 nodejs서버가 아래와 같이 있으며, 모든 요청에서 중요한 데이터를 저장하려 한다고 생각해보자.

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

const ml_Var = []
const server = http.createServer((req, res) => {
  let chunk = JSON.stringify({ url: req.url, now: new Date() })
  ml_Var.push(chunk)

  res.writeHead(200)
  res.end(JSON.stringify(ml_Var))
})

const PORT = process.env.PORT || 3000
server.listen(PORT)
```

모든 요청에 대해서 json stringify로 리스트에 푸쉬한다고 가정해보자. `ml_Var`는 글로벌 변수 이기 때문에 서버가 종료될 때 까지 메모리에서 계속 존재할 수 있다. 이는 굉장히 위험한 지점이다.

특히 다른 개발자들이, 내가 볼 수 없는 지점에서 아이템을 추가할 수 있기 때문에, 이러한 객체는 애플리케이션에서 문제를 야기할 수 있다.

```bash
node --inspect index.js
```

```bash
Debugger listening on ws://127.0.0.1:9229/16ee16bb-f142-4836-b9cf-859799ce8ced
For help, see: https://nodejs.org/en/docs/inspector
```

이제 크롬에서 `chrome://inspect` 명령어로 살펴보면 아래와 같은 화면이 나온다.

![chrome-inspection](./images/chrome-inspection.png)

`remote target` 섹션에 `inspect`링크가 있다. 이를 클릭하면, nodejs 애플리케이션의 세션을 볼 수 있는 화면이 뜬다. 로그, 소스, CPU 프로파일링 및 메모리 분석 등을 수행할 수 있다.

메모리 탭에서 `Take snapshot`을 크릭하면, 현재 실행중인 애플리케이션의 더미 스냅샷 프로필 (메모리 덤프)를 생성한다. 메모리 누수가 일어나기 전후의 메모리를 비교하는 것이 일단 목표다.

메모리 덤프를 가져오기에 앞서, 벤치 마킹을 돕기 위한 도구로 [siege.js](https://www.npmjs.com/package/siege)를 사용할 것이다. 이 라이브러리는 엔드포인트에 대해 수백 수천건의 요청을 실행하는 작업을 단순화 하는 node.js의 벤치마킹 도구다.

```javascript
const siege = require('siege')
siege().on(3000).for(2000).times.get('/').attack()
```

3000포트에 대해서 `/`요청을 2000번 날릴 것이다.

```bash
GET:/
GET:/
GET:/
GET:/
GET:/GET:/GET:/GET:/        done:2000        200 OK: 2000        rps: 2721        response: 1ms(min)      24ms(max)     5ms(avg)
```

DevTool로 돌아가서 `Take snap shot`버튼을 누르자.

![siege](./images/siege.png)

수 많은 string 들이 쌓인 것을 볼 수 있다. 실제 애플리케이션이었다면, 더 많은 양의 string 이 쌓여 있을 것이다. 따라서 이러한 메모리 누수를 조기에 발견하고 해결해야 할 것이다.

## 더 읽어보기

- [ibm의 javascript memory leak 보고서](https://www.ibm.com/developerworks/web/library/wa-memleak/wa-memleak-pdf.pdf)
- [Mozilla Performance](https://developer.mozilla.org/en-US/docs/Mozilla/Performance)


원래 이런건 이해가 될 때 까지 하는거임

자바스크립트의 가비지 컬렉션

100%의 테스트 리커버리가 도달한 이상적인 세계가 왔다. 오류 처리 또한 완벽했고, 모든 실패는 우아하게 처리되었다. 모든 시스템이 정말로 완벽에 도달했기 때문에, 이런 오류에서의 회복 같은 논의 따위는 필요가 없다.

그러나 나부터 시작해서, 2020년의 지구에는 아직 그런 이상적인 시스템이 있는 곳은 단언코 아무 곳도 없을 것이다. 누군가의 서버는 여전히 프로덕션에서 박살나고 있다.

이 글에서, 서버를 더욱 탄력적으로 만들고 프로세스 관리 능력을 향상시키는 몇가지 개념과 도구를 살펴보자.

## `node index.js`

Nodjs, 특히 서버 관련 작업을 처음 접하는 경우 원격 프로덕션이나, 개발 환경이든간에 동일한 방식으로 앱을 실행한다.

nodejs를 설치하고, repo를 clone하고, `npm install` 이후에 `node index.s`또는 `npm start` 로 시작한다.

이는 모든 프로젝트를 시작하는 완벽한 방법 처럼 보인다. 만약 이게 정말 제대로 작동만 한다면, 우리는 더이상 수정할 필요가 없다.

그러나 사전에 예상하지 못했던 발생할 수가 있다. vm또는 호스트가 재시작 된다면? 서버 크래쉬가 발생한다면?

복구(Recovery)는 다양한 방법으로 처리할 수 있다. 크래시 이후 서버를 다시 시작하는 편리한 솔루션도 있고, 프로덕션을 크래쉬로 부터 안전하게 만드는 것보다 더 우아한 방법들이 많다.

우리가 실행하려는 환경에 따라서, 복구는 다른 특성을 가지고 있다. 개발환경에서의 목표는 편의성이고 (코드를 수정하면 알아서 재시작 되는 것과같은), 프로덕션의 경우에는 오류로부터의 탄력성이라 볼 수 있다.

## 문제가 발생하자 마자 해결하기

개발 환경에서 nodejs 서버를 작성하고 있다고 상상해보자. 몇줄의 코드를 고칠 때마다 탭을 전환하여 `node index`나 `npm start`로 프로세스를 실행한다. 이는 몇번 반복하게 되면 끔찍할 정도로 지루해진다.

코드를 변경한 뒤에 자체적으로 그냥 재시작하면 좋지 않을까?

여기에서 도움이 되는 것이 바로 `nodemon`이다.

```bash
nodemon index.js
```

혹은 `Supervisor`를 동일한 방식으로 사용할 수도 있다.

```bash
supervisor index.js
```

두 서비스 보두 인기만큼이나 유용하다. 두 개의 차이점은, `nodemon`은 코드(파일)이 변경되면 재시작 되는 반면, `supervisor`는 에러가 발생할 때 다시 시작한다는 것이다.

개발 환경에서의 문제는 해결이 쉽다. 그러나 프로덕션 환경의 문제는 다르다. 프로덕션 서버에 내보내기 시작하면 대학을 보낸 부모마냥 안절부절해진다. 여기에서 사용하는 것이 프로세스 관리자다.

## 프로세스 관리

앱을 실행하게 되면, 프로세스가 생성된다.

개발환경에서는, 터미널 윈도우를 열고 코맨드를 실행한다. foreground proccess가 만들어 진것이며, 앱이 실행된다.

그러나 터미널 윈도우를 닫는다면, 앱 또한 종료된다. 또한 터미널 윈도우는 더이상 추가적인 작업을 할 수 없는 상태가 된다. `Ctrl+c`로 끄지 않는 이상, 터미널은 사용할 수 없게 된다.앱 실행이 터미널 윈도우와 강하게 연결되어 있기 때문에, 로그와 에러 또한 볼 수 있다. 그러나 프로덕션 서버에서는 앱을 백그라운드에서 실행해야 하기 때문에 이러한 장점을 잃게 된다.

이 때 등장하는 것이 프로세스 관리자다.

### PM2

nodejs에서 가장 널리 쓰이는 프로세스 관리자는 [PM2](https://github.com/Unitech/pm2)다. `PM2`를 설치하고 아래 명령어로 실행하면 된다.

```bash
pm2 start index.js
```

```bash
===============================================================================
--- PM2 development mode ------------------------------------------------------
Apps started         : src
Processes started    : 1
Watch and Restart    : Enabled
Ignored folder       : node_modules
===============================================================================
```

실행하게 되면, 무언가 다른점을 눈치챌 수 있을 것이다. 마치 아무것도 일어나지 않는 것처럼 보이지만, 앱의 엔드포인트로 가면 앱이 실행중인 것을 알 수 있다. `PM2`는 앞서 언급된 것처럼, 앱을 백그라운드에서 실행하게 해준다. 또한 `--watch` 명령어로 pm2가 파일을 감시하고 재시작하는 것을 볼 수도 있다.

```bash
pm2 start index.js --watch
```

그럼에도 여전히 가시성이 조금은 부족하다. 서버로그를 보기 위해서는, 아래와 같은 명령어를 쓰면 된다.

https://blog.appsignal.com/2020/09/09/nodejs-resiliency-concepts-recovery-and-self-healing.html

| command           | Description                                                                                                           |
| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
| `pm2 list`        | 앱의 목록을 보여준다. pm2에서 관리하고 있는 애플리케이션의 ID를 볼 수 있다. 이 아이디로 아래 명령어를 실행할 수 있다. |
| `pm2 logs <id>`   | 앱의 로그를 확인한다.                                                                                                 |
| `pm2 stop <id>`   | 프로세스를 중단한다. 단순히 중단만 되는 것이므로, 프로세스까지 제거하기 위해서는 `delete` 를 사용해야 한다.           |
| `pm2 delete <id>` | 프로세스를 지운다. 지우게 되면 `stop` 도 이루어진다.                                                                  |

`pm2` 는 설정하기 용이하며, 로드밸런싱도 수행할 수 있고, hot reload도 가능하다.

`pm2`는 놀랍도록 편리하지만, 몇가지더 살펴볼 것이 존재한다.

## Systemd

만약 Linux VM에서 앱을 실행하려고 계획중이라면, 컨테이너와 오케스트레이터 개념을 깊게 들어가기이전에 `systemd`를 언급할 필요가 있다. (그러나 Azure, AWS Lambda, GCP App Engine 등에서 실행하려고 준비중이라면 그다지 필요가 없다.)

`systemd`는 프로세스를 시작, 중지, 재시작을 할수가 있다. VM이 재시작 된다면, `systemd`는 앱이 다시 시작하게끔 도와준다.

`systemd`는 다음 시스템에서 사용가능하다.

- Ubuntu Xenial 또는 그 이상
- Centos 7 / RHGEL 7
- Debian Jessie 또는 그 이상
- Fedora 15 또는 그 이상

추가로 확인해야 할 것은 해당 유저가 `sudo`권한이 있어야 한다는 것이다.

이제부터 예제는 `Ubuntu`를 사용하고 있고, 홈 디렉토리는 `/home/user/`라고 가정하며,`index.js`는 이 홈 디렉토리에 있다고 가정한다.

### systemd 서비스 파일

`systemd` 파일은 서비스에 대한 설정을 보관할 수 있는 시스템영역을 만드는데 도움을 주는 파일이다. 먼저 한번 설정해보자.

`systemd` 파일은 아래 디렉토리에 존재한다.

```bash
/lib/systemd/system
```

```bash
cd /lib/systemd/system
```

```bash
sudo nano myapp.service
```

그리고 이 파일을 만들어보자.

```bash
# /lib/systemd/system/myapp.service

[Unit]
Description=My awesome server
Documentation=https://awesomeserver.com
After=network.target

[Service]
Environment=NODE_PORT=3000
Environment=NODE_ENV=production
Type=simple
User=user
ExecStart=/usr/bin/node /home/user/index.js
Restart=on-failure

[Install]
WantedBy=multi-user.target
```

몇가지 설정들은 꽤 분명하게 되어 있지만, `After` `Type`에 대해서만 알아보자.

`After=network.target`은 포트가 필요하기 때문에, 서버의 네트워킹이 가동되고 실행될 때 까지 기다려야 한다는 것을 의미한다. `Type`은 단순히 미친짓 하지말고 실행하라는 것을 의미한다.

### systemctl로 앱 실행하기

파일을 생성했으니, `systemd`에게 새롭게 변경된 파일을 이용하라고 알려줄 때다. 이 파일에 변화가 있으면, 아래 명령어를 계속 실행해야 한다.

```bash
sudo systemctl daemon-reload
```

이제 `systemctl` 명령을 사용하여 서비스를 시작하고 중지할 수 있어야 한다.

```bash
sudo systemctl start myapp
```

멈추고 싶다면 `stop`을, 재시작하고 싶다면 `restart`를 쓰면 된다.

이제 제일 중요한 부분이다. VM이 실행될 때 애플리케이션이 자동으로 시작되게 하고 싶다면, 아래 명령어를 입력하면 된다.

```bash
sudo systemctl enable myapp
```

작동중지는 `disable`을 쓰면 된다.

이게 전부다. 이제 Node.js가 아닌 프로세스를 관리를 하는 다른 시스템이 생겼다.

하지만 아마도 🤔 요즘 이렇게 리눅스 VM에 직접 서비스를 올려서 굴리는 시스템은 별로 없을 것이다......... 컨테이너로 넘어갈 차례다.

## 컨테이너란 무엇인가

Mesos, CoreOS, LXC, OpenVZ 등 다양한 컨테이너 런타임 환경이 존재하지만, 아마도 가장 유명한 것, 그리고 컨테이너의 진정한 동의어로 취급받는 것은 Docker다. 현재 컨테이너로 굴러가는 시스템의 80%가 Docker로 이루어져 있고, 사람들이 컨테이너를 이야기 하면 아마두 열에 아홉은 도커를 이야기 하고 있다고 봐도 무방하다.

컨테이너가 하는 일은 정확히 무엇인가? 컨테이넌 말그대로 컨테이너다. 그리고 이 컨테이너에는 무엇을 보관하고 있을까?

컨테이너에는 응용프로그램과 그에 필요한 모든 종속성이 포함되어 있다. 단순히 그것 뿐이다. 그렇다면 Nodejs 서버가 가지고 있어야 할 것이 있는지 생각해보자. Nodejs, index.js파일, 그리도 npm 패키지 종속성들이 필요할 것이다. 따라서 컨테이너를 만든다면, 이것이 존재하며 제대로 담겨있는지 확인하고 싶을 것이다. 그리고 컨테이너가 준비되어 있다면, 컨테이너를 컨테이너 엔진(도커)를 이용해 실행 시킬 수 있다.

### Container vs VM

Docker의 마법은 동일한 기반의 물리적 시스템과 운영체제를 사용하여 서로 충돌하지 않고, 다양한 형태의, 다양한 애플리케이션을 원활하게 실행할 수 있다는 것이다.

### 도커 컨테이너 만들기

도커 컨테이너를 만드는 것은 정말로 쉽다. 로컬 머신에 Docker를 먼저 설치하면 된다. Docker는 어떤 운영체제에서든 설치가 가능하지만, 프로덕션 머신에는 Linux 환경에서 설치하기를 권한다.

도커는 `Dockerfile`이라고 불리우는 파일을 참조하며, 도커 이미지라고 불리우는 컨테이너의 레시피를 만드는데 사용할 것이다. 따라서 컨테이너를 만들기 전에 이 파일을 생성해야 한다. `index.js`와 동일한 위치에 생성하면 된다.

```Dockerfile
# Dockerfile

# Base image (we need Node)
FROM node:12

# Work directory
WORKDIR /usr/myapp

# Install dependencies
COPY ./package*.json ./

RUN npm install

# Copy app source code
COPY ./ ./

# Set environment variables you need (if you need any)
ENV NODE_ENV='production'
ENV PORT=3000

# Expose the port 3000 on the container so we can access it
EXPOSE 3000

# Specify your start command, divided by commas
CMD [ "node", "index.js" ]
```

`.dockerignore`를 사용하면 `node_modules`와 같이 복사를 원치 않는 파일목록을 명시할 수 있다. `.gitignore`와 정확히 똑같이 동작한다.

```Dockerfile
# .dockerignore

node_modules
npm-debug.log
```

이제 설정이 완료되었고, Docker Image를 만들 차례다.

이미지는 컨테이너를 만드는 일종의 레시피다. 또는 소프트웨어를 인스톨을 하기 위한 플로피 디스크/씨디롬과 같은 존재로도 볼 수 있다. 이는 실제 작동하는 소프트웨어가 아니지만, 패키징된 소프트웨어 데이터를 포함하고 있다고 보면 된다.

```bash
docker build -t myapp .
```

이미지가 준비되어있다면, 이미지 목록에서 확인할 수 있다.

```bash
docker image ls
```

그리고 실행은 아래와 같이 하면 된다.

```bash
docker run -p 3000:3000 myapp
```

컨테이너에서 시작하는 서버를 볼 수 있고, 그 과정에서 로그도 확인할 수 있다. 백그라운드에서 실행시키기 위해서는 `-d` 플래그를 사용하면 된다. 또한 컨테이너를 백그라운드에서 실행중인 경우, 아래 명령어를 활용하여 컨테이너 목록을 확인할 수 있다.

```bash
docker container ls
```

이제 컨테이너에 대한 이해는 마쳤으므로, 원래 글의 주제인 복구와 매우 밀접한 오케스트레이션에 대해 알아보자.

## Orchestration

이상적으로 생각해봤을때, 레고블록과 같은 인프라는 개별적으로 관리하는 것은 굉장히 손이 많이 가기 때문에 어렵다. 앞서 이야기한 프로세스 관리자 처럼, 다른 존재가 이러한 관리를 대신 해주는 것이 좋을 것이다. 여기에서 오케스트레이터가 활약한다.

오케스트레이터는 컨에테이너를 관리하고 스케줄링 할 수 있도록 도와주며, 여러 위치에 분산되어 흩어져있는 VM (컨테이너 호스트)에 걸쳐서 이러한 작업을 할 수 있도록 해준다.

여기에서 우리가 특히 관심을 가져야 하는 것은 `Replication`이다.

### Replication과 높은 가용성

크래시가 발생했을 때 서버가 재기동하는 것은 좋은일이다. 그러나 재기동 중에는 어떤 일이 생기는가? 사용자들이 서비스가 다시 시작 되길 기다려야 하는가? 우리의 목표는 서비스를 고 가용성으로 만드는 것인데, 이는 사용자들이 서버에서 크래시가 있어도 앱을 사용할 수 있어야 함을 의미한다. 어떻게 하면 가능할까?

답은 간단하다. 서버의 복사본을 만들어두고, 동시에 실행하는 것이다.

처음에 이를 설정하는 것은 골치 아프지만, 다행히도 이 매커니즘을 가능하게 하는 모든 것을 가지고 있다. 일단 앱이 컨테이너화가 되어 있으면, 원하는 만큼의 복사본을 실행할 수 있는데 이를 Replica라고 한다.

이제 컨테이너 오케스트레이션 엔진을 활용하여, 어떻게 이를 설정할지를 알아보자. 여러가지 방법이 있지만, 도커 오케스트레이션 엔진과 가장 쉽게 할 수 있는 방법은 Docker Swarm이다.

### swarm 내의 replication

머신에 Docker가 설치 되어있다면, docker swarm은 비교적 간단하게 시작할 수 있다.

```bash
docker swarm init
```

이 명령어로 Docker swarm을 사용할 수 있으며, 다른 VM을 스웜에 연결하여 분산 클러스터를 구성하라 수 있다. 이번 예제에서는, 단순히 하나의 머신만 사용할 것이다.

스웜이 활성화 되어 있으면, 서비스라 불리우는 컴포넌트에 접근할 수 있게 된다. 이는 일종의 마이크로 서비스 아키텍쳐의 빵과 버터인데, replica를 만들기 쉽게 해준다.

이제 서비스를 만들어 보자.

```bash
docker service create --name myawesomeservice --replicas 3 myapp
```

위 명령어는 `myawesomeservice`라 불리우는 서비스를 만들어주며, `myapp`이라고 하는 이미지를 활용하여 3개의 동일한 컨테이너를 만들게 된다.

```bash
docker service ls
```

이제 서버가 복제되어 실행되며, 컨테이너가 크래쉬가 되도 재시작 되며, 프로세스 전체에 결쳐 온전한 컨테이너 엑세스를 제공할 수 있다. 서비스 replica의 수를 조정하기 위해서는 아래 명령어를 활용하면 된다.

```bash
docker service scale <name_of_service>=<number_of_replicas>
```

```bash
docker service scale myapp=5
```

이제 원하는 만큼 복제본을 만들어 실행시킬 수 있다.

### 쿠버네틱스에서의 replication

오케스트레이션을 논하는데 쿠버네틱스를 빼먹으면 섭섭하다. 컨테이너하면 도커 듯이, 오케스트레이션하면 쿠버네틱스다.

개인적인 의견으로는, 도커의 스웜보다 쿠버네틱스가 더 학습하기 어렵다. 따라서 이제 막 컨테이너를 시작했다면, 도커 스웜을 먼저 해보는 것이 좋다. 그렇긴하더라도, 쿠버네틱스 세계가 어떻게 작동하는지 이해하는 것도 나쁘지 않다.

- https://minikube.sigs.k8s.io/docs/start/
- https://labs.play-with-k8s.com/

이 예제에서는 두개의 yaml파일을 만들어 설정을 진행한다. 하나는 A 클러스터 IP 인데, 이는 앱과 통신할 수 있는 포트를 연다. 또다른 하나는 도커 스웜과 같은 서비스이다.

`cluster-ip.yml`

```yaml
# cluster-ip.yml

apiVersion: v1
kind: Service
metadata:
  name: cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: server
  ports:
    - port: 3000
      targetPort: 3000
```

`development.yml`

```yaml
# deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: server-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: server
  template:
    metadata:
      labels:
        component: server
    spec:
      containers:
        - name: server
          image: your_docker_user/your_image
          ports:
            - containerPort: 3000
```

`your_docker_user/your_image`를 실제 도커 유저와 이미지로 교체하고, 도커 레포에 해당 이미지가 호스팅 되고 있는지 확인해야 한다.

이제 아래 명령어를 실행해보자.

```bash
kubectl apply -f .
```

이제 서비스가 실행되고 있는지, 아래 명령어로 확인해볼 수 있다.

```bash
kubectl get deployments
kubectl get services
```

모든 것이 정상적으로 되고 있다면, `cluster-ip-service`에서 보여주는 IP와 포트를 복사하여 브라우저에 붙여넣기 한다면, 애플리케이션에 접속할 수 있을 것이다.

생성된 복제본을 보고 싶다면, 아래 명령어를 활용하면 된다.

```bash
kubectl get pods
```

나열된 pod는 `deployment.yaml`에 지정한 replica의 수와 일치해야 한다. 모든 컴포넌트를 정리하기 위해서는, 아래 명령어를 사용하면 된다.

```bash
kubectl delete -f .
```

## 결론

이제 우리는 고 가용성의 복구 가능한 애플리케이션을 가지고 있다. 물론, 이게 다가 아니다.

실제로 애플리케이션이 고장이 나지 않는데, 어떤 문제가 있는지 어떻게 알까?

로그를 확인해야할까? 만약 엔드포인트를 확인할 때마다 앱이 작동한다면, 아마도 일년에 한두번 정도만 로그를 볼 것이다. 따라서 앱이 개선되고 있는지 확인하기 위해서는 모니터링, 오류처리 및 오류 전파에 대해서 생각해볼 필요가 있다. 문제가 발생할 때마다 인지하고, 서버를 다운시키지 않더라도 문제를 해결할 수 있도록 해봐야 한다.

출처: https://blog.appsignal.com/2020/09/09/nodejs-resiliency-concepts-recovery-and-self-healing.html


아 내 서비스는 완벽해서 그런거 필요 없다니까요?

yceffort

nodejs

Nodejs에서 로깅하기

그런데 왜 brotli를 사용하지 않는 것일까? 🤔

개발자가 알아야 하는 4가지 nodejs 디자인 패턴

자바스크립트의 가비지 컬렉션

Nodejs 서비스 Recovery 전략