정리하며 배우다.

들어가며

처음으로 SignalR 을 이용해서 채팅 서버를 구현한 것이라, 이를 위해 성능을 검증해야 하는 상황이 생겼습니다.

어찌보면 당연한 프로세스 였는데요. 저희가 진행한 성능검증은, 1대의 IIS 서버에 어느정도의 Request를 감당할 수 있는지, 최대 동접인원을 기준으로 한대의 서버에 몇명의 유저를 감당할 수 있는지 등등 이였습니다.

진행하는 과정에서 SignalR의 성능 튜닝을 아래와 같이 진행하였습니다. 

※ SignalR 2.x 버전의 IIS 환경임을 참고해주세요.

IIS 구성 수정

SignalR의 성능 튜닝을 위해서는, 어플리케이션당 최대 동시 요청자 수를 늘립니다. 

IIS 관리자에서 SignalR로 설정되어 있는 사이트 선택시, 하단부에 구성편집기 메뉴를 선택하면, 아래와 같은 화면이 보여집니다. 

해당 메뉴에서 구성편집기의 system.webServer/serverRuntime 섹션의 appConcurrentRequestLimit 수를 기본값 5000 에서 20,000 으로 수정하였습니다.

ASP.NET Configuration 의 CPU당 최대 동시요청 수정

기본적으로  ASP.NET 4.0 의 최대 동시 연결 수는 CPU당 5000 으로 설정되어 있습니다. 더 많은 동시 연결이 필요할 경우 설정값을 늘려야 합니다. 

해당되는 키 이름은 maxConcurrentRequestPerCPU 이며, 

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Aspnet.config

파일을 수정하면 됩니다. 

참고로 각 설치 환경 (32비트, 64비트) 따라 폴더위치는 다릅니다.

Aspnet.config

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy enabled="false" />
        <legacyImpersonationPolicy enabled="true"/>
        <alwaysFlowImpersonationPolicy enabled="false"/>
        <SymbolReadingPolicy enabled="1" />
        <shadowCopyVerifyByTimestamp enabled="true"/>
    </runtime>
    <startup useLegacyV2RuntimeActivationPolicy="true" />
</configuration>


<!-- 위 내용을 아래와 같이 수정합니다. -->


<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy enabled="false" />
        <legacyImpersonationPolicy enabled="true"/>
        <alwaysFlowImpersonationPolicy enabled="false"/>
        <SymbolReadingPolicy enabled="1" />
        <shadowCopyVerifyByTimestamp enabled="true"/>
    </runtime>
    <startup useLegacyV2RuntimeActivationPolicy="true" />
    
    <!--추가내용-->
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
    
</configuration>

ASP.NET Configuration 의 요청 대기열 제한 수정

총 연결 량이 maxConcurrentRequestsPerCPU 설정을 초과하면, ASP.NET 은 대기열을 사용하여 요청을 조절합니다. 대기열 크기를 제어하려면, 아래의 설정을 변경해 줍니다. 

(총 연결량은 maxConcurrentRequestsPerCPU * 논리 프로세스 수)

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

파일의 processModel 의 속성을 변경합니다. 

machine.config

<system.web>
        <processModel autoConfig="true"/>

        <httpHandlers/>
        
        
<!-- 위 내용을 아래와 같이 수정 -->

        
<system.web>
        <processModel autoConfig="false" requestQueueLimit="250000" />

        <httpHandlers/>

위와같이 SignalR의 성능 튜닝을 진행하였으며, 자세한 성능카운트 설정 관련해선 참조링크를 참조해주세요.

참고

https://github.com/SignalR/SignalR/wiki/Performance

END

들어가며

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

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

웹서버 스케일 아웃

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

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

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

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

그것은 백플레인 (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)을 구성하였습니다. 

Pub/Sub

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

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

Sticky Session

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

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

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

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

END

---

들어가며

SignalR을 이용해서, 채팅시스템을 구현할 일이 생겼는데요.

그러는 과정에서 Client 에서 동작하는 라이브러리를 검색했었습니다.

https://github.com/jenyayel/SignalR.Client.20

위 소스가 .NET 2.0 환경에서 동작하는 SignalR 클라이언트 라이브러리 입니다. 

하지만, 이걸 그대로 Unity3D 에 적용하려면, meta 확장자로 변경해야 하는 과정이 필요하다고 해서, Unity3D 환경으로 포팅된 라이브러리가 있는지 좀더 검색해보기로 했습니다.

Unity3D에서 작동하는 SignalR

그렇게 해서 찾은 라이브러리가 아래에 공유한 uSignalR 입니다. 

