무지성에서 시작하는 K8s 공부해보기 시리즈(2)

K8s 공부 (2)

https://www.youtube.com/watch?v=X48VuDVv0do

## Table of Contents

## 1. K8s는 무엇인가?

### K8s

- 오픈소스 컨테이너 오케스트레이션 도구
- 구글에서 개발
- 컨테이너화된 애플리케이션을 관리하기 쉽게 도와주는 역할
  - 수백~수천개의 다른 환경에 있는 컨테이너에 있는 애플리케이션을 관리하게 쉽게 해준다.

### K8s 는 무엇을 해결하려 하는가?

- 모노리스에서 마이크로 서비스로 트렌드가 넘어가고 있음
  - 그에 따라서 컨테이너가 많아지고 있음
  - 이렇게 다른 환경에 있는 다른 컨테이너들을 쉽게 관리하고자 함

### 오케스트레이션 도구?

- 고가용성으로, 다운타임이 없다
- 확장성이 뛰어나고, 고성능을 제공할 수 있다.
- 장애로부터 복구가 빠르게 이뤄질 수 있다. (백업, 복구)

## 2. K8s 주요 컴포넌트

먼저 아주 간단한 예로, 애플리케이션과 데이터베이스만 있는 서비스를 상상해보자.

### Node

- 여러개의 pod를 묶는 하나의 단위
- 한대의 서버라고 보면됨

### Pod

- K8s에서 가장 작은 단위
- 컨테이너를 추상화 한 것
  - 추상화 한 이유는, 대체 하기 쉽고, docker등 다른 컨테이너 기술을 사용하게 할 수 있게 하기 위함
  - 따라서 직접 다루는게 아니라, K8s의 레이어에서 다룬다고 볼 수 있음
- pod안에는 일반적으로 하나의 애플리케이션 컨테이너만 실행하도록 함.
  - 물론 여러개를 다루는 것도 가능.

위 예제에서는, 하나의 서버에서 두개의 컨테이너가 두개의 pod로 실행되고 있다고 보면 된다.

### Service

- K8s는 내부적으로 가상 네트워크를 활용하며, 각 pod는 고유 ip를 가진다. (컨테이너가 아님)
- 각 pod는 이 내부 ip로 통신 가능
- 그러나 pod는 쉽게 죽고, 쉽게 대체가 가능하며, pod가 죽어버리면 새로운 pod가 생성되는데, 이 때 새로운 ip를 할당받아버리므로 ip를 기준으로 통신하는 것은 비효율적임
- 영구적인 IP 주소를 pod에 주는 도구
- pod의 라이프사이클과 서비스가 공유되는 것은 아니므로, pod가 죽어도 서비스의 ips는 유지됨.
- internal과 external로 나눌 수 있으며, internal은 내부에서만 사용 가능
- external을 사용하면 외부와 통신이 가능하나, IP주소와 PORT가 있는 형태라 외부로 공개하기엔 부적절함

### Ingress

- 서비스를 외부 주소와 연결하는 도구
- 우리가 일반적으로 알고 있는 URL로 external service를 연결해준다.

### ConfigMap

pod가 서비스를 통해서 서로 통신한다는 것을 알게 되었다. 만약 애플리케이션에서 DB의 주소가 필요하다고 하면 어떻게할까? 일반적으로는 환경변수 등을 통해서 DB의 주소 등을 주입할 것이다. (빌드 시) 만약 서비스의 명이나 주소가 바뀌면, 빌드를 새로 해서 다시 해야하는 번거로움이 존재한다.

- 애플리케이션에서 사용하는 외부 변수등을 쓸 수 있게 하는 도구
- pod와 연결하여, ConfigMap에 있는 데이터를 pod에서 가져다가 쓸 수 있음.

### Secret

- 민감한 정보 (암호 등)의 경우에는 ConfigMap을 사용하지 않음
- 보안상 중요한 데이터를 plain text가 아닌 base64로 저장해서 ConfigMap과 같이 동일하게 사용할 수 있는 도구

`ConfigMap`과 `Secret`은 pod에서 환경변수나 속성파일 (yaml, json 등)으로 접근해서 가져다가 쓸 수 있다.

### Volumes

- 데이터베이스의 데이터 같은 경우에는, pod안에 해당 데이터가 있다면 pod가 죽어버리면 그 데이터도 날라가게 된다.
- 영구적인 데이터를 저장하기 위해 쓰는 것이 Volume
- 마치 물리적인 하드디스크를 pod에 붙이는 것이라 볼 수 있음
  - local, remote, cloud등 어떤 형태로든 가능
- Pod가 재시작되도, 데이터는 별도의 위치에 존재하기 때문에 영구성을 유지할 수 있음
- 따라서 이러한 데이터는 K8s 외부에서 잘 관리해야됨.

### Deployment

