실버바인 대기열 서버 설계 리뷰데브캣스튜디오 강 성훈2019-04-26

누구세요?

• 강 성훈

• @senokay

• lifthrasiir

• https://mearie.org/

뭐 하세요?

• 데브캣스튜디오

• 〈마비노기 듀얼〉 라이브

• 카일루아 (NDC 2016/2017)

• 실버바인 서버 엔진 2 • 〈로드러너 원〉 • 〈마블 배틀라인〉 • 〈제이미와 제롬의 런웨이스토리〉 • 〈마비노기 모바일〉 (예정)

뭐 하세요?

• Rust 개발을 좀 했었지요

• IOCCC에서 입상한 적이 있고

• 오징어 IRC 네트워크도 아직 살아 있습니다…

• 아희아희를 만들었고요

• 리듬게임을 너무 많이 하고

대한민국 교통안전표지 일시정지(227), 위키미디어 공용

조선민주주의인민공화국 교통표지 섯, 위키미디어 공용

대기열을 어떻게 만드나요?

대기열이 죽으면 어떻게 되나요?

대기열을 더 잘 만들 수는 없을까요?

대기열을 왜 만드나요?

대기열을 왜 만드나요?

😀😃☺😎☺😁😎😁😎 😃😊😆🙂☺😄😁😀😁☺ 🙂😆🙂😄😊😆😍🙂😎😁😊

😃😍☺😁😊😃😁🙂☺😃😍😃 😍😆🙂☺😆😃😁😆😍 😎😊😊☺😎😍🙂😎😎

😎😊😃😄😊☺😊😀🙂 😃😊😎😃😍😊😎😁😃😊😊 😊😍😁😍😊😁😀😀😍😁

😀😄😀🙂😀😁😆☺😎😁🙂 😄😆😎☺😁😃😎😆😍 😀☺☺😍😃🙂😊😁😎😍

블레이드 서버, 위키미디어 공용

한 서버에 들어올 수 있는 동접 수에는 제한이 있습니다.당연히 동접을 늘리려면 서버를 늘려야 하죠.

😁😆😃😁😍😊😁😎😍😍🙂😎😁😍😁😃😊😎😁😎☺🙂☺☺😃 😃🙂😆🙂😊🙂😎☺😃😃🙂🙂☺😎☺😃☺😍😁😍😃😆☺😃😍 😃☺😆🙂😊☺🙂☺😁😆😍☺☺😍☺☺😆😊😆🙂😃😃😎😃😍

😆😁🙂😍🙂🙂😃😎😎😎☺☺😎🙂😁😆🙂😊😁😁🙂😊😃😆☺ 🙂🙂😊☺😃😆😊😎😁😁😃😎😁😃😎😊☺😎😍🙂☺😊😆😁😆 😃😆😍😃😊🙂😁☺😎🙂😍😍😆😆☺☺☺😎😃😁🙂😎🙂😎🙂

😎😊😃😄😊☺😊😀🙂 😃😊😎😃😍😊😎😁😃😊😊 😊😍😁😍😊😁😀😀😍😁

😀😄😀🙂😀😁😆☺😎😁🙂 😄😆😎☺😁😃😎😆😍 😀☺☺😍😃🙂😊😁😎😍

블레이드 서버, 위키미디어 공용

서버를 늘리는 데는 시간과 자원이 필요해요. 넘치는 사용자를 튕겨내는 것보다는 뭔가 알려 주는 게 좋겠지요?

옛날에는 서버를 사용자가 선택하게 할 수 있었어요.

🤔

일부 서버가 붐벼도 덜 붐비는 서버를 선택할 수 있었습니다.

옛날에는 서버를 사용자가 선택하게 할 수 있었어요.

🤔

모든 서버가 붐비면 그 사실을 시각적으로 알 수 있지요.

🤔

하지만 요즘 모바일 게임은 그렇지 않죠? 사용자가 보기에 하나의 서버만 있는 것처럼 동작해야 합니다.

🤔

