정리하며 배우다.

protobuf-net 이란?

protobuf-net은 .NET 코드용 계약 기반 직렬 변환기로, Google에서 설계한 "프로토콜 버퍼" 직렬화 형식으로 데이터를 작성합니다. 그러나 API는 Google과 매우 다르며 일반적인 .NET 패턴을 따릅니다. (사용 면에서 XmlSerializer, DataContractSerializer, 등) 표준 유형을 작성하고 특성을 사용할 수 있는 대부분의 .NET 언어에서 작동해야 합니다.

.proto 파일을 생성 하지 않아도 됩니다.

NuGet  패키지 다운로드

protobuf-net 은 Nuget Package 관리자를 통해서 다운로드 받을 수 있습니다. 

제가 받았을때 버전은 3.1.17 이였네요.

사용방법

[ProtoContract]
public class Account
{
    [ProtoMember(1)]
    public string UserID { get; set; }
    [ProtoMember(2)]
    public int Age { get; set; }
    public int Num { get; set; }
}

사용방법은 크게 어렵지 않았습니다.  사용하려는 프로토콜 Class 에 ProtoContract 라는 Attribute를 선언해주고, 

각각의 Property에 ProtoMember Attribute를 추가적으로 선언해주면 됩니다. 

인덱스는 1 번 부터 시작합니다. 

static void Main(string[] args)
{
    Account account = new Account
    {
        UserID = "Martin",
        Age = 1337, 
        Num = 1
    };



    //  serialize
    MemoryStream serialize = new MemoryStream();
    ProtoBuf.Serializer.Serialize<Account>(serialize, account);
    byte[] byteData = serialize.ToArray();
    Console.WriteLine($"Serialize : {BitConverter.ToString(byteData)}");
    //Console.WriteLine($"Json : {}")


    //  deserialize
    MemoryStream deserialize = new MemoryStream(byteData);
    Account result = ProtoBuf.Serializer.Deserialize<Account>(deserialize);
    Console.WriteLine($"DeSerialize : {result.UserID}, {result.Age}, {result.Num}");


    Console.ReadLine();
}

간략하게 Serialize, Deserialize 하는 방법입니다. 

protobuf-net 을 사용해서 C# 내에서는 사용방법이 간략하네요. 

참조

https://reqres.tistory.com/6

https://dotnetcoretutorials.com/2022/01/13/protobuf-in-c-net-part-2-serializing-deserializing/

END

들어가며

gRPC를 보다보니, gRPC는 기본적으로 프로토콜 버퍼를 함께 사용합니다. 저도 아직 실무에서 사용해본적은 없지만 이번기회에 개념을 같이 정리해보았습니다. 

개요

프로토콜 버퍼는 구조화된 데이터를 직렬화하기 위한 구글에서 개발하고, 공개한 언어 중립적, 플랫폼 중립적,

확장 가능한 구조입니다. (Serialized Data Structure)

다양한 언어를 지원하며, XML 보다 작고, 빠르고, 간단하며, 일반적으로 RESTFul API 사용시 JSON을 많이 사용하며, 이와 유사한 직렬화 데이터 구조입니다.

JSON, XML의 경우 일반 사람들이 육안으로 데이터 확인이 가능하다면, 프로토콜 버퍼의 구조는 16진수로 인코딩 하기때문에, 직접적인 확인은 불가능하다는 단점이 있지만, 데이터 구조화 를 한번 정의한 다음, 특수 생성 소스 코드를 사용하여 다양한 데이터 스트림과 다양한 언어를 사용하여 구조화된 데이터를 쉽게 쓰고 읽을 수 있습니다.

사용범위

• 프로토콜 버퍼는 언어 중립적, 플랫폼 중립적, 확장 가능한 방식으로 구조화된 레코드와 같은 유형 데이터를 직렬화해야 하는 모든 상황에 이상적입니다.
• 통신 프로토콜 정의(gRPC와 함께) 및 데이터 저장에 가장 자주 사용됩니다.

장점

• 컴팩트한 데이터 스토리지
• 빠른 구문 분석
• 많은 프로그래밍 언어에서 사용 가능
• 자동 생성 클래스를 통한 최적화된 기능

단점

• 16진수 형태의 byte 로 변환되기 때문에, 직관적으로 데이터를 읽기 어렵습니다.
• 타 언어의 경우 .proto 확장자 파일이 있어야, protobuf 로 쓰여진 데이터를 읽을 수 있습니다.

언어 간 호환성

지원되는 모든 프로그래밍 언어로 작성된 코드로 동일한 메시지를 읽을 수 있습니다. 한 플랫폼의 Java 프로그램이 한 소프트웨어 시스템에서 데이터를 캡처하고 .proto정의에 따라 직렬화한 다음 다른 플랫폼에서 실행되는 별도의 Python 응용 프로그램에서 직렬화된 데이터에서 특정 값을 추출하도록 할 수 있습니다.

