사양이 낮은 시스템의 재활용 방안
제목: 사양이 낮은 시스템의 재활용 방안
작성: RisaPapa
먼저 저는 대기업의 대형 시스템의 경험이 없고 제가 주로 생각하는 것(타겟)은 중소기업이나 대학및 교육기관등의 중규모시스템이라는 것을 전제하에 개발에 임하고 있다는 것을 밝힙니다.
그런데 지금 현실에서는 시스템 부분에 과투자가 이루어진것이 아닌가하고 생각하는 때가 많습니다. 제가 주로 개발하고 테스트하는 환경은 펜티엄II 266/350 MHZ 메모리 512M Bytes입니다. 이러한 기종을 5대정도를 가지고 분산 시스템과 과부하 시스템등의 테스트와 개발을 하고 있고 운영 시스템 개발의 경우에는 펜티엄 150 MHZ 메모리 32M Bytes을 메인 머신으로 하고 있습니다. 펜티엄3/4는 아직 구경도 못해보고 사용해본적도 없는 기종이라서 이러한 기종을 사용하면 어떤 결과가 있을까하는 기대감이나 설레임을 억제하면서 구닥다리 기종을 아직도 메인으로 사용하고 있습니다. 전 시스템의 컴퓨터 비용이라고 해 보았자 한대에 2,000엔에서 5,000엔 정도로 중고 기종을 사다가 부품을 교환하고 해서 다시 구축한 시스템이 대부분이라서 아마 모든 비용을 합해도 30,000만엔(30만원) 정도 되리라고 생각합니다. 사실 집에는 거의 사용하지 않는 컴퓨터와 부품 교채용를 합치면 10대정도가 됩니다. 일하고 있는 방은 창고 같이 되버린지 오래되었습니다.
운영시스템은 윈도우2000 서버 영어버전과 FreeDSD로 구성되어 있습니다. 2년전에는 주로 윈도우95를 많이 사용했고 가끔 윈도우3.2와 도스6.X도 함께 사용하고 있었습니다. 요즈음은 윈도우환경에서 공개소스를 사용한 윈도우용 서버팩키지를 개발하느라고 주로 윈도우2000 서버를 사용하고 있으나 마이크로소프트 운영시스템에서 제가 좋아하는 버전은 NT4.0과 윈95입니다.
이런 환경에서 개발을 하다보면 스피드라든지 메모리 사용율 CPU사용율을 항상 체크하면서 테스트를 하고 서버에서는 아파치나 펄, PHP, 데이터베이스등의 소프트 버전이 올라갈 때마다 성능이라든지 시스템사양, 스피드등에 많이 신경쓰게 되고 반드시 테스트를 하게 됩니다. 그러면서 2000연대를 지나면서 개발자들이 거의 시스템의 성능에 대한 배려를 하지 않고 오로지 기능(함수라든지 지원하는 API등등)추가에 대해서만 매진하여 온 듯한 느낌이 듭니다.
이러한 배경에서인지 운영시스템을 포함한 애플리케이션 시스템의 거대화 현상은 점점 가속화되고 컴퓨터의 사양도 왠만한 사양으로는 웹서비스하기에도 무리가 있을 정도가 된듯합니다. 사실 FreeBSD-2.2.7에서 아파치(어느정도 튜닝을 하고 1.3.9이하 버전)하나만으로 HTML과 텍트트기반으로 한 사이트를 운영하면 현재 운영되고 있는 KLDP사이트의 경우에는 펜티엄2 머신으로도 충분하고도 남지 않을까하는 생각도 하게 됩니다.
시스템에 부하를 많이 주는 부분으로서는 커넬도 한몫하지만 거대해지는 데이터베이스(DBMS)나 PHP와 같은 아파치에 로드되는 여러 모듈도 한몫을 한다는 생각이 많이 듭니다. 펄의 경우에는 5.005_03이나 5.6.0버전으로 테스트하는 것과 5.8.0으로 테스트하는 것에는 많은 차이가 있고 여러 지원하는 것에서는 5.8.0버전이 유리(주로 유니코드 부분)하지만 스피드나 시스템 자원에서는 무려 두배이상 차이가 납니다. 사실 PHP의 경우에도 PHP/F1(php-2.0.1) -- 올해 만우절에 일본 PHP사이트에서 php-2.0.2 버전이 이러한 것을 풍자하기라도 한듯이 릴리즈되기도 했습니다. 물론 컴파일이 되고 실제로도 버전업이 되었습니다.-- 과 현재 버전들을 비교하면 너무나 무겁습니다. PHP/F1은 BISON(BYACC, LEMON, ETC)등으로 언어부분을 파싱하는 엔진부분의 코드가 작성이 되지 않아서 조금 스피드는 떨어집니다만 php-2.0.2부분에 언어 파싱코드(현재의 젠드엔진에 해당)만 추가하면 --실질적으로 이 부분(젠드엔진)이 추가되고 다른 많은 기능이 추가되어 PHP-3.X.X 버전으로 업그레이드 되었습니다. -- 그 스피드는 환상적입니다. 물론 아파치모듈이나 FastCGI등으로 운영할 때입니다. 사양이 낮은 시스템에서 CGI로는 현재의 급격하게 증가하는 억세스수에 따른 프로세스의 오버헤드를 감당하기가 힘들기 때문입니다.
많은 개발자들이 개발비용과 효능 그리고 생산성이라는 이유로 최신 버전에 최신의 장비를 사용하는 것이 정답이라고 대부분이 말을 합니다. 때에 따라서는 성능이나 스피드가 나오지 않으면 소프트의 질적인 개량에 의존하기 보다는 하드웨어의 성능에 의존해 돈을 더들여서 좋은 장비를 구입하면 된다고 말을 하는 이도 있습니다. 저는 이러한 하드웨어 적인 장비보다는 소프트에 의한 노력에 더 중점을 두고 있고 개발자라면 이러한 노력을 하는 것은 당연한 것으로 생각하고 있습니다. 사실 기업에서 소프트로 이러한 노력을 해서 시스템 사양이 낮더라도 잘 돌아가는 시스템을 구성하고 소프트를 개발할 수 있는 개발자를 구하기가 힘들것이라는 생각도 합니다. 지금까지 이러한 노력을 하면서 개발을 해온 회사들이 거의 없었고 생산성에만 지나친 편중을 두었기 때문에 이러한 개발자 역시 배출될 토양도 없었다고 봅니다.
지금은 주로 윈도우 시스템에서 낮은 사양에서도 운영이 가능한 서버 팩키지를 개발하고 있기 때문에 FreeBSD쪽은 거의 손을 대지 않지만 이 작업이 끊나면 FreeBSD에서 낮은 사양에서도 서버로 운영될수 있는 시스템을 한번 만들어 보고 싶은 마음을 가지고 있습니다. 현재의 윈도우 시스템에서는 아파치2와 perl-5.6.0, php-4.3.2, FastCGI 기반이고 데이터베이스는 MySQL로 할까 아니면 GDBM/DB(버클리DB)/SQLite로 할까 고민중에 있습니다.
펄에서는 DB_FILE이나 GDBM_FILE모듈이 세계적으로도 중규모 시스템에서 많이 사용되고 있는데 테스트를 해보면 SQLite가 가장 성능이 좋고 스피드 또한 아주 마음에 들었습니다. 그래서 지금은 SQLite쪽으로 많이 기울어져 가고 있기는 합니다.
지금도 크레이지 보드는 여러사이트에서 많이 운영되고 있는 것을 보곤하는데 윈도우32 환경에서 크레이지 보드의 C소스를 컴파일해서 운영해 보고 펄의 GDBM을 사용하여 C소스를 펄로 포팅해 FastCGI상에서 스피드를 비교해 보면 Perl로 FastCGI모듈을 사용해서 운영하는 것이 훨씬 스피드면에서 유리하다는 결과도 나옵니다. SQLite나 GDBM_FILE, DB_FILE등을 FastCGI상으로 운영할 때는 하나 혹은 설정에 의해서 수십개까지 FastCGI 프로세스를 뛰울 수가 있는데 이러한 프로세스가 데이터베이스의 Daemon과 비슷한 역활을 하여 MySQL과 같은 DBMS으로 운영하는 것과 같은 효과가 있지 않나하는 생각도 하게 됩니다. 그리고 펄 --C로 작성된 FastCGI라면 더 빠른 성능을 얻을 수 있을 것입니다-- 에서 직접 DB의 FILE에 억세스 하기 때문에 MySQL과의 소켓통신과정이 줄어들어 더 빨라지지 않을까하는 추측도 하게됩니다.
KLDP에서 PHPBB2가 사용이 되고 있는데, 작년에 PHPBB2 서포트 사이트에 한국어로 번역해서 한국어를 추가해서 올렸을 때(지금은 누가 관리하는지 모르겠습니다만) 스피드 테스트를 해본 적이 있습니다. 펨티엄2 266에서 처음 포럼페이지를 출력하는데 걸리는 시간이 0.4초 정도 걸렸던 것으로 기억을 합니다. 현재 운영중인 KLDP의 9개 포럼 인덱스를 출력하려면 아마 0.6초대를 넘어 갈것이라고 생각됩니다. 이 정도로는 시스템의 사양이 좋아도 그렇게 많은 억세스수를 담당하기가 힘들지 않을까하는 생각도 하게 되어 PHPBB2는 제가 멀리해오게 되었습니다. PHP의 정규표현은 펄보다는 느린데 PHPBB2에서 이 정규표현을 구하는 식이 아주 많이 사용되어 스피드가 떨어지지 않는가 하고 추측도 해봅니다.
저는 주로 펄을 사용하고 있고 PHPBB2정도의 비슷한 기능을 제공하는 것이 한국에는 테크노트가 있는데 이것을 수정해서 DB_FILE을 사용하고 FastCGI를 사용하면 제가 사용하는 시스템에서는 0.03에서 0.1초대에서 실행이 되고 있습니다. 이것은 무려 5배에서 10배가 빠르다는 이야기인데 시스템의 성능을 5배이상 빠르게 하기 위한 하드웨어적인 투자비용를 생각하면 FastCGI의 사용가치는 충분히 있다는 생각도 하게 됩니다. mod_perl은 메모리를 많이 사용하고 사양이 어느정도 좋지 않으면 사용하는데 무리가 있어 이것이 주로 FastCGI를 중심으로 개발을 하게 된 동기가 입니다. FastCGI가 더 쉽다는 장점이 있는데 하나의 프로세스로 작동하기 때문에 어느정도 애플리케이션이라는 개념으로 생각을 해야하고 그래서 메모리 문제를 항상 염두하지 않으면 안된다는 단점이 있기도 합니다. 그러나 기본 개념에 충실한 프로그램을 하는 사람에게는 별로 어려운 사항이 아닐것입니다.
최근에 임베드 시스템이 많이 개발이 되고 차세대 전자기기 제품에도 주목받는 분야라고 생각이 됩니다만 FastCGI가 하나의 프로세스로 작동을 하기 때문에 FastCGI를 이러한 시스템에 장착을 하게 되면 일반 펄과 같은 스크립으로도 임베드 시스템의 간단한 프로그래밍이 가능하지 않을까하는 생각까지도 가져봅니다.
이러한 생각과 함께 사양이 낮은 시스템에서 중규모정도의 시스템이라면 Perl-5.6.0(FastCGI와 SQLite를 정적으로 컴파일한 미니펄)에 FastCGI와 SQLite 그리고 아파치(윈32라면 아파치2를 권장합니다)를 사용한다면 충분하다는 생각을 가져봅니다. C/C++로 FastCGI를 개발한다면 더 많은 억세스를 감당할 것입니다. 웹상에 환경변수를 출력하는 프로그램을 C로 FastCGI를 작성하면 펜티엄2 350MHZ에서 초당 170정도의 억세스수를 감당해낼 수가 있습니다. 펄은 140정도이고 순수한 HTML은 240정도 입니다. 많은 사람이 관심을 가지고 있으리라고 생각되는 PHP는 초당 65정도의 억세스수를 감당합니다. 많은 개발자들이 PHP가 빠르다고 하는데 저는 이러한 여러 테스트를 하면서 FastCGI로 Perl을 운영할 경우에는 PHP는 너무느리게 느껴지는 것입니다. 테스트한 소스는 맨 아래에 첨부했니다. Win2000 Server에서 Apache2, Perl5.6.0, Php-4.3.2을 사용했고 mod_ssl 이 로드된 상태에서 테스트(ab -n 5000 -c 50 URL)를 했습니다.
일반 중소기업에서는 회사에 어울리지 않는 너무 과분한 장비와 고급소프트(IT-Bubble)를 사용하고 있다는 생각이 많이 듭니다. 일본에서는 경제지표의 수치상으로는 IT거품이라는 현상이 발생하지 않았습니다. 일본에서 이야기하는 소프트의 정의는 달라 GDP에서 수주 소프트만이 설비투자로 취급이 되는데 미국이나 한국에서는 일반 팩키지 소프트도 설비투자로 취급하는 것을 감안하면 조금 다른 수치적인 해석이 필요합니다. 실질적으로는 팩키지 소프트를 포함하면 GDP의 1%에 해당이 되는 4조엔이 더 추가되어야 한다고 주장하는 이도 있습니다. 그러나 생활에서는 별로 IT거품이라는 현상을 느끼지 않는데 이것의 주요 원인이 과분한 장비와 과분한 소프트의 투자가 적었기 때문이라는 생각도 가져봅니다.
요즘은 오히려 IT분야의 대기업에서도 중고 PC의 재활용이 검토되고 있고 리사이클 PC 시장에도 본격적으로 참여하는 움직임도 볼 수가 있습니다. 이러한 현상을 보면서 하드웨어가 급격히 성장한데 반해서 소프트는 진정한 개발보다는 하드의 자원을 소비하려고만 개발이 된듯한 생각도 가져봅니다. 다시말해서 발전이라고 보다는 뒷걸음을 해왔다는 생각까지도 하게 됩니다.
[테스트 참고자료]
/* echo.c */ #include "fcgi_config.h" #include <stdlib.h> #ifdef HAVE_UNISTD_H #include <unistd.h> #endif #ifdef _WIN32 #include <process.h> #else extern char **environ; #endif #include "fcgi_stdio.h" static void PrintEnv(char *label, char **envp) { printf("%s:<br>\n<pre>\n", label); for ( ; *envp != NULL; envp++) { printf("%s\n", *envp); } printf("</pre><p>\n"); } int main () { char **initialEnv = environ; int count = 0; while (FCGI_Accept() >= 0) { char *contentLength = getenv("CONTENT_LENGTH"); int len; printf("Content-type: text/html\r\n" "\r\n" "<title>FastCGI echo</title>" "<h1>FastCGI echo</h1>\n" "Request number %d, Process ID: %d<p>\n", ++count, getpid()); if (contentLength != NULL) { len = strtol(contentLength, NULL, 10); } else { len = 0; } if (len <= 0) { printf("No data from standard input.<p>\n"); } else { int i, ch; printf("Standard input:<br>\n<pre>\n"); for (i = 0; i < len; i++) { if ((ch = getchar()) < 0) { printf("Error: Not enough bytes received on standard input<p>\n"); break; } putchar(ch); } printf("\n</pre><p>\n"); } PrintEnv("Request environment", environ); PrintEnv("Initial environment", initialEnv); } /* while */ return 0; }
# * echo.fpl (Perl) * # use FCGI; use strict; sub print_env { my($label, $envp) = @_; print("$label:<br>\n<pre>\n"); my @keys = sort keys(%$envp); foreach my $key (@keys) { print("$key=$$envp{$key}\n"); } print("</pre><p>\n"); } my %env; my $req = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%env); my $count = 0; while($req->Accept() >= 0) { print("Content-type: text/html\r\n\r\n", "<title>FastCGI echo (Perl)</title>\n", "<h1>FastCGI echo (Perl)</h1>\n", "Request number ", ++$count, "<p>\n"); my $len = 0 + $env{'CONTENT_LENGTH'}; if($len == 0) { print("No data from standard input.<p>\n"); } else { print("Standard input:<br>\n<pre>\n"); for(my $i = 0; $i < $len; $i++) { my $ch = getc(STDIN); if($ch eq "") { print("Error: Not enough bytes received ", "on standard input<p>\n"); last; } print($ch); } print("\n</pre><p>\n"); } print_env("Request environment", \%env); $req->Flush(); print_env("Initial environment", \%ENV); $req->Finish(); }
/* echo.php (PHP) */ <html><head><title> FastCGI echo (PHP)</title> </head> <body bgcolor="#FFFFFF" text="#000000"> <p align="center"><b> Request environment (PHP)</b></p> <table width="100%" border="1" cellspacing="0" cellpadding="5" bordercolor="#333333"> <tr><td bgcolor="#CCCCCC" width="40%" height="24">Name</td> <td height="24">Value</td></tr> <? foreach ($_SERVER as $key => $val) { print "<tr><td bgcolor='#CCCCCC' width='40%'>"; print "$key</td><td>$val</td></tr>"; } ?> </table></body></html>
일단 몇가지 질문사항(?)에 대한 답부터.... 8) phpBB
일단 몇가지 질문사항(?)에 대한 답부터.... 8)
phpBB의 한글 패키지는 phpBB 공식 사이트에서 받으실 수 있는데 제가 관리하고 있습니다. 그 이전에 여러 비공식 한글 패키지들이 있었다는 이야기를 들은 적이 있는데 제가 phpBB를 이곳에 적용할 때 phpBB 공식 사이트에 이미 한글 패키지가 있긴 있었습니다만 오타 등이 조금 있어서 제가 고치고 원 번역자분과 합의하에 공동관리하기로 했지요.
그리고 구형 하드웨어의 활용은.... 하드웨어의 가격이 갈수록 낮아지고 있고, 개발기간도 점점 짧아지고 있기 때문에 어느 정도 타협을 하는 것이 아닐까 생각하고 있습니다. 튜닝 및 디버깅에 들어가는 시간과 노력에 대한 비용보다 하드웨어를 업그레이드하는 비용이 더 싸다고 판단되면 하드웨어를 업그레이드하는 것이 더 편리하겠지요.
최근의 상황을 보면, 하드웨어 변경이 현실적으로 어려운 임베디드 환경에서는 소프트웨어에 대해 최대의 성능을 위한 튜닝이 주로 이루어지고 상대적으로 하드웨어 변경 및 업그레이드가 용이한 인터넷 서버들은 하드웨어 업그레이드가 손쉬운 선택이 되는 것 같습니다.
제 경우도 성능 튜닝은 일단 기반 소프트웨어(Apache, MySQL 등)의 설정값을 조절하는 정도에서 우선 시작을 하고 그래도 해결이 안될 경우는 그냥 하드웨어를 업그레이드하는 쪽으로 쉽게 마음이 기울게 됩니다. 하드웨어는 업그레이드할 경우 일단 어느정도의 성능 향상을 곧바로 기대하게 되지만 소프트웨어 튜닝은 기대반 우려반인 심정이 되거든요. 더군다나 설정이 복잡하게 얽혀 있는 경우에는 한쪽의 설정을 변경했을 때 다른 쪽에서 생각지도 못했던 문제가 발생할 위험이 있어서....
그렇지만 소프트웨어적인 튜닝만으로 원하는 성능을 얻었을 때는 아무래도 기분이 훨씬 좋지요. 돈이 굳으니까. (사실상 소프트웨어 튜닝에 소요된 시간과 노력도 비용으로 생각해야 되는데 그렇게 되지 않는 경우가 많더라구요.) :)
그냥 생각을 하면...
어떤 시대이고간에 엔지니어의 미덕(??)은 싼값에 성능좋은 상품을 제때 내놓는 것입니다. 이 조건을 충족시켜주는 최적지점이 시대와 환경에 따라 바뀐 것 뿐이겠죠.
더군다나 요즘처럼 '시장진입'을 빨리 해야 하는 시대에서는,
무엇인가 만들어야 한다는 지시가 떨어지면 빨리 만드는 놈이 무조건 이깁니다.
상품 종류에 따라 다르겠지만, 시장진입이 남들보다 6개월이 늦는다면,
그 사업은 종치는 것이겠죠.
간단히 말해서, php 같은 거 써서 성능 하나도 튜닝 안하고 기능만 재빨리 구현해서 1개월만에 만든 다음, 이걸 1억원짜리 서버에 돌리는 것이 엄청난 소프트웨어 기술을 이용해서 6개월간 최적화 한 다음, 이걸 1000만원짜리 서버에 돌리는 것보다 훨 낫다는 것이죠. 후자의 경우에는 천재적인 마케팅 능력 없이는 아마 사업 접어야 할 것입니다.
임베디드쪽에서 무작정 그렇게 하지 못하는 이유는 따로 있겠죠. 만일 스크립트 언어로 개발하고 고성능 하드웨어를 이용한다면, 제품 단가가 올라가는 것은 물론, 하드웨어 개발 비용 및 시간도 늘어나겠죠. 이런 건 시장에 아무리 빨리 진입한다고 하더라도 비싼 가격때문에 큰 빛을 보기 힘들겠고요. 후속 제품에 순식간에 따라잡히겠죠. 게다가 고성능 제품이 먹는 전력을 비교해보면, ...그건 무리겠죠. 그런 이유로 '최적인 방법'의 위치가 프로세서나 DSP 같은 것을 이용해서 C 같은 프로그램을 죽어라고 튜닝해서 집어넣는 것이겠고요.
사실 임베디드 쪽에서는 다른 옵션도 많습니다. 가령, 일부는 하드웨어, 일부는 소프트웨어로 만드는 방법도 있겠고, 아니면 몽땅 하드웨어로 만드는 방법도 있겠고요. 하드웨어로 만든다고 해도 ASIC을 통해 칩을 다 만들 것인지, FPGA 같은 것을 이용해서 할 것인지, 아니면 남들이 만든 칩을 그대로 쓸 것인지... 한두가지 solution이 있는 게 아닙니다. 그렇지만 이미 존재하는 프로세서를 PCB에 적당히 잘 배열해서 거기에 프로그램을 잘 짜서 뭔가를 만든다는 것은, 그 방법이 '최적지점'에 존재하기 때문이겠죠.
(많은 경우에 임베디드에서는 칩을 직접 설계해서 제품을 제조하는 것이 가장 고성능이고, 가장 가격도 낮고, 전력도 조금 먹고, ... 뭐 그럴 것입니다. 그렇지만, 그렇게 하지 않는 이유는 개발비용과 개발에 걸리는 시간과 그에 따른 위험도의 증가 때문입니다. 요즘은 칩 하나 샘플 만드는 데에만 해도 100만달러씩 필요하니깐요. 실수로 잘못 만드는 순간 중소기업은 망합니다-_-; )
말씀하신 '퇴보'는 서버쪽에서는 많이 일어나는 일 같습니다. 서버 한 두대에서 돌릴 때, '요구되는 하드웨어의 사양'이라는 것은 별로 큰 의미가 아니니깐요.. :)
그렇지만, 개발이 쉽다고 DB 엔진을 php로 직접 만들어서 쓰거나, 스크립트 언어로 3D 게임 엔진을 만드는 사람은 없을껍니다... :)
RisaPapa 님께서 중소 규모의 많은 서버에 소프트웨어를 deploy 하신다면, 제 생각에도 FastCGI 같은 방법이 최적일 것 같습니다. 이 경우에는 프로그램 하나 잘 짜면 컴퓨터 수천대를 업그레이드 할 필요가 없을테니깐요. 그렇지만, 모든 사람들이 님과 같은 환경에 처해있는 것이 아니기 때문에 php같은 솔루션이 환영을 받는 것이겠고요. 사실 대부분의 웹애플리케이션은 하나 만들어서 몇군데에밖에 안 쓰이잖아요... -0-
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24