[O'REILLY] Node & Express - 12장 : 실무 환경 - 2

1. 예외처리

- 노드는 비동기적이므로, 항상 예외처리에 신경을 써줘야 한다.

- express는 라우트 핸들러를 실행할 때 try/catch 블록으로 감싸므로 실제로는 잡히지 않는 예외란 없다.

- 모든 라우트에 오류 핸들러를 추가해서 '보기 좋은' 오류 페이지를 만들어줄 뿐이다.

Error 객체를 만들어서 던지면 에러핸들러에서 받는다.

에러핸들러 미들웨어. 인자가 4개여야하고, 던진 에러를 받아서 처리한다.

- 항상 에러페이지를 만들어두어야 대응을 잘 할 수 있다.

- 더 심각한 상황을 가정해보자.

아주 큰일난 상황

- 이렇게 하면 서버 전체가 다운된다. 사용자에게 에러메시지를 보내고 자시고 없고 서버가 다운되면서 어떠한 처리도 불가능하게 된다.

- 이 문제는 setTimeout이 비동기적으로 실행되기 때문이다. 함수 실행은 노드가 유휴상태가 될 때 까지 지연된다.

- 노드에서 앱의 안정성을 파악하지 못한다면, 예상하지 못한 예외처리가 불가능하여 아주 큰일인 퇴사상황에까지 놓이게 될 수 있다는 것.

- 만약 이런 일이 이미 터져버렸다면, 서버를 다운시키고 복구해야한다. 복구는 클러스터를 활용하는 것이 가장 쉬운 메커니즘이다.

- 클러스터모드로 동작한다면, 워커 하나가 다운될 때 마스터에서 다른 워커를 작동해 그 자리를 대신한다.

- 노드에서 서버를 간지나게 다운시키는 방법

우아하게 서버 다운

- 잡히지 않는 예외를 가볍게 생각하지 말고, 다양한 툴을 이용해서 이유를 파악하고 기록하여 개선해나갈 수 있도록 한다.

- 센트리, 롤바, 에어브레이크, 뉴 렐릭 등의 서비스가 있다.

 

2. 여러 서버로 확장

- 클러스터를 통한 수평적 확장으로 개별 서버의 성능을 최대한 끌어낼 수 있지만, 물리적 서버를 늘리려면 '프록시서버'가 필요하다.

- 리버스프록시라고 라고 부르기도 하지만, 그거나 그거나이다.

- NGINX 혹은 HA프록시를 주로 사용한다. 

- 프록시서버를 사용할 때는 프록시를 사용 중이며 신뢰할 수 있다고 익스프레스에 알려줘야 한다.

app.enable('trust proxy')

- 이로케

 

3. 웹사이트 모니터링

- 모니터링은 매우매우 중요하다.

- 고객에게 신뢰를 주려면 장애가 발생하기 전에 파악하고 있어야 한다.

- 서드파티 모니터

  1) 업타임로봇 : 모니터 50개까지는 무료이고 설정도 단순하다. 이메일/문자/트위터/슬랙을 통해 경고를 보낸다.

    페이지에서 보내는 코드를 모니터하거나(200 외는 다 오류) 페이지에 특정 키워드가 존재하는지 여부 확인도 가능하다.

  2) 핑덤이나 site24x7도 있다.

 

4. 스트레스 테스트

- 동시에 수백, 수천 개의 요청이 드어와도 서버가 감당할 수 있는지 테스트

- 아주 두꺼운 책도 할애할 수 있는 주제다.

- 임의로 복잡하게 만들 수도 있고, 이용자 수가 많을 것이라면 시간을 더 투자해서 꼼꼼히 처리해야 한다.

- 아틸러리로 간단한 스트레스 테스트 만들기

npm i -g artillery

- 설치하고 나서 package.json 파일의 scripts 섹션에 다음을 추가해야 한다.

"scripts" : {
	"stress" : "artillery quick --count 10 -n 20 http://localhost:3000/"
}

- 10명의 가상 사용자(--count 10)가 각 서버에 20개의 요청(-n 20)을 보내는 상황을 시뮬레이션 한다.

- 앱을 실행한 다음에 npm run stress 로 테스트를 실행하면 결과가 나온다.

- 결과를 chatGPT에 넣으면 자세히 분석해준다 개꿀

- 앱이 신속하게 동작한다고 느끼려면 총 연결 시간이 50밀리초 미만이 되어야 한다.

- 이 시간은 서버에서 클라이언트 데이터전달까지의 시간이며, 렌더링시간은 들어있지 않음을 유의해야 한다.

 

항상 예상하는 것이 많을 수록 결과는 더 좋아진다.