클러스터를 직접 설계하기에 앞서 분산처리에대한 의미 정리를 먼저 해보겠습니다.
클러스터 활용 개발자 수준단계
- A : 분산처리 클라우드 기능을 사용하지만 클러스터가 무엇인지 관심없음
- B : 클러스터를 컨셉을 이해하고,클라우드 객체를 이용할수있음
- C : 클러스터 컨셉을 이용하고, 오픈진영 클러스트 노드를 직접 구성할수 있음
- D : 클러스터를 이해하고 직접 설계하여 개발에 반영할수 있음
여기서의 목표는 D단계입니다.
분산처리 이해하기
단일지점 병목
여기서 DC는 DB일수도 있고, 단일지점 API일수도 있습니다.
위와같은 구성에서 API를 확장한다고 해도 단일지점 병목지점이 생기기때문에
분산처리를 하였다고 볼수 없습니다.
개발자들이 격을수 있는 일반적인 오류이며, 비지니스 로직이 DC에 모두 존재하는데
그것에 의존이 있고, 별다른 기능을 가지고 있지 않은 API를 늘렸다고 분산처리를 했다고 볼수 없습니다.
네트워크 관점에서 Rest는 아주 저성능 프로토콜이기때문에, 단순하게 Rest의 성능만 스케일아웃 했다라고 표현하는것이 맞아보입니다.
또한 위와같은 구조에서 오토스케일을 거는 것은 아주 위험합니다. API가 늘어남에 따라 성능이 향상되는것이 아닌, 병목현상으로 더 저하가 될수 있습니다.
이 구조에서는 측정을 통한 최적화된 한계값을 찾는것에 더 의미가 있으며
다음과같은 시나리오로 이 구조에대한 오토 스케일링은 최악의 시나리오 빠질수 있습니다.
오토스케일링이 무한개의 서버를 만드는 케이스
- DC가 느려짐에 따라 API 요청리퀘스트가.각 노드에 쌓여 메모리에서 제거되지 않음
- 각 노드는 메모리 부족한 현상에 따라 지속적인 GC(가비지컬렉트)활동에 의해 CPU증가
- 하는일없이 CPU만 증가하고 결국 메모리 풀을 일으키며 노드 다운
- 오토 스케일링은 정상 서버개수를 유지하려고 무한대의 서버 증식 - https://docs.microsoft.com/ko-kr/dotnet/standard/garbage-collection/performance
파편화된 설정
분산처리를 위해 복제되는 DC를 수동으로 구성하였다고 가정해봅시다.
위 구조를 통해 단일지점 병목 포인트를 나눴다고 하지만, 다음과 같은 문제가 여전히 남아있습니다.
- 균등의 문제 : 예측하지 못하는 기능을 서비스별 수동으로 나누었을시, DC1은 80%처리 DC2는 20% 처리 결국 DC1에 병목현상이 발생할수 있습니다.
- 설정의 문제: API는 자동으로 늘어날수 있으나, 실제 도메인 기능이 존재하는 DC~ 는 수동 확장을 하여야합니다.
위와같은 구조는 분산처리가 아닌, 파편화된 처리로 정의할수 있습니다.
클러스터 분산처리
액터 클러스터는 단일지점이 없는, Peer To Peer 고성능 통신방식을 사용합니다. (Netty Protocol)
각노드는 특정 노드를 Seed노드(Discovery를위한) 로 지정할수 있으며
도메인 로직이 없는 Discovery 기능을 분리하여 등대(LightHouse)기능을 부여할수 있습니다. - 아파치에서는 주키퍼(동물관리자)라고 불리는 녀석과 동일한 역활을 수행
여러오픈진영에서 사용하는 클러스터의 작동방법은 동일하다고 보면 되겠습니다.
클러스터 OverView
Gossip Protocol
단일지점 병목을 없애기위해 피어투 프로토콜을 이용하며, 각노드는 빠르게 특정대상(정확히는 구성된 라우터)에게 이야기할수 있으며
설정없이 서로의 존재를 알기위해 잡답(Gossip) 방식을 사용합니다.
- 최초 Node1을 뛰운다.
- A1 : Node1은 인스턴스를 뛰우고 난후, LightHouse(이하 등대)에게 자신의 존재를 알린다.
- Node2를 뛰운다
- A2 : 노드2는 인스턴스를 뛰우고 난후, 등대에게 자신의 존재를 알린다.
- A1 : 등대는 Node1에게 Node2의 존재를 알린다.
- B1 : Node1은 Node2에게 인사를 하여 서로 연결을 맺어둔다.
- A2 : 연결이 완료되었음을 등대에게 알린다.
- Node3를 뛰운다.
- 동일과정 : A3 → (A1,A2) → (B3,B2) → A3
- Node1이 탈퇴(Down)한다.
- A1 : Node1이 등대에게 탈퇴를 알린다. ( 비정상 종료시에는 등대가 Node1이 사라짐을 파악후 제거진행)
- A3,A2 : 등대가 Node1의 탈퇴 사실을 알린다.
- B3,B1 : Node1과의 연결을 제거한다.
위 작동방법이 복잡하고 트래픽을 증가시키는것처럼 보이지만, 신규 Node가 가입하거나 탈퇴할때에만 발생합니다.
동일한 설정으로 노드를 유연하게 확장할때 유연하며 다음과 같은 리얼 세계와 연관을 시키면 이해가 쉽습니다.
- 새로운 담당자가 회의실에 참여하여, 모든 직원과 명함을 주고 받는다. (여기서 회의실은 등대역활)
- 담당 영역을 서로 확인했기때문에, 이후에는 중간 관리자(병목지점) 없이 빠른 실무처리
- 처리된 중간 결과를 중간 관리자가 알게 하기위해서는 싱글톤 클러스터 이용가능 ( 추후 설명)
기존 설계된 로컬 액터에 클러스터 룰 셋팅만하고, 라우팅 전략역시 설정만으로 분산처리를 설계할수 있습니다.
라운드 로빈만이 유일한 라우팅으로 알고 있다고 하면, AKKA에서는 다음과 같은 라우팅을 클러스터에서 사용할수 있습니다.
분산 처리의 세계에서는 구현된 로직의 단순화를 위해 다양한 라우팅을 사용할수 있습니다.
Links :