[SignalR 2.0] SignalR 서버의 스케일 아웃을 위한 Redis Backplane

 

들어가며

단일 서버로 구성을 하게 된다면, 여러뭐로 고민할 내용이 줄어들지만 현실은 그렇지 않죠.
다양한 failover 상황을 고려해야 하고, 부하분산 상황에 대한 상황도 같이 고려해야 합니다. 
SignalR을 이용하여 채팅서버를 구성할 때에도 위와같은 상황을 고려해서 설계를 진행해야 하는데요. 
IIS 환경에서 웹서버는 스케일 아웃, 그리고 그 안에서 메시지를 전달하는 부분은 Redis 의 Pub/Sub을 이용한 BackPlane 을 이용해서 설계를 진행했었습니다. 

 

아래 SignalR 채팅 시스템을 개발했을때, 고려했던 내용을 정리하였습니다. 

 

 

 

웹서버 스케일 아웃

SignalR은 웹서버로 IIS를 사용하는데요. 일반적으로 웹서버의 경우 성능을 확장하기 위한 방식으로 스케일 업, 스케일 아웃 방식중에 선택을 하게 됩니다. 

• 스케일 업의 경우는, 장비의 사양을 올린다고 생각하시면 되고,
• 스케일 아웃의 경우는, 동일한 장비를 여러대로 구성해서 분산처리 한다고 생각하시면 됩니다. 

저희는 Load Balancer를 이용해서 스케일 아웃을 하는 방식으로 웹서버의 확장을 고려하여 설계하였습니다.

 

출처 : MSDN

 

그렇다면, 각각의 웹서버들은 서로다른 서버에 붙은 클라이언트에게 어떻게 전달받은 메시지를 전달할까요?

그것은 백플레인 (BackPlane) 을 이용해서 메시지를 주고 받을 수 있습니다. 

 

 

 

백플레인

Load Balancer를 이용해서 웹서버를 확장할 경우, 각각의 서버에 Message를 보내야 하는 방식이 필요한데요.

이를 백플레인 (BakcPlane) 이라고 부릅니다. 

 

SignalR 에서는 3가지의 백플레인 (BackPlane) 을 제공하며, Azure Cloud를 이용해서 SignalR을 서비스 할 경우에는 Azure Service Bus를 이용하는 것이 효율적이라고 MSDN에서 얘기하고 있습니다. 

• Azure Service Bus.
• Redis. 
• SQL Server. SQL Server 

 

제한 사항

MSDN에서는 몇가지 제한 사항에서도 명시가 되어 있는데요. 백플레인을 사용하면 클라이언트가 단일 서버 노드와 직접 통신할 때보다 최대 메시지 처리량이 낮다고 합니다. 백플레인은 모든 메시지를 모든 노드에 전달하므로 백플레인은 병목 상태가 될 수 있기 때문입니다. 

 

• 서버 브로드캐스트 (예: 주식 시세): 백플레인은 이 시나리오에서 잘 작동합니다. 서버는 메시지가 전송되는 속도를 제어하기 때문입니다.
• 클라이언트 간 (예: 채팅): 이 시나리오에서는 메시지 수가 클라이언트 수로 확장될 경우 백플레인에 병목 현상이 발생할 수 있습니다. 즉, 더 많은 클라이언트가 조인할 때 메시지 비율이 비례적으로 증가하는 경우입니다.
• 빈도가 높은 실시간 (예: 실시간 게임): 이 시나리오에서는 백플레인을 사용하지 않는 것이 좋습니다.

 

 

 

메시징 처리를 위한 Redis BackPlane

SignalR에서 모든 메시지는 메시지 버스를 통해 전송됩니다. 메시지 버스는 Pub/Sub 구독 추상화 기능을 제공하는 IMessageBus 인터페이스를 구현합니다. 

저희는 Redis를 이용하여 RedisMessageBus인 Pub/Sub 매커니즘을 사용하는 방식으로 백플레인 (BackPlane)을 구성하였습니다. 

 

출처 : MSDN

 

 

Pub/Sub

Redis는 메시지를 보내기 위한 방식으로 게시/구독 패턴을 지원합니다.

저희는 이 기능을 이용해서 백플레인 (BackPlane) 을 구성하기로 하였습니다.

 

 

Sticky Session

SignalR 웹서버를 Load Balancer를 이용해서 스케일 아웃 할 경우, 일반적인 Round Robin 방식으로 하면 접속이 되지 않습니다. 

SignalR의 경우, 두가지 패턴, 즉 협상이후 접속을 하는 방식을 사용하게 되는데, 최초 커넥션 아이디를 가져오는 협상 단계에서의 웹서버와 커넥셕이 맺어지는 웹서버가 다를 경우 연결이 되지 않습니다.

 

이를 해결하기 위해서는 Load Balancer의 Sticky Session 방식으로 설정을 해야 하는데요.

이는 협상 및 연결이 단일 서버에서 유지하게 해주는 역활을 하게 됩니다. 

 

 

 

 

 

 

 

 

 

END

---