서버의 세계로 - 아름다움이 만드는 힘

캡슐리어 여러분, 안녕하세요.

EVE Online의 미래의 기반이 될 Quasar 이야기를 해보겠습니다. 2022년 팬페스트에서 처음 발표된 이후 다양한 주요 최신 기술 도입의 바탕이 되었습니다.

EVE Evolved 계획에 따라 세트 이론, 그래프 이론, 컬러 이론을 도입해 진행되었습니다. 이제 캡슐리어가 제작하는 함선 SKIN에 집중하려 합니다. SKINR 시스템은 그저 화려한 SKIN 편집 도구나 그림자 표현 생성기가 아니기 때문이죠! SKINR 시스템은 미래의 서버 성능을 확인할 수 있는 핵심 도구입니다. 지금부터 어떤 기술적 발전이 이뤄졌는지 살펴보겠습니다. 마음을 단단히 먹고 자세히 알아보죠.

넷코드 및 틱 레이트

멀티플레이어 게임을 개발하며 가장 흔히 마주하는 난점은 네트워크 구조입니다. 일반적으로 '넷코드'라고 부릅니다. CCP는 모든 캡슐리어 여러분이 안정적인 게임을 진행할 수 있고 부정행위도 방지하려 노력하고 있습니다. 각종 정보가 게임 클라이언트에 전달되는 방식이 전반적인 성능과 재미에 영향을 미치는 것이죠. 핵심은 틱 레이트였습니다. 게임 서버의 정보가 클라이언트에 업데이트되는 주기를 의미합니다.

틱 레이트는 게임 엔진에 따라 다르게 구현됩니다. 언리얼 엔진을 예로 들어보면 연관성 필터링을 중요하게 여깁니다. 클라이언트에 가장 중요한 정보만 업데이트하는 것이죠. 반면에 소스 엔진은 입력 예측을 중요하게 여깁니다. 정보 수정 횟수를 제한해 게임이 원활하게 진행하게 조정하는 것이죠.

접근 방식이 다르지만 틱 레이트가 네트워크 성능에 미치는 영향은 같습니다. 대부분의 게임은 접속하는 플레이어의 수에 따라 틱 레이트를 20Hz에서 120Hz 사이로 조정합니다. 즉, 1초에 20회에서 120회 가량 클라이언트를 업데이트한다는 뜻입니다. 예를 들어 60Hz 틱 레이트는 서버가 1초에 클라이언트를 60회 업데이트해야 하므로 16.6 밀리초마다 업데이트 정보를 클라이언트로 보내야 합니다. 또한 같은 시간에 다른 플레이어들이 같은 정보를 받을 수 있는 시간적 여유도 확보해야 합니다. 전송 지연이 일어나지 않는 마법 같은 인터넷 연결이 가능해 클라이언트에 서버 정보가 즉시 전달된다고 가정하면 60Hz 서버의 작동 방식은 다음과 같습니다.

60Hz 서버 틱 2회

입력 예측 및 움직임 보간 기술은 전송 지연이 없는 가상 인터넷을 상정하지 않아도 실시간 상호 작용과 비슷하게 보이는 현상을 만들 수 있습니다. 그러나 틱 레이트가 떨어지면 전송 지연을 체감할 수 있게 됩니다. 전송 지연은 언제나 좋은 현상이 아니죠. 그렇다면 왜 낮은 틱 레이트를 선호하는 것일까요?

EVE Online은 56k 모뎀 시절에 태어났습니다. 대규모 우주 전쟁을 한정된 인터넷 대역폭으로 전송해야 하기 때문에 서버 틱 레이트를 1초에 1회로 맞췄습니다.

또한 1Hz 틱 레이트 물리적 시뮬레이션 결과 클라이언트로 업데이트를 전송하는 횟수를 획기적으로 줄일 수 있었죠.

