Page History

분산처리 이해하기

단일지점 병목

Image Removed

여기서, 메시지가 집결하는 데이터센터(이하DC)는 특정한 메시지 큐일수도 있고,단일지점 API이거나 DB일수있습니다. ( DB에대한 파티션닝은 논외)

위와같은 구성에서 API를 확장한다고 해도 단일지점 병목지점이 생기기때문에 

분산처리를 하였다고 볼수 없습니다.  

비지니스 로직이 DC에 모두 존재하는데

그것에 의존이 있고, 별다른 기능을 가지고 있지 않은 API를 늘렸다고 분산처리를  했다고 볼수 없습니다. 

네트워크 관점에서 Rest는 아주 저성능 프로토콜이기때문에, 단순하게 Rest의 성능만 스케일아웃 했다라고 표현하는것이 맞아보입니다.

만약 DC의 성능은 충분하고, 각 노드의 API들의 연산이 훨씬 많다고 가정하면 분산처리라 할수 있습니다.

...

DC 성능이 느린구조에서, 오토스케일을 거는 것은 문제가 있을수 있습니다. API가 늘어남에 따라 성능이 향상되는것이 아니고

병목현상으로 더 저하가 될수 있습니다. 이 구조에서는 측정을 통한 최적화된 한계값을 찾아 고정하는것이 더 효율적입니다.

오토스케일링이 무한개의 노드를 만드는 케이스

1. DC가 느려짐에 따라 API 요청리퀘스트가.각 노드에 쌓여 메모리에서 제거되지 않음
2. 각 노드는 메모리 부족 현상에 따라 지속적인 GC(가비지컬렉트)활동에 의해 CPU증가
3. 하는일 없이 CPU만 증가하고 결국 메모리 풀을 일으키며 노드 다운
4. 오토 스케일링은 정상 서버개수를 유지하려고 무한대의 서버 증식

분산처리 노드를 늘려 DC가 뻗는경우

1. 느려서 분산 노드를 늘림~
2. 빠르게 처리되는듯 보이나, DC의 부하 한계점 도달
3. DC가 뻗어 모두가 작동안되는 상황발생

파편화된 설정

Image Removed

분산처리를 위해 Type별로 복제되는 DC를 수동으로 구성하였다고 가정해봅시다.

위 구조를 통해 단일지점 병목 포인트를 나눴다고 하지만, 다음과 같은 문제가 여전히 남아있습니다.

• 균등의 문제 : 예측하지 못하는 기능을 Type(서비스 혹은 기능)별로 수동구성하였을시, DC1은 80%처리 DC2는 20% 처리 결국 특정 DC에 병목현상이 생겨 재조정해야합니다.
• 설정의 문제: API는 설정없이 자동으로 늘어날수 있으나, 실제 도메인 기능이 존재하는 DC~ 는 수동 확장을 해야 합니다.

위와같은 구조는 분산처리가 아닌, 파편화된 처리로 정의할수 있습니다.

클러스터 분산처리

클러스터 분산처리

클러스터 OverView

Gossip Protocol

...