Page History
...
| Info |
|---|
클러스터를 직접 설계하기에 앞서 분산처리에대한 의미 정리를 먼저 해보겠습니다. 클러스터 활용 개발자 수준단계
여기서의 목표는 D단계입니다. |
분산처리 이해하기
단일지점 병목
여기서 DC는 DB일수도 , 메시지가 집결하는 데이터센터(이하DC)는 특정한 메시지 큐일수도 있고,단일지점 API일수도 있습니다.API이거나 DB일수있습니다. ( DB에대한 파티션닝은 논외)
위와같은 구성에서 API를 확장한다고 해도 단일지점 병목지점이 생기기때문에
분산처리를 하였다고 볼수 없습니다.
개발자들이 격을수 있는 일반적인 오류이며, 비지니스 로직이 DC에 모두 존재하는데
그것에 의존이 있고, 별다른 기능을 가지고 있지 않은 API를 늘렸다고 분산처리를 했다고 볼수 없습니다.
네트워크 관점에서 Rest는 아주 저성능 프로토콜이기때문에, 단순하게 Rest의 성능만 스케일아웃 했다라고 표현하는것이 맞아보입니다.
AKKA가 사용하는 Netty프로토콜과 비교해도, Websocket Protocol역시 상대적으로 저성능 프로토콜이라고 정의할수 있습니다.
만약 DC의 성능은 충분하고, 각 노드의 API들의 연산이 훨씬 많다고 가정하면 분산처리라 할수 있습니다.
DC 성능이 느린구조에서, 오토스케일을 거는 것은 문제가 있을수 있습니다또한 위와같은 구조에서 오토스케일을 거는 것은 아주 위험합니다. API가 늘어남에 따라 성능이 향상되는것이 아닌,
병목현상으로 더 저하가 될수 있습니다. 이 구조에서는 측정을 통한 최적화된 한계값을 찾는것에 더 의미가 있으며다음과같은 시나리오로 이 구조에대한 오토 스케일링은 최악의 시나리오 빠질수 있습니다찾아 고정하는것이 더 효율적입니다.
오토스케일링이 무한개의 서버를 노드를 만드는 케이스
- DC가 느려짐에 따라 API 요청리퀘스트가.각 노드에 쌓여 메모리에서 제거되지 않음
- 각 노드는 메모리 부족한 부족 현상에 따라 지속적인 GC(가비지컬렉트)활동에 의해 CPU증가 - +GC최적화
- 하는일없이 하는일 없이 CPU만 증가하고 결국 메모리 풀을 일으키며 노드 다운 - +요청제한
- 오토 스케일링은 정상 서버개수를 유지하려고 무한대의 서버 증식 - https://docs.microsoft.com/ko-kr/dotnet/standard/garbage-collection/performance
...
- 균등의 문제 : 예측하지 못하는 기능을 Type(서비스 혹은 기능)별로 수동구성하였을시, DC1은 80%처리 DC2는 20% 처리 결국 특정 DC에 병목현상이 생겨 재조정해야합니다.
- 설정의 문제: API는 자동으로 설정없이 자동으로 늘어날수 있으나, 실제 도메인 기능이 존재하는 DC~ 는 수동 확장을 해야 합니다.
...