서버와 클라이언트 상호 작용 요소 중 물리적 영향을 받지 않는 다른 요소는 Python hamster로 빠르게 처리할 수 있습니다. 따라서 틱 직전에 전송될 내용이 발생하면 매우 빠르게 반응하지만 틱 직후에 발생하면 클라이언트에 적용될 때까지 1초 이상 걸리는 것처럼 느껴질 수 있습니다. 이론적으로 정확히 1초 간격으로 키를 하나씩 누르면 서버와 원활하게 동기화될 수 있습니다. 그러나 정신 건강을 고려하면 '점프'를 1초에 30번씩 클릭하는 것이 적절할 수 있죠.

작년 Tranquility 서버를 전반적으로 살펴보면, 1초에 발생하는 업데이트의 수는 뉴에덴에 접속한 전체 캡슐리어의 수와 비례합니다. 평균적으로 1초에 0.7번 업데이트를 실행합니다. 이는 EVE Online가 얼마나 효율적으로 필요한 정보를 업데이트하는지 보여주는 수치죠.

물론 실제 업데이트 횟수는 상황에 따라 다릅니다. 0.7이라는 수치는 평균일 뿐이죠. 함선 전투로 발생한 정보가 업데이트 제한 횟수를 초과하면 타임 딜레이(TiDi)가 발생합니다. 타임 딜레이의 정확한 개념을 알아보고 싶다면 타임 딜레이 해설 기사를 참고하세요.

SKIN은 어떻게 적용되는가?

EVE Online의 외형 대부분은 EVE의 틱 레이트라고 할 수 있는 시뮬레이션 프레임에서 처리됩니다. SKINR 시스템이 도입되기 전에 SKIN을 교체하면 해당 정보가 시뮬레이션 프레임에 전송되고 이후 해당 정보를 받아야 하는 클라이언트로 전송되었습니다. 따라서 SKIN 변경 업데이트는 1초에 1회만 이뤄졌습니다. 시뮬레이션 프레임의 전송 횟수가 1초에 1회로 제한되기 때문에 UI 및 네트워크 요청 횟수 제한이 없거나 1초에 SKIN을 자주 교체하더라도 업데이트는 1초에 1회만 이뤄지는 것입니다.

남은 문제: 팬아웃 - 마지막 문제입니다. 정말이에요.

함선의 SKIN을 교체하면 업데이트 정보가 여러 지점으로 전송됩니다. 이렇게 여러 지점으로 정보를 전송하는 것을 '팬아웃'이라고 표현합니다. 그렇다면 정보는 어디로 전송되어야 할까요? 주변에 함선이 수백 대가 있으면 어떨까요? '주변' 이라는 단어의 정확한 의미는 무엇일까요? 함선 수백 대라는 것은 무엇을 말할까요?

시뮬레이션 프레임은 같은 버블에 있는 함선들만 한 번에 처리해 팬아웃 문제를 해결합니다. 버블은 일반적으로 그리드라고 부르는 것으로 워프 디스럽터 버블과 전혀 다릅니다. 이때, 시뮬레이션 프레임이 처리해야 할 데이터가 커지면 해당 성계를 시뮬레이션하는 서버에 더 많은 직렬화 및 팬아웃 절차가 발생합니다. 이전까지 Quasar는 함선이 있는 성계 정보만 추적했지만 SKINR 시스템이 실시간으로 작동하면서 함선이 버블과 버블 사이로 이동하는 경로까지 추적하게 되었습니다.

결코 작은 문제가 아니었죠. EVE Online의 핵심 시뮬레이션 엔진을 수정해야 Quasar가 함선의 이동 정보를 확인할 수 있었기 때문입니다. 그러나 결과는 놀라웠습니다! 단순한 성계 간 이동과 비교하면 처리할 수 있는 데이터의 양이 27배나 증가한 것입니다.

성계 간 이동과 버블 간 이동을 시뮬레이션하여 비교한 자료입니다. 단, 워프는 단순히 A 지점에서 B 지점으로 이동하는 것이 아니라 여러 버블을 거쳐 이동하는 것입니다.

이 결과는 팬아웃 문제를 고려하지 않고 단순히 내부 트래픽 전송만 측정한 것입니다!

팬아웃 문제 해결