심지어 필요하면 자기가 알아서 확장되기도 하고요.이런 환경에서 서버별 동접을 곧바로 보여 주기는 어렵습니다.

대기열은 다른 사용자가 빠지거나 서버가 충분히 확장되어서사용자가 접속할 수 있을 때까지 기다리게 합니다.

🤔

대기열의 한계

• 사용자가 대기열에서 천년만년 기다려 주지는 않는다!

• 대기열은 예측 불가능한 상황을 대비하는 임시 방편

• 런칭이나 주요 이벤트 직후

• 구조적으로 스케일링이 쉽지 않은 경우 (MMORPG 등)

• 사용자 패턴을 미리 예측 및 사전 대비할 수 있으면 필수는 아님

대기열을 어떻게 만드나요?

대기열의 목표

1. 가뜩이나 바쁜 게임 서버에 부하를 더 주지 않고서사용자들이 기다릴 수 있게 해야 한다

2. 게임 서버보다 훨씬 안정적이고 빨라야 한다

3. 오래 기다린 사람이 가급적이면 먼저 통과했으면 좋겠다

4. 기다리는 동안 사용자에게 유용한 정보를 줘야 한다(대기자 수, 예상 대기 시간)

대기열의 목표 → 바로 도출되는 결정

1. 가뜩이나 바쁜 게임 서버에 부하를 더 주지 않고서사용자들이 기다릴 수 있게 해야 한다→ 대기열을 담당하는 서버를 다른 네트워크에 따로 두자

2. 게임 서버보다 훨씬 안정적이고 빨라야 한다→ 대기열 서버를 게임 서버와 별도 코드로 독립시키자

3. 오래 기다린 사람이 가급적이면 먼저 통과했으면 좋겠다

4. 기다리는 동안 사용자에게 유용한 정보를 줘야 한다(대기자 수, 예상 대기 시간)

대기열의 목표 → 바로 도출되는 결정

1. 가뜩이나 바쁜 게임 서버에 부하를 더 주지 않고서사용자들이 기다릴 수 있게 해야 한다

2. 게임 서버보다 훨씬 안정적이고 빨라야 한다

3. 오래 기다린 사람이 가급적이면 먼저 통과했으면 좋겠다→ 대기 중인 사용자를 구분할 수 있어야 한다

4. 기다리는 동안 사용자에게 유용한 정보를 줘야 한다(대기자 수, 예상 대기 시간)→ 대기열 서버 전체가 공유하는 상태가 필요하다

1. 모든 대기자를 다 기록한다

2. 가장 오래된 대기자만 기록한다

미만의 순번을 발급

미만의 순번을 통과

상태 관리 전략

6riw 7J6Q6rOg🐱7J6

Q

🐰6ri

w

🐶6rO

g

🐱201

4

🐰201

5

🐶201

6

2014

2017

1. 모든 대기자를 다 기록한다

2. 가장 오래된 대기자만 기록한다

미만의 순번을 발급

미만의 순번을 통과

상태 관리 전략

6riw 7J6Q6rOg🐱7J6

Q

🐰6ri

w

🐶6rO

g

🐱201

4

🐰201

5

🐶201

6

2017

2015

1. 모든 대기자를 다 기록한다

2. 가장 오래된 대기자만 기록한다

미만의 순번을 발급

미만의 순번을 통과

상태 관리 전략

6riw 7J6Q6rOg🐱7J6

Q

🐰6ri

w

🐶6rO

g

🐸64y

A

64yA

🐱201

4

🐰201

5

🐶201

6

🐸201

7

2015

2018

1. 모든 대기자를 다 기록한다

2. 가장 오래된 대기자만 기록한다

미만의 순번을 발급

미만의 순번을 통과

상태 관리 전략

6riw 7J6Q🐱7J6

Q

🐰6ri

w

🐸64y

A

64yA

🐱201

4

🐰201

5

🐶201

6

🐸201

7

2015

2018

상태 관리 전략

1. 모든 대기자를 다 기록한다

• 이론적으로는 대기자 수를 정확히 추산할 수 있다

• 상태가 크고 동기화하기 어렵다

