블러그를 운영하다 보니 내용이 너무 프로그램이 가득해서 좀 답답하더군요
게임 업계 개발 인프라에 대해서 얘길 하고자 합니다.
우선 SI 업계(웹에이젼시포함)와 서비스 업계의 개발 환경은 차이가 많습니다.
SI업계는 우선 개발이 주요 업무이다 보니 다양한 서비스 환경을 놓고 개발하는 경우가 많습니다.
뭐 알다시미 자기 주력언어 이외에도 시도해야 하는 다양한 언어와 환경들이 존재를 하죠
개발 환경이 이런 부류가 대부분이고 최근엔 자바개발 전문 업체다 APM이다, 닷넷이다
전문적인 부분들도 등장을 하고 있는 거 같습니다.
하지만 그 개발 완성품을 꾸준히 유지 관리를 해 가면서 더욱 깊은 수준의 컨트롤을 할 시간까지는
주어지지 않는 것이 현실이죠, 또 다음 프로젝트에 투입이 된다든지 이후 유지보수팀이
그 부분을 맡아서 하지만 실제 개발이라기 보다는 서버관리라든지 작은 버그 사항 수정이
대부분입니다.
SI의 개발환경이 패단이 이런것들 인거 같습니다.
1. 실제 개발 기간을 예상 보다 절반 수준의 기간으로 개발을 완료하고 그 차익을 남기는 프로세스
2. 빨리 개발해야 하다 보니 성능 및 퍼포먼스 면은 조금 덜 신경 쓰게 됨(현실적으로 어쩔수 없음)
3. 버그 없이 빠른 개발을 위해 기존의 플랫폼을 재사용하는 경우가 많지만 그에 대한 고찰은 적다
물론 SI업계가 모두 그런것은 아니자만 대부분 그런거 같습니다.
그럼 SI의 개발 인프라 부분 어떨까요
1. 개발 WEB 서버 1~2대
2. 개발 DB서버 거의 1대
3. 미들 티어 서버(없는데도 많음)
개발완료 이후 프로젝트 자체를 서비스 운영 회사로 넘길 작업이다 보니
위와 같은 서버의 세팅 환경이면 충분 하고 또 그에 최적화 시켜 개발합니다.
여기까지는 SI (WEB 에이젼시) 얘기였습니다.
----------------------------------------------------------------------------------------------
서비스 회사 인프라
게임서비스, 포탈 등 대형 포탈 사이트의 경우는 대부분 외주소스를 많이 발주 하지 않습니다.
외주소스를 믿지를 않기 때문이죠
물론 전부가 그런것이 아닙니다.
대형 포탈들이 외주 소스를 왜 꺼리는 것일까요 간략히 요약하면 아마 다음과 같은 이유들 일것입니다.
1. 수백대의 웹팝 환경에 적절한 개발이 아님
2. 수백대의 DB를 분산 처리 하는 상황이 고려되어 있지 않음
3. 개발속도에 가장 많은 신경을 쓰기 때문에 성능 및 보안에 취약함
물론 웹서버 2~3대 두고 하는 작업 중소 서비스 업체의 경우에는 적절할지 모르나
SI 업체 계신 분들이 보통 대형 포탈을 경험해 보신분이 적습니다.
업계 구조상 SI를 떠나 대형 포탈로 가는 경우는 있지만.
대형 포탈을 떠나 SI로 가는 사람은 거의 없기 때문이죠 (물론 월급부터 복지까지 차이가 많습니다.)
한때 FID, 이퓨전 등 쟁쟁한 국내 에이젼시들도 있었지만 현재 거의 망해져 없거나
유명무실하죠.
이런 SI업계에만 계시던 분은 서비스 업계로와 한번의 대 변혁을 격습니다.
저도 SI 있을때 서비스 회사에서 개발 능력이 부족해서 우리한테 부탁하는 구나 하고
2~3년차때 자만심을 가진적도 있었죠.
실 예로 서비스 업체는 DB사용을 줄이고 분산환경을 최대한 활용하기 위해
할 수 있는 모든 것을 다합니다.
NHN 경우 NHN용 전용 웹서버, CJ인터넷의 SSO 등 DB사용을 줄이기 위한 하나의 방향임을 알 수 있고
XML, RSS 그리고 고전적인 HTML Generator 처럼 DB 에서 데이터를 가져올 만한 부분은
전부 튜닝하는 것이 대형 포탈의 필수적인 튜닝 조건이라고 하겠습니다.
각 중요 Impression이 많은 부분은 거의 모든 부분을 DB없이도 운영 가능한 환경을 만들려고 하죠.
이쯤 얘기하다 보면 DB 설계를 어떻게 했길래 그렇게 DB 죽을 걱정만 하냐 하고 하실분도 있을지 모릅니다.
이런 문제는 단지 걱정이 되기 때문이거나 DB튜닝에 자신이 없어서가 아닙니다.
위 언급드린 DBA, DBM 팀들 간은 경우는 컨설팅 업체에서 오랜 경력을 가지고
이름만 들어도 모우 알수 있는 대형 사이트의 튜닝, 운영, 관리등 많은 부분에 경험을 많이 가진 분들..
즉 쟁쟁한 분들이 DB를 관리하고들 계십니다.
이름을 언급 드리면 개발하시는 분이라면 책의 저자로 한번 만나보았을지도 모르겠습니다.
(회의적인 사고방식을 가진 분들은 "책 낸놈들이 다 잘하는 놈들이냐!..." 하실지도 모르지만....)
최고의 DBA들은 DB를 되도록 사용하지 않길 권합니다. 아이러니 한가요?
아닙니다. 할 수 있는 모든것을 다 해야 하기 때문에고 DB까지의 연결되는 부분에서 부하를
줄여주는 것 프로시저로 CPU 시간을 줄일수도 있고 컴파일 시간을 줄일 수도 있습니다.
하지만 실시간으로 연결 할 필요가 없는 부분은 연결하지 않고도 가능한 방향으로 운영하는 것이
가장 좋다는 말씀을 드리는 겁니다.
예를 들면 운영팀(CS라든지)에서 유저의 글중 베스트를 선정하는데 일주일에 한번 그런 작업을 한다고 친다면
일주일에 한번 갱신되는 몇개의 내용을 위해서 페이지가 호출 될때마다 디비를 커넥할 필요가 없죠
다른 예를 들어보겠습니다. 이번에는 파일 서버입니다.
포탈에서 셀카 콘테스트를 통해 추천을 많이 받은 사람들을 사이트 메인 페이지에 관련 항목의 베스트 유저로
내보내리고 기획을 합니다.
헌데 콘테스트까지 문제가 없었고 파일 등록까지 문제가 없습니다.(트래픽도 DB사용도 정상적입니다.)
콘테스트가 끝난 후 DB에서 1,2,3위를 추려 XML로 데이터를 미리 DB접속없이 작업을 해 놓았습니다
아침 8시가 되면 이 발표된 자료는 자동으로 사이트에 올라가게 됩니다.
<? xml version...........?>
<picture_event>
<best_user>
<rank>1</rank>
<name>고길동</name>
<picURL>http://fileserver.portal.co.kr/event_2007-09-20/userimage.jpg</picURL>
</best_user>
<best_user>
<rank>2</rank>
<name>둘리</name>
<picURL>http://fileserver.portal.co.kr/event_2007-09-20/userimage.jpg</picURL>
</best_user>
<best_user>
<rank>3</rank>
<name>도우너</name>
<picURL>http://fileserver.portal.co.kr/event_2007-09-20/userimage.jpg</picURL>
</best_user>
</picture_user>
이 파일을 읽어 들여 사이트 메인 페이지 및 이벤트 페이지등에서 읽어 오도록 했습니다.
최근 이슈로 떠 올랐던 Ajax까지 적용해서 멋지게 만들고서 담당 개발자는 점심을 먹으로 갔습니다.
하지만 이 개발자는 점심을 다 먹기도 전에 다시 사무실로 돌아와야 했습니다.
어떤 문제 였을까요
....
.......
...........
바로 파일 서버의 트래픽에 문제가 발생한 것 입니다.
파일서버에서 이미지 호출되는 수준이 평소 트래픽의 수십배 가량 늘어나 버렸습니다.
파일서버에서 섬네일 이미지 하나 부르는게 무슨 문제였을까요
이 회사는 메인페이지 하루 방문자 수가 1000만명에 육박하는 사이트 입니다.
이쯤 되면 점태그 하나도 파일로 올릴수가 없죠
이미지 사이즈 숫자는 이미 의미가 없어진 상황입니다. 트래픽 자체로만해도 엄청난 부하를 발생할 수 있으니까요
결국 이 섬네일 이미지들을 발표용으로 바꾸기 위해서 이미지서버(캐싱기능이 있는)로 옮길수 밖에 없었습니다.
그리고 XML파일의 경로도 수정했죠
물론 위에 예는 캐싱기능을 가진 파일 서버를 사용한다면 문제가 없을지 모르지만.
파일서버에 캐싱기능 사용할 정도로 정신 없는 CTO가 존재하는 회사는 없습니다.
파일서버쪽이라면 오히려 센 장비 처럼 용량에 최적화 하고 위 예처럼 메인페이지라든지
각 서비스 페이지에서 자랑스런 유저의 얼굴을 표시하는 등의 비슷한 비지니스로직이 있다면
관리자페이지에서 운영자가 최종 3명을 선정하고 XML을 배포(자동이죠 당연히....)할 당시
이미지들이 캐싱서버로 옮겨가도록 되어 있어야 합니다. (일회성 이벤트가 아니라면 자동으로....)
DB까지 고려해서 이 개발자는 모든 부분을 잘 수행햇지만 마지막 하나를 놓친거죠
이런 것들이 제가 대형 포탈에 대해서 말씀드리고 싶은 부분들입니다.
장비들이 싸졌고 네트워크 인프라가 좋아졌다고 서버하나 더 박아 넣으면
튜닝보다 성능이 나는 세상이긴 하지만. 이런 네트워크 환경들을 조금만 더 생각하면
웹 개발자로서 SE나 DBA 관리자들에게 사랑받고 인정 받는 동료가 되겠죠 ..
이런 부분들에 대한 작은 소스 튜닝도 많이 신경이 가는 부분이고
30분 생각하고 3시간 코딩하느니 3시간 생각하고 30분 코딩하는 쪽이
누가봐도 인정할 만한 프로그래머로 인정 받을 수 있는 결과물이 나올겁니다.
(HTML 코더와 개발자는 엄연히 다른 분야죠.....)
많은 고민과 과연 이것이 좋은가.
DB를 생각하고 서버를 생각해 봅니다.
블랙박스 테스트, 화이트 박스 테스트
이 모든 것을 생각하고 수행하면서
개발은 주어진 기간안에 완료해야 하는 것이
프로 개발자이고 우리들이 나아가야 할 궁극입니다.
자 영업부에서 마케팅에서 기획, 사업 부서에서 말도 안되는 일정에
업무들을 가지고 와서 언제까지나 불평만 하고 있을 건지..
그런 업무들이 가능한 회사 공용 프레임워크를 만들건지
지금 바로 결정하셔야 합니다.
그리고 그런 마인드를 가진 분들이 직장내 더 놓은 자리와 더 많은 연봉을 받고 있는 것이
현실입니다.
개발자는 회사원아 아닙니다.
하나의 독립체이면서도 조직에서 하고자하는 모든 업무를 현실화 시켜주는
마이더스의 손이 되지 않으면 그저 흔한 개발자일 뿐이죠
사고의 벽을 넘자 !!
간단한 저의 개동같은 개발 철학입니다.
열심히 밤을 세서 하면 꼭 그 보답이 돌아옵니다.
누군가가 알아주는 것이 현실입니다.
회의적 개발 마인드는 이제 그만 버립시다.~~~~
by Vins~
