듀랑고 서버 접속 불가- 왜 듀랑고는 4대명검을 들고야 마는가?

Posted on
  • 본 글은 외부에서 바라본 듀랑고의 런칭 후 점검/접속 불가 이슈를 개인적인 경험에 비추어 살펴보고/외부 대응에 대한 아쉬움을 정리한 글입니다.
  • 듀랑고 서비스 정상화를 진심으로 기원합니다.

오랫동안 기대했던 듀랑고가 결국은 오픈 2시간만에 긴급 점검이후, 대다수의 유저들은 접속이 어려운 상황에 있습니다.

저기요.. 1시간 대기는 은행에서도 안해요..

왜 오랜 기간 동안 개발했음에도, 듀랑고는 접속 불가라는 사태를 면치 못했을까요?이은석 디렉터의 해명을 하나씩 살펴보면서 이유를 찾아가 봅시다.

  1. 개발자 노트를 통해 이은석 PD가 직접 커뮤니케이션 – GOOD!
    • 공지사항 링크
    • 어떤 내부 사항이라도 런칭 초기에는 많은 유저들의 관심이 몰려있기 때문에 중요 이슈에 PD가 직접 코멘트하는 것은 빠른 이슈해결의 의지를 외부에 전달할 수 있습니다.
    • 다만, 단기간에 해결할 수 없는 게임의 구조적 이슈와 공지 내용에 대한 아쉬움이 있네요.
  2. 이은석 디렉터가 언급한 서버점검 이슈들 – 아쉽!
    • 기술적으로 해당 이슈들을 발견하고, 기술적으로 가능한 조치를 취한 부분은 맞습니다.
    • 다만, <대기표 시스템>,<인구밀도>에 대한 언급은 게임이 헤비 트래픽에 대응할 준비가 되어 있지 않다는 스스로의 언급 밖에는 되지 않습니다.
    • <DB 성능>에 대한 언급도 DB 스키마 설계/유저 트래픽에 대한 대응이 부족한 부분을 인정한 것 밖에는 되지 않습니다.
    • 거기에 유저 대응/ 커뮤니케이션에 크리티컬하게 아쉬운 부분들이 있습니다.
언제나 예측을 뛰어넘는 그들- 유저

언제나 예측을 뛰어넘는 그들 – 유저!

기나긴 개발기간 CBT를 포함한 다양한 테스트를 통해 퍼블리셔는 최대 트래픽을 예측하고 그에 따라 서버 스펙을 산정합니다. 그럼에도 불구하고 접속불가 현상이 일어나는 이유는 딱 하나 뿐 입니다. 그 예측을 뛰어넘는 접속이 발생했을 뿐입니다. 그 밖에 다른 이유가 없어요. 변명을 할 필요도 없습니다. 유저/개발자/서비스 담당자 모두 알고 있는 이야기 입니다.

그렇다면, 대안은 없을까요? 유저들이 준비한 서버보다 초과 접속할때 마다, 서버를 바로바로 증설하면 되요. 근데 그게 물리적 작업은 어렵기 때문에 가상서버를 증설하는 기술적 준비를 고려했을 꺼에요. 듀랑고도 분명히 가상서버를 고려해서 서버 설계 / 개발 진행했을 것 입니다. 다만, 이런 트래픽 폭주에 대한 서버 증설 시나리오/준비가 부족했습니다. 유저폭증 시점에서 결국 추가 서버군(그것도 공지에서 말했듯이 미리 준비된 서버) 추가에 상당한 시간이 걸렸으니까요.

자세한 서버 가상화 개념은 이미지 링크를 참조

 

첫번째 이슈, 인구밀도 조절 장치 

공지원문

