FE.

BE.

WebRTC (Mesh)

도입 이유 실시간 화상 채팅 기반의 게임 서비스를 만들기 위해서 도입
해결 방안 WebRTC에는 Mesh / SFU / MCU가 있었는데 각각의 장단점은 아래와 같다.

Mesh

장점: 처음 peer간의 정보를 중계할 때 만 서버 부하가 발생하기 때문에 서버 자원이 적게들고 peer간의 직접 연결로 데이터 송수신을 하기 때문에 실시간성이 보장된다.

단점: 너무 많은 peer가 연결될 때 클라이언트의 부하가 심하다 (총 100명이 연결됐을 경우에 한명이 99개의 데이터를 보내고 99개의 데이터를 받는다)

SFU

장점: 데이터가 서버를 거치고 시그널링 서버를 사용할 때 보다 느리긴하지만 비슷한 수준의 실시간성을 유지할 수 있고, 클라이언트가 받는 부하가 줄ㅇ다.

단점: 서버의 비용이 추가적으로 발생하고 대규모 화상 채팅에서는 여전히 클라이언트가 많은 부하를 감당한다.

MCU

장점: 클라이언트의 부하가 현저히 들어든다.

단점: WebRTC의 최대 장점인 실시간성이 저하되고 중앙 서버에서 데이터를 혼합 및 가공하기 때문에 비용이 많이 든다. + 중앙 서버의 강한 컴퓨팅 파워도 요구된다. | | 의견 조율 | 실시간성이 중요한 게임 서비스임을 고려했을 때, 실시간성이 가장 낮고 중앙 서버에서 데이터 혼합 및 가공에 많은 비용이 요구되는 MCU는 제외하기로 했다. Mesh와 SFU 방식을 놓고 고민하게 됨. | | 의견 결정 | 나몰닭 서비스 특성 상 한 방에 최대 인원이 4명인 점을 고려했을 때 클라이언트의 부하가 심하지 않을 것이라고 판단했고, 서버에 거치는 일 없이 바로 peer끼리 정보를 주고 받기 때문에 실시간성이 중요한 게임 서비스에 적합하다고 판단했다. 또한 서버의 부하를 줄일 수 있다는 장점까지 포함하여 Mesh 방식을 선택했다. |

게임 셋팅을 저장하기 위한 Redis 서브 DB 선정

도입 이유 한 번 게임이 진행됐을 때 최대 80번의 DB 데이터 변경이 발생하기 때문에 비용적인 측면과 빠른 속도가 중요한 게임 서비스 특성에 맞는 DB 선정이 필요
해결 방안 RDS에 저장되어 있는 MySQL 데이터에 접근을 하지 않고, 컴퓨터 내에 인메모리 방식으로 데이터를 저장할 수 있으며 MySQL보다 처리 속도가 빠르기 때문에 게임 서비스에 적합하다고 생각되는 Redis를 고려하게 됨.
의견 조율 Redis를 사용했을 때의 문제점

  1. MySQL을 이용해서 RDS의 비용이 증가하는 것 보다 Redis를 이용함으로써 서버의 컴퓨팅 자원을 사용하는 비용이 Redis 아키텍쳐를 선택할 만큼 작지 않다. 비용적인 측면에서 큰 장점이 되지 못 한다고 판단.

  2. 프로젝트 규모를 보았을 때 MySQL의 처리 속도로도 유저가 게임을 진행하는데에 큰 문제가 되지 않음 | | 의견 결정 | 그냥 MySQL 쓰는 것으로 결정 추후에 유저 피드백 받아보고 실시간성이 떨어지는 이슈가 있을 경우 추후에 다시 논의 |

CI/CD

도입 이유 지속적인 통합을 통하여 업무 효율 상승위해 도입
해결 방안 Jenkins

장점: 1000개 이상의 플러그인을 통해 쉽게 기능을 확장할 수 있다. (범용성이 높음)

단점: 초기 설정을 해야하는 부분이 많아서 소규모 서비스일 경우 효율적이지 않을 수 있으며, 플러그인을 최신 상태로 유지하지 않을 경우 장애가 발생 할 수 있다.

**Github Action

장점: 추가적인 설치 과정 없이 Github에서 제공하는 환경에서 CI 작업이 가능하기 때문에 소규모 프로젝트에서 적합하고, 모든 환경과 호환이 된다.

단점: 새로운 환경을 구축할 경우 서버에 장애가 일어나거나 리소르르 초과할 경우 개발자가 직접 문제를 해결해야 한다.

Travis CI