• C++, C#, Java, Kotlin, Objective-C, PHP, Python, Ruby

적합하지 않은 경우

• 프로토콜 버퍼가 직렬화가 되면, 동일한 데이터여도 다양한 이진 직렬화를 가질 수 있습니다. 이진데이터를 비교해야 할 경우 다른 솔루션을 고려해야 합니다.
• 메시지는 압축되지 않습니다. gzip으로는 압축할 수 있지만, 특수 목적 압축 알고리즘에는 적합하지 않습니다.
• 비 객체지향 언어에서 잘 지원되지 않습니다. (언어 호환 확인 필요)
• 공식적인 표준이 아닙니다. 표준을 따라야 하는 프로젝트에서는 부적합합니다.

참조

https://developers.google.com/protocol-buffers/docs/overview

END

들어가며

Web 서버로 구성된 프로젝트에서, 서버 클라이언트간에 데이터를 전송하는 방식으로 RESTFul API 에 Json 데이터 포멧을 이용해서 많이 사용합니다. 분명한 장/단점이 있는데요. 클라이언트와의 데이터 포멧은 데이터 파악의 용이한 점으로 인해서 Json 포멧을 많이 사용하고 있습니다. 

서버끼리의 통신에도 Json 방식으로 데이터 포멧을 유지하고 있었는데요. 

데이터 구조를 노출하지 않고 (물론 다양한 방법이 존재하지만요.), 서버간의 통신을 gRPC를 이용해서 좀더 빠른 통신을 구성해보는 것이 어떨까 해서 gRPC 에 대해 알아보기로 했습니다. 

gRPC 개요

gRPC는 google Remote Procedure Call 의 약자로서, 이름에서 보이듯 구글에서 만든, 모든 환경에서 실행할수 있는 최신 오픈 소스 고성능의 원격 프로시져 호출 프래임워크 입니다. 

RPC는 프로세스 간에 통신을 하기 위한 프레임워크인데, 이를 구글에서 HTTP/2 기반으로 구현한 것이 gRPC 입니다.

로드밸런싱, 추척, 상태확인 및 인증을 위한 플러그형 지원을 통해 데이터 센터 안밖에서 서비스를 효율적으로 연결할 수 있습니다. 또한 디바이스, 모바일 앱, 브라우저의 백앤드 서비스에 연결하기 위한 분산 컴퓨팅의 라스트 마일에도 적용할 수 있습니다.

gRPC에서 클라이언트는 로컬 개체인것처럼 다른 서버 응용프로그램의 메서드를 직접 호출할 수 있으므로, 분산 응용 프로그램 및 서비스를 더 쉽게 만들 수 있습니다.

서버측에서 인터페이스를 구현하고 gRPC 서버를 실행하여, 클라이언트 호출을 처리합니다.

프로토콜 버퍼

기본적으로 gRPC는 프로토콜 버퍼를 사용합니다.

일반적으로 proto2(현재 기본 프로토콜 버퍼 버전)를 사용할 수 있지만 proto3를 gRPC와 함께 사용하면 gRPC 지원 언어의 전체 범위를 사용할 수 있고 proto2 클라이언트와 통신하는 호환성 문제를 피할 수 있으므로 gRPC와 함께 사용하는 것이 좋습니다.

proto3 서버와 그 반대의 경우도 마찬가지입니다.

주요 사용 시나리오

• 마이크로 서비스 스타일의 설계에서 폴리글랏 서비스의 효율적인 연결
• 모바일 장비, 브라우저 클라이언트의 백엔드 서비스에 연결
• 효율적인 클라이언트 라이브러리 생성

핵심 특징

• 11개 언어로 된 관용적 클라이언트 라이브러리
• 간단한 서비스 정의 프레임워크로 매우 효율적입니다.
• http/2 기반 전송을 통한 양방향 스트리밍
• 플러그인 형 인증, 추적, 로드밸런싱 및 상태확인

지원 언어

참조

https://narup.tistory.com/119?category=925261

https://grpc.io/docs/what-is-grpc/introduction/

END

들어가며

사내에서 Issue Tracking System 툴로 JIRA, Redmine 을 병행해서 사용중에 있습니다. 서로 장단점이 있는 툴로서 각 직군에 맞게 사용중인데요. 2022년 06월 이후로 메일 Notification 이 발송이 안되고 있었습니다. 오랜시간 해당 부분에 대해서는 아예 잊고 있을만큼 메일 발송이 잘 되고 있었는데, 해당 년월 이후로 발송이 안되서 확인해봤습니다. 

보안 수준이 낮은 앱!!

