IT's 잡탕찌개 블로그

이번 포스팅에서는 MSA를 설계할 때 고려해야할 것들, 주의할 점등에 대해서 알아보자.

MSA의 설계 철학
. service의 크기는 작아야한다.
. test 및 자동 배포를 하여 유지보수 부담을 낮춰야 한다.
. 각 작업자는 자신의 코드영역만 작업할 수 있어야 한다.
. 각 service는 유연하고 회복력이 있게 구성되어야 하며, 해당 service만으로도 완전해야 한다.
. 각 service는 구분되며 이에 필요한 기술스택은 다양할 수 있다.

위의 설계 철학에 따른 구조를 위 그림과 같다고 할 수 있을 것이다.
일부 시스템은 단일 서비스로 구현되고 어떠한 시스템은 여러 service에 분산 될 수 있다.
분산되는 service의 경우 HTTP를 통해 통신하거나 Kafka와 같은 메세지 브로커를 비동기식으로 사용해 구현될 수 있다.
그렇다면  MSA 적용시 어떠한 점들을 고려해야 할까?
우선 우리의 프로젝트가 과연 MSA를 적용하는것이 옳은지 생각해봐야한다.
만약 MSA를 적용하기에 비효율적으로 복잡하거나 런타임 시 결합이 긴밀할 것으로 생각된다면 MA를 적용하는 것이 좋을 수 있다.
MSA를 적용하기로 했다면 이제 분산 작업을 설계할 차례이다.
MSA를 사용할 때 우리는 service를 분산시킬 것이며, 이는 각 service가 고유 DB를 지닌다는 얘기가 된다.
이로인해 DB에 대해 어떻게 접근할 지를 고려해야 하며 DB와 관련된 여러가지 문제가 발생할 수 있다. 해결책으로는 아래 이미지의 여러 패턴을 적용하는 것이 있지만 이 내용은 다소 분량이 커서 다른 포스팅에서 다루기로 한다.

