트래픽 2배면 서버도 딱 2배? 부하 분산 시스템에 숨은 '규모의 경제'

트래픽이 2배 늘면, 서버도 딱 2배만 늘리면 될까요?

운영을 하다 보면 한 번쯤 이런 계산을 해보게 되거든요. "지금 서버 10대로 버티고 있는데, 사용자가 2배가 된다니까 서버도 20대로 늘리면 똑같이 굴러가겠지?" 직관적으로는 너무 당연한 말 같죠. 그런데 AWS의 시니어 엔지니어 Marc Brooker가 풀어놓은 이야기에 따르면, 부하 분산(로드 밸런싱) 시스템에서는 이 직관이 꽤 빗나간다고 해요. 오히려 큰 시스템일수록 같은 돈으로 더 많은 일을 처리할 수 있는, 일종의 '규모의 경제'가 숨어 있다는 거죠.

여기서 부하 분산이 뭐냐면요, 들어오는 요청을 여러 대의 서버에 골고루 나눠주는 장치(로드 밸런서)를 앞에 두고 일하는 구조예요. 식당으로 치면 손님을 빈 창구로 안내해주는 직원이라고 보면 돼요.

핵심은 '가동률과 대기 시간의 관계'예요

서버 한 대가 얼마나 바쁜지를 가동률(utilization)이라고 불러요. 100%면 쉴 틈 없이 일하는 거고, 50%면 절반은 놀고 있는 거죠. 그런데 이 가동률과 응답이 느려지는 정도(대기 시간)의 관계가 직선이 아니에요. 가동률이 70%, 80%까지는 그럭저럭 버티다가, 90%를 넘어 100%에 가까워지면 대기 시간이 하키 스틱처럼 수직으로 치솟거든요. 줄 서는 걸 생각하면 쉬워요. 창구가 한가할 땐 바로바로 처리되지만, 거의 꽉 찬 상태에선 손님 하나만 더 와도 줄이 확 길어지잖아요.

여기서 진짜 재미있는 게 나와요. 창구(서버)가 한 대일 때랑 백 대일 때, 똑같이 가동률 80%로 굴린다고 쳐볼게요. 한 대짜리는 그 서버가 바쁜 순간에 요청이 오면 무조건 기다려야 해요. 그런데 백 대짜리는 한 대가 바빠도 나머지 99대 중 노는 놈한테 넘기면 되거든요. 백 대가 '동시에 전부' 바쁠 확률은 굉장히 낮아요. 그래서 같은 80% 가동률이라도 큰 시스템은 거의 기다림 없이 처리돼요. 이렇게 여러 요청을 한데 모아 처리해서 이득을 보는 걸 '통계적 다중화'라고 불러요.

이 현상을 수식으로 정리한 게 100년도 더 된 Erlang C 공식이에요. 덴마크 수학자 Agner Erlang이 전화 교환소에서 회선을 몇 개 깔아야 통화가 안 끊길지 계산하려고 만든 건데, 지금의 서버 풀에도 그대로 들어맞아요. 결론만 말하면, 서버를 많이 모아둘수록 같은 응답 속도를 유지하면서 가동률을 더 높이 끌어올릴 수 있어요. 즉 큰 풀은 더 '뜨겁게' 굴려도 안 터진다는 거죠.

그래서 뭐가 의외라는 거냐면요

비용 관점에서 보면 이게 꽤 충격적이에요. 작은 서버 풀을 여러 개로 쪼개놓으면, 각 풀마다 만약을 대비한 여유분(놀고 있는 용량)을 따로따로 떼어놔야 해요. 반대로 하나의 큰 풀로 합치면 그 여유분을 다 같이 공유할 수 있으니 전체 낭비가 확 줄어요. 그래서 '작은 시스템 10개 = 큰 시스템 1개'가 절대 아니에요. 합쳐놓은 쪽이 훨씬 이득이거든요.

이게 요즘 아키텍처 논쟁이랑 바로 연결돼요. 마이크로서비스로 잘게 쪼개면 관리는 깔끔해지지만, 서비스마다 작은 서버 풀을 따로 갖게 되니 위에서 말한 여유분 낭비가 곳곳에서 생겨요. 반대로 AWS Lambda 같은 서버리스가 싸게 먹히는 비밀도 여기 있어요. 수많은 고객의 요청을 거대한 공용 풀에서 한꺼번에 처리하니까, 통계적 다중화의 이득을 극한까지 뽑아내는 거죠. 물론 너무 크게 합치면 장애가 한 번에 전체로 번지는 위험(blast radius)이 커지니까, 그걸 막으려고 일부러 칸막이를 치는 cell 기반 설계도 있고요. 결국 효율과 안정성 사이의 줄타기인 셈이에요.

한국 개발자에게 주는 시사점

실무에서 바로 써먹을 포인트가 있어요. 첫째, 비용 최적화를 할 때 가동률 목표를 무작정 50%로 낮게 깔지 마세요. 풀이 충분히 크다면 70~80%까지 올려도 응답 속도가 멀쩡하거든요. 둘째, 서비스를 마이크로서비스로 쪼갤지 말지 고민할 때 '풀 크기가 작아져서 생기는 비용'도 계산에 넣어야 해요. 트래픽이 적은 서비스를 굳이 따로 떼어내면 여유분만 잔뜩 들고 있게 될 수 있어요. 셋째, 쿠버네티스 오토스케일링 임계값을 잡을 때도 이 곡선을 기억하면 좋아요.

결국 한 줄로 정리하면, '규모는 그 자체로 효율'이라는 거예요. 여러분 회사의 시스템은 풀을 잘게 쪼개서 여유분을 곳곳에 흘리고 있나요, 아니면 크게 모아서 뜨겁게 굴리고 있나요? 한번 점검해보면 의외로 줄일 비용이 보일지도 몰라요.