정리하며 배우다.

들어가며

단일 서버로 구성을 하게 된다면, 여러뭐로 고민할 내용이 줄어들지만 현실은 그렇지 않죠.
다양한 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

---

들어가며

프로젝트를 진행하다 보면, 다양한 개발 환경이 존재 합니다. 

개발환경, 개발QA환경, 정식QA환경, 핫픽스환경 등등등.. 몸담고 있는 회사에서 정한 규칙대로 여러가지 환경이 존재하는데요. 프로젝트 환경에 따라 각 구성 파일을 변경하는 정책도 각 회사마다 차별점이 있는거 같습니다. 

.NET Core 에서는 이러한 환경을 구성하기 위해서 appsetting.json 파일을 제공하는데요. 

이를 이용해서 각 환경에 디버깅 하는 방식을 간략하게 정리했습니다.

정답은 아니니, 참고만 해주시면 되며, 배포 환경은 다른 얘기입니다.

appsettings 파일 추가

먼저 앱 설정 파일을 추가합니다. 프로젝트의 새 항목을 추가하는 방식으로 appsettings 파일을 추가합니다.

기본적으로 프로젝트를 생성하면, appsetting.Development.json 파일과, appsetting.json 파일이 기본적으로 제공이 되는데요.

저는 환경을 하나더 추가 하는 방식으로 진행을 해봤습니다. 

개발 과정에서 QA도 진행되기 때문에 appsetting.DevQA.json 파일을 json 파일 이름 형식에 맞춰서 생성하였습니다. 

각 구성에 설정값 추가

//	appsettings.json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "Zone": "Release"
}



//	appsettings.Development.json
{
  "DetailedErrors": true,
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "Zone": "Dev"
}



//	appsettings.DevQA.json
{
  "DetailedErrors": true,
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "Zone": "DevQA"
}

구분을 위해 "Zone" 컬럼을 추가해서, 각 구성을 구분하는 테스트를 했습니다.

테스트를 위한 Configuration 주입

Index.cshtml.cs

namespace WebAppSetting.Pages
{
    public class IndexModel : PageModel
    {
        private readonly ILogger<IndexModel> _logger;
        private readonly IConfiguration _configuration;

        public IndexModel(ILogger<IndexModel> logger, IConfiguration configuration)
        {
            _logger = logger;
            _configuration = configuration;
        }

        public ContentResult OnGet()
        {
            var key = _configuration["Zone"];

            return Content(key);
        }
    }
}

웹 프로젝트로 구성을 했고, 해당 페이지를 호출할 경우 configuration 값을 읽어오기 위해서 종속성을 주입했습니다. 

launchsetting.json 파일 수정

각각의 구성에 맞는 설정 파일을 읽어오는 방식 설정에 두가지 방식이 있는데요. 

그중 하나는 launchsetting.json 파일을 수정하는 것이고, 

다른 하나는, 속성의 디버그 UI에서 직접 수정을 하는 방식입니다. 

먼저 저는 launchsetting.json 파일에 profiles 에 해당 속성을 추가 했습니다. 

릴리즈 환경, Dev 환경, DevQA 환경을 각각 어떠한 Environment 를 사용할지 정의 해 주었습니다. 

ASPNETCORE_ENVIRONMENT 에 appsetting.json 파일을 읽을지 환경변수를 등록해줬습니다.

UI 화면에서 본다면, 이와 같은 형태가 됩니다.

결과 확인

위처럼 실행을 위해서 해당 profile 를 선택할 수 있는데요. 각 구성에 맞게 실행을 하게 되면 각각의 구성에 맞게 configuration 파일을 읽어 오게 됩니다. 

Release 환경 (appsetting.json)

Dev 환경 (appsetting.Development.json)

DevQA 환경 (appsetting.DevQA.json)

프로젝트를 개발하는 과정에, 각 환경에 맞는 구성을 읽어들여가며 개발할때, 유용하게 사용하면 됩니다. 

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 로도 방법을 찾아보려고 합니다.^^

System.Math 의 Round 메소드의 경우 기본적으로 소수점 이하 자리수를 파라메터로 제공을 하지만, 

올림 (Ceiling), 버림(Truncate) 메소드의 경우에는 제공을 하지 않습니다. 그렇기 때문에 해당 처리를 별도로 해줘야 하는데요. 

간단한 방법으로 특정 소수점 이하의 올림, 버림 처리를 할 수 있습니다. 