- 일반적인 경우에는, 사용자가 외부에서 애플리케이션을 접근할 수 없게 된다. 그러므로 하나의 pod만 관리하는 것은 위험
- 따라서 K8s에서는 모든 것을 복제(Replicate)한다.
- Node를 여러개로 복제한다음, 하나의 서비스에 다 연결 시킨다.
- 서비스는 영구적인 IP를 가지고 있고, 내부적으로 로드밸런서도 가지고 있음. 따라서 하나의 pod가 죽거나 바쁘다면, 다른 pod로 알아서 넘겨준다
- 이런식으로 pod를 여러개 복제하기 위해서는 pod의 `blueprint`를 정의해야 한다. 이 `blueprint`에는 얼마나 많은 pod들을 가질 지 정의할 수 있음
- 이러한 나의 애플리케이션 내부의 pod의 `blueprint`를 정의한 것이 Deployment다.
- 일반적으로 K8s에서는, 직접 pod를 만들지 않는다. deployment를 만들고, 그것이 blueprint에 따라서 알아서 pod를 만든다.
- 여러 pod를 추상화 한것으로 보면 된다.

### StatefulSet

- 그러나 데이터베이스는 상태, 즉 데이터가 있기 때문에 deployment로 복제할 수 없음.
  - 만약 여러개로 데이터베이스 pod를 복제한다면, 이들이 같은 volume에 접근하려 할 것이다. 이렇게 되면 터의 불일치가 발생하게 된다.
- 그렇기 때문에 이런 상태가 필요한 pod 들은, Deployment가 아니라 StatefulSet으로 만들어져야 한다.
- 마찬가지로 복제하거나, 스케일링을 할 수 있으며, 데이터 베이스들간에 불일치가 발생하지 않도록 도와주는 역할을 한다
- 이건 deployment에 비해 다루기 어려워서, K8s 외부에서 일반적으로 관리한다

### 요약

- Pod: 컨테이너들을 추상화 한것
- Service: Pod간 통신에 사용
- Ingress: 외부 트래픽을 K8s내부 클러스터로 유입시키기 위한 것
- ConfigMap: 외부 설정
- Secrets: 외부 설정 (보안상 민감한 데이터)
- Volumes: 영구적인 데이터 관리
- Deployment: pod등을 정의하는 것
- Statefulset: 영구적인 데이터를 위한 Deployment

## 3. K8s의 아키텍쳐

일반적으로 master와 slave 노드로 구성되어 작동된다.

- 각 노드들은 여러개의 pod를 실행하고 있다.
- 워커 노드란 일반적인 작업을 하고 있는 노드를 의미한다.
- 노드에는 세가지 프로세스가 필수적으로 필요하다.
  - Container Runtime: 도커 등
  - kublet: pod와 컨테이너의 스케쥴을 관리하는 도구. 컨테이너 런타임과 노드의 머신간에 상호작용을 담당. 실제로 pod를 실행하는 역할을 담당하고 있음. 노드에서 CPU 등의 자원을 할당하는 역할을 하고 있다.
  - kube proxy: 서비스로들어온 요청을 pod에 전달하는 역할. 네트워크의 오버헤드를 줄이기 위해서, 하나의 요청이 들어왔을 때 동일한 pod의 동일한 db로 가게하는 등의 역할도 하고 있음

이러한 프로세스를 관리하는 것이 마스터 노드에서 이루어진다.

### Master Process

여기에는 4개의 process가 필요하다.

- Api server: Cluster gateway, 인증 게이트 키퍼. UI 대쉬보드나, kublet 같은 ci 도구로 노드를 제어할 수 있게 하는 역할. 새로운 pod를 만들거나, 서비스, 컴포넌트를 만들고 싶다면 마스터 서버의 api server를 거치게 된다. api server는 이러한 요청을 검증하고 (인증, 요청의 정합성 등) 이를 다른 프로세스에 전달하여 실행하게 하는 역할을 한다.
- Scheduler: api server로 요청을 보낸다면, 스케쥴러가 이를 받아서 애플리케이션 pod나 컴포넌트를 시작하게 하는 역할을 하고 있음. pod가 어느 노드에 둬야 하는지를 알아서 현명하게 결정함. 노드의 가용성등을 보면서 알아서 결정함. 스케쥴러는 단순히 어느 노드에 pod를 둬야 하는지만 결정함. 그리고 이를 실제로 실행하는 것은 kublet.
- Controller Manager: 클러스터의 상태변화 (pod가 죽는 경우 등)를 감지하여, 이를 가능한 빨리 복구하도록 스케쥴러에게 명령하는 역할을 하고 있음.
- etcd: key-value store. 클러스터의 모든 변화를 기록하는 역할. 클러스터에 필요한 모든 정보가 담겨 있음. (애플리케이션 관련 정보는 없음) 이 정보는 매우 중요하므로, 여러개의 master 노드를 가지고 있음.

### 일반적인 세팅

- 2개의 마스터 노드 (리소스를 적게 할당)
- 3개의 worker node (실제 애플리케이션을 담당하므로 많은 자원을 할당)
- 이들 모두 필요에 따라 증가 시킬 수 있으며, 필요한 프로세스만 설치하면 됨.

![example](./images/example-cluster-setup.png)


무지성에서 시작하는 K8s 공부해보기 시리즈(1)