2. 가장 오래된 대기자만 기록한다

• 대기자 수에 허수가 끼어 있지만 뭐 어때?

• 상태는 발급된 순번과 진입 가능한 순번 단 두 가지 뿐

🤔

게임 서버

대기열 서버

클라이언트CDN

Redis

0. 서버 목록 확인

1. 대기표 발권 및 폴링3. 대기 종료 후 입장권 발권

2. 동접에 따라 피드백

4. 입장권 검증 및 로그인

• 대기표 발권

미만의 순번을 발급

미만의 순번을 통과

기본 동작

2017

2014

• 대기표 발권

• 사용자가 들어오면

미만의 순번을 발급

미만의 순번을 통과

기본 동작

🤔2017

2014

• 대기표 발권

• 사용자가 들어오면

• 사용자에게 순번을 발급해서 전달하고

미만의 순번을 발급

미만의 순번을 통과

기본 동작

🤔201

7

2014

• 대기표 발권

• 사용자가 들어오면

• 사용자에게 순번을 발급해서 전달하고

• 발급 순번을 증가

미만의 순번을 발급

미만의 순번을 통과

기본 동작

🤔201

7

2014

2018

• 대기표 폴링

미만의 순번을 발급

미만의 순번을 통과

기본 동작

🤔201

7

2014

2018

• 대기표 폴링

• 사용자가 발급받은 순번을 건네주면

미만의 순번을 발급

미만의 순번을 통과

기본 동작

🤔201

7

2014

2018

• 대기표 폴링

• 사용자가 발급받은 순번을 건네주면

• 통과 순번과 비교해서

미만의 순번을 발급

미만의 순번을 통과

기본 동작

🤔201

7

2014

2018

• 대기표 폴링

• 사용자가 발급받은 순번을 건네주면

• 통과 순번과 비교해서

• 아직 때가 되지 않으면 튕겨냄

미만의 순번을 발급

미만의 순번을 통과

기본 동작

🤔201

7

2014

2018

• 입장권 발권

• 사용자가 발급받은 순번을 건네주면

미만의 순번을 발급

미만의 순번을 통과

기본 동작

2029

2037

🤔201

7

• 입장권 발권

• 사용자가 발급받은 순번을 건네주면

• 통과 순번과 비교해서

미만의 순번을 발급

미만의 순번을 통과

기본 동작

2029

2037

🤔201

7

• 입장권 발권

• 사용자가 발급받은 순번을 건네주면

• 통과 순번과 비교해서

• 때가 되었으면 입장권을 건네주고 게임 서버에 접속시킴

미만의 순번을 발급

미만의 순번을 통과

기본 동작

2029

2037

게임 서버가 해야 할 일

1. 대기열 서버가 발급한 입장권을 잘 검증한다

2. 가능하면 순번이 이미 사용되었는지 확인한다

• 재사용 공격replay attack을 막기 위함

• 입장권의 만료 기한을 참고해서 효율적인 캐싱이 가능

3. 대기열 서버에게 동접에 맞춰 적절한 피드백을 보낸다

• 게임 서버가 대기열 서버에 통과 순번을 올려 달라 요청

게임 서버와 대기열 서버의 피드백

475/1000

미만의 순번을 발급

미만의 순번을 통과2014

2028

• 게임 서버가 대기열 서버에 통과 순번을 올려 달라 요청

게임 서버와 대기열 서버의 피드백

475/1000

미만의 순번을 발급

미만의 순번을 통과

2028

2029

+15

😃😁😎🙂😄🙂😄😀😁😎😆😀😄

• 게임 서버가 대기열 서버에 통과 순번을 올려 달라 요청

게임 서버와 대기열 서버의 피드백

475/1000

미만의 순번을 발급

미만의 순번을 통과

2028

2029

+15

• 게임 서버가 대기열 서버에 통과 순번을 올려 달라 요청

• 대기열 압력은 실제 진입 사용자 수와 다를 수 있다

• 얼마나 많이 올려야 할까?

게임 서버와 대기열 서버의 피드백