특정 소수점 올림

원하는 소수점까지의 표현을 위해 값을 곱해주고 나눠주는 방식으로 표현이 가능합니다. 

double value = 132.15469;

//	소수점 두자리 올림
Console.WriteLine($"Ceiling : {Math.Ceiling(value * 100) / 100}");

//	소수점 세자리 올림
Console.WriteLine($"Ceiling : {Math.Ceiling(value * 1000) / 1000}");


출력
132.16

132.155



원리
1. 132.15469 * 100 => 13215.469;
2. Ceiling(13215.469) => 13216;
3. 13216 / 100 => 132.16;

특정 소수점 버림

올림과 마찬가지 원리로, 원하는 소수점까지의 표현을 위해 값을 곱해주고 나눠주는 방식으로 표현이 가능합니다. 

double value = 132.15469;

//	소수점 두자리 버림
Console.WriteLine($"Ceiling : {Math.Truncate(value * 100) / 100}");

//	소수점 세자리 버림
Console.WriteLine($"Ceiling : {Math.Truncate(value * 1000) / 1000}");


출력
132.15

132.154



원리
1. 132.15469 * 100 => 13215.469;
2. Truncate(13215.469) => 13215;
3. 13215 / 100 => 132.15;

C#을 이용해서 개발을 진행하다보면, System.Math 를 통해서 수학함수를 사용할 일이 생기는데요. 그중 가장 많이 사용하는 부분이 수치를 이용한 올림/반올림/버림 처리가 아닐까합니다.

자주 사용하지만, 한번 만들어 놓으면 다시 보지 않기에 정리해봅니다.

올림

올림의 경우 Math.Ceiling(double a) 메소드를 사용합니다.

double value = 132.15469;

Console.WriteLine($"Ceiling : {Math.Ceiling(value)}");

//출력
Ceiling : 133

버림

버림의 경우 Math.Truncate(double a) 메소드를 사용합니다.

double value = 132.15469;

Console.WriteLine($"Truncate : {Math.Truncate(value)}");

//출력
Truncate : 132

반올림

반올림의 경우 Math.Round(double a, int digits) 메소드를 사용합니다.

반올림의 경우에는 소수점 자리수를 지정할 수 있으며, 입력한 자리수 (digits) 까지 표현이 됩니다.

아래의 예시를 들어, 132.15469 의 3번째 자리로 반올림의 경우, 표현을 3번째 자리로 하기때문에 6을 반올림하게 됩니다.

double value = 132.15469;

//	두번째 파라미터가 없을 경우 소수점 1자리 기준
Console.WriteLine($"Round : {Math.Round(value)}");

//	소수점 3째자리 반올림
Console.WriteLine($"Round 3 : {Math.Round(value, 3)}");


//출력
Round : 132

Round 3 : 132.155

IIS WebServer를 사용해서 서비스 하는 Web 어플리케이션의 경우 장기간 접속이 되지 않은 페이지에 대해서 Sleep 상태로 전환이 되는 경우가 발생하는데요.

이때 접속을 시도하게 되면, 약간의 딜레이가 발생하게 됩니다. 이런 문제는 사전에 예방할 수 있으며, 아래의 방법으로 웹 어플리케이션이 항상 준비단계로 대기하도록 설정 할 수 있습니다. 

어플리케이션 풀 설정

IIS관리자 (inetmgr) 을 실행한 뒤, 어플리케이션 풀에서 담당풀의 기본값 설정을 선택합니다.

IIS 관리자는 시작 -> 실행 -> inetmgr로 실행하셔도 됩니다.

시작모드의 기본값이 OnDemand 로 되어 있는데요. 이를 AlwaysRunning 으로 바꿔주면, 항시 준비 상태로 요청을 기다립니다.

유후 시간 제한 조치도 Terminate 에서 Suspend 로 변경해줍니다. 

사이트 설정

사이트 설정에서는, 하당 사이트의 "고급설정" 메뉴를 선택 후, 미리 로드 활성화됨을 False -> True 로 변경해줍니다.

서버 역할 선택 설치

Windows Server를 사용할 경우, 서버 역활 설치에서 "응용 프로그램 초기화" 를 설치해줍니다. 

해당내용을 설치할 경우, 웹 페이지 처리시, 비용이 많이 드는 웹 응용 프로그램의 초기화 작업을 수행합니다.