https://support.google.com/accounts/answer/6010255?hl=ko 

엇! 언제 이런 공지가 있었을까요. 2022년 05월 30일 부터 사용자 이름과 비밀번호만 사용해서 로그인 하는 서드파티 앱을 지원 안한다니!!

시기도 딱 맞아 떨어지네요.

구글은 열심히 알렸겠지만, 메일발송과 연관이 있을거라고 생각 못하고 있었습니다. 

해결방법

위 내용을 해결 하려면, 2차 인증을 완료해서, 앱 비밀번호를 생성해서 이용하면 해결 됩니다. 

계정관리 메뉴에 들어가면, 왼쪽에 보안메뉴를 확인 할 수 있습니다. 

해당 메뉴를 선택해 줍니다.

보안 메뉴에 들어가면, 2단계 인증과 관련한 부분이 보이며, 해당 부분을 완료해주시면 됩니다. 

그 다음, 앱 비밀 번호를 만들면 되는데요. 

위 이미지 처럼 "메일", "Windows 컴퓨터" 를 선택 후 생성 하면, 아래와 같이 비밀번호가 생성됩니다. 

비밀번호가 정상적으로 생성되었습니다. 

해당 비빌번호를 복사해서 사용하면 됩니다. 

email_delivery:
    delivery_method: :smtp
    smtp_settings:
      enable_starttls_auto: true
      address: "smtp.gmail.com"
      port: 587
      domain: "smtp.gmail.com"
      authentication: :plain
      user_name: "*****@gmail.com"
      password: "******"

Redmine의 경우 smtp 설정 부분에, password 에 넣어주시면, 정상적으로 메일이 발송됩니다.

END

들어가며

Hyper-V를 사용할 일이 생겨서 예전에 설치된 Hyper-V를 실행하려고 했는데.. 포맷했다는걸 잊어버렸네요. 

다시한번 Hyper-V 를 설치하려고 하던 중 PowerShell 로도 설치가 가능하거 같아서 정리했습니다.

더불어 Windows 10 MSIX packaging 도 빠른 설치가 가능한거 같아서 같이 정리했습니다. 

Hyper-V 설치 요구사항

• Windows 10 Enterprise, Pro 또는 Education
• 두 번째 수준 주소 변환(SLAT)을 사용하는 64비트 프로세서.
• VM 모니터 모드 확장(Intel CPU의 VT-c)에 대한 CPU 지원.
• 최소 4GB의 메모리.

PowerShell 을 사용하여 Hyper-V 설치

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

PowerShell 을 실행 후~ 위 명령을 복사 붙여넣기 후 실행해 줍니다.

그러면 아래와 같이 Hyper-v 설치 화면이 진행됩니다.

설치가 모두 완료가 되면, 컴퓨터 재시작 메시지가 보여지면서, 

Y 를 눌러 PC를 재시작 해주시면 설치가 완료됩니다.

재시작 이후, 별도의 창은 실행되지 않습니다.

MSIX란?

MSIX는 모든 Windows 앱에 최신 패키징 환경을 제공하는 Windows 앱 패키징 형식입니다. MSIX 패키지 형식은 Win32, WPF 및 Windows Forms 앱에 새로운 최신 패키지 및 배포 기능을 사용할 수 있도록 하며, 기존 앱 패키지 및/또는 설치 파일의 기능도 유지합니다.

MSIX를 사용하면 엔터프라이즈를 최신 상태를 유지하고, 애플리케이션도 항상 최신 상태로 유지할 수 있습니다. 이를 통해 IT 전문가와 개발자는 사용자 중심의 솔루션을 제공할 수 있으며, 다시 패키징할 필요성이 줄어들어 애플리케이션의 소유 비용을 절감할 수 있습니다.

https://docs.microsoft.com/ko-kr/windows/msix/overview

Windows 10 MSIX Packaging 설치

 Hyper-v 관리자에서 빨리 만들기를 선택하면, 아래와 같이 가상 컴퓨터 만들기 창이 생성이 되는데요.

상단에 Windows 10 MSIX packaging 을 설치할 수 있습니다. 

Ubuntu Linux 도 설치가 가능한거 같네요.

가상 컴퓨터 만들기 버튼을 선택하면, 아래와 같이 이미지를 다운로드 하고, 설치까지 진행을 합니다.

특별히 어려운 점 없이 진행이 가능합니다. 

설치가 완료가 되면, 해당 서버를 실행해주면 Windows 셋팅 화면이 나오며, 온라인 계정이 없으신 분은 로컬계정으로 생성이 가능합니다. 

추가적인 내용이 있다면! 이미지 다운로드시 언어팩이 설치가 되지는 않아서 영문 윈도우 화면으로 설정을 진행하셔야 합니다. 

END

들어가며

처음으로 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