488/1000

미만의 순번을 발급

미만의 순번을 통과

2028

2029

+15

게임 서버와 대기열 서버의 피드백

• 너무 많이 올리면 서버가 터질 수 있다

• 한계 동접에 근접하면증가 폭을 줄여야 한다

• 여유가 있어도 로그인은 보통 비싸서무작정 사용자를 들일 수는 없다

• 너무 적게 올리면 사용자가 불평한다

동접

대기열 압력

한계 동접

동접

• 피드백 = min(남은 동접 × 피드백 비율, 시간당 허용 진입)

• 상수는 실험적으로 결정, 실시간 변경 가능

게임 서버와 대기열 서버의 피드백

동접

한계 동접 대기열 압력 (남은 동접에 비례)

피드백되는 대기열 압력 (최대 진입 속도 적용)

상태를 줄여라!

• HTTP는 대표적인 상태가 없는stateless 프로토콜

• 자연스럽게 상태가 없는 프로토콜을 만들게 됨

• 대기표를 매번 보냄 (≈ HTTP 쿠키)

• 암호학적 방법으로 인증authentication

• 상태를 관리할 책임을 클라이언트에게 떠넘김

상태를 줄여라!

• 최소한의 상태를 Redis로 관리

• 프로덕션에서는 AWS ElastiCache 사용

2000GET cutoff

GET serial

SET cutoff 2048

INCR serial 1

2019

OK

2020

대기열이 죽으면 어떻게 되나요?

대기열이 죽으면 어떻게 되냐고요?

• 큰일 납니다

© Stephen Goodwin (Wikimedia Commons), CC-by-sa 4.0이 슬라이드에 영감을 준 1.usagi.moe에 감사를 표합니다

대기열이 죽으면 어떻게 되냐고요?

• 저장소는 죽으면 대기열 전체가 멎음

• AWS도 만능이 아닙니다

• 횡분할 = 대기 순서와 진입 순서가 다름 = 😡

• 부하를 덜 주고 하드웨어 장애가 없길 바랄 수 밖에…

• 대기열이 죽었을 때 게임 서버가 다르게 행동하게 할 수는 있다

🤔클라이언트

CDN0. 서버 목록 확인

4’. 입장권 검증 없이 로그인 허용

0. 우리 대기열 안 씀.

게임 서버

4. 우리 대기열 안 썼었지?

🤔불타는 대기열 서버

클라이언트

Redwas

1’. 대기표 폴링 중 접속 장애 수차례

3’. 입장권 없이 로그인 시도4’. 입장권 검증 없이 로그인 허용

게임 서버

2’. 피드백 중 접속 장애

🤔대기열 서버

클라이언트

Redis

1. 대기표 발권 및 폴링

3. 입장권을 받아 로그인 시도4’. 입장권 검증 없이 로그인 허용

게임 서버

2’. 피드백 중 접속 장애

2. 서버측 장애

🤔대기열 서버

클라이언트

Redis

1’. 대기표 폴링 중 접속 장애 수차례

0. 클라이언트측 장애

3’. 입장권 없이 로그인 시도4. 입장권 검증 및 로그인

게임 서버

2. 동접에 따라 피드백

4. 난 접속 잘 되거든? 입장권 없으면 로그인 불가

5. 네트워크 연결이안 좋나 보네?

강건한 게임 서버가 추가적으로 해야 할 일

1. 대기열 서버가 발급한 입장권을 잘 검증한다

• 단, 대기열 서버가 죽은 것 같으면 그냥 보내 준다

2. 가능하면 순번이 이미 사용되었는지 확인한다

3. 대기열 서버에게 동접에 맞춰 적절한 피드백을 보낸다

• 피드백이 계속 실패하면 대기열 서버가 죽은 것이다

• 단, 한 번이라도 성공하면 살아난 것으로 간주한다

강건한 게임 서버가 추가적으로 해야 할 일

1. 대기열 서버가 발급한 입장권을 잘 검증한다

• 단, 대기열 서버가 죽은 것 같으면 그냥 보내 준다