uSignalR 라이브러리는 Unity3D 환경에 동작하는 SignalR 2.0 환경의 라이브러리 입니다. 

https://github.com/gromchen/uSignalR

위 소스를 이용해서 iOS 와 Android 환경에서 SignalR 서버와 통신하는 부분을 구현했고, 

실제 라이브 서비스 중에 있습니다. 

물론 uSignalR 에 몇가지 부족한 점이 있어서 소스를 좀 보완하기는 했습니다만, 

기본적으로 사용하는데에는 큰 문제는 없었습니다. 

왜 SignalR Core 를 사용하지 않았나요?

현시점에서는 SignalR Core 를 이용해서 작업하는게 맞습니다. 하지만 바로 적용하지 못했던 이유가 있었는데요.

첫번째로 .NET Core 환경은 Unity3D 에서는 아직 동작하지 않습니다.

두번째로는 핑계일수 있지만, 시간부족이였어요.

Unity3D 환경에서 동작하려면 .NET Standard 로 변경했어야 했는데, 이부분에서 R&D를 지속할 만한 시간이 부족했습니다. 

현 시점에서 SignalR 2.0 환경으로 게임에서 동작하는 것을 확인했으니, SignalR Core 로도 방법을 찾아보려고 합니다.^^

들어가며

프로젝트로 채팅서버를 구현해야할 필요성이 생겨났습니다. 어떠한 방식으로 채팅 서버를 구현할까 내부적으로 많은 이야기가 나왔었는데요. 확장성이 용이한 웹을 이용한 채팅을 개발하는 것에 초점이 맞춰졌습니다.

단기간에 해결해야 했기에, SignalR을 이용한 채팅 시스템을 구현을 했는데요.

클라이언트가 웹이 아닌 Unity3D 였기 때문에 가능한 방법을 다각도로 알아봤고, 아직은 Unity3D에서 .NET Core를 지원하지 않기 때문에 .NET Framework 4.5 버전에서 지원되는 SignalR 2.x 버전대로 채팅 시스템을 구현했습니다.

SignalR 이란?

ASP.NET SignalR은 애플리케이션에 실시간 웹 기능을 추가하는 프로세스를 간소화하는 ASP.NET개발자를 위한 라이브러리입니다. 

실시간 웹 기능은 서버가 클라이언트가 새 데이터를 요청할 때까지 기다리지 않고 서버 코드가 사용 가능해지면 즉시 연결된 클라이언트에 콘텐츠를 푸시하는 기능입니다.

SignalR을 사용하여 모든 종류의 "실시간" 웹 기능을 ASP.NET 애플리케이션에 추가할 수 있습니다.
채팅이 주된 예로 사용이 되고 있으나, 다양한 범위로 사용이 가능합니다.
사용자가 새로운 데이터를 보기 위해 웹 페이지를 새로 고치거나, 페이지가 새 데이터를 검색하기 위한 Long Polling 을 구현하는 웹 기능엔 SignalR을 사용할 잠재적 후보군 들 입니다.

아키텍쳐 다이어그램

특징

• SignalR은 연결 관리를 자동으로 처리하며,
• 대화방처럼 메시지를 연결된 모든 클라이언트에 동시에 브로드 캐스트 할 수 있다.
• 메시지를 특정 클라이언트에 보낼 수 있다.

시스템 요구사항

• .NET Framework 4.5 이상이 지원되는 운영체제
• Windows Server 2008 r2 이상
• Windows 7 이상
• SignalR 2.x 는 .NET Framework 4.5 에서만 지원이 됩니다. 최신버전은 .NET Core 를 이용해주세요.

지원되는 IIS 서버 버전

• IIS 8 또는 IIS 8 Express 이상.
• IIS 7 및 7.5. 확장 없는 URL에 대한 지원이 필요합니다.
• IIS는 통합 모드에서 실행 중이어야 합니다. 클래식 모드는 지원되지 않습니다. IIS가 Server-Sent 이벤트 전송을 사용하여 클래식 모드로 실행되는 경우 최대 30초의 메시지 지연이 발생할 수 있습니다.
• 호스팅 애플리케이션은 완전 신뢰 모드에서 실행되어야 합니다.

IIS 사용시 주의 사항

서버 버전이 아닌 IIS를 사용 할 경우, 동시 연결이 10개로 제한이 됩니다. 개인적으로 이것 때문에 한참을 검색했었는데요. MSDN에 답이 명시되어 있었습니다.

개발할 경우에는 IIS Express 를 사용하시고, 실제 서비스를 할때에는 서버용 IIS 를 사용하시면 됩니다.