brunch

You can make anything
by writing

C.S.Lewis

by 판뚜 May 21. 2019

서버 개발자가 꺼리는 일 - 이벤트

많은 서비스들이 사용자를 끌어모으기 위해 프로모션의 일환으로 적립금, 쿠폰 지급이나 선착순 이벤트를 많이 진행합니다. 물론 적당한 프로모션 이벤트는 서비스가 성장하는데에 큰 도움이 되겠습니다만 사실 이는 서버 개발자들에겐 가장 하기 싫은 일 중에 하나입니다.

감당이 안 되는 이벤트

앞선 글의 상황과 동일하게 카페에 비유해보도록 하겠습니다.

기획이와 개발이는 회사를 때려치우고 1평 남짓한 작은 카페를 차렸습니다. 기획이는 주로 경영을 하고, 개발이는 홀 관리 및 손님 응대를 합니다. 카페 홍보를 위해 기획이는 이벤트를 기획했습니다.

기획이 曰
"카페가 망할 것 같아.. 가수 아니유가 내 20년 지기 친구인 거 알지? 친구에게 부탁해서 음료 구매자들에게 프리허그 이벤트를 제공해야겠어. 내일 당장 실행하자."

개발이 曰
"...? 그... 그래 좋은 이벤트네.. 근데 내일 당장..?"

기획이의 필살에 개발이는 기뻐하긴 커녕 깊은 고민에 빠졌습니다.

우린 1평 남짓한 카페인데 손님들이 몰려오면 어떻게 해야 할까?

일시적으로 간이 테이블과 의자를 대량으로 구매하고 야외에 비치하면 해결될까?

일시적으로 알바를 몇 명 뽑을까?

이런 대응 계획을 세우고 아니유 프리허그 이벤트를 추진하게 되었습니다.

올바르지 못한 계획

그런데 과연 저 수고들이 적절한 대응 방안일까요? 위 방식에는 몇 가지 문제점이 있습니다.

첫째, 1회성 이벤트에 너무 많은 리소스가 투입되어야 한다는 것입니다. 평소에 손님이 없는 곳인데 야외에 둘 테이블을 구매할 필요가 전혀 없습니다. 이벤트가 끝나면 전부 팔던지 버리던지 해야 합니다. 알바도 전부 잘라야 합니다.

둘째, 위 대응방식으론 근본적인 문제를 해결할 수 없습니다. 아래와 같은 병목 구간이 존재하기 때문이죠.

카운터는 한 곳뿐이다.

커피머신이 한대뿐이다.

1평 남짓한 공간의 한계와 카운터, 커피머신 등의 인프라도 1평에 맞게 설계되어 있습니다. 수백 개의 테이블을 깔아놓는 것으로는 이리저리 나도는 손님들을 앉게 만들 순 있을지언정 근본적인 병목 현상을 해결할 수 없는 것입니다.

이런 식으로 이벤트를 운영하면 어떻게 될까요?

손님 통제하느라 매장 정리가 안됩니다.

커피의 맛 또한 보장할 수 없습니다.

이 상황을 해결하기 위한 선택지는 많지 않습니다.

카운터에서 손님께 죄송하다고 하고 내보낸 뒤 문 앞에 사과 공지를 붙인다.

그냥 가게 문을 닫고 손님을 내 보낸 뒤 아니유한테 사과하고 집에 보낸다.

개발의 언어로 바꿔봅시다.

우린 1평 남짓한 카페인데 손님들이 몰려오면 어떻게 해야 할까?
→ 트래픽 폭발

일시적으로 알바를 몇 명 뽑을까?
→ 서버 추가 투입 (scale out)

일시적으로 간이 테이블과 의자를 빌려서 야외에 비치하면 해결될까?
→ 서버 추가 투입 (scale out)

scale out(횡적 확장)은 더 많은 리퀘스트를 받을 수 있게는 하겠지만 근본적인 병목을 해결할 순 없습니다. 이 처럼 트래픽 대응은 쉽지 않은 문제입니다. 티켓팅 혹은 선착순 구매 이벤트 등에서 서버가 죽어나가는 현상들을 종종 경험하셨을 겁니다. 과연 그 서비스 개발자들은 의지가 없고 능력이 없어서 서버를 죽게 놔둔 것일까요? 결코 아닙니다.

카운터는 한 곳뿐이다.
→ 병목 지점

커피머신이 한대뿐이다.
→ 병목 지점

횡적 확장에도 불구하고 위처럼 근본적으로 병목일 수밖에 없는 지점이 있습니다. 물론 처음부터 이런 상황을 고려해서 인프라를 구성하고 개발을 하면 됩니다만 처음부터 그러지 않은 상황이라면 이것을 개선하는 데는 굉장히 어렵습니다. 왜냐면 이미 live 중인 서비스이기 때문에 쉽게 건들 수가 없기 때문이죠.

손님 통제하느라 매장 정리가 안됩니다.
→ 서비스 성능 저하

커피의 맛 또한 보장할 수 없습니다.
→ 기존 로직에 사이드 이펙트 발생

결국은 기존에 잘 돌아가던 로직이 영향을 받을 가능성이 커지고 서비스를 제대로 할 수 없게 됩니다. 이벤트 로직 배포했는데 사이드 이펙트가 발생되는 경우에 서버 개발자들은 매우 화가 납니다.

카운터에서 손님께 죄송하다고 하고 내보낸 뒤 문 앞에 사과 공지를 붙인다. (서버 점검 후 공지 걸기)

그냥 가게 문을 닫아버린다. (서버 내리기)

개선을 위해서는 위처럼 손님을 전부 내쫓아야 합니다. 서버 점검을 걸듯이 말이죠.

그럼 어떻게..?

카운터를 여러 개 설치한다.
→ 자금 낭비

커피머신을 더 구매한다.
→ 자금 낭비

물론 이런 해결방법도 있겠습니다만 평소에는 이 리소스들이 필요 없기 때문에 자원 낭비가 됩니다. 사실 이것을 정말 아름다운 방법으로는 해결할 수 없습니다. 어쩔 수 없는 현실을 받아들이고 타협해야 하죠.

일단 기획이를 설득해서 내일은 도저히 안 되겠다고 한다.
→ 일정 연기

밖에 줄을 그어 대기열을 만든다.
→ queue 도입

번호표를 만들고 순서가 되면 오라고 안내한다.
→ 적절한 비동기 처리

병목을 해결하진 못했지만 트래픽을 강제로 막는 방법으로 해결이 가능합니다. 이것도 많은 공수가 들겠지만 위처럼 카운터, 커피머신을 구매하는 것보단 리소스를 아낄 수 있을 것입니다. 또 굳이 야외에 테이블을 안 펴도 되겠습니다. 물론 가장 중요한 것은 무리한 일정부터 조정하는 것이겠죠.