K8s 공부 (1)

자바스크립트에서 배열을 순회하는 방법은 4가지가 있다.

- `for`
- `for-in`
- `forEach`
- `for-of`

각각의 방법을 살펴보면서, 배열을 순회하기 위한 가장 좋은 방법은 무엇인지 나름 결론을 내려본다.

## for

ES1 시절부터 있었던 가장 근-본적인 방법이다.

```javascript
const arr = ['a', 'b', 'c']
arr.prop = 'prop'

for (let i = 0; i < arr.length; i++) {
  const e = arr[i]
  console.log(i, e)
}
// 0 "a"
// 1 "b"
// 2 "c"
```

- 배열의 첫번째 뿐만 아니라 n번째에서 돌 수도 있음
- 단순히 배열을 순회하려는 목적에 비해서 많은 작업이 필요함 (추가적인 변수 선언 및, 증가, 길이 계산 등)

## `for-in`

놀랍게도, `for-in`도 ES1부터 있었던 근-본 방식이다.

```javascript
const arr = ['a', 'b', 'c']
arr.prop = 'prop'

for (const key in arr) {
  console.log(key, typeof key, arr[key])
}

// 0 "string" a
// 1 "string" b
// 2 "string" c
// 3 "string" prop prop
```

위의 코드 실행결과에서 알 수 있듯이, `for-in`을 배열을 순회하는데 쓰는건 별로 좋지 못하다.

- `key` 값만 가져올 수 있음
- `key` 값의 타입에서 볼 수 있다시피, 숫자가 아니고 문자열로 나온다.

```javascript
const arr = [1, 2, 3]
arr[0] === arr['0'] // true
```

> 배열은 `[]` 에서 숫자로도 접근할 수 있기 때문에 객체와 다르다고 생각할 수 있다. 그러나 배열 또한 객체 이므로, `[]`안에 심볼 외의 값이 들어가면 강제로 string으로 변환한다.

- 위에서 볼 수 있는 것 처럼, 모든 enumerable한 키들을 죄다 순회한다.

따라서 `for-in`은 객체가 enumberable한 모든 속성을 순회할 때 사용하는 것이 좋다. 그러나 이 경우에도, 프로토타입 체인을 순회하는 것이 더 낫다.

## `forEach`

ES5에서 추가된 새로운 방법, `Array.prototype.forEach()`이다.

```javascript
const arr = ['a', 'b', 'c']
arr.prop = 'prop'

arr.forEach((e, index) => {
  console.log(e, index)
})

// a 0
// b 1
// c 2
```

꽤 편리한 방법처럼 보인다. 배열의 요소와 인덱스 모두에 접근할 수 있으며, 화살표 함수를 통해서 더욱더 우아하게 코드를 짤 수 있다.

그럼에도, 아래와 같은 단점이 있다.

- `await`을 루프 내부에 쓸 수 없음
- `forEach()` 중간에 루프를 탈출하는 것이 곤란. 다른 문법의 경우엔, `break`로 가능

```javascript
const arr = ['a', 'b', 'c']
arr.forEach((e, index) => {
  console.log(e)
  if (e === 'b') {
    // break Illegal break statement
    return
  }
})
// a
// b
// c
```

아래와 같이 [some](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/some)을 사용하면 탈출할 수 있다.

```javascript
const arr = ['a', 'b', 'c']
arr.some((e, index) => {
  if (e === 'b') {
    return true // break
  }

  console.log(e) // falsy한 값이기 때문에 계속 루프를 돈다.
})
```

그러나 이는 `some`을 의도대로 사용하는 것이 아니거니와, 왜 이런 코드를 짰는지 다른 사람들이 이해하기 어려울 것이다.

## `for-of`

ES6에 나온 가장 최신 기능이다.

```javascript
const arr = ['a', 'b', 'c']
arr.prop = 'prop'

for (const e of arr) {
  console.log(e)
}

// a
// b
// c
```