2. 가능하면 순번이 이미 사용되었는지 확인한다

3. 대기열 서버에게 동접에 맞춰 적절한 피드백을 보낸다

• 피드백이 계속 실패하면 대기열 서버가 죽은 것이다

• 단, 한 번이라도 성공하면 살아난 것으로 간주한다

1. 대기열 서버가 발급한 입장권을 잘 검증한다

• 단, 대기열 서버가 죽은 것 같으면 그냥 보내 준다

2. 가능하면 순번이 이미 사용되었는지 확인한다

3. 대기열 서버에게 동접에 맞춰 적절한 피드백을 보낸다

• 피드백이 계속 실패하면 대기열 서버가 죽은 것이다

• 단, 한 번이라도 성공하면 살아난 것으로 간주한다

대기열을 더 잘 만들 수는 없을까요?

성능 최적화

• 저장소에 전달되는 대부분의 명령은 무의미하다

• 누군가가 합쳐 주면 좋겠다

SET cutoff 2048

INCR serial 1

OKSET cutoff 2040

INCR serial 1 2019

OK

2020

성능 최적화

합체

합체 기준점

성능 최적화

성능 최적화

합체 기준점

성능 최적화

• 통상적인 서버에는 이런 합체 프리미티브가 없다

• 하지만 실버바인 서버 엔진 2에는 있다!

• 통상적인 서버에는 이런 합체 프리미티브가 없다

• 하지만 실버바인 서버 엔진 2에는 있다!

• 지연latency을 약간 희생해서 대역폭throughput을 크게 늘린다

• 대역폭 = 상수 × 서버 수 × 최대 허용 지연 (요청량과 무관)

• 저장소에 가해지는 부하가 최소화

• 간단한 구현으로도 초당 10만 요청을 버티는 것으로 추산

대기 시간 추정

• 정말로 대기 시간을 추정할 수 있을까?

• 게임 서버로부터의 피드백은 이산적

• 피드백이 없으면 대기 시간은 무한정 길어질 수 있다!

• 대신 허용 순번이 증가하는 속도를 계측

• 마지막 피드백 시점에서 계측된 속도와 그로부터 지난 시간,내 앞에 서 있는 대기자 수로부터 대기 시간을 추정한다

대기 시간 추정 → 통과 속도 계측

• 아무 피드백도 없으면 통과 속도는 지수적으로 감쇄

• 마지막 피드백 시각에서 감쇄되는 정도를 계산해서 제공

• 속도를 주기적으로 피드백하므로 실제 값에 수렴하게 된다

대기 시간 추정 최적화

• 감쇄는 기계적으로 계산할 수 있다

• 오로지 피드백이 있을 때 속도가 새로 계측된다

• 계측된 속도와 통과 순번을 묶어 저장하면 저장소 부하가 줄어듦

SET cutoff_and_estimate (2048, 2019-04-26 16:20:47, 3.51 users/sec)

그 밖에…

• HTTP JSON API 설계 원칙

• 대기표와 입장권의 암호학적 인증 절차

• 게임 클라이언트 인증 절차

• 프로토콜에 순번을 노출시켜도 괜찮은가?

…등의 이야기가 있지만 여기서는 생략하겠습니다 ;-)

대기열을 어떻게 만드나요? 가장 최근에 들어온·나간 대기자의 순번만 저장하고, 암호학적 인증으로 클라이언트가 주기적으로 폴링하게 합니다.

대기열이 죽으면 어떻게 되나요? 구조적으로 상태를 횡분할할 수 없지만,각 서버가 죽었을 경우에도 강건하게 동작하도록 준비할 수는 있습니다.

대기열을 더 잘 만들 수는 없을까요? 저장소에 보낼 명령을 미리 합치는 걸로 성능을 향상시키거나, 대기 시간을 적은 부하로 추정할 수 있습니다.

대기열을 왜 만드나요? 넘치는 사용자를 막는 것보다는, 다른 사용자가 빠지거나 서버가 충분히 확장될 때까지 기다리게 하는 게 더 나으니까요.

끝