이제 '주변에 함선 수백 대가 있는 함선이 SKIN을 변경'했을 때로 돌아가보죠. Quasar는 모든 버블의 함선을 추적합니다. 따라서 '주변' 이라는 의미는 모든 버블이며 버블 안에 모든 캡슐리어의 클라이언트에 정보를 업데이트해야 하죠. 이때 Quasar는 다음 시뮬레이션 프레임 업데이트를 기다리지 않고 즉시 버블에 포함된 캡슐리어의 클라이언트에 SKIN 변경 정보를 업데이트합니다.

이러한 절차는 강력한 NATS 메시지 기술로 구현했습니다. 여러 EVE 클라이언트에 1초에 10,000번 메시지를 전송할 수 있죠. 우주 전체의 상태를 직렬화하고 SKIN 업데이트 정보를 1회 전송합니다. 전송한 업데이트 정보는 SKIN을 변경한 함선 주변에 있는 캡슐리어의 클라이언트에 팬아웃됩니다. 다음에 시뮬레이션 프레임이 작동할 때까지 1Hz를 기다릴 필요가 없죠.

다음 SKINR 테스트에서 어떻게 작용하는지 확인할 수 있습니다.

새로운 의문: 그렇다면 Quasar 서버가 함선 위치를 추적해 주변 함선에 함선 외형 변경 정보를 보내는 것이 왜 중요할까요? 그것은 이 기능으로 EVE Online의 주 시뮬레이션 엔진에서 외형 관련 기능을 완전히 독립시킬 수 있기 때문입니다.

또한 직렬화 및 팬아웃이 필요한 다른 외형 관련 효과를 더 넓은 범위에서 다룰 수 있습니다. 그렇다면 Quasar는 외형 관련 작업 이외에 어떤 일을 할 수 있을까요?

한계를 너머

하지만 정말 흥미로운 결과는 과부하 테스트에서 관찰할 수 있었죠. 같은 버블에 있는 500명의 플레이어가 동시에 SKIN을 교체하는 테스트를 진행한 것이죠. 그리고 1초에 약 45,000개의 업데이트 정보가 발생했습니다!

테스트에 참여해주신 모든 분께 감사드립니다. 캡슐리어 여러분이 EVE Online에 얼마나 기여하는지 명확하게 표현하기 어려울 때도 있지만 이번 테스트는 여러분의 참여가 얼마나 소중한지 확실하게 보여준 일이었습니다.

그렇다면 위에서 보여드린 혼란스러운 예시로 돌아가보죠. 대체 어떤 결과가 나온 걸까요?

이전 통계를 보면 Tranquility 서버 전체에서 1초에 약 30,000개의 업데이트 정보가 처리됩니다. 정보는 대체로 1Hz로 처리됩니다. 즉, 1초에 1회 업데이트 되는 것이죠. 그러나 SKINR 테스트 결과를 보면 캡슐리어 500명 기준으로 1초에 45,000개의 업데이트 정보가 처리됩니다. 이는 Quasar가 업데이트 정보를 90Hz로 처리한다는 의미입니다.

Quasar가 캡슐리어 노드를 세 개만 사용하는 소규모 테스트 서버에서 500명 기준으로 90Hz로 업데이트 정보를 처리할 수 있다면 230개의 노드를 사용하고 30,000명 이상의 캡슐리어가 활동하는 Tranquility 서버에서는 어떨까요?

시뮬레이션 프레임이 같은 패러다임을 따른다면 어떻게 될까요?

시뮬레이션 프레임이 업데이트 정보를 보낼 때 1초를 대기할 필요가 없다면 어떻게 될까요?

타임 딜레이에는 어떤 영향을 미칠까요? 실시간으로 전투를 진행할 수 있다면 전략의 유행이 달라질까요?

네트워크 업데이트 속도가 90배로 향상된다면 뉴에덴의 캡슐리어 여러분에게 어떤 일이 벌어질까요?

이러한 질문의 답이 EVE Online의 진화를 결정하게 될 것입니다. 답이 궁금하다면 2월 20일 15:00 UTC에 CCP TV에서 알아보세요.

o7