장점: 깃허브와 손쉽게 연동이 가능하고 다양한 레퍼런스 및 YML 파일을 통한 손쉬운 설정이 가능하다. 그외 많은 장점이 있지만 후술할 단점으로 인해 여기까지만 적습니다.

단점: 유료** | | 의견 조율 | 현재 프로젝트 관리를 깃허브를 통하여 진행하고 있고, 소규모 프로젝트이기 때문에 러닝 커브가 없는 Github Action을 사용하는 방향으로 조율 | | 의견 결정 | 프로젝트 규모를 생각했을 때 Github Action과 AWS에서 제공하는 Code Deploy를 이용하기로 결정. 초기 설정이 적고 편의성이 높아 리소스를 줄이는 방향으로 진행 |

무중단 배포 전략

도입 이유 운영중인 서비스를 중지하지 않도록 하여 유저 서비스 경험에 이점이 되고 개발단에서도 재배포 시 휴먼 에러를 줄이기 위해서 사용
해결 방안 1. 롤링 방식 (Rolling Update)
장점 : 많은 지원툴들이 있어서 간편하고 많은 서버 자원을 확보하지 않아도 무중단 배포가 가능하다
단점 : 구버전과 신버전이 동시에 서비스되기 때문에 호환성 문제가 발생할 수 있음

2. 블루 그린 방식 (Blue-Green Deployment) 장점 :롤링 배포와 달리 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않고 작은 규모의 프로젝트에 적합하다. 단점 : 실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야하기 때문에 규모가 큰 프로젝트의 경우 비용 부담이 크다

3. 카나리 방식 (Canary Release) 장점 : 새로운 버전으로 인한 위험을 최소화할 수 있다. 단점 : 롤링 배포와 마찬가지고 신/구 버전이 함께 존재하므로 호환성 문제가 발생할 수 있다. | | 의견 조율 | Blue/Green 배포를 선택한 이유

우선 롤링 배포와 비교해 봤을 때, 좀 더 신속하게 롤백이 가능하다. 또한 롤링 배포는 두 대 이상의 WAS 서버를 이용해 로드 벨런싱을 이용했을 때 큰 이점이 있다고 판단했는데, 우리는 하나의 서버만 사용하고 있는 상황이라 적합하지 않다고 생각했다. 마지막으로 롤링 배포에서는 구버전과 신버전의 공존으로 인한 호환성 문제도 발생할 수 있다는 단점도 존재했다. 카나리 배포와 비교해 봤을 때는 카나리 방식의 최대 이점인 A/B 테스트가 현재 서비스에선 필요가 없었기 때문에 선택하지 않았다.

Blue/Green 배포 전략을 취함으로써 신속하게 롤백이 가능하다는 점과 배포하는 속도가 다른 배포법들에 비해 빠르다는 이점을 얻을 수 있다. | | 의견 결정 | EC2 프리티어 1대로 구성한 다음 Port를 2개로 나눠 블루-그린 배포 방식으로 진행할 것이다. 비용 측면에서 이 방식이 효율적이라고 생각했다. 새로운 버전 또한 기존 EC2 인스턴스에 그대로 적용하면 되므로 배포를 위해 AWS EC2 인스턴스가 추가로 더 필요하지 않다. 구조는 EC2 혹은 리눅스 서버에 Nginx 1대와 스프링 배포 파일 Jar 2대를 사용하면 되므로 간단하다 |

Refresh Token

도입 이유 보안을 위해 엑세스 토큰의 시간을 짧게 설정하면 유저 입장에서 잦은 로그아웃 경험을 하게 된다. 그렇다고 액세스 토큰 기간을 길게 설정하게 되면 보안상 더 탈취에 노출되는 위험이 존재하는데 이를 보안하기 위해 리프레시 토큰을 도입하기로 함
해결 방안 Refresh Token을 활용하여 해당 이슈를 해결하고자 함.

  1. 클라이언트가 로그인을 요청하고 성공하면, 서버는 Access Token과 Refresh Token을 함께 제공한다.

  2. 이후 클라이언트는 인가가 필요한 요청에 Access Token을 실어 보낸다.

  3. 시간이 조금 흘러 Access Token이 만료 되었다면, 클라이언트는 Refresh Token을 서버로 전달하여 새로운 Access Token을 발급 받는다. | | 의견 조율 | 1. Local Storage 저장할 것인지 아니면 쿠키에 저장할 것인지 의견조율 필요

  4. Redis를 활용할 경우 timeToLive 설정을 통해 별도의 관리 없이 자동으로 삭제할 수 있기 때문에 Redis에 저장하는 것으로 논의 | | 의견 결정 | |