[소고] 물리적인 한계들…

@codemaru · June 19, 2015 · 12 min read

초등학교 때 였다. 요즘은 PC방에 거의 자취를 감춰 버렸지만 그 당시만 해도 아케이드 게임을 들여놓은 오락실이 동네마다 엄청 많이 있었다. 100원 짜리 동전 한두개를 가지고 오락실을 가면서 난 항상 고민에 빠지곤 했다. 그 부족한 자원을 가지고 오락실에서 가장 오래 시간을 때울 수 있는 방법을 찾아야 했기 때문이었다. 인기 있는 게임을 하는 것은 재미는 있었지만 위험 부담이 너무 컸다. 중학생이나 고등학생 형들이 연결하기 일쑤였고, 나의 황금같은 100원은 순식간에 하늘 나라로 증발해 버리기 때문이었다. 그래서 구석 한켠에 아무도 하지 않는 오래된 RPG 게임을 하면서 시간을 죽이기도 했다. 나름 최적화된 투자였다.

세월이 흘렀고, 세상은 많이 변했다. 그때는 G.O.D 가사에 나오는 것처럼 대부분의 집들에서 자장면이 외식 메뉴였지만 요즘은 웬만한 가정에서는 집밥 보다도 못한 메뉴로 전락해 버렸다. 거리에 차도 늘었고, 고급 레스토랑도 늘었고, GDP도 눈에 띄게 늘었다. 그런데 아이러니 하게도 모든게 풍족해 보이지만 여전히 우리는 늘 리소스 부족에 시달린다. 컴퓨터도 그렇다. 난 486 컴퓨터에서 C 프로그램을 짤 때에도, 펜티엄에서 짤 때에도, 듀얼코어에서 짤 때에도, 항상 리소스는 부족했다. 게임보안 제품을 만들면서는 더 심해졌다. 게임이란 것이 원체 헤비 프로그램이기 때문에 동시에 돌아갈려면 CPU 점유율 0.01%에도 쩨쩨하게 굴어야 하고, 메모리를 아끼기 위해서 고속 서칭 알고리즘을 포기해야 하기도 한다. 그래도 이런 것들은 비교적 귀여운 축에 속하는 고민이었다는 것을 난 최근에야 깨달았다. 물리적인 한계가 있다는 사실을 속속 깨달았기 때문이다.

#0

최근에 GIT 저장소를 UTF-8로 업그레이드 하는 작업을 단행했다. 이전 버전의 GIT의 경우에는 UTF-8을 지원하지 않아서 일부 한글 파일들이 제대로 저장소에 업로드가 되지 않는 문제가 있었다. UTF-8로 된 저장소로 변경하고 나서는 그런 일이 없었다. 업그레이드 작업은 무척이나 간단한 명령어 몇 개로 가능했지만 안타깝게도 이 작업은 애꿏은 나의 하루를 모두 소비해 버렸다. 문제는 이랬다. 우리는 4-5년 전에 구매한 델 서버를 소스 저장소로 사용하고 있었다. 뭐 델 서버라고 하는데 뭔가 엄청난 건 아니고 그냥 좀 더 견고하게 만들어진 그런 하드웨어일 뿐이다. 성능이 특별히 뛰어나거나 하지는 않다. 그간 이 서버는 단 한 차례도 문제를 일으킨 적이 없어서 잘 사용하고 있었다. 그런데 저장소를 업그레이드 하고 나서는 이상하게 저장소를 클론하는데 지나치게 오랜 시간이 걸렸다. 도대체 문제가 무엇인지 알 수 없었다. 당연히 내가 바꾼 거라곤 GIT 저장소 뿐이니 그 부분을 의심할 수 밖에는 없었다.

하지만 문제는 서버에 있었다. 우리가 구매한 델 서버는 4년이란 시간을 감안하더라도 놀랍게도 고작, 고작 1기가 바이트의 메모리가 달려 있었다. 그런데 더 놀라운 사실이 있다. 난 뭐 1기가 바이트라고 한들 GIT 저장소를 운영하는데는 충분한 메모리라고 생각했던 것이다. 그런데 그건 터무니 없는 나의 생각이었다. GIT 클론 명령은 오브젝트를 압축하는 작업을 하는데 그 작업 과정에서 엄청나게 많은 메모리를 요구했다. 문제의 그 저장소를 클론하려면 1기가에 육박하는 메모리가 필요했다. 만약 재수없게 동시에 두 사람이 클론하는 경우에는 시스템은 메모리 부족으로 그 어떤 서비스도 동작하지 않는 엄청난 사태가 발생했다.