- 모든 루프를 원하는 대로 순회할 수 있다.
- `await`을 사용한 [for-await-of](https://exploringjs.com/impatient-js/ch_async-iteration.html#for-await-of)가 가능하다.
- `break` `continue`를 사용할 수 있다.

`for-of`를 활용하면, 키만 접근하거나, 혹은 키와 값 모두 접근하거나 하는 것이 모두 가능하다.

```javascript
const arr = ['a', 'b', 'c']
for (const key of arr.keys()) {
  console.log(key, typeof key)
}

// 0 "number"
// 1 "number"
// 2 "number"
```

```javascript
const arr = ['a', 'b', 'c']
for (const [key, value] of arr.entries()) {
  console.log(key, value)
}
// 0 "a"
// 1 "b"
// 2 "c"
```

```javascript
const m = new Map().set(1, 1).set(2, 2).set(3, 3)
for (const [key, value] of m) {
  console.log(key, value)
}

// 1 1
// 2 2
// 3 3
```

## 결론

- `for-of`로 다른 순회문에서 할 수 있는 모든 것을 할 수 있어서 가장 좋다.
- 성능에 대한 비교는 사실 의미가 없을 것 같다. (엄밀히 따지면 `forEach`가 제일 느리다.) 그러나 자바스크립트에서 성능이 유의미할 정도로 순회문을 돌아야 한다면, 웹 어셈블리 등 다른 방법을 알아보는 것이 좋다.
- 여담으로, 적어도 프론트엔드 개발에서 `for-of`를 돌아야 하는 일은 거의 없었던 것 같다. 대부분이 `map` `reduce`를 사용해서 해결할 수 있고, 그 쪽이 더 함수형이고 읽기도 간결하다.


for vs for-in vs forEach vs for-of 무엇으로 자바스크립트 리스트를 돌아야 하나

Nodejs에서 비동기 프로그래밍을 처음 접해보는 개발자들은, 종종 에러를 제대로 처리하는 방법에 대해서 혼돈을 느끼곤 한다. 비동기 처리의 경우 에러가 제대로 잡히지 않는 경우도 있다. 뭐 어쨌든, 애플리케이션에서 에러를 올바르게 처리했고, 그 에러를 성공적으로 발견했다고 가정하자. 그 다음에 중요한 것은, 방금 잡은 에러에 대해서 어떻게 해야하냐는 것이다. 그냥 로그만 남길까? 그 위로 에러를 한번 더 던져야 하나? 이 에러가 어디서 끝나야 하나? 그렇다면 어떻게? 만약 애플리케이션이 HTTP 요청을 하는 동안, 에러가 났고 이를 잡았다면, 해당 에러를 요청한 사람에게 보여줘야 하나?? 여기에는 수 많은 질문이 있을 수 있다.

먼저, 애플리케이션이 REST API를 다루고 있고, 네트워크를 통해 하나이상의 다른 서비스와 통신하는 nodejs 기반 마이크로 서비스라고 가정해보자. 그렇다면, 여기에서 우리가 다뤄야 하는 것은 무엇일까?

- 가능한 모든 에러의 결과물에 대해서 예측 가능해야 한다.
- 수동으로 개입ㅈㅇㄱ 하지 않아도 심각한 에러에서 스스로 복구 될 수 있어야 한다.
- HTTP 요청을 처리하는 동안 발생한 오류는, 클라이언트가 이를 기반으로 작업을 수행하는데 도움이 될 수 있는 최소한의 정보와 함께 클라이언트에 전달되어야 한다.
- 오류의 근본적인 원인을 쉽게 추적할 수 있고 디버깅하기도 쉬워야 한다.

## 1. 비동기 에러를 정확히 잡아야 한다

비동기 코드를 작성하는데 익숙하지 않다면, 비동기 상황에서 발생하는 에러를 처리하는 코드를 작성하기 어려울 수 있다. 일반적으로, 이를 처리하는 세가지 정도의 패턴이 있다.

- callback: [error-first callback](https://nodejs.org/api/errors.html#errors_error_first_callbacks) 접근법. 이 상황 에서는 `try-catch`가 별로 도움이 안된다.

```javascript
function myAsyncFunction(callback) {
  setTimeout(() => {
    callback(new Error('oops'))
  }, 1000)
}

myAsyncFunction((err) => {
  if (err) {
    // handle error
  } else {
    // happy path
  }
})
```

- promises와 promise callback을 사용하는 방법

```javascript
function myAsyncFunction() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      reject(new Error('oops'))
    }, 1000)
  })
}

myAsyncFunction()
  .then(() => {
    // happy path
  })
  .catch((err) => {
    // handle error
  })
```

- `async-await`와 resolve promise (혹은 ES6 generator & yield)

```javascript
function myAsyncFunction() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      reject(new Error('oops'))
    }, 1000)
  })
}

;(async () => {
  try {
    await myAsyncFunction()
    // happy path
  } catch (err) {
    // handle error
  }
})()
```

`await`을 사용하게 되면 조금 시나리오가 다르다. 다음 두 가지 예를 보자.

```javascript
// Example 1
try {
  return await myAsyncFunction()
} catch (err) {
  // await을 사용했기 때문에 여기서 함수에서 에러가 나면 잡히게 된다.
}

// Example 2
try {
  return myAsyncFunction()
} catch (err) {
  // promise가 resolve된게 아니고, 단순히 리턴이 되어버렸기 때문에 여기에 닿을 수가 없다.
}
```

따라서 비동기 함수에서 에러를 처리하려고 할 때는 조심해야 한다.

## 2. uncaught exception이나 unhandled rejections에 대해 적절하게 처리해야 한다.

진짜 열심히 코딩을 해서 대부분의 잠재적인 오류 시나리오를 쫀쫀하게 처리했다고 하더라고, 내가 예상했던 시나리오를 벗어나는 에러가 발생할 수 있다. 이러한 시나리오를 일괄적으로 파악해서 처리할 수 있다. 프로세스 객체에서 내보내는 두가지 이벤트 `uncaughtException`, `unhandledRejection`를 사용하면 가능하다. 그러나 이를 적절하게 활용하지 않는다면 예기치 못한 상황이 발생 될 수 있다.

`uncaughtException`, `unhandledRejection`는 애플리케이션이 지속할 수 없는 상황을 의미한다. 여기에 리스너를 달 때는, 아래 사항을 조심해야 한다.

- 에러에 대해 명확하게 로그를 남겨서 추후에 원인 파악을 할 수 있게 할 것 (로그 관리 시스템 또는 APM 서버에 전송)
- 애플리케이션을 강제로 종료하여, 프로세스 매니저나 도커 오케스트레이터가 이를 대체할 프로세스를 시작 할 수 있도록 한다.

위 두 상황에서 프로세스를 종료하지 않고 계속 애플리케이션을 실행한다면, 애플리케이션이 멈추거나 예기치못한 동작을 빚을 수 있다.

```javascript
process.on('uncaughtException', (err) => {
  logger.fatal('an uncaught exception detected', err)
  process.exit(-1)
})

process.on('unhandledRejection', (err) => {
  logger.fatal('an unhandled rejection detected', err)
  process.exit(-1)
})
```

## 3. 에러 마스킹

대부분의 개발자들이 저지르는 또하나의 실수중 하나는 오류를 마스킹 하여 콜스택 아래의 호출자가 오류가 발생했음을 인식하지 못하게 하는 것이다. 경우에 따라서 이렇게 해야하는 경우도 있지만, 무지성으로 이 작업을 수행해버리면 오류를 추적하고 진단하는 것이 불가능하게 되어 애플리케이션의 심각한 다운타임으로 이어진다.

```javascript
function processUsers() {
  try {
    const body = await client.get('http://example.com/users')
    const users = body.users || []
    // do something with users
  } catch (err) {
    // handle error
    // client.get에서 에러가 나든 users처리하다 에러가 나든 상관없다면 이렇게 해도된다.
    // 그러나 이렇게 여러 경우의 수를 묶어버리면 에러에 대한 문제를 정확히 찾기 어렵다.
  }
}
```

이러한 코드는 에러에 대한 로그처리를 다른 곳에서 진행했고, 현재 함수로 부터 더이상 에러가 올라가도 되지 않아도 된다는 자신감이 있을 떄만 해야 한다. (HTTP 요청 에러가 클라이언트로 가지 말아야 한다거나) 그렇지 않으면, 어떠한 유형의 오류가 발생했는지 정확히 확인하고, 아래 호출자에서 무엇이 잘못되었는지 정확히 알 수 있도록 에러를 던져야 한다.

## 4. 제네릭 에러를 정확한 에러로 변환해야 한다.

애플리케이션이 에러의 유형에 따라 다른 행동을 해야 하는 경우, 에러 객체를 특정 에러 객체로 변환하는 것이 중요하다.

```javascript
if (err instanceof AuthenticationError) {
  return res.status(401).send('not authenticated')
}

if (err instanceof UnauthorizedError) {
  return res.status(403).send('forbidden')
}

if (err instanceof InvalidInputError) {
  return res.status(400).send('bad request')
}

if (err instanceof DuplicateKeyError) {
  return res.status(409).send('conflict. entity already exists')
}

// Generic error
return res.status(500).send('internal error occurred')
```

자바스크립트의 `Error`는 매우 제네릭하다.따라서 에러를 명확히 하기 위해서는, `error.message` `error.code` `error.stack` 속성을 확인해봐야 한다. 그러나 이는 꽤 규모있는 애플리케이션을 처리하는 경우에는 불편할 수 있다. Nodejs에는 `TypeError` `SyntaxError` `RangeError`와 같은 [구체적인 에러](https://nodejs.org/dist/latest-v12.x/docs/api/errors.html#errors_class_assertionerror)들이 몇가지 있다. 그러나 모든 경우에 이들을 재사용할 수 있는 건 아니다.

이를 위해서는, 나만의 에러 유형을 정의하고 적시에 올바른 에러를 던져야 한다.

```javascript
class UserServiceError extends Error {
  constructor(...args) {
    super(...args)
    this.code = 'ERR_USER_SERVICE'
    this.name = 'UserServiceError'
    this.stack = `${this.message}\n${new Error().stack}`
  }
}

class InvalidInputError extends Error {
  constructor(...args) {
    super(...args)
    this.code = 'ERR_INVALID_INPUT'
    this.name = 'InvalidInputError'
    this.stack = `${this.message}\n${new Error().stack}`
  }
}

async function getUser(userId) {
  if (!userId) throw new InvalidInputError('userId is not provided')

  try {
    return getUserFromApi(userId)
  } catch (err) {
    throw new UserServiceError(err.message)
  }
}
```

이렇게 처리하면, 다른 개발자들에게 에러 코드 목록을 보여주거나, 에러가 발생할 때 마다 코드를 확인하여 처리할 필요가 없다.

## 5. 외부 서비스의 예기치 못한 상황에 대처하기

만약 외부 서비스를 사용해야 하는 경우가 있다면, 가능한 잘못될 수 있는 모든 시나리오에 대처할 필요가 있다.

```javascript
function processUsers() {
  try {
    const body = await client.get('http://example.com/users')
    const users = body.users || []
    // do something with users
  } catch (err) {
    // handle error
  }
}
```

위 예제에서, 사용자 목록을 불러오기 위해서는, api가 성공 응답(200)에서만 객체를 반환한다고 가정한다. 결과가 있다면 베열이 될 수도 있고, 없다면 null이 될 수도 있는 users 속성이 있다고 가정해보자.

만약 api 개발자들이 `body.users`가 외 다른 곳에서 결과가 오도록 객체의 응답구조를 변경한다면? 애플리케이션은 기본값 `[]`를 사용하여 계속 실행되며, 어떤일이 발생했는지 알 수 없게 된다.

항상 다른 서비스를 사용할 때는 엄격하게 대처할 필요가 있다. 비정상적인 방법으로 계속 서비스 하는 것보다, 애플리케이션이 빠르게 실패하는 것이 좋다. 이렇게 하면 잠재적으로 발생할 수 있는 문제를 빠르게 식별할 수 있고, 데이터 손상이나 불일치 등을 막을 수 있다.

## 6. 에러 별로 적절한 로그 레벨을 사용하기

적절한 로그 레벨을 선택하여 로그를 남기는 것은 중요하다. 모든 로그 라이브러리는 일반적으로 서로 다른 레벨의 로그를 기록할 수 있고, 각 수준의 로그를 다른 대상 (`stdout` `syslog` `file`) 으로 보낼 수 있다. 이 작업을 제대로 수행하기 위해서는, 메시지의 중요도에 따라 올바른 로그레벨을 선택해야 한다.

- `debug`: 심각하지 않는 메시지. 후에 디버그를 위해서 필요한 경우
- `info`: 성공(또는 실패하지 않는) 작업을 식별하는데 필요한 정보성 메시지
- `warn`: 즉각적인 액션이 필요하지 않은 경고성 메시지. 그러나 추후에 디버깅을 위해서 필요한 경우
- `error`: 즉각적인 액션이 필요한 모든 에러. 이 에러를 무시할 경우 심각한 시나리오로 이어지는 경우
- `fatal`: 서비스 중단 과 같은 중요 구성요소의 장애를 나타내는 모든 오류

위와 같은 규칙을 엄격히 준수한다면, 잘못된 경보가 울리지 않는 상태에서 중요하거나 필요한 문제를 즉시 식별할 수 있다.


SSR을 다루면서 에러처리에 대해 고민했던 나날들😑

Nodejs에서 올바르게 에러 처리하기

Nodejs는 2009년 만들어진 이래로 많은 사랑을 받고 있는데, 아마도 그 이유 중 하나는 자바스크립트로 작성할 수 있다는 사실 일 것이다. nodejs는 그 이름에서 느낄 수 있는 것처럼, 서버사이드 애플리케이션을 자바스크립트로 작성할 수 있도록 만들어졌다. 그렇다고 해서, nodejs가 100% 자바스크립트로 이루어져있는 것은 아니다.

자바스크립트는 싱글 스레드로, 언어가 처음 디자인 되었을 때는 서버사이드에서 실행되기에는 부적절하게 디자인 되어 있었다. 그러나 구글의 고성능 자바스크립트 엔진인 V8이 등장과, 비동기 I/O 를 수행하는 libuv의 탄생, 그리고 몇가지 기술들이 추가되면서 자바스크립트로 몇천개의 소켓 연결이 일어나는 서버를 구현할 수 있게 됐다.

![nodejs](https://miro.medium.com/max/3840/1*-0Sa0i_g-gcL9sJqvecKEw.png)

> 이미 몇번씩이나 본 nodejs의 구조

nodejs는 위 그림에서 볼 수 있는 것처럼 여러가지 컴포넌트로 구성된 대규모 플랫폼이다. 그러나 nodejs 내부 동작에 대한 이해가 부족하기 떄문에, 많은 개발자들이 잘못된 가정을 가지고 개발을 하며, 이로인해 추적하기 어려운 버그를 만들고 심각한 성능 문제로 이어지는 애플리케이션을 만들어 낸다. 여기서 몇가지 nodejs의 잘못된 이해에 대해 짚고 넘어가려고 한다.

## Table of Contents

## EventEmitter와 EventLoop간에 관계가 있다?

[Nodejs EventEmitter](https://nodejs.org/api/events.html)는 nodejs 애플리케이션을 만들다보면 많이 사용하게 되는 라이브러리다. 그러나 이름만 비슷할 뿐, EventEmitter와 EventLoop사이에는 아무런 관계가 없다.

Nodejs의 EventLoop는 Nodejs의 비동기, 논블로킹 I/O 메커니즘을 처리하는 핵심적인 부분이다. EventLoop는 다양한 유형의 비동기 이벤트를 특정 순서로 처리한다. EventLoop에 대한 글은 인터넷에 차고 넘치니.. 더이상 자세한 설명은 생략한다

- https://yceffort.kr/2019/09/06/javascript-event-loop
- https://yceffort.kr/2020/10/how-node-js-works
- https://blog.insiderattack.net/event-loop-and-the-big-picture-nodejs-event-loop-part-1-1cb67a182810

반면에 Nodejs의 EventEmitter는 특정 이벤트에 리스너 함수를 달아서, 이벤트가 발생 했을 때 이를 캐치할 수 있도록 만들어진 api다. 이 동작은 일반적으로 이벤트 리스너가 원래 등록된 이벤트 헨들러보다 나중에 호출되기 때문에 비동기처럼 보인다.

그러나 EventEmitter의 인스턴스는 EventEmitter 인스턴스 자체내에서 이벤트와 연결된 모든 이벤트와 리스너를 추적한다. 따라서 EventLoop의 큐를 사용하는 것이 아니다. 이 정보가 저장되는 데이터 구조는, 단순히 이벤트 이름이 있는 이벤트 객체일 뿐이다. 그리고 그 값은 이벤트 리스너 함수들이 들어가 있는 배열일 뿐이다.

> 대략 이런 느낌 https://yceffort.kr/2020/10/implement-event-emitter

![EventEmitter](https://miro.medium.com/max/2180/1*9dCC-WJOstRw8vL1v5C6cA.jpeg)

EventEmitter의 `emit`함수가 호출되면, emitter는 **동기적으로** 등록되어 있는 리스너 함수를 순차적으로 호출한다.

```javascript
const EventEmitter = require('events')

const myEmitter = new EventEmitter()

myEmitter.on('myevent', () => console.log('handler1: myevent was fired!'))
myEmitter.on('myevent', () => console.log('handler2: myevent was fired!'))
myEmitter.on('myevent', () => console.log('handler3: myevent was fired!'))

myEmitter.emit('myevent')
console.log('I am the last log line')
```

```
handler1: myevent was fired!
handler2: myevent was fired!
handler3: myevent was fired!
I am the last log line
```

EventEmitter가 동기적으로 모든 이벤트 핸들러를 호출하기 때문에, `I am the last log line`는 모든 리스너 함수가 실행되기 전까지 출력되지 않는다.

## 콜백을 받는 모든 함수는 비동기로 실행된다?

함수가 동기인지 비동기 인지는 함수가 실행중에 비동기 리소스를 생성하는지 여부에 따라 달려 있다. 따라서 아래에 주어진 함수를 사용하고 있다면, 함수가 비동기인지 여부를 판단할 수 있다.

- 자바스크립트/Nodejs의 네이티브 비동기 함수: `setTimeout` `setInterval` `setImmediate` `process.nextTick` ...
- nodejs만으이 네이티브 비동기 함수: `child_process` `fs` `net` ...
- `Promise` API (`async` `await`)
- [c++ addon](https://nodejs.org/docs/latest/api/n-api.html)으로 부터 호출되어 비동기로 작성된 함수 [becrypt](https://www.npmjs.com/package/bcrypt)

콜백함수를 argument로 받아도 함수가 비동기화 되는 것이 아니다. 그러나 일반적으로 비동기 함수는 콜백을 마지막 인수로 받는다. (Promise를 리턴하기 위해 랩핑되지 않는 한) 콜백을 받고, 그 결과를 콜백을 전달하는 패턴을 [Continuation Passing Style](https://en.wikipedia.org/wiki/Continuation-passing_style)이라고 한다. 이 스타일을 하면, 100% 동기함수를 작성할 수 있다.

```javascript
const sum = (a, b, callback) => {
  callback(a + b)
}

sum(1, 2, (result) => {
  console.log(result)
})
```

동기 함수와 비동기 함수는 실행 중에 스택을 사용하는 방법에 있어 큰 차이가 존재한다. 동기 함수는 스택이 반환될 떄 까지, 다른 사용자가 스택을 점유할 수 없도록 하여 전체 실행기간 동안 스택을 점유 한다. 그러나 비동기 함수는 일부 비동기 작업을 예약한 채로 즉시 반환되므로, 스택에서 제거된다. 예약된 비동기 작업이 완료되면 제공된 콜백이 호출되고, 이 콜백 함수가 다시 스택을 점유하게 된다. 이 시점에서 비동기 작업을 시작한 함수는 이미 리턴되어버렸으므로 스택에서 더이상 사용할 수가 없다.

그렇다면, 아래 함수는 동기일까 비동기 일까?

```javascript
function writeToMyFile(data, callback) {
  if (!data) {
    callback(new Error('No data!'))
  } else {
    fs.writeFile('myfile.txt', data, callback)
  }
}
```

정답은, `data`로 무슨 값이 오느냐에 따라 다르다. `data`가 `falsy` 한 값이라면 콜백은 즉시실행되어 에러를 뱉는다. 이 경우, 함수는 100% 동기로 작동되어 어떠한 비동기 작업도 수행하지 않는다.

반대로, `data`가 `truthy`한 값이라면, `data`가 `myfile.txt`에 쓰여지기 시작하고, I/O작업이 끝나게 되면 콜백이 실행된다. 이 경우 파일 I/O 작업이 수행되므로, 100% 비동기다.

함수를 이따위(?)로 일관적이지 못하게 작성하는 것(= 비동기일수도 동기일수도 있게)은 애플리케이션이 함수의 동작을 예측할 수 없기 때문에 매우 별로다.

```javascript
function writeToMyFile(data, callback) {
  if (!data) {
    process.nextTick(() => callback(new Error('No data!')))
  } else {
    fs.writeFile('myfile.txt', data, callback)
  }
}
```

`process.nextTick`는 콜백함수 호출을 지연시켜 비동기로 만드는데 사용할 수 있다. 물론, `setImmediate`를 사용할 수도 있다. [그러나 `process.nextTick`이 `setImmediate`보다 더 높은 우선순위를 가지고 있어 빠르다.](https://stackoverflow.com/questions/15349733/setimmediate-vs-nexttick)

## CPU 집약적인 함수는 EventLoop를 블로킹한다.

많은 사람들이 CPU 집약적인 작업은 Node.js의 EventLoop를 블로킹한다고 믿고 있다. 이는 어느정도는 사실이지만, EventLoop를 차단하지 않는 일부 함수들이 있기 때문에 100% 사실이 아니다.

일반적으로, 암호화/압축 작업은 CPU를 많이 잡아 먹는다. 이러한 이유로, 특정 crypto 함수나 zlib함수는 비동기 버전이 있으며, 이 함수는 EventLoop를 차단하지 않도록 libuv 쓰레드 풀에서 계산을 수행한다. 그 함수들의 목록은 아래와 같다.

- `crypto.pbkdf2()`
- `crypto.randomFill()`
- `crypto.randomBytes()`
- `zlib`의 모든 비동기 함수

그러나 순수 자바스크립트를 사용하여 libuv 쓰레드 풀에서 CPU 집약적인 작업을 수행할 수 있는 방법은 없다. 그러나 libuv 스레드 풀에서 작업을 예약할 수 있는 C++ addon을 직접 작성할 수는 있다. CPU 집약적인 연산을 수행하고, CPU 바운더리 연산을 위한 비동기 API를 구현하기 위해 C++ addon을 사용하는 이와 같은 라이브러리에는 [brcypt](https://github.com/kelektiv/node.bcrypt.js)가 있다.

## 모든 비동기 작업은 쓰레드 풀에서 실행된다?

최신 운영체제들은 Event Notification(linux의 epoll, Macos의 kqueue, 윈도우의 IOCP)을 사용하여 네트워크 IO작업을 위한 네이티브 비동기화를 용이하게 지원하는 커널을 내장하고 있다. 따라서 네트워크 IO는 libuv쓰레드 풀에서 실행되지 않는다.

그러나 파일 IO는 운영체제 전반에 있어서, 경우에 따라는 운영체제 버전에 따라서 상이한 경우가 많다. 따라서 일반화된 플랫폼 독립 File IO api를 만드는 것이 매우어렵다. 따라서 파일 시스템 작업은 일관된 비동기 API를 만들기 위해서 libuv 스레드 풀에서 수행된다.

`dns` 모듈 내에 있는 `dns.lookup()` 함수도 마찬가지로 libuv스레드 풀에서 실행된다. 이 함수를 사용하여 도메인 이름을 IP 주소로부터 확인하는 것은 플랫폼 종속적인 작업이며, 이작업은 100% 네트워크 IO가 아니기 때문이다.

## NodeJS는 CPU 집약적인 작업을 하는 애플리케이션에서 사용하면 안된다?

정확히 말하면, 이는 과거까지는 사실이었지만 이제 [worker thread](https://www.google.com/search?q=worker_thread&oq=worker_thread&aqs=chrome..69i57j0i10i19i30j0i19i30l8.2621j1j1&sourceid=chrome&ie=UTF-8)가 도입되면서 가능해졌다. 따라서 CPU 집약적인 작업을 처리하는 프로덕션 애플리케이션에서 Node.js를 사용하기에 적합해졌다.

각 Nodejs의 워커 쓰레드는 자체 v8 런타임의 복사본, Event Loop, libuv 스레드풀을 가진다. 그러므로 CPU 집약적인 블로킹 작업을 하는 하나의 worker thread는 다른 worker thread에 영향을 주지 않게 된다.

https://yceffort.kr/2021/04/nodejs-multithreading-worker-threads

그러나 worker thread를 원활하게 지원하는 IDE는 현재 없는 것으로 보인다. 일부 IDE의 경우, 기본 main worker가 아닌 worker thread에 디버거를 연결하는 것을 지원하지 않는다. 그러나 현재 점차 많은 개발자들이 비디오 인코딩과 같은 CPU 집약적인 작업의 지원을 위해 worker thread 채택을 시작하기 때문에 점차 성숙할 것으로 보인다.


Nodejs도 CPU 집약적인 작업 잘 할 수 있습니다(?)

Page 2

K8s 공부 (2)

K8s 공부 (1)

for vs for-in vs forEach vs for-of 무엇으로 자바스크립트 리스트를 돌아야 하나

Nodejs에서 올바르게 에러 처리하기

Nodejs에 대한 잘못된 상식 몇가지