한바탕 아키텍처를 정리하고 나서
지속적으로 개선할수 있는 이슈들을 찾아 보게 되었습니다.
게임 업계에는 악명높은 3대 명검이 존재합니다.
긴급점검 임시점검 정기점검
이중 매주 목요일에 진행하는 게임 정기 점검에 자연스럽게 플랫폼 점검도 이루어졌는데요,
배포중에 서비스가 멈추는 부분은 긴급 패치나, 게임점검 지연이슈를 발생시켰습니다.
첫번째 점검이슈를 해결하기위해 무중단 배포를 구상하였습니다.
이때 nginx를 자주 접하면서 신세계를 맛보았는데요
로드밸런싱 기능 뿐만아니라
흐르는 트래픽을 아주 우아하게(graceful)끊고 다른 흐름으로 흘려주는 덕분에
(nginx graceful reload 설명해줘)
NGINX는 높은 성능과 안정성으로 인해 많은 웹 서버에서 사용되고 있습니다. NGINX를 재시작할 때는 이전 연결을 끊고, 새로운 연결을 생성하는 등의 처리가 발생합니다. 이러한 처리로 인해 재시작 시간이 오래 걸리거나, 연결에 문제가 발생할 수 있습니다.
이를 해결하기 위해 NGINX는 graceful reload 기능을 제공합니다. Graceful reload는 NGINX를 재시작할 때, 이전에 실행 중인 프로세스가 종료될 때까지 새로운 프로세스를 실행하지 않고, 이전 프로세스와 새로운 프로세스를 동시에 유지하면서 처리를 전환하는 방식입니다. 이를 통해, 이전 연결이 끊기지 않고, 새로운 연결을 생성하는 등의 처리를 중단하지 않고, 부드럽게 프로세스 전환을 수행할 수 있습니다.
Graceful reload는 NGINX 설정 파일을 변경하거나, 업그레이드를 수행할 때 유용합니다. 기존 프로세스가 새로운 설정을 사용하도록 다시 로드하거나, 새로운 버전의 NGINX로 업그레이드 할 때에도 사용할 수 있습니다. 이를 통해, NGINX를 재시작할 때 연결이 끊기지 않고, 안정적으로 서비스를 유지할 수 있습니다.
다양한 긴급 상황이나 기능들을 구상할 수 있었습니다.
예를들어 무중단 배포는
기존 1머신에 1개의 톰캣 인스턴스를 사용하던것을
리버스 프록시를 위한 1개의 nginx와 두개의 톰캣 인스턴스를 구성하여
젠킨스를 통해 무중단 배포 자동화를 구성하였습니다.
https://cusmaker.tistory.com/250
[Nginx + Tomcat] 무중단 배포 구현하기
개요기존의 1 machine = 1 WAS Instance 구조로소스 패치시 해당 머신을 서비스에 사용하지 못하던 부분을 해소하고자동 배포를 구현하기 위해 고안된 구조입니다. In the before as 1 machine = 1 WAS Instance stru
cusmaker.tistory.com
(블로그에 올렸던건 나중에 일)
무중단 배포는 배포를 언제든 가능하게 해주는데,
이를 위해서는 운영에 나갈 코드들의 엄격한 형상 관리가 필요하다고 판단했습니다.
무중단 배포를 위해 도입된 코드리뷰 시스템입니다.
기존에 회의를 통해 하던 코드리뷰를 온라인에서 진행하기 시작하였습니다.
하지만 그동안 제대로 해본적이 없던 코드리뷰는 어설펐고
개발할 시간도 모자란데 이걸 언제하고 있냐는 분위기를 설득시키기에는 현실적 장벽이 존재했습니다.
그래도 뒤에서 나올 MSA를 위해선 꼭 필요할거라 생각했습니다.
그 다음은 로그개선입니다.
많아진 서버와 로그정보들은 각각의 서버에 남기고 있어 추적이 쉽지 않았습니다.
먼저 서버에 접근하기 전에는 서버에 어떤 문제가 남고 있는지 확인이 어려웠습니다.
https://cusmaker.tistory.com/252
[graylog2] 적용
증가된 서버로 인해 분산된 로그를 한눈에 보고자 도입한 GrayLog2여러 후보중 가장 큰 이유는 오픈소스이고, 최근에 업데이트가 활발했기때문에 다양한 환경에 추가할 수 있도록 라이브러리가
cusmaker.tistory.com
그래서 도입하게된 Graylog2 (이것도 잘 안씁니다. ELK 서드파티라 보시면됩니다)
그동안에는 참 미련하게도 문제가 생기면 해당 서버에 접근해서 하나하나 로그를 확인하곤 했습니다.
그 외에도 부가적인 기능들이 많아 다용도로 활용했던게 기억납니다.
자세한 내용은 해당 블로그글에 있으니 생략하겠습니다.
데이터 추출 요청도 많아졌는데, 이부분도 많은 시간을 잡아먹던 업무중 하나였습니다.
그래도 생소한 게임 업계 용어들을 공부해가며(지금 보면 또 게임에만 국한되지는 않네요)
DAU, MAU, MCCU, PU, RU, CU, ARPPU ...
- DAU (Daily Active Users) : 일일 활성 사용자 수
- MAU (Monthly Active Users) : 월간 활성 사용자 수
- MCCU (Max Concurrent Users) : 최대 동시 접속자 수
- PU (Paying Users) : 지불 고객 수
- RU (Retention Rate of Users) : 유저 유지율
- CU (Charge Users) : 충전 유저
- ARPPU (Average Revenue Per Paying User) : 평균 지불 고객 당 수익
이러한 통계 쿼리 데이터들을 라이브 DB에 직접 데이터를 뽑을때나 조회할때마다
잠재적인 DB 부하 리스크를 감수해야했습니다.
그래서 일별 백업 db를 가지고 별도 통계서버를 구축하여
라이브서비스에 부하없이 데이터를 추출할 수 있는 서버를 구축하였습니다.
덕분에 BI(Business Intelligence)에서 무거운 통계등을 눈치 안주고 마음껏 조회할 수 있게 되었습니다.
게임업계에서 Business Intelligence (BI) 백오피스란, 게임 회사에서 운영하는 게임 데이터를 수집, 분석하여 게임 서비스를 최적화하고, 게임의 성과를 향상시키는데 활용하는 플랫폼이나 시스템을 말합니다.
BI 백오피스는 게임 데이터를 수집하고 분석하는 역할을 합니다. 이를 통해, 게임 데이터의 트렌드, 유저 동향, 아이템 판매량 등의 정보를 수집할 수 있습니다. 이 데이터를 바탕으로 게임 서비스를 최적화하고, 유저 경험을 향상시키는 다양한 시도를 할 수 있습니다.
또한, BI 백오피스는 게임 서비스의 수익과 관련된 정보도 제공합니다. 게임 서비스의 매출과 수익을 추적하고, 마케팅 효율성 등의 데이터를 분석하여, 비즈니스 전략을 수립하는 데 도움을 줍니다.
BI 백오피스는 대부분의 게임 회사에서 필수적으로 도입하고 있는 시스템 중 하나입니다. 게임 업계에서는 빅데이터와 AI, 머신러닝 등의 기술을 활용하여, 게임 데이터를 보다 정확하게 수집하고 분석하는 기술적인 발전도 예상되고 있습니다.
다음 내용은 시도했지만 성공하지못했던
MSA, Microsoft Azure Cloud 전환, DB 샤딩, TDD, containerize
등에 대해 깊이 없이 다뤄보겠습니다.
감사합니다.
다음글 : https://cusmaker.tistory.com/266
'커리어' 카테고리의 다른 글
| [무작정 게임 퍼블리싱 플랫폼 구축기] 7. 모두를 위한 문서화 (0) | 2023.04.16 |
|---|---|
| [무작정 게임 퍼블리싱 플랫폼 구축기] 6. 못다이룬 TDD, MSA, cloud, docker, MSA ... (0) | 2023.04.13 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 4. 서버 터지기 싫으면 바꿔야해 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 3. 사이드 프로젝트도 틈틈히 .. (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 2. 개발만 하던 개발자가 운영을 한다면 (0) | 2023.04.08 |