첫 번째 문제는 <인구 밀도 조절 장치>에서 발견되었습니다.
야생의 땅: 듀랑고는 여러 섬을 오가면서 탐험과 개척을 즐기는 게임입니다. 그런 만큼 유저분들이 많이 접속할 수록 더 많은 섬이 필요하게 되고, 새로 접속한 유저가 쾌적한 플레이가 가능한 섬에서 플레이할 수 있도록, 섬을 스마트하게 배정하거나 필요시 새 섬을 생성하는 장치를 탑재했습니다.
이 장치에서는 어떤 섬에 몇 명의 사람이 있는지 카운트하는 것과, 쾌적한 인구 밀도가 유지되는 섬이 어디에 있는지 확인하기 위한 “데이터베이스 색인”를 만들고 유지하는 것이 관건입니다.
어제 발견된 문제는 동시에 너무 많은 사람이 가입할 경우, 다른 섬보다 수용인구가 작게 만들어진 앙코라 섬과 안전가옥 섬들이 급속도로 생겨나면서, 해당 색인을 유지하는 데이터베이스 노드에 과부하가 걸리는 것이었습니다. 이 문제는 해외 베타 테스트 기간에는 유저의 유입 속도가 충분히 빠르지 않아서 드러나지 않았고, 내부의 과부하 테스트에서도 가입 속도가 빠를 때의 시나리오에 포함되지 않아서 드러나지 않았습니다.
이 문제로 오픈 초기 많은 분들이 캐릭터 생성이 불가능하거나, 뗏목을 완성했으나 떠나지지 않거나, 열기구를 타도 출발되지 않는 문제를 겪으셨을 것입니다.
이 문제는 해당 색인의 성능 부하를 줄이고 색인을 담당하는 데이터베이스를 늘려서 해결할 수 있었습니다.

듀랑고에 핵심이 되는 부분이에요 인구가 늘어날 수록 섬을 배정하고 신규 섬을 생성해야지만 유저들이 게임을 할 수 있겠죠. 색인의 요소를 최적화 한다든지 대안이 필요했던 부분이에요. 가장 중요한 부분이기 때문에 여러가지 상황에 대비할 수 있도록 2,3안이 있어야 하는 부분이라고 생각해요.

  • 공지에도 나와 있듯이 해당 색인의 성능 부하를 줄이고 색인 담당의 DB를 늘려서 해결했다고 나오네요.- 그로인한 추가적인 마이너 이슈들이 발생하지만요

두번째 이슈, 대기표 시스템 문제

공지원문

두 번째 문제는 <대기표 시스템>의 문제였습니다.
듀랑고의 대기표 시스템은 많은 유저분들이 몰릴 때 조금이라도 쾌적한 경험을 드릴 수 있도록, 예상 대기 시간을 자세히 계산할 수 있는 구조로 만들기 위해 노력했습니다. 그러나 앞서의 문제로 데이터베이스가 아직 충분한 동시 접속자를 감당하기 어려운 상황이라 서버의 수용량을 계획보다 낮춰 놓자, 대기하는 분들이 예상보다 훨씬 많아지면서 대기표 시스템 자체에 부하가 걸리면서 문제가 발생하고 말았습니다.
이후 대기표 시스템이 사용하는 데이터베이스를 확장하고 부하를 줄일 수 있는 다양한 방법을 강구했으나 이 문제가 계속 발생했고, 대기열에 들어가는 대신에 이상한 오류 메시지를 보고 계신 분들이 많아지는 결과가 생기게 되었습니다.
대기표 시스템의 문제를 근본적으로 해결하기 위해서는 시간이 조금 더 필요하기에, 그 전까지는 이 시스템에 부하를 줄이기 위해 예상 대기 시간을 정확하게 계산하는 기능을 생략했습니다. 그로 인해 대기 시간 산정이 어려워졌지만 당분간 양해를 부탁 드립니다.

여러모로 아쉬운 부분이 많은 대응이였어요. 대기표는 유저들에게는 반드시 필요한 기능이에요. 내가 얼마나 기다려야하는지 알아야만, 기다리는 스트레스도 최소화 할 수 있겠죠. 트래픽이 몰려서 담당 개발자가 패닉이 오면 가장 쉽게 대응할 수 있는 부분이 대기표 시스템 disable이에요 로직을 최소화 하면 서버에 약간의 여유를 제공하니까요.

대기인원 10000 표기는 것은 정말 아쉬운 대응이에요. 원본 공지에는 기능을 생략했다고 하고, 표기는 10000명이로 해버리면, 유저들은 실제 만명 대기인원이 있는 건지, 혼란이 올거고, 계속 시도하면 결국 의미없는 숫자임을 알게 되고 이건 유저들의 분노를 키우는 것 밖에는 안되요. ‘현재 접속 시도가 많습니다. 대기시간 산정이 어렵습니다’ 라고 솔직히 노티하는 게 나은 대응으로 보여요. 공지사항과도 일치하구요.

