[2019] 200만 동접 게임을 위한 MySQL 샤딩

[@강정식-l4e]

감사합니다

[@jay-fk6pl]

너무재밌네요ㅠㅠ 귀한 내용 발표 감사합니다!

[@greg-lee]

내용 너무 좋네요. 소중한 경험을 공유해주셔서 감사합니다.

[@mancheolj]

좋게 봐주셔서 감사합니다. 조금이라도 도움이 될 수 있으면 좋겠습니다~

[@yowon8986]

너무 유익하네요 감사합니다.

[@sumiryu2698]

한국 MySQL 사용자그룹 리더 류수미예요. 내용이 너무 좋아서 그룹에 공유했습니다. 혹시 싫으시거나 공유에 문제가 있으시면 내리도록 하겠습니다. 내용이 너무 좋더라구요. 사실 많은 분들께 도움이 될 듯해요.

[@mancheolj]

내용이 좋다고 해주시니 너무 감사합니다. 공유는 전혀 문제가 되지 않구요. 오히려 부족한 내용이라 좀 부끄럽지만 다른 분들께 조금이라도 도움이 될 수 있으면 좋겠습니다.

[@HntrDoyo]

와.. 정말 아름답습니다!!
소중한 경험을 공유해주셔서 감사합니다!!

[@handfootshrink]

커넥션수가 드라마틱하게 관리되네요
혹시 대기하는 queue 가 발생하지는 않나요?

[@PTK-qt5vq]

Game server 마다 샤드 갯수 만큼의 커넥션풀(to proxysql)을 유지해야 하는거죠?

[@c_8285]

파이널 아키텍처 부분이 좋네요 ㅎㅎ DB 여러 개의 프록시를 만든 후에 프록시를 타서 실제 DB를 찾을 때, 또 다른 DB (RouteDB)를 쓰지 않고 함수로 실제 DB를 찾을 수 있게 하자는 그 취지가 좋은 듯 합니다.

[@나뚜루-z6n]

게임서버와 게임DB 1:1 구조가 왜 말이 안되는지 모르겠네요.
1:1 구조를 잡는다면 서버별 동접에 따라서 서버별 scale up - down 처리가 유연하고
커넥션 문제도 해결되고 동접이 급격히 줄어든 경우 하나의 인스턴스에 몰아넣어도 되는데요.
1:1구조가 말이안되는 예시라도 있었으면 좋았을것 같습니다 ^^

[@micoding]

저만 소리가 안나오나요?

[@NHNCloud]

일부 환경에서 소리가 나오지 않는 현상을 확인했습니다. 다른 기기에서 다시 시도해보시기 바랍니다. 감사합니다. :)

[@sehyungkim6985]

굳이 이렇게까지 할 필요가 없습니다..
MySql 호환인 aws aurora는 컨넥션이 최대 7000개까지 사용 가능하거든요;;;

[@구독자1명미만만들기]

Aurora를 게임서버용으로 사용하려면 MM Cluster를 도입해야 하지않을까요? MM Cluster사용시 엔드포인트 기능이 지원되지 않아 샤딩을 직접 구현해야하는걸로 알고 있습니다. 게다가 AWS는 스토리지 비용이 워낙 고가이고 Aurora는 MYSQL RDS 보다 30%이상 서비스비용이 더 붙기 때문에 쉽사리 도입하기는 어려울 것 같다는 생각입니다.

[@sehyungkim6985]

@@구독자1명미만만들기
위 발표자료에서 해결하려고 하는 문제는 db 컨넥션 갯수 입니다.
1. 그 문제는 aurora의 multi master node와 15개의 read replica 기능으로 컨넥션을 분산시켜 해결 가능해 보입니다.
2. 비용 30% 증가는 정말 쌉니다. 300%도 아니고 겨우 30% 라니요. 발표자께서 연구하고 개발한 시간과 인건비, 그리고 앞으로 발생할 유지보수 비용까지 생각한다면 말이죠.

[@데미쑤]

@@sehyungkim6985 aurora multi master는 MySQL 5.6에서 지원이 끝났습니다. 이제 못쓴다는 거죠. MySQL MM은 AWS도 포기한 아키입니다. write 분산 시키려면 샤딩 해야 합니다.