Page History

성능관련 스케일 아웃은 라우팅 전략과 관련이 있고

운영중 장비를 Down없이 스케일 늘리고 줄일수 있는 탄력적 전략은 클러스터링과 연관이 있다고 볼수 잇습니다.

기술적으로 AKKA내에서 클러스터는 목표는 병목 현상이 없는 탄력적인 분산형 피어 투 피어 네트워크라고 정의 내릴수 있습니다.

단순하게 들어온 메시지 순서대로, 순차적으로 대상 노드를 바꿔가며 전송시 사용

ex>단순한 RestAPI의 성능향상및 특정 노드 장애 대응에대한 장애에 대응하는 다중화구성 ( 기본적으로 Pool에 등록된 Node Crash발생시 어떠한 라우터라도 해당 노드와 통신시도를 하지 않음해당노드는 해당풀에서 자동제거됨)

특정 처리에 대해 해시값기반 베이스로 노드의 변경의 가능성을 최소화할때

ex>

• 웹소켓 (핸드쉐이크 성공이후, 노드변경시 웹소켓으로 작동안됨)기능 보장기능 보장 ( 핸드쉐이크과정에서 노드변경이되면 오동작)
• 자체캐쉬 작동 보장(성능을 위해 노드 자체에 서버 캐시처리를 하였지만, 노드변경시 서버캐시 적용못받음)
• 최초 설계에의한 제한적 분산(기능적으로 생성한 오브젝트가 예상되는 특정 노드에 있어야하는 경우등)
• SSL등 SSL및 서비스 로그인 세션유지 ( 노드변경시 재인증을 받아야하는 성능이슈 )
• X에 해당하는 고객(또는 몰)의 외부적인 요소에의해 API 호출제약이 n이라고 가정하면 단순하게 분산처리가 되어버리면 TPS제어를 할수 없습니다. 클러스터내에 하우터가 조장되면 분산이 재조정되기 때문에 특정 컨디션의 데이터를 특정노드에 실행이 보장되면 단일노드 환경에서 원격캐싱이아닌 수백배 빠른 로컬캐시를 활용할수도 있으며 호출 제약또한 리모트가 아닌 인메모리 기능으로 심플하게 구현할수 있습니다.
  • Redis에대한 오해 : Redis가 Key/Value여서 RDB를 사용하는것보다 빠른 캐시개념으로 접근할수 있지만... 원격 접근이라는 네트워크 전달 비용이 있습니다. 인 메모리전략은 수백배/수천배 빠를수 있습니다. 로컬캐싱을 이용할수 있습니다.

성능을 위해 다중노드로 구성하였으며, 가장 빠르게 처리한 녀석의 결과를 사용할시

ex> 1개의 빠른인스턴스 검색시 인덱스된 데이터가 불규적으로 분산되거나 중복이있을시 , 가장 빠른 결과물을 사용할시 ( 검색엔진)

한가한 노드우선으로 메시지를 보내고자 할때

동일한 작업을 수행해도 완료시간을 동일하게 보장할수 없음으로

덜바쁜 노드에게 우선으로 일을 주는방식