Versions Compared

Old Version 44

changes.mady.by.user PSMON

Saved on

compared with

New Version Current

changes.mady.by.user PSMON

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

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

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

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

 AKKA에서는 다양한 라우팅 전략을  디플로이 환경설정 전략으로 최소의 코드변경만으로 적용가능합니다.

또한 이러한 전략을 적용하기 위해 운영중 장비를 Down없이  다이나믹하게 스케일아웃할수있는 

클러스터로 개념으로 확장 가능합니다. AKKA의 라우팅전략은 코드설계가아닌, 설정화로 이루어내니 

지원가능한 대표적인 라우팅을 설명합니다. ( 라이브러리 내에서는 지속적으로 새로운 라우팅 모델이 업데이트중에 있습니다.)

Info

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

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

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

  • AKKA가 아니여도 이러한 라우팅 분산처리는 IT에서 이미 활용하고 있는 컨셉입니다.

RoundRobin

...


Round Robin Router

Info

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

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



Broadcast

...


Broadcast Router


Info

어떠한 정보의 변경을 모든 노드가 알아야할시, 주로 전체 동기화및 전체 푸시용도

ConsistentHashing

...


ConsistentHash Router

Info

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

ex>

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


ScatterGatherFirstCompleted

...


ScatterGatherFirstCompleted Router

Info

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

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


SmallestMailbox

...


SmallestMailbox Router

Info

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

덜바쁜 노드에게 우선으로 일을 주는방식덜바쁜 노드우선으로 메시지를 보내고자 할때, 대용량 메시지 전송 보증이 필요할때


TailChopping

...


Info

기본적으로 랜덤 라우터이나, 최적 응답시간내에 반응못하면(5s)

마지막까지 처리는

...

다음 누군가 접근시 제외되지 않은 녀석중에서 또 랜덤 선택

일반적으로 모두 안정적이나 , 가끔 불특정 노드가 느려지는 상황을 고려하여

안정적인 응답속도 보장을 위한 라우터 전략 , 모두가 느려지는 상황이 자주 발생하면 이전략 사용 못함

Akka와 Stream으로 연동가능 한 몇가지 플랫폼

Image Removed

 같은팀원이 소개해줘서 알게되었으며, RabiitMQ가  중간에는 Queue 를 적용시키고 양 끝단에는 적절한 Route전략을 사용하여

대용량 전송 메시지가 분산처리되어 최대한 메시지 전송 보장을 지원하는 플래폼인듯

이와같은 메시지 큐 서비스는, MS Azure 에서 원클릭으로도 서비스 생성이 가능합니다.

e-좋은 세상입니다. RabbitMQ도 아마존 클라우드에서 원클릭 생성이 가능한듯 보입니다.

Image Removed

Image Removed

고성능 스트리밍 서비스

기존에 안정적인 메시지 서비스가 있다고 하면, 굳이 교체할 필요없이

기존 서비스와 Actor-Stream을 통해 연동전략도 가능합니다. Akka의 Actor는 위와같은 서비스를

직접 개발하여 구축하는데 목표가 있는 프레임워크(툴킷)이지만 자연스럽게 연동도 가능합니다. 

하지만~ 특정노드를 잠시쉬게 하는 전략 
> GC를 제대로 할 시간을 주지 못할때 해당 노드는 GC를 계속 시도하느라 CPU를 점유해서 뻗을수 있습니다. 이때 빈도가 특정노드중 일부이며 잠쉬 쉬면 정상화가 될수도 있다란 측정이 가능 했을때 활용가능합니다.

추가정보


Info

https://github.com/reactive-streams

여러 업체및 진영( Java/C#/SCALA/JS등 )에서 네트워크상의 비동기처리를 비롯하여 이와 관련한 문제에대해

공통적으로 고민하기 시작하였으며, 표준 인터페이스를 만드는 reactive-streams 활동으로 이어집니다.

akka를 비롯하여 위에서 언급한 stream처리가 필요한 플래폼들은 이 활동에 영향을 주거나/받았으며,

이러한 인터페이스에 대한 표준을 따르고 있습니다.

이것은 어떠한 구현체가 아니라, 구현을 위한 약속된 스펙입니다.

서로 다른 스트리밍구현이 상호운영이될수 있도록하는것이 이 프로젝트의 기대치입니다.

...