만명 대기 공지 이건 아니지.. 공지랑도 다르고 유저 혼란만 가중시키는 거자나… 모바일이라 빌드 수정/업로드가 힘들다고 해도 다른 방안/대비가 있었어야지.. 차라리 텍스트가 안보이는게 나을듯..

세번째 이슈, 인구 밀도 문제

공지원문

세 번째 문제는 <인구 밀도> 문제입니다.
첫 번째 문제를 해결하기 위해 인구 밀도 조절 시스템을 급히 수정하는 과정에서 인구 밀도를 정확하게 예측하기 어려운 부분이 생기게 되었고, 많은 유저분들이 열기구를 타고 마을섬으로 진출하시면서 인구가 의도보다 과도하게 많은 마을섬과 불안정섬들이 출현하게 되었습니다. 해당 섬들은 저희가 생각한 한계 인구의 4배 이상의 유저분들이 진출해 계신 상황입니다.
듀랑고 게임 서버의 특성 상 한 곳에 많은 사람이 몰려 있으면 동시 접속 인원 대비 부하가 커지는 경향이 있습니다. 예상보다 훨씬 많은 사람이 한 곳에 몰린 지역이 생기면서 서버 전체적으로 지연 현상과 상호작용 장애, 지형이나 사유지 영역이 보이지 않는 등의 다양한 문제가 생겼습니다.
이 문제를 근본적으로 해결하기 위해서는 적절히 인구가 분산돼야 하지만, 이미 마을섬에 터를 잡으신 유저분들을 강제로 이주시킬 수는 없어서 어려움이 있습니다.
항구를 이용하여 다른 마을섬으로 이주할 수 있으므로, 붐비는 섬에 계시는 유저분들은 새로 생성되는 비교적 한적한 마을섬으로 이주하는 것을 고려해보시면 좋을 것입니다. 듀랑고에서는 이사의 편의성을 위해 사유지에 있는 가구류는 쉽고 빠르게 포장해 가방에 넣을 수 있게 했고, 새 섬에서 사유지를 선언하실 때도 이전 사유지 크기만큼 될 때까지는 티스톤 소비 없이 확장이 가능합니다.

3번째 문제인 인구 밀도 문제도 마찬가지에요. 결국 색인의 정보를 최소화 시켰으니, 색인 범위에 영향을 받는 밀도 조절 시스템이 같이 영향을 받은거라고 예상되요. 결과적으로는 한계치를 넘어선 인구를 가진 마을섬, 불안정섬 들이 출현하게 된거죠

NDC에서도 발표가 되었듯이 유저를 분산하기 위한 시스템으로서 섬이라는 컨셉은 현재도 아주 독특한 개념이였어요. 그러나 그것을 개발상으로 구현할 때, 인구 제한이라는 가장 기본적인 부분의 구현이 미숙했던거죠. DB 인덱싱을 통한 1차 필터링 외에도 전체섬에 대한 인구수 모니터링 통해, 강제 이주 혹은 모니터링이 필요했던 거죠. 해당 모니터링 프로시저를 비활성화 할 수 밖에 없는 상황일 수도 있겠네요.

DB 성능문제에 대한 코멘트는 결국,

  • 현재 상황에 대한 예측 실패
  • 개선의 여지가 있음에도 런칭 진행 (기 개발기간 대비)

에 대한 인정 부분으로 추가로 언급 드릴 내용은 없는 것 같아요.

글을 작성하는 중에도, 신규 서버가 계속 추가되고, 개발사/퍼블리셔에서 주말에도 계속 대응하시는 분들의 노고가 느껴집니다. 모쪼록 건강 챙기면서 일하시고, 화이팅 하시길 기원합니다!

유저분들은 조금만 인내심을 가져 주세요. 여러분들이 쉽게 생각하는 의사결정/개선을 위해서 실제로는 정말로 많은 고민과/책임이 따르는 일들이 내부에서 진행되고 있어요. 조금만 여유를 가지고 게임을 즐겨 주시길 바래봅니다.