DB외에도 고려해야 할 점은 또 있다.
우선 service를 구분하는 범위에 대한 기준을 정해야 한다.
단순히 A service로 묶을지 혹은 A의 기능인 A`와 A``를 개별 service로 묶을지에 대한 기준이다.
이러한 기준은 비즈니스 혹은 해당 서비스에 따라서 달라질 수 있다.
그 외에도 service내에서 API를 어떻게 설계할지, 또는 service간의 종속성과 배포 용이성, 장애 대응을 어떻게 할지 등등 고려해야할 점이 많다.


참고 -
https://microservices.io/patterns/microservices.html https://ko.m.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

MA란 무엇인가?
Monoilithic Architecture의 경우 전통적인 개발 방식으로 하나의 프로젝트 속에 여러 기능을 모두 포함한다.

MA의 특징
MA의 경우 기능이 모듈별로 쪼개지는 것이 아니기 떄문에 하나의 프로젝트에 전체 APP이 다 포함된다.
이러한 구조로 인해서 기능, 모듈이 추가될 때마다 프로젝트가 커지게 된다.

MA의 장점
아무래도 구조등을 고민할 필요가 적어 초기에 개발하기가 편하다.
더불어 모든 기능이 같은 내부에 존재하기 때문에 별도의 통신이 없이 다른 기능을 직접 사용할 수 있다.  

MA의 단점
시간이 지나 프로젝트 규모가 커질수록 유지보수 규모와 비용이 커지며 확장이 점점 힘들어진다.
그외의 사소한 기능 수정임에도 전체 App을 재기동해야하는등의 단점이 존재한다.

MSA 란 무엇인가?
msa(micro service architecture)란 MA에 반대되는 개념으로
여러개의 작은 service로 구성되어 각 service가 독립적으로 개발 되고 배포되는 구조를 의미한다.

MSA 의 특징
MSA는 MA와 달리 각 기능별로 독립적으로 배포 및 개발이 되기 때문에 전체적으로 시스템이 분산되어 있다.
이로 인해서 각 기능별로 개발, 배포가 독립적으로 가능하며 MA에 비해서 규모 및 기능을 확장하기가 쉽다.
또한 유지보수가 용이하다.

MSA의 장점
각 service간의 독립성으로 인해서 확장성과 유연성이 높아진다.
가령 cloud 환경에서 특정 기능에 부하가 몰리는 경우 해당 기능과 관련된 instance 규모만 확장하면 된다.
또한 각 service가 구분되어 있기 때문에 일부 service의 장애가 다른 service에 영향을 끼치지 않는다.

MSA의 단점
반면 MSA 역시 단점이 존재하는데 각 service가 독립되어 있기 때문에 service간의 통신을 고려해야한다.
이로 인해서 각 service와의 연결구조 및 관리가 다소 복잡해진다.
추가로 초기 구조 세팅에 소모되는 비용이 다소 크다.

MSA가 적용된 예
MA의 경우 프로젝트 크기가 별로 크지 않을때 많이 적용되며 반대로 MSA의 경우 대규모 프로젝트에 적합하다.
간단하게 게임분야의 경우 login server와 lobby server, battle server, guild server 등으로 구분하여 service를 구현하는 경우도 MSA로 볼 수 있을 것이다.

요즘은 점점 더 스마트 기기를 이용하여 Game을 즐기는 사람들이 늘어나고 있다.

Pc와는 다르게 Mobile에서는 session이 끊기는 일이 자주 발생하며

이러한 특징에 의해서 Mobile Game Server는 PC Game Server와는 다른 특이사항들이 존재한다.

이중 하나가 바로 HandOver인데 HandOver가 어떤것인지 알아보자.

수집형 RPG 모바일 게임등의 경우 실시간 동기화가 아닌 비동기식으로 게임을 진행하는 경우가 많다.

예를 들자면, 카드 수집형 RPG의 경우 전투를 시작할 시 전투 시작정보를 server와 통신한 후

실제 전투는 Server와 통신없이 진행된 후 마지막에 결과정보만 Server에 전달하는 식이다.

이러한 때문에 짧은순간만 Server와 통신을 해도 게임 진행이 가능하다는 특징이 있다.

그러나 이러한 특징과 모바일 기기의 특징이 만나면 PC와는 다른 예외상황들을 고민해야한다.

전투 시작 전 Session과 와이파이로 바뀐후에 전투결과를 Server로 보낸경우 동일 유저임을 어떻게 판단할 것이며

그에 따른 처리는 어떻게 진행해야 하는가등을 고려해야 하는 상황이 된것이다.

이러한 문제를 해결하기 위해서 Client는 Server에 접속할 시 SessionKey 등의 특정 식별값을 받는다.

그 후 실제 재접속이 이루어질 때 해당 SessionKey를 전달하여 재접속 처리를 진행한다.

(예를 들면 유저가 대기화면에서 Handover 발생시 Session이 접속해있던 LobbyServer로 연결을 다시 해준다거나 등등)

참고 : http://elky.tistory.com/318

LockFree에 대해서 검색하던 중 알게된 용어.

Convoying이란 MultiThread 구현 시 무분별한 Lock의 사용으로 인해서

MultiThread의 장점을 활용하지 못하고 특정 Thread가 작업 시 다른 Thread는 Lock에 걸린채로 대기하는 문제를 말한다.

즉, 특정 Lock에 대하여 여러 Thread가 접근하려고 할때 획득하지 못한 Thread들을 모두 기다릴 것이다.

이러한 상황에서 불필요한 ContextSwitching이 발생하며 비용이 발생할 수 있다.

Convoying을 해결하기 위해서는 LockFree 알고리즘을 활용하는 것도 좋은 방법이다.

위키에서는 Convoying을 이렇게 표현하더라

In computer science, a lock convoy is a performance problem that can occur when using locks for concurrency control in a multithreaded application.

[ 출처 : https://en.wikipedia.org/wiki/Lock_convoy ]

LockFree 알고리즘이란?

. MultiThread에서의 동기화 기법(lock 등)을 사용하지 않고 다중 호출에 대하여 최소한 1개의 호출이 완료되는 알고리즘

. Game Server에서는 JobQueue등에서 사용할 수 있다.

. 원리는 자료구조에 대하여 변경을 수행할 때 다른 Thread가 접근한 경우 작업 시도를 취소하는 것이다.

LockFree 알고리즘을 사용하는 이유

. 잘못된 MultiThread 사용으로 인한 성능 하락이 없다.

. lock을 사용하지 않고 DeadLock 이슈를 피하기 위해서

. 다른 Thread의 상태와 상관없이 호출이 완료된다.

. non blocking 하면서 원장성을 유지해야 하는 경우

LockFree에서 사용하는 자료구조

. Queue : enqueue, dequeue

. Stack : pop, push

. BinaryTree : insert delete, search

//걍 대충 적은 코드

push(int x)
{
	var e = new Node(x);
    lock(new object())
    {
    	someTail.next = e;
        somTail = e;
    }
}

push_nonBlock(int x)
{
	var e = new Node(x);
    while(true)
    {
    	var t = someTail;
        var next = t.next;
        if(t != someTail)
        	continue;
        if(next == null)
        {
        	if(Interlocked.Compare(t.next, null, e))
        	{
            	Interlocked.Compare(someTail, t, e);
            	return;
        	}
        }
        else
        {
        	Interlocked.Compare(someTail, t, next);
        }
    }
}

LockFree 알고리즘의 단점

. 구현하기가 다소 난해하다.

. 코드가 복잡해져서 버그를 발견하기가 어렵다.

=> 요즘 장비 성능도 좋아지는데 걍 멀티스레드를 잘 활용하는게 좋은듯?

Process란 운영체제로부터 자원을 할당받은 작업의 단위이다.

Thread는 Process의 자원을 이용하는 실행 흐름의 단위이다.

CPU 역시 Thread 단위로 점유하며 한개의 Process안에 여러개의 Thread가 존재 할 수 있다.

같은 Process에 속한 Thread들은 Process의 code, data, heap영역을 공유하며

이로 인해 context switching 시 다른 process의 thread가 cpu를 점유할때에 비하여

같은 Process에 속한 Thread가 CPU를 점유 시 레지스터에 복사하는 비용이 적어 더 효율적이다.

각각의 Thread는 고유의 Stack 영역을 지닌다.

이러한 특징 때문에 Process에 속한 특정 Thread가 code, data, heap 영역에서 문제를 발생시킬 경우

관련 Thread들이 모두 영향을 받는다.

Server Programmer 들에게 동기화란 매우 민감하며 중요한 주제이다.

동기화 기법이란 Thread들에게 특정 Resource에 대한 접근 권한을 주는 기법이다.

각각의 동기화 기법들의 종류, 간단한 설명을 알아보자.

Lock 

 - 가장 기본적인 동기화 기법이며 critical section을 활용하여 동기화를 한다.

Mutex

 - 단 하나의 Thread 접근을 허용한다. [모든 프로세서에서 접근 가능.]

 - 이름을 지정하여 여러 Process가 접근 가능.

Shemaphore

 - 지정된 갯수만큼의 Thread 접근을 허가한다. [갯수 지정가능한 Mutex 느낌]

 -> 임계영역에 진입 시 lock, 임계영역 탈출 후 unlock을 하여 접근횟수를 관리한다.

 - Mutex처럼 이름을 통해 접근이 가능.

Event

 - 신호, 비신호 두 가지의 상태가 가능하다. [Manual mode, Auto reset mode]

 - 임계영역 탈출 시 자동으로 비신호상태로 바꿔주는 Auto Reset 여부를 설정이 가능하다.

 - 임계영역 진입 시 Non signaled 상태에서 signaled 상태로 변경한다.

 - 타 Thread 들은 signaled 상태인 event에 접근 시 대기한다.

 - Auto Reset Event 가 아닌 경우 임계 영역을 탈출 한 후 Signal 상태로 계속 존재한다.

  -> ResetEvent를 통해서 Non signaled 상태로 변경해줘야함.

 - 보통 Event의 경우 Thread간의 실행순서를 지켜야 하는 경우 많이 사용한다.

Atomic

 - 특정 int형 변수에 대한 접근을 제한하는 기법

 - Interlock을 통해서 Increase, Decrease, Compare 가 일반적으 로 사용된다.

Winsock 관련하여 Socket을 처리하는 방법들을 여러가지가 있다. 

그중 대표적인 몆가지 방법들에 대해서 개념적으로 알아보자.

우선 소켓의 처리방식은 Proactor / Reactor 방식으로 구분된다.

. Proactor : 이벤트가 발생 시 특정 함수를 호출하는 방식

 -> 밑의 ASIO, IOCP 방식이 해당

. Reactor : loop를 돌면서 이벤트가 발생했는지 일일히 확인하는 방식

 -> Select , epoll 방식

Select 방식

. SingleThread 기반의 다중 I/O 처리 방법

. 송신, 수신, 예외 이벤트가 발생한 소켓들을 관리하는 3가지의 "Set"으로 구분한다.

. 각각의 Set을 매 순간 확인하여 해당 이벤트가 발생한 소켓을 목록으로 얻어온다.

. 소켓목록을 순회하며 송신, 수신, 예외에 따른 처리를 수행한다.

. 단, 최대 관리할 수 있는 소켓의 갯수는 1024개로 제한된다.

epoll 방식

. Select 방식의 단점을 보완한 리눅스에서 사용이 가능한 I/O 방식

. Select와 같은 동기형 통지방식을 따르며 FD_SET을 운영체제가 직접 관리한다.

. non blocking, blocking을 설정이 가능하다.

IOCP 방식

. c++ 게임 서버 개발자라면 필히 공부해야 하는 것.

. In/Out Completion  Port의 약자

. 기본적으로 Overlapped I/O Callback 방식을 따른다.

. IOCP 내부의 Thread Pool을 사용하여 소켓의 송수신을 관리한다.

. 따라서 적은 수의 Thread 로 소켓관리가 가능하며, 별도의 Thread 생성, 제거를 할 필요가 없음.

 -> Callback 함수들을 해당 Thread들을 통해 호출한다.

 . 주의할 점으론 I/O가 완료된 Overllaped 구조체에 접근해야 한다는 것이다.

 -> I/O 가 미완료된 Handle에 접근하면 안됨.

ASIO 방식

. Boost lib에 존재하는 방식.

. 아마도 C++ 20에 들어갈 예정이라고 한다...

. Asynchronous IO의 약자.

서버 구현 시 일반적으로 Socket을 설정하는 단계는 아래와 같다.

1. 리스닝 Socket 생성

2. 해당 소켓의 EndPoint 설정[ port와 addr 정보 설정 단계 ]

3. 해당 소켓 Binding

4. 소켓 리스닝 시작

5. 클라이언트 접속 Accept

그렇다면 이러한 방법이 실제 각 언어별 Code로는 어떻게 작성될까?

c++

int main()
{

WSADATA wData;
WSAStartup(MAKEWORD(2, 2), &wsaData);
SOCKET listenSock;
listenSock = socket(AF_INET, SOCKET_STREAM, IPPROTO_TCP);

SOCKADDR_IN sAdd;
ZeroMemory(&sAdd, sizeof(SOCKADDR_IN));
sAdd.sin_family = AF_INET;
sAdd.sin_port = htons(PORT);
sAddr.sin_addr.s_addr = htonl(INADDR_ANY);

bind(listenSock, (SOCKADDR)*sAddr, sizeof(listen));
listen(listenSock, SOMAXCONN);

SOCKADDR_IN cAdd;
Zeromemory(&cAdd, sizeof(SOCKADDR_IN));
int iClientSize = sizeof(cAdd);
SOCKET cSock = accept(listenSock, (SOCKADDR*)&cAddr, &iClientSize);

WSACleanup();

}

C# 

기본적으론 C++과 다르지 않지만 C#은 유틸성 클래스를 여러개 지니고 있기 때문에 알아두면 편한 것들이 있다.

public static void Main()
{

  Socket lSock = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
  IPAddress hostIP = (Dns.Resolve(IPAddress.Any.ToString())).AddressList[0];
  IPEndPoint ep = new IPEndPoint(shotIP, port);
  lSocket.Bind(ep);
  
  int backLog = 100;	//동시에 Accept할 수 있는 최대 갯수
  lSocket.Listen(backLog);
  
  whlie(true)
  {
  	Socket client = lSocket.Accept();
    //연결된 client 관련 처리
  }
}

//TCP 연결에 대한 Socket

public static void Main()
{
  TCPListener server = null;
  try
  {
    int port = 13000;
    IPAddress localAddr = IPAddress.Parse("127.0.0.1");
    
    server = new TCPListener(localAddr, port)
    
    //Socket은 Listen을 시작.
    server.start();
    
    while(true)
    {
      TCPClient newClient = server.AcceptTcpClient();
      
      //새로운 client에 대한 처리.
    }
  }
  catch(Exception e)
  {
  
  }
  finally
  {
  }
}

JAVA의 경우는 C++보다는 약간 더 간단하다 단순하게 포트번호만 지정해주면 되는것 같다.

public static void main(String[] args)
{
  try
  {
    ServerSocket sSocket = new ServerSocket(9000);
    //client 접속 소켓 생성
    Socket cSocket = sSocket.accpet();
    
    .....
  }
  catch(Exception e)
  {
  }
}

출처 : https://gameqa.tistory.com/86

게임을 서비스하다보면 필수적으로 여러가지 로그를 남기게 된다.

[ ex : 결제 시도 및 성공 로그라던가 아이템 획득 로그 등등 ]

이러한 로그를 구성할 때 기본적으로는 6하 원칙에 추가정보[예를 들어 대상이라던가 상태라던가]까지 

총 7가지 정보를 기반으로 작성하는 것이 좋다.

즉 언제 / 어디서 / 누가 / 무엇을 / 어떻게 / 왜 / 추가정보 로써

2019-09-09 14:00:00 / achieve / 토끼겅듀 / 화속성 메이스 / get / [공란] / gold 500소모

이런식으로 작성을 하면 로그가 포함하는 정보가 명확해진다.

다만 로그 용도에 따라서 굳이 위 정보를 모두 포함할 필요 없이 핵심 정보만 남기는 경우도 있다.

그때 그때 개발 상황에 맞게 판단하면 된다.