그래 메모리 그 까이꺼 얼마한다고 늘리면 되는 것 아닌가, 라는 생각에 델 서버를 뜯었다. 하지만 현실은 그리 녹록치가 않았다. 뭔가 호환도 되지 않는 이상한 메모리가 하나 달려 있었기 때문이다. 다른 메모리를 끼우면 동작하지 않았다. 뜯어본 델 서버는 더 가관이었다. 보드부터 시작해서 당췌 확장 가능한거라곤 아무것도 없었다. 말 그대로 재앙이었다. 그냥 조립 피씨를 한 대 구매해서 옮겨야 겠다는 생각을 했다.

#1

XIGNCODE3는 별도 옵션 없이 로그 서버를 무상으로 제공한다. 고로 고객님들께서는 적용하는 그 순간부터 발생하는 모든 로그와 통계 정보를 실시간으로 볼 수 있는 아름다운 신세계를 경험할 수 있다. 그런데 후발 주자로써 제품의 차별성을 두기 위해서 시작한 이 정책이 생각보다 골치아픈 존재가 되었다. 왜냐하면 고객에겐 공짜로 제공되지만 우리는 공짜로 사용할 수 있는 것이 아니기 때문이다.

우리가 사용하는 서버는 IDC에 10Mbps에 물려있는데, 사실 이제껏 한번도 트래픽에 대해서 생각을 해본 적이 없었다. 그것도 이유인 즉슨 몇십만되는 동접 게임도 큰 문제 없이 로그를 받았기 때문이다. 그래서 와 웹서버는 짱짱맨 이러면서 트래픽은 기억의 저편으로 날려 보냈다. 그런데 그게 아니었다. 지난 주에 대규모 게임을 런칭하면서 웹 서버가 다운되는 어처구니 없는 상황을 경험했기 때문이다. 10Mbps에서 우리 웹 서버는 이 지경이었다. 남부순환로로 출퇴근을 해 보았다면 이래서는 안 된다는 걸 일찍 알았어야 할 일이다.

traffic2
인간적으로 10Mbps 라인에 이게 무슨 짓이냐고 가비아에서 따질만도 하다.

일단 10Mbps라는 말은 10메가 비트를 일초에 전송한다는 말이다. 그러니 8로 나누면 초당 꼴랑 1.25메가 바이트를 전송할 수 있다는 결론에 도달한다. 60을 곱하면 분당 75메가 바이트를 전송할 수 있다. 우리 로그가 서버가 요구하던 용량은 게임에 따라 다르지만 헤비 게임을 기준으로 기존에 210메가 바이트 정도였던 거 같다. 그런데 75메가를 전송할 수 있는 라인에 그 정도는 버벅대면서 그럭저럭 돌아갔던 것이다. 이번에 추가된 게임은 트래픽 기준으로 분당 340MB메가 바이트를 필요로 했다. 그 지경이 되니 웹서버가 정지했다. 많은 고민을 했지만 피같은 돈을 들여 더 대역폭이 높은 라인을 사용하는 것 외에는 딱히 방법이 없었다.

#2

퇴근하러 나갔다가 배란다에서 커피를 마시는데, 새로 들어온 분석팀 직원이 담배를 피우러 와서는 묻는다.

너님: 서버 메모리 좀 올려주시면 안되요?

나님: 왜요?

너님: 계속 메모리 폴트 나요 ㅠㅜ~

나님: 2번 서버 아직도 그래요?

너님: 아뇨. 거의 전부 다 그래요.

나님: 헉. 그래도 메모리 추가는 안 되요. 서버 한 대당 메모리 1기가 추가하면 월에 만원 추가되거든요.

나님: 스크립트 새로 고쳐 놓을께요.

-- 2012. 07. 03.

지금도 가난하지만 정말 가난했던 시절 이야기다. 델 서버는 조립식 서버로 교체됐고, 올초에는 저장소를 github으로 변경했다. 가비아는 모두 클라우드 서비스로 옮겼고 더 이상의 회선 문제는 없다. 물론 트래픽 비용이 발생한다는 점은 추가됐다. 로그 서버 인스턴스도 겁 없이 하이엔드를 사용하기도 한다. 월 만원 때문에 파이썬 코드 최적화 시킨답시고 메모리 해제를 강제로 하는 방법을 찾지 않아도 되니 개발자 입장에서 많이 편해졌다. 물리적 한계에 봉착해 보면 돈이 있으면 많이 편하다. 그러니 일단 많이 벌고 볼 일인듯 ㅋㅋ~

@codemaru
돌아보니 좋은 날도 있었고, 나쁜 날도 있었다. 그런 나의 모든 소소한 일상과 배움을 기록한다. 여기에 기록된 모든 내용은 한 개인의 관점이고 의견이다. 내가 속한 조직과는 1도 상관이 없다.
(C) 2001 YoungJin Shin, 0일째 운영 중