전공자는 아니지만 블리자드같은 큰회사에서 이런 방법론들을 모를까요 모르면 더큰문제일듯 저희가 예상하는것말고 다른문제가 있을수도있고 아무튼 지들 내부문제는 지들이더 잘알겠죠 문제는 ㅈ도 소통을 안함…게시글들이 난리가난 상황에 이러저러하다 하루가 다르게 공지를써서 24시간 지들 똥싸는것까지 알려줘도 모자를판에 대기열후에도 왜 또 대기해야하는지 왜 튕기는구간이 발생하는지 혹은 스위치는 왜 패치가느린지(검수과정에서 스위치는 조금더걸립니다 이런뻔한글이라도) 무슨 고객센터가 활성화되있는것고아니고 여기있는 글들이나 읽을려나요 그냥 개답답함
무식한대 아는척해서 내가 한자 적는다… 니말대로라면 구글서버는 폭발했냐… 말이되는 개소리를 해야지… 개소리를 말처럼 적으면 그게 맞는게 되냐…
블자 애들이 이걸 몰라서 '못’하는거라고 생각하시는지?
아는데 '안’하는거예요…
샤딩이니 세션클러스터링이니 모를 애들이 아니잖수?
그냥 최소한의 투자로 최대한의 이익을 빨아먹으려다 보니 이런 사태가 생긴거임…
글 적으신 거 보니 IT바닥좀 아시는 분인가본데…
얘들이 온프레미스 서버에 포팅 한 것도 아닐거고 클라우드에 배포했을텐데…
스케일-아웃을 제대로 안걸어 놓은거예요…그것도 ‘일부러’
그렇지 않고서야 클릭 몇 번으로 서버가 병렬로 수천대씩 늘어나는 세상에 이런 말도 안되는 대기열을 타는 일은 없겠죠?
그냥 유저들을 농락하고 있는거예요…
20년차 TA가 한 마디 적습니다.
좋아요 3개
좋아 주방 작은 것도 이해하고 홀이 작은 것도 이해한다 이거야
그런데 번호표 받고 기다려서 들어갔더니 몇분 만에 내 쫓는건 아니지
무슨 욕쟁이 할머니 해장국집도 아니고…개발자들아…
좋아요 2개
한10분당 1개방 생성되면 어떨까요?
음… TA 20년차와 서버개발이 어떤 관계가 있는지 잘모르겠습니다만.
위에 작성자가 한 말이 어떤 의미인지 이해를 하실만도 한데 안타깝습니다.
문제는 단일 DB에 있는데 단순 가용 서버 리소스만 늘린다고 비용대비 문제가 해결될까요?
정답은 아닙니다. 훌륭한 서버는 소프트웨어와 하드웨어의 퍼포먼스가 최적화 되어야 나오는 겁니다.
초반에는 이해가 됐으나 중반 이후로 전문용어가 나오기 시작하면서 이해가 어려워졌음…
하지만 결론은 블리자드 siba…
DL로 팔았으면 접속량 예측은 충분히 가능했을텐데 그에 대한 대비를 전혀 하지 않았음
손 안대고 코푸려는 격이군요…서버팅기면 또 대기 타야 하는 아재들은 어쩌라고 ㅡ,.ㅡ
ㄴ빈병 님.
지금의 현상은 단순히 개발로 해결 될 일이 아니라는 겁니다.
개발을 아무리 기깔나게 해봤자 서버의 리소스가 버텨주질 못하면 말짱 꽝이라는 거죠.
코드 최적화라는 것도 서버의 리소스가 적당할 때 의미가 있는 겁니다.
그리고 블자에서 공지한 내용을 잘 보세요.
DB는 각 지역 섭에도 있고, 지역 섭의 DB를 한 군데 모으는 중앙DB가 있어요.
유저는 중앙DB에 붙는게 아니라 각 지역DB에 붙는 거고요.
현재의 현상은 단순히 DB 세션 수의 문제가 아녜요.
이런 논쟁을 왜 유저랑 해야 하는지 잘 모르겠지만,
결국은 서버 리소스와 개발 최적화가 같이 되어야 한다는 겁니다.
지금 블자는 둘 다 안하고 있는 상태에서 대기열이라는 말도 안되는 방법으로 유저들을 기만하면서 리소스를 늘리지 않고 있다는 것이 문제고요.
개발 최적화가 빠를까요…리소스 확장이 빠를까요?
지금처럼 서버가 유저 수를 못 버틸 때는 일단 서버를 늘려서 서버 대수로라도 유저들을 받아 줄 수 있게 해놓고,
그 다음에 개발 최적화를 하는겁니다.
서버 스케일-다운은 그 이후에 해도 되고요.
이것이 스케일-아웃/업/다운이 용이한 클라우드 플랫폼을 쓰는 이유고요.
유저들의 시간을 볼모로 리소스도 안늘리고 최적화도 안하는 것이 아니라요.
좋아요 2개
블자 서버관리자는 레베루가 하급이다?
대충 해결책 요약하면 db서버 증설및 분산처리 메모리db를 이용한 디스크 io 최소화 정도로 정리되는건가…
좋아요 1개
ㄴㄴ 그냥 서버 개발자가 일하기 싫어한다 정도로 요약 되지 않을까…
우리끼리 토론해 봤자 큰 의미는 없는데요.
게임서버만 스케일 아웃해서 10000000대로 늘려도 DB가 못버텨서 터지는겁니다. 공지사항 내용만 보자면요.
디아2 레저렉션 DB는 클러스터링이나 샤딩이 고려되지 않은
고가용 서비스 경험이 없는 개발사에서나 만들법한 구형 서버 구조라 더 어이가 없고요. 글로벌DB 동기화도 백그라운드 처리가 아닌 서버 로직에 동기 코드로 물려 있는 100% 장애 발생 조건입니다.
유럽, 아메리카, 아시아 이렇게 3개의 DB
그리고 각 리전 간 동기화를 위한 글로벌DB 1개.
이런구성으로 보이는데요.
아시아1, 아시아2, 아시아3 이렇게 DB셋을 나누더라도 단일 글로벌DB 문제는 그대로 남게되어
글로벌DB가 스케일아웃 분산처리가 가능하도록 조치가 되지 않으면 계속 욕을 얻어 먹을 것 같네요.
제가 생각한 것을 대부분 설명해주신 글입니다.
특히 1,2번 항목 부분에서 크게 공감합니다.
제 사견을 덧붙히자면, 현재 친구가 만든 방에 입장하지 못하는 현상이 너무나 자주 발생합니다.
정확한 원인은 모르겠으나, 추측으로는 방에 대한 정보를 가진 서버처리에 어떤 오류가 있는 것으로 생각됩니다. 이 문제 해결이 시급합니다.
추가적으로 아시아에서 한국서버를 분리해 주길 바랍니다.
한국 사용자 수를 보고 한국서버 1,2,3… 형태로 늘려나가는 것도 좋다고 봅니다.