You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

RestAPI는 단순하고 작성하기 쉽습니다.

하지만 미들웨어 고성능통신 또는 미들웨어 분산 마이크로 서비스 구축시

RestAPI 로만은 분명 성능적한계,구현적 한계가 있습니다.

우리의 목표는 다양한 메시지 모델처리를 위해 n개의 서비스를 뛰우는것이 아닌

1개의 서비스로으로도 가능하고 , 필요하면 확장하는 전략을 선택할것입니다.

그것을 위해 앞으로 활용이될 메시지 전송모델 몇개를 간략하게 소개합니다.


RestFul

 일반적으로 웹서비스에 많이 사용하는 Rest방식입니다. 어떠한 웹브라우져또는 외부 고객에게

Rest-API를 통해 서비스를 제공하는것은 가장 무난하고 일반적입니다.  

하지만 실시간통신및, 내부서비스의 상태를 고성능으로 처리하기위해서는 REST는 성능적으로 한계가 있습니다.

HTTP 프로토콜을 사용하는 REST는 일반적으로 매 요청마다 새로운 커넥션을 요구하고 끊어버리기 때문에

단순하게 초당 천개의 메시지를 전송하는 시나리오에서, 다수의 커넥션을 맺는데 모든 리소스를 다 사용할것입니다.


Rest vs Websocket 수행시간

 

Rest의 수행속도가 메시지가 증가함에 따라, 기울기가 급격해지는 성능저하를

볼수가 있습니다. 이것은 Rest의 수행속도에 한계가 있음을 의미합니다.

일반적으로 API호출당 중앙DB SP를 꼭 한번 호출해야하는 경우이고

커넥션 비용보다 SP호출 비용이 더 크다고하면 이 부분은 프로토콜 변경문제로

해결할수가 없으며 추후 설명하게될 영속성있는 액터를통해 부분 해결가능합니다. 

단순하게 노드당 초당 1000개의 메시지를 처리해야되는 어떠한 내부기능이

필요하다고 했을때, Rest는 적당하지 않다는 의미입니다.


Server/Client VS PeerToPeer

Client/Sever방식은 Client가 중앙관리를 해주는 서버에 항상 연결을 유지하여 중앙 서버의 통제를받습니다.

대부부분의  요청 트래픽은 중앙 서버에 집중이됩니다.

PeerToPeer방식은 각 노드의 요소들이 서로연결하여 필요한 데이터를 룰에의해 주고 받습니다.

분산처리가 되지만, 중앙서버 방식보다 구현방법이 더 복잡해집니다. AKKA가 기본으로 채택한

메시지 처리 모델이며 AKKA의 목표는 이 사용을 단순화하는데 있습니다.

PUB/SUB

In this rails tutorial, publish-subscribe design pattern is laid out in this diagram.

아주 직관적이고 간단한 메시지전송 모델이기떄문에 여러 통신가능한 라이브러리 혹은 툴킷에서 많이 도입되었습니다.

대표적으로 고성능 Read기능을 수행하려는  메모리 DB인 Redis에도 채택된 모델이며

브라우져 지원 Websocket 라이브러리인 Socket.io / Atmosphere / SignalR 에서도 기본으로 지원하는 메시지 전송모델입니다.

간단하게 설명하면 메시지 공급자는, 채널만을 분류하여 메시지를 발송합니다. 

메시지를 받으려고 하는측에서, 특정 채널에 가입을 하면 메시지공급자의 메시지를 공급받을수 있습니다.


PUB/SUB 모델은 심플하기때문에, 직접 구현도 가능합니다.

아래는 TopicEventBus 라는 객체를 자바모델 참고하여 실제로 작성하고 사용해본 샘플입니다. (이개념을 쉽게 설명하기위해 직접 개발)



다양한 언어의 시청자가 존재하는 다국어 방송 메시지 모듈

//Create Act Act System for Testing
ActorSystem system = TopicEventBus.inItSystem("TestTopic"); //ActorSystem Init
 
//Create user
TopicEventBus.CreateActor("A");
TopicEventBus.CreateActor("B");
TopicEventBus.CreateActor("C");
 
//A user wants to receive News A in English
TopicEventBus.Subscribe("A", "newsA", "en").Wait();
 
//User B wants to receive news A in Korean
TopicEventBus.Subscribe("B", "newsA", "kr").Wait();
 
//Users of c want to receive News B in English
TopicEventBus.Subscribe("C", "newsB", "en").Wait();
 
 
//Server real-time messages (server sprays news regardless of user)
TopicEventBus.Publish("newsA", "Hi...here news A", "en");
TopicEventBus.Publish("newsA", "여기에 새로운 뉴스가 있습니다.", "kr");
TopicEventBus.Publish("newsB", "Hi...here news B", "en");

Result:
create actor name:A
create actor name:B
create actor name:C
Subscribe actor name:A to newsA
Subscribe actor name:B to newsA
A FirstSet LangCode en from newsA
B FirstSet LangCode kr from newsA
Subscribe actor name:C to newsB
C FirstSet LangCode en from newsB
Publish Topic:newsA msg:Hi...here news A
Publish Topic:newsA msg:여기에 새로운 뉴스가 있습니다.
A가 뉴스를 받음 Hi...here news A from newsA
Publish Topic:newsB msg:Hi...here news B
C가 뉴스를 받음 Hi...here news B from newsB
B가 뉴스를 받음 여기에 새로운 뉴스가 있습니다. from newsA


저장소위치

http://git.webnori.com/projects/AKKA/repos/topiceventbus/browse


메시지 처리및 전송 최종목표

우리의 응답이 좋은 메시지의 목표는 출발한 메시지 type상관없이 ( rest / websocket ) 출발하여

미들웨어에서 가장 효율적인 처리를 위해 어떠한 라우터및 클러스터 방식을 선택할것이며 ( client to server ,peertopeer , pubsub)

중앙 Db의 호출을 최소화 하여 응답을 할것입니다.




  • No labels