Node.js 에서 멀티코어를 활용하자 - 실무에서 쓰자 개념

배경

전 글을 보고 온다. https://sejin-technology.tistory.com/129

Node.js 에서 멀티코어를 활용하자 - 개념

 

일단 단일 서버는 왜문제가 없냐면

[ Client ]
↓
[ OS Kernel ]
↓
[ Master ]
↓
[ Worker 1 / 2 / 3 ]

이와같이 구조를 잡기때문에 OS가 자연스럽게 Load balancer의 역할을 수행해서 문제가 없다.

 

근데 멀티서버가 되면 이게 깨지는데

      ┌─ Server A (Cluster)

[ Client ] ├─ Server B (Cluster)
└─ Server C (Cluster)

1. Cluster는 다른서버를 모른다. 즉 다른 서버에 있는 워커들을 모르게 된다.
2. 상태는 서버를 통해 관리되는데, 세션이나 Soket 연결, 인메모리 캐시같은걸 쓰면 문제가 발생한다.
3. 연결기반 서비스의 치명적이게 된다.

    서버에 소캣이나, 외부 API에서 폴링 처리를 한다거나 크론같은 스케줄러가 돌고 있다면 누가 뭘했는지 알 수 가 없어진다.

   그래서 Sticky Session이나 레디스의 이런 관리를 추가하거나, PQ 브러커를 달아야하는데 이거 만들고 관리하는건 조상님이 해주는게 아니라서 공수가 추가되고 관리가 복잡해진다.

그래서 다음과 같이 이를 우회하는걸 만들 수 있다.

1. 실무에서는 단일서버는 없다

SI에서 고정된 서버에서 작동하는 서비스거나, 특수한 목적에 서버라면 수직적확장이나 아니면 걍 트래픽을 줄여라 라고 할 수 있겠지만,

실제 서비스에서는 많이 들어오면 그걸 보장하는게 당연하다. 우리서버는 하나니까 100명만 들어올 수 있습니다는 자신만의 도메인이 특별한 경우에나 가능하다.

 

예를들어 특정 수량이 정해진 티켓팅 시스템 같은게 있는데 뭐 요구사항으로 200명 들어와야 되는데요 하면
서버가 작아서 안됩니다 도 말이 안되는 소리긴 한다.

 

즉, 서버는 플렉시블하게 확장이 가능해야하는데, 이거에서는 보통 2가지를 쓸 수 있다.
수직적 확장과 수평적 확장이라고 하는데,

수직적확장은 서버사양을 높이는 거다.

예를들어 AWS 같은 클라우드환경이라면 서버 아키텍처를 변경하거나 추가용량을 붙이거나 하는거고,
온프레미스면 다른서버 가져다가 쓴다는 소리다.

 

수평적확장은 여러개의 서버를 만들어서 부하분산을 하는 방식을 말하고,
어지간한 서비스는 이게 기본적으로 요구된다.

 

생각을 해보면 수직적확장이라고 하는것은 결국 서버가 내려가고 다른 서버가 올라와서 이를 대체하는건데
여기서 물론 배포전략을 통해 안정적으로 할 수 는 있겠지만, 당연히 시간이 오래걸린다.

 

반면에 수평적확장은 사용량 보고 TPS가 1000인데 지금 700 쯤됬으니까 하나 늘리고,
다시줄어들면 다시 내려서 관리하고 이렇게 쓸 수 있다.

양쪽 다 주요하게 사용할 수 있는 방식인다.

 

어쨋든 실무에서는 LoadBalancer가 앞에 달려있고 하위에 여러개의 노드들 (서버들) 이 붙어 있게 되는건
당연한거다.

서버리스도 알면 좋다

만약 아모르겠고 이거하기싫고, 관리할 리소스가 없다라고 한다면,
GCP의 CloudRun이나 AWS Lamda 같은 펑션기반의 서버리스 형태의 아키텍처를 잡는것도 매우좋은 방법이다.
어쩌면 대부분의 작은 회사들은 이 방식을 쓰는게 더욱 유리할 수 밖에 없고, 이를 FaaS 라고 부른다.

 

일단 쓸만큼 돈나간다는 장점이 있는데
얘를들어 100 불 서버 두개를 써야 핫트래픽까지 버틸 수 있는 서비스를 운영하고 있다고 치자
근데 대부분의 시간은 매우 적은 트래픽이고, 특정시간이나 이벤트에 따라 늘어난다고 하자

 

클라우드 서비스를 안쓴다? -> 이걸 대응하기 위해 100불서버 두개를 구매하고 안쓰는 자원은 그냥 버린다.
클라우드 서비스를 쓴다 > 50불 서버를 뒀다가 필요할때 하나 더 늘린다.

 

이렇게 하는건데 그러면 그 트래픽에 따라 엔지니어들의 피로도가 엄청나게 높아질꺼다

뭐 새벽에 트래픽 늘어나면 그거 보고 있느라고 정신 없고, 이게 정말 문제 없이 버텨지는지 보는것도 확인해야하고 , 그리고 서버가 정말 많기 때문에 관리자 입장에서는 볼게 너무 많아진다. (경험담이다 ㅠㅠ)

 

근데 서버리스를 쓰면 이걸 대형 IT의 축적된 엄청난 노하우로 운영되는 안정된 환경에서
내가 발생된 트래픽만큼 돈을 내고 쓰기 때문에 유리한것이다.

 

하지만, 당연히 장점만 있는건 아니고 콜드타임이나 유지연결형 서비스 불가.
다른 서비스의 의존된 기능이 있어서 해당응답이 늦게돌아와 이를 유지시키지 못해 의도하지 않는
특수한 에러 발생가능성 등의 문제가 존재한다.

 

물론 IT에서는 대기업들도 장애나는 경우가 많기 때문에 내가 조치할 수 없다는 단점도 존재한다.

그래서 어떻게 극복하는가

일단 기술적으로 stateLess한 기술을 적용하는것이 좋다.

예를들어 로그인을 만든다면 세션을 쓰기 보다는 토큰기반의 인증 방식을 사용한다던가

외부 연동을 통해 값을 주기적으로 혹은, 특정 동작에 따라 훅들을 통해 들어온다면
DB를 통해 데이터로써 관리하고 이를 트랜잭션 보호 아래에서 관리하는 방식을 사용할 수 있는데

만약 상황에따라 세션기반의 로그인이 필요하다.

그렇다면 당연히 세션서버를 따로 때내서 Redis 같은 인메모리 캐시를 도입해서 거기서 세션정보를
관리할 수 있게 만든다던가. (꼭 캐시DB가 아니여도 된다.)

 

아니면 Stick Session을 기반한 Session Clustering 을 하는 것도 좋은 방법인데
늘 생각하는건 모든 개발적 사고에 정답은 없으니 상황따라 내가 유리하다고 생각하는것을
논리적으로 쓰면 된다.

 

참고할만한 좋은 포스트 추천 : https://woo0doo.tistory.com/26

스티키 세션(Sticky Session), 세션 클러스터링(Session Clustering)이란? + 세션, 로드 밸런싱, Session Storage

 

실무에서 쓸만하게 간단히 정리해자

계층	담당
Node.js Cluster	서버 내부 CPU 활용
Load Balancer	서버 간 트래픽 분산
Redis / DB	상태 공유
K8s / ASG	서버 수 조절

 

이렇게 구성해서 쓰는게 매우 일반적이며, 도메인에 따라 상황에따라 여기에 노하우를 넣어서
새로운 동작흐름을 만들어주는것이다.