2020. 1. 19. 18:18ㆍ참고
원래 게임 서버로 사용할 웹 서버 구성은 단순하게 계획했었다.
AWS 게임 서버 스케일링 + DB.
얼마나 단순한가. 인디가 뭔 호사를 누리겠다고 ㅋ
왜 한 것인가?
단순하게 구성했으면 개발 속도도 빠를 텐데.
바로 기술 경험에 대한 욕심 때문이다.
향후 확장성과 컨테이너 기반 서버 구성의 초석을 다지기 위해 결국 욕심부린 것이다.
그 대가로 피로와 철야 그리고 밤샘. -_ -
그 외 이사와 시한부 기업의 목줄 조이기는 덤. ㅋ
효과
도커 스웜 오케스트레이션 한계, 쿠버네티스를 통한 오케스트레이션 필요 인정.
컨테이너 기반 서버 관리의 편리성 체험. 앞으로 다른 서버 개발에도 영향 불가피.
위 이미지 설명
(1) 서버 모니터링을 위해 Prometheus, Grafana 사용.
MySQL 모니터링도 그냥 대시보드 연결하면 잘 될거라 생각했으나... 산산조각. 커스터마이징 필요. (안해)
(2) MySQL 리플리케이션 구성 (RW DB 분리)
정말 금방 될 거라 생각했습니다.
그러나.
MySQL 8.x 버전 전후로 유저 추가 및 로그인할 때 차이 발생. (구천 떠돌기)
https://ondemand.tistory.com/246
(3) 원래는 분리하여 3개의 도커 스택을 관리할 생각이었습니다.
mon : 모니터링 스택
mymon : DB 리플리케이션 스택
gmon : 게임 서버 스택...
그러나 swarm overlay 문제(자동 로드밸런싱)를 회피하기 어려워서 세션 유지형 게임에 부적합. ㅋ
회피 하려면 각 게임 서버 호스트에 IP 테이블 라우팅 기능을 막아야한다. -_ - 음?
(누군가 도커 스웜 ingress 네트웍을 분노의 탐구심으로 분석... RIP
https://ops.tips/blog/blocking-ingress-traffic-to-docker-swarm-worker-machines/)
휴... 그래서 로컬 컨테이너로 게임 서버 구성하고 scp로 매니저에서 코드 푸시하는 방식으로 배포. ㅋ
(4) 도커 컨테이너가 동작하는 (3) 게임 서버의 스냅샷을 이용하면 간단히 해결. 다만 코드 패치할 때 push 할 대상을 늘여주어야 한다. 도커 스웜 무한 사랑이 무너지는 순간. ㅠㅠ
ingress 네트웍 공유 기능이 막힌 네트웍 드라이버만 공식 제공 했어도 이렇게 무너지지는 않았을 것 같다. (구글의 마수)
세션 유지해야 하는 서버가 어디 한둘인가. 쩝.
여기서 더 한다면,
로그 빅데이터 분석 -> AI 강화 학습 -> 서비스 개발 -> 서비스 -> 로그 빅데이터 분석 ... 이건 게임 개발의 또다른 영역이기 때문에 옆으로 피해가자. ~_ ~
그렇게 무사히(?) 서버 구축이 끝나고 다시 개발에 들어갑니다. ㄱㄱ
(풀석)
이사도 해야하는데... 한 주만 추스르자. ㅋ