'머리아픈 이야기'에 해당되는 글 35건
- 2010/08/28 텍스트큐브 공지사항 블로그 속도 업그레이드(?) 6
- 2009/01/24 컴퓨터 길들이기 3
- 2008/10/08 실종아동찾기 캠페인 (findingNemo 프로젝트) 관련 서버 장애 및 오류 복구 안내 3
- 2008/08/29 PHP5와 텍스트큐브 3
- 2008/06/20 Needlworks.org i18n 적용! 6
- 2008/05/14 예외 처리는 언제나 확실하게! 1
- 2008/02/11 연휴 휴유증 +
- 2007/12/25 아이디어 3
- 2007/12/10 요즘 잠수타고 있는 이유 3
- 2007/11/16 오픈소스 활동을 바라보며 2
텍스트큐브 공지사항 블로그 속도 업그레이드(?)
머리아픈 이야기 2010/08/28 03:00엊그제 정말 딱 한 줄만 고쳐서 평균 접속 속도를 5~8초 가량 걸리던 것을 0.2~0.3초 정도 걸리도록 개선했습니다. 과연 무엇이 문제였을까요?
1. 텍스트큐브 자체의 속도가 느리지 않을까?
가장 먼저 해본 일이 세션 테이블을 비우는 것이었습니다. 서버 쪽에서 수십~수백 군데의 PC로부터 동시에 들어오는 HTTP 요청을 가지고 각자의 PC별로 현재 접속한 사용자를 잘 구분하여 처리하기 위해 세션이라는 것을 사용합니다. 사용자를 구분하는 것 말고도 현재 사용자의 상태에 관한 데이터를 가지고 있기도 하죠. 로그인 상태는 이 세션이 유효한 상태에서만 지속됩니다.
보통 이러한 정보를 파일 또는 데이터베이스 상의 특정 테이블에 저장하게 되는데, HTTP 특성 상 새로운 요청이 들어오지 않는다고 사용자가 웹페이지를 닫은 것인지 아니면 밥 먹으러 간 것인지 알 방법이 없습니다. (그래서 일정 시간이 지나면 개인정보 유출을 방지하기 위해 서버 쪽에서 세션을 만료시켜 자동 로그아웃되도록 해놓는 경우가 많죠) 이 만료 시간을 길게 설정할수록, 사이트의 동시접속자 수가 많을수록 서버가 동시에 유지하고 있어야 하는 세션 개수가 엄청나게 늘어나게 됩니다.
당연히 텍스트큐브 공지사항 블로그는 설치형 텍스트큐브를 설치한 온갖 곳의 서버로부터 공지사항 업데이트를 받고 있으므로 이러한 세션 수가 상당히 높게 유지됩니다. 그래서 혹시 DB가 느려져서 그런 것은 아닐까 했던 것이죠. 주절주절 썼는데 결론은 효과 없었다, 즉 이것이 원인이 아니었다는 겁니다. orz
그래서 텍스트큐브의 PHP 코드 자체가 느린 부분이 있나도 생각해봤습니다만, 같은 서버에서 동작하는 다른 텍스트큐브 및 PHP 기반 웹사이트들은 멀쩡했습니다. 그렇다면 PHP 자체의 속도가 느린 것은 아니었죠.
2. Apache 웹 서버의 속도가 느리지 않을까?
다음으로 살펴본 것은 Apache 웹 서버였습니다. 우선 시간 지연이 어떤 패턴으로 나타나는지 정확히 알아야 했기 때문에 wget, ab, Firebug 등등 온갖 벤치마킹 프로그램을 동원해서 어떤 경우에 그러한 심각한 시간 지연이 나타나는지 조사했습니다.
그 결과, 텍스트큐브가 HTML을 뿌려줄 때, 그리고 몇몇 리소스 파일(자바스크립트와 CSS)을 로딩할 때만 그런 현상이 발생하고, 서버 내에서 서버 자신으로 접속할 때는 그런 지연이 전혀 나타나지 않고 외부에서 접속할 때만 그렇다는 사실을 알아냈습니다. 또한 시간 지연은 매우 일정하게 5초 정도 발생하며, 실제 컨텐츠 전송은 시간 지연이 없으나 전송이 시작되기 전까지 기다리는 시간이 길다는 것을 알 수 있었습니다.
이러한 사실로부터, 이것이 네임서버(DNS)와 관련된 문제라는 것을 직감할 수 있었습니다. 우리가 홈페이지 주소를 입력하면 웹사이트가 뜨는 그 과정에는 홈페이지 주소를 실제 서버의 IP 주소(4자리 숫자로 된 그것)로 변환해야 하는데, 그런 변환 또는 역변환을 하는 서버가 네임서버입니다. 대부분의 웹서버들은 어떤 곳으로부터 접속이 들어왔는지 로그를 남기는데요, 이때 클라이언트의 IP 주소는 바로 알 수 있지만 그 클라이언트가 가진 도메인은 네임서버를 통해 조회해봐야만 알 수 있습니다.
그런데 이 역변환의 경우 네임서버에서 지원하지 않거나 네임서버에서 찾을 수 없는 경우 응답이 아예 돌아오지 않는 경우가 생깁니다. 그러면 웹서버는 일정 시간이 지나 timeout될 때까지 기다리고(그래야 로그를 남긴 후 웹페이지 내용을 전송할 수 있으므로), 클라이언트 PC를 사용하는 사용자 입장에서는 "응답을 기다리는 중" 상태로 그 시간만큼 똑같이 기다리게 됩니다.
그래서 첫번째로 한 것은 Apache 설정에서 네임서버를 이용하지 않도록 하는 것이었습니다. 하나의 IP 주소에서 여러 웹사이트를 서비스하기 위해 virtual host라는 것을 이용하는데 이것을 설정하는 방법에 따라 네임서버 접근이 발생할 수 있었기 때문에 이것도 모두 손보고, 텍스트큐브의 PHP 코드 내에서 자체적으로 네임서버 접근하는 부분이 있는지 검사하고, HostnameLookups 설정변수 및 로그 포맷에서 호스트 이름(도메인)이 들어가는지 모두 확인해서 제거하였습니다.
문제는 그래도 나아지지 않았다는 것이지요. T_T
최후의 수단으로 사용한 것은 strace라는 것입니다. Linux에서 시스템콜을 추적하여 로그로 남겨주는 프로그램인데, 이것을 이용하면 파일 입출력, 소켓 접근 등 운영체제의 도움을 받는 모든 부분을 다 들여다볼 수 있습니다. 네임서버에 접근하기 위해선 소켓을 이용해 인터넷에 접속해야 하므로, 웹서버가 네임서버와 어떻게 상호작용하는지 알 수 있는 것이죠. (아니면 특정 파일을 읽어야 하는데 하드디스크나 운영체제 내부적인 문제로 비정상적으로 오래 걸린다든지 하는 경우, 권한 문제인지 등도 상세히 알 수 있습니다.)
처음 시도했을 땐 웹서버의 구조 상 각각의 동시 요청을 처리하기 위해 여러 개의 프로세스를 만들도록 되어 있었기 때문에 로그가 너무 많이 나와서(간단한 텍스트 파일 하나 보여주기 위해서만도 수백개 이상의 시스템콜이 발생합니다) 분석이 불가능했습니다.
방법을 고민하던 중 니들웍스의 쿨엔지니어님이 프로세스를 한 개만 띄우도록 설정해보라고 조언해주셔서, 다른 웹사이트를 이 서버에서 모두 내리고(...) 딱 1개의 프로세스만 띄워서 얘가 notice.textcube.org에 대한 요청을 처리하도록 설정을 분리한 다음에서야 다음과 같은 데이터를 확인할 수 있었습니다.
socket(PF_FILE, SOCK_STREAM, 0) = 16 <0.000101>fcntl(16, F_GETFD) = 0 <0.000089>fcntl(16, F_SETFD, FD_CLOEXEC) = 0 <0.000090>connect(16, {sa_family=AF_FILE, path="/var/run/avahi-daemon/socket"}, 110) = 0 <0.000094>fcntl(16, F_GETFL) = 0x2 (flags O_RDWR) <0.000060>fstat(16, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 <0.000091>mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5429003000 <0.000092>lseek(16, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) <0.000099>write(16, "RESOLVE-ADDRESS ###.###.###.###\n", 31) = 31 <0.000075>read(16, "-15 Timeout reached\n", 4096) = 20 <5.002403>close(16) = 0 <0.000068>munmap(0x7f5429003000, 4096) = 0 <0.000090>stat("/var/www/needlworks/notice.textcube.org/root/ko", 0x7fffead9e930) = -1 ENOENT (No such file or directory) <0.000065>stat("/var/www/needlworks/notice.textcube.org/root/rewrite.php", {st_mode=S_IFREG|0644, st_size=535, ...}) = 0 <0.000058>
시스템콜 함수의 이름과 거기에 전달된 인자값들이 무엇인지, 그리고 그 반환값과 수행 시간이 초 단위로 찍혀 있습니다.
맨 윗줄은 TCP 소켓을 만들었다는 뜻이고, 그 다음 connect 함수 부분은 Linux 계열 시스템에서 제공되는 avahi라는 네임서버 접근용 데몬 프로그램이 만들어놓은 파일형태의 소켓과 만든 소켓을 연결하겠다는 뜻입니다. (조금 복잡한데, Linux 계열에서는 모든 시스템 자원을 파일이라는 형태로 접근할 수 있도록 되어 있어서, 다른 프로그램과 상호작용하기 위해 위와 같은 방법을 자주 사용합니다.) 이런저런 설정과 확인을 거친 후, write 함수를 보면 어떤 IP 주소(실제로는 제가 집에서 접속할 때 사용한 유동IP입니다)에 대한 도메인을 가져오라는 내용을 쓰고 있고, 그 결과로 받은 것이 timeout, 그리고 그 결과를 받기까지 정확히 5초가 걸렸음을 보여줍니다.
네... 범인은 이거였습니다. (....)
그렇다면 웹서버가 제 의지와 상관 없이(...) 마음대로 네임서버에 접근하려다 실패하는 걸 계속 반복하고 있다는 뜻인데 왜 그런지 알아야겠지요.
약간의 구글링 끝에 알아낸 단서는, 보안을 위한 것이라지만 실제론 약간 습관적으로 사용하는 Allow from all과 관련이 있었습니다. Allow from all 자체가 이미 모든 곳으로부터의 접속을 받겠다는 뜻인데, Deny from none이라는 설정이 더 있었습니다. 그것도 텍스트큐브 관련 virtual host 설정에만요. 얼핏 보면 같은 뜻이니까 문제 없겠지 싶지만, 알고보니 none이라는 건 존재하지 않는 특수 이름이었습니다.
...그래서 "none"이라는 주소로부터 온 것인지 아닌지 검사하기 위해 모든 접속마다 IP 주소를 도메인으로 변환하려고 시도했던 것입니다. 랄랄랄라라라랄라라라... (참고로 이 일을 하는 mod_access 모듈은 다른 곳의 설정을 몽땅 무시하고 무조건 DNS 확인 절차를 수행한다고 합니다. -_-)
설정에서 Deny from none 한줄 지워주니 모든 문제가 해결되었습니다. 이 서버에서의 텍스트큐브 정상 속도대로 서비스되기 시작한 것이죠.
이상 삽질기 끝이었습니다.
아 허무해 ...ㅠㅠ
컴퓨터 길들이기
머리아픈 이야기 2009/01/24 03:18텍스트큐브 개발을 해오면서 수많은 사용자들의 건의와 질문을 받습니다. 설치 과정에서 DB 정보를 입력해야 하는데 그게 뭔말인지 몰라서 질문하는 경우부터, 스킨을 수정하는데 특정 브라우저에서 깨지니까 소스 주면서 어떻게 고쳐야 되냐고 물어본다거나, 굉장히 세세한 동작에 대한 옵션을 추가해달라는 경우까지 정말 다양하지요.
문제는 오픈소스 커뮤니티의 특성상, 사용자들의 모든 요구에 일일이 응대해주기도 어려울 뿐더러--사실 전문대응팀을 가진 큰 기업도 쉽지 않은 일입니다만--각 요구를 우리가 추구하는 목표에 맞게 자를 건 자르고 받아들인 건 받아들인다면 그 기준을 어떻게 세울 것인가도 큰 문제입니다. 100% 사용자의 요구에 맞출 수도 없는 일이고(사공이 많으면 배가 산으로 간다고 했습니다), 우리의 목표에 맞추자니 당장의 버전 로드맵부터 개발자의 취향(!)에 이르기까지 다양한 변수의 영향을 받습니다.
개발 프로세스를 좀더 세분화해서 알파 단계까지 새 버전에서 지원할 기능 목록을 확정하고 베타에서 테스트하고 발표후보 단계에서 다국어 번역 및 최종 디버깅하는 식으로 가면 가장 이상적이겠습니다만, 그럼 그 지원할 기능 목록을 정하기까지 어떤 기준으로 잘라내야 하는지는 사실 정답이 없는 문제라는 겁니다. 기술적으로 봤을 때 구현난이도를 포함, 현재 프로그램의 구조에 잘 끼워맞출 수 있는 것인지 볼 수도 있고, 무조건 이건 사용자가 원하는대로 가야 한다는 식이 있을 수도 있고 그 둘의 절충안이 있을 수도 있겠죠.
어떤 분들은 자신이 처한 상황을 매우 잘 분석해서 정말 도움을 드리고싶게끔 하시는 경우도 있지만, 어떤 분들은 무조건 자기가 필요로 하는 것을 해결해달라고 하는 경우도 많습니다. 물론 저 또한 제가 사용하는 다른 제품이나 소프트웨어에 대해서 그런 태도를 보일 때도 있을 것입니다. 어쨌든, 이런 사용자 지원 요청들을 중간에서 적절하게 잘라서 영양가 있는 것만 골라내야 하는데 그게 참 어렵습니다. 누가 그 일을 할 것인가도 문제고, 누가 그 기준을 세울 것인가도 문제고...
* * *
한편 얼마 전 이런 글을 읽었습니다. 컴퓨터가 일상에서 너무나 자주 사용되는 물건이 되었기 때문에, 이제는 마치 펜과 종이를 다루듯 컴퓨터 교육도 변해야 한다는 내용이었습니다.
예를 들면, 국어 시간에 글쓰기 방법을 가르치면서 문단 개념과 함께 HTML의 p 태그와 br 태그의 차이점을 알려준다든지, 수학 시간에 함수를 배우면 이 개념을 그대로 구현한 함수형 프로그래밍 언어 실습을 한다든지, 가사에 관해 다루는 가정 시간에는 컴퓨터 운영체제 설치하는 방법을 가르친다든지 말이죠.; 미술 시간엔 문서 디자인 정의하는 방법을 실습해보고, 음악 시간엔 MIDI 소프트웨어로 써보며, 도덕 시간에는 네티켓에 대해 배우는 겁니다.
컴퓨터는 현대의 학생들에겐 마치 연필과 같은 존재입니다. 더이상 '컴퓨터'라는 별도의 과목에 가두어두기보단 생활과 모든 분야에 자연스럽게 녹아들어갈 수 있도록 해야 한다는 것이 그 주장의 요지입니다.
한 가지 질문을 해보겠습니다. 이 글을 보시는 여러분들 중 워드프로세서의 구조적 서식 기능을 얼마나 사용하시나요? 구조적 서식이란 미리 제목, 부제목, 문단, 캡션 등의 속성을 글에 적용해놓고 각각에 대한 서식을 정의함으로써 문서 전체에 일관성있는 디자인을 적용하는 걸 말합니다. 웹에 비유하자면 h1, h2, h3, p 태그 등으로 잘 작성해놓은 문서에 CSS로 서식을 입히는 것과 같죠.
이런 기능이 있다는 것을 모르거나, 있는 걸 알고 있어도 그냥 당장 눈에 잘 보이면 되니까-하고 안 쓰는 경우도 있을 것입니다. 혹은, 어딜가나(다른 프로그램으로 옮겨서 보거나 다른 문서에 붙여넣었을 때) 내가 편집한 건 무조건 똑같이 보여야 한다는 생각 때문일 수도 있겠죠. 가끔은 그런 구조화 기능이 실제 사용자가 필요로 하는 구조화를 미처 다 지원하지 못하여 어쩔 수 없는 경우도 있습니다.
특히 마지막과 같은 경우로 얼마 전 아버지가 쓰실 파워포인트 슬라이드 정리를 했었는데, 파워포인트가 제공하는 '제목 - 항목 나열'의 구조로는 '제목 - 현재 섹션 - 1개 이상의 페이지 부제목 - 부제목 별 항목 나열'이라는 구조를 도저히 흡수시킬 수 없었기 때문에 결국 일일이 서식 노가다를 해야 했었습니다.
* * *
사람들이 컴퓨터를 컴퓨터로 보지 않고 일상에서의 도구로 보게 되는 날이 오면, 아마도 지금은 기술자들이나 다루는 추상화라고 생각하는 것들이 자연스런 상식으로 받아들여지거나 아니면 애초에 기술이 존재하는지 모를만큼 자연스러워지거나 하게 될 것입니다.
그렇지만 언제나 그렇듯 추상화의 구멍이 생기는 순간 어쩔 수 없는 부분들이 생깁니다. 바로 위의 파워포인트 서식 사례가 바로 그렇습니다. 그러면 여기서 제가 마이크로소프트에 저런 서식 구조도 지원해달라고 건의해야 할까요? 만약 건의를 해서 받아들여진다면, 결과가 사용자가 직접 파워포인트의 템플릿을 정의하고 각각에 대한 디자인 요소 이름을 정의할 수 있게 만든다면 디자인 서식들이 이를 '일반적으로 잘' 지원할 수 있게 하기 위한 오버엔지니어링이 엄청날 겁니다. 그리고 그게 저한테는 편하다손 치더라도 다른 사람들한테도 편할 것인지는 절대 장담할 수 없습니다.
제가 보기엔 텍스트큐브 포럼에 올라오는 많은 건의와 질문들 중 이런 경우도 종종 있는 것 같습니다. 물론 그렇다고 사용자분들께 건의하지 말라는 건 아닙니다. 언제나 그렇듯(^^) 모든 분들의 의견은 어떤 식으로든 소중하니까요. 다만 그러한 건의들의 우선순위를 결정하고 그 기준을 세우고 거기에 적절한 인력을 할당하는 일은 정말 어렵다는 이야기를 하고 싶은 것입니다. 기준이 구체화될수록 결정은 쉬워지겠지만 그만큼 놓치는 것도 많을 겁니다.
* * *
위지윅 에디터는 무조건 사용자가 눈에 보이는 문서를 편집하기 쉽게 만들어져야 할까요 아니면 문서의 구조화를 통해 서식 기능을 활용하도록 만들어져야 할까요?
개발자가 아닌 분들은 이런 문제에 대해 어떻게 생각하시나요? 정말 궁금합니다.
실종아동찾기 캠페인 (findingNemo 프로젝트) 관련 서버 장애 및 오류 복구 안내
머리아픈 이야기 2008/10/08 17:37실종아동 찾기 캠페인 프로젝트 및 플러그인 동작 오류에 대한 안내를 드립니다.
10월 1일부터 TNF/Needlworks 의 메인 서버인 TNF1에 오류가 생겨 이후 서버 이전 및 복구 작업을 진행하였습니다. 그 과정에서 실종 아동 찾기 플러그인 파일의 마지막 백업일이 2008년 2월이라 당시의 파일을 복원하며 임시파일인 RSS 캐시 데이터가 10월 8일 새벽 4시경부터 오전 10시 30분까지 노출되었습니다. 이로 인하여 과거의 정보가 출력되는 문제와 함께, 해당 데이터를 12시간 단위로 캐싱해서 사용하는 티스토리의 플러그인도 과거 정보를 보여주는 문제가 있었습니다.
현재는 서버 복구 작업및 과거 캐시 파일들에 대한 삭제 작업이 이루어진 상태입니다.
이번 데이터 장애는 서버 복구 과정에서 과거 파일을 사용하면서 해당 서비스와 같이 백업 되었던 임시파일이 출력된 경우이므로, 실종 아동의 데이터 보관과는 아무런 연관이 없음을 알려 드립니다. 또한 TNF/니들웍스의 서버 복구 과정에서 일어난 사고이므로, 캠페인에 관련해서 도움을 주시는 어린이 재단과는 관련이 없음도 함께 알려 드립니다.
예상치 않은 긴급 복구 작업으로 인하여 과거의 임시 저장 데이터가 출력된 부분에 대하여 관계자 분들께 죄송하다는 말씀을 드립니다. 또한 관련하여 문제를 해결하기 위해 도움을 주신 어린이 재단 및 다음 커뮤니케이션 측에 감사의 말씀을 드립니다.
PHP5와 텍스트큐브
머리아픈 이야기 2008/08/29 01:14오랜만에 글을 적습니다. 핑계라면 핑계이겠습니다만, 살아가면서 가끔 여러 일들을 겪으며 정리가 필요한 시기가 니옵다. 비단 한 사람만이 아니라 사람들의 모임에도 그런 시가기 오지요. 그 시기를 어떻게 지나가는지가 참 중요하다는 생각이 듭니다.
간만의 글 치고는 고른 내용이 좀 딱딱하겠습니다. 텍스트큐브 1.8 이후부터 실행을 위해 PHP5.2 와 MySQL 4.1 이상을 기본 사양으로 요구하는데, 오늘은 그에 대한 설명이나 변화점을 이야기 하려고 합니다.
국내의 대부분의 PHP 어플리케이션들은 PHP4를 기준으로 제작되고 있습니다. 여러 이유가 있지만, 가장 큰 이유는 프로그램을 설치할 수 있는 환경을 주로 제공하는 호스팅 업체들이 PHP5 를 지원하는 경우가 적기 때문입니다. PHP4 와 PHP5 는 숫자 하나 차이가 나지만, 굉장히 다른 특성을 보이는 언어입니다. 그래서 PHP4를 기준으로 만들어진 응용 프로그램들은 PHP5에서 동작하지 않는 경우들이 간혹 있습니다.
그렇다고 PHP5 가 굉장히 새로운 언어는 아닙니다. 물론 PHP4 보다는 최근에 나왔지만, 어디까지나 상대적으로 보았을 때 입니다. 올해는 PHP5가 나온지 5년이 된 해입니다. PHP 5.3과 PHP6 이 개발 중에 있으며, 멀지 않아 사용할 수 있게 될 것입니다.
지금까지 PHP 4.3을 기준으로 제작되던 텍스트큐브가 PHP 5.2를 기본 환경으로 선택하게 된 근본적인 이유는, 더이상 PHP 4 가 개발되지 않는다는 점 때문입니다. PHP 4의 공식적인 지원은 얼마전 종료 되었습니다. PHP.net에서는 보안을 포함한 여러 문제로 사용자들이 PHP 5.2 이상으로 이주할 것을 권고하고 있습니다. 웹을 둘러싼 환경은 빠른 속도로 변하게 될 것입니다. 이러한 과정에서 니들웍스와 텍스트큐브 개발 그룹도 결정을 해야 했습니다.
텍스트큐브 1.7의 과거 환경 지원은 굉장히 폭넓습니다. PHP 4.3 과 MySQL 3.23 이상의 환경을 지원합니다. 이러한 지원은 사용자에게는 환경에 대한 고민을 하지 않아도 되는 이점이 있지만, 코드의 효율성 입장에서는 문제가 있습니다. 더 상위의 환경에서 텍스트큐브를 돌려도 속도의 이점을 볼 수 없기 떄문입니다. 예를 들면, 윈도우 비스타가 지원되는 환경에서도 도스 시절의 프로그램을 돌릴 수는 있지만 그 프로그램이 윈도우 비스타의 성능을 모두 끌어낼 수는 없는 것과 마찬가지입니다. 텍스트큐브가 하위 호환 모드로 동작할 때, 유니코드 환경 지원과 MySQL 3 데이터 베이스 지원을 위해 들어가는 서버 리소스는 텍스트큐브 전체 동작시 사용하는 리소스의 1/3 이상입니다.
개발 패러다임의 변화도 PHP 5.2를 택한 이유입니다. 텍스트큐브의 일부 컴포넌트는 객체 지향 패러다임을 기반으로 작성 되었지만, PHP 4 의 객체 지원은 굉장히 부족합니다. 또한 속도 부분에서 큰 손해가 있기 때문에 텍스트큐브 1.7까지는 일부의 객체 기반 코드 일부의 순차 처리 코드로 이루어져 있습니다. 그러나 텍스트큐브 2.0에서 사용될 TCF (텍스트큐브 코어 프레임웍 – 가칭입니다.)를 개발하는 과정에서 개발에 참여하는 분들은 현재 코드의 혼란을 최소화 하기 위해서 코드의 패러다임을 변경하기를 원했습니다.
위에서 설명 드린 것과 같이 PHP.net 에서의 PHP 4의 지원 중단, 과거 환경 지원으로 인하여 발생하는 성능 감소, 새 프레임웍을 둘러싼 개발 패러다임의 변화를 이유로 텍스트큐브 1.8 이후부터는 PHP 5.2와 MySQL 4.1 이상을 요구합니다. 새로운 프레임웍은 텍스트큐브 2.0부터 본격적으로 도입될 예정이며, 텍스트큐브 1.8은 텍스트큐브 1.x 코드를 새로운 환경의 특징을 살려 최적화하는, 다리 역할을 하는 주춧돌이 될 예정입니다. 텍스트큐브 1.8은 그 전까지 막혀 있던 병목들을 제거하여, 단위 시간당 더 많은 트래픽을 더 적은 CPU와 서버 로드를 사용해서 처리할 수 있는 가능성을 시험하게 됩니다.
간단하게 결졍된 내용은 아니었습니다. 기본 요구 환경의 변화와 관련하여 내부적으로 많은 토론이 있었습니다. 한국 호스팅 업체의 환경이 과련 이러한 요구 사항을 받아 줄 것인지부터, 새로운 환경의 어떤 특징을 살려서 코드를 써 나갈 것인지에 대한 이야기도 있었습니다.
그 논의에 참여하며 한가지 확신한 것이 있습니다. 정체는 무기력을 낳습니다. 텍스트큐브를 현재 한국 웹 호스팅의 현실에 맞게 개발하는 것도 중요합니다. 그렇지만 조금 눈을 밖으로 돌리고 조금 앞을 내다보려고 합니다. 지금이 현실에 대한 안주가 아닌 변화를 위한 적기입니다. 언젠가는 시작해야 하는 일입니다. 그래서 시작하려고 합니다.
덧) PHP 4.3 사용자 분들이 많고, 당장 쉽게 새로운 환경으로 이전하기 힘든 부분을 어떻게 지원할 것인지에 대한 논의도 있었습니다. 텍스트큐브 1.8을 개발하는 중, 성능 향상이나 기존 버전에서 구현이 불가능한 부분들을 제외한 기능이나 인터페이스 추가와 같은 부분들은 기존의 텍스트큐브 1.7 에도 계속 반영하고 발표할 예정입니다.
Needlworks.org i18n 적용!
머리아픈 이야기 2008/06/20 08:25안녕하세요. 오랜만입니다.
이번 토요일에 스웨덴을 떠나 일요일이면 드디어 기나긴(그러나 한편으론 짧디 짧은) 반년 동안의 교환학생 생활을 마치고 한국에 돌아가는 daybreaker입니다. (어디서 '날뷁~~'하고 부르는 소리가 들리지만 무시하시고-_-)
이번에 알려드릴 소식은 needlworks.org 업데이트 내용입니다. 겉보기에는 전혀(...) 별 차이가 없겠지만 내부적으로는 약간의 변화가 있었습니다. 우선 기반 프레임웍으로 사용되는 Django의 버전업에 맞추어 새로 업데이트한 후 호환성 문제들을 수정하였고, 특히 중요한 것은 이제 외국에서 needlworks.org에 접속할 경우 영문으로 소개 내용이 표시되도록 했다는 것입니다. (사실 뜬금없이 i18n 지원을 넣게 된 건 제가 그동안 외국 친구들에게 needlworks 명함을 나눠주면서 홈페이지에 들어왔을 때 영문 지원이 없으면 좀 황당해하겠다 싶어서 그랬다고 말 못합니다..-_-..) 한편 Mac 환경에서 글꼴이 좀더 예쁘게 보이도록 CSS를 일부 변경하였습니다.
이것은 Django의 i18n 프레임웍을 이용한 것으로, 제가 추가로 코드를 짠 것은 전혀 없고 단지 설정 파일과 템플릿 파일 및 python 코드 파일에 번역할 문자열을 표시해주고 번역한 데이터를 넣어준 것 뿐입니다. 역시 python을 사랑할수밖에 없군요..=3=3==3
웹브라우저 언어 설정을 영어 우선으로 놓고 들어가본 모습.
물론 번역을 급조했기 때문에 번역의 질은 장담 못합니다만 그래도 없는 것보다는 낫겠지요.;; 번역 내용은 앞으로 차차 개선할 생각이며, (이렇게 쉽게 가능할지는 모르겠지만) textcube.org도 i18n을 할 예정입니다. :D
혹시, 일본어·중국어 등 다른 언어로 needlworks.org 번역을 도와주실 분은 이곳에 비밀댓글로 메일 주소를 달아주시면 번역 분량 파일을 보내드리도록 하겠습니다.
예외 처리는 언제나 확실하게!
머리아픈 이야기 2008/05/14 10:06정말로 오랜만의 글이로군요. 간만에 재미있는, 그러나 슬픈(...) 삽질기를 하나 들려드릴까 합니다. ㅠ_ㅠ
지금 스웨덴 교환학생의 가장 마지막 관문(?)으로 Musical Communication and Music Technology라는 매우 긴 이름을 가진 과목의 기말 프로젝트를 하는 중입니다. 발표는 오늘(!)이지만 프로젝트 기간 자체가 워낙 짧았던 데다 같이 하는 애들이 지난 주에 시험이 계속 겹치는 등의 이유로 실제 진행은 거의 3일 벼락치기로 하는 중이지요;;;
과목 이름에서 유추할 수 있듯 프로젝트 내용은 상당히 '미디어 아트'적인 내용입니다. 과제로 했던 Lab에서 마지막에 했던 것이 실시간 비디오프로세싱 프로그램인 EyesWeb을 이용하여 사람의 동작을 웹캠으로 찍어 음악을 컨트롤하는 내용이었는데, 그것을 좀더 확장하기로 한 것이지요. 처음엔 막연히 뭘 더 넣을 수 있을까 고민하다가 요즘 한창 유명해진 니코니코조곡 오토마리오 버전 동영상을 보고 실제 몸의 움직임을 추적하여 실제 사람이 연기하는 마리오를 만들면 재밌겠다 싶어서 그쪽으로 방향을 잡았습니다. (그게 어젭니다-_-)
수업 때 소리를 컨트롤하는 프로그램으로 실시간 소리 합성이 가능한 오픈소스 사운드 프로그래밍 툴인 Pure Data를 이용했는데, 이게 사운드 생성은 쉬워도(?) 기존에 녹음된 사운드를 재생하는 것이 난감하더군요.; 그래서 EyesWeb에서 Open Sound Control(이하 OSC)이라는 프로토콜을 이용해 UDP로 쏴주는 메시지들을 직접 받아 소리 재생을 하는 프로그램을 짜면 어떨까 싶었습니다.
자, 서론이 길었습니다.<br/> 제가 요즘 유용하게 이곳저곳 잘 써먹는 Python을 이용하기로 했고, 크로스플랫폼 소리 재생을 위해 pygame 라이브러리를 써서 쉽게 소리 재생을 할 수 있었습니다. 또한 OSC 프로토콜을 파싱해주는 것도 이미 Python으로 구현되어 있었기 때문에 그 라이브러리를 가져다 쓰니 통신도 금방 구현할 수 있었지요. 근데 갑자기 어느 순간부터, EyesWeb에서 계속 쏴주고 있는 UDP 데이터를 못 받고 block되어버리는 겁니다.
EyesWeb 문제인가 싶어서 데이터 전송 속도를 줄여보기도 하고, 파일을 새로 만들어보기도 했고 윈도우 문제인가 싶어서 방화벽에 UDP 포트 추가도 해보고 심지어 패킷스니핑 프로그램까지 썼습니다.;; 또 OSC 라이브러리 문제인가 싶어서 멀티쓰레드로 된 구현을 싱글쓰레드로 바꿔보기도 하고 별의별 짓을 다 해봤지요. 일단 혐의(?)는 소켓 쪽에 문제가 있을 것으로 생각하고 있었습니다.
근데 여기가 스웨덴이다보니, 저보다 Python을 잘 하시는 퍼키군님과 같은 다른 사람들의 도움을 요청하자니 다들 자고 있을 시간이더군요. -_-; 혼자 힘들게 구글링하며 온갖 삽질을 다 하다가, 결국 가장 원시적인 디버깅 방법, 즉 print 찍어보기를 해봤습니다. 그리고 1분만에 좌절했습니다. (........)
원인은 세 가지였습니다.
- pygame.mixer.get_busy()를 이용해 현재 재생 상태를 알아내는 부분이 있는데, is_busy()라는 잘못된 이름의 함수를 썼습니다. (이건 전적으로 제 잘못입니다..orz) 근데 이 부분이 항상 실행되는 게 아니고, 받아온 모션캡처 데이터에 따라 반랜덤하게 실행되는 곳이었죠.
- OSC 라이브러리가 멀티쓰레드로 돌며 제가 지정한 핸들러 함수를 호출해주는 방식이었습니다. 따라서 그 안에서 뭔 일이 발생하여 죽더라도 프로그램은 죽지 않았습니다.
- OSC 라이브러리 내부 코드에서 핸들러를 호출하는 부분을 try-except 구문이 둘러싸고 있었는데, 그 except 구문에 어떤 예외를 받을지 지정이 되어 있지 않았습니다. 즉, 모든 예외를 다 받겠다는 것이었죠.
자, 이쯤에서 무슨 일이 벌어졌을까요?
잘못된 이름의 함수를 썼으니 당연히 예외가 발생하여 프로그램이 죽어야 할 것입니다. 하지만 그 예외를 라이브러리 코드 내에서 먹어버렸고, 불행히도 그 try-except가 소켓 데이터를 읽는 while 루프 바로 바깥이라서 루프가 종료되고 결과적으로 해당 쓰레드는 아무 일 없었다는 듯 '정상 종료'를 했습니다. 하지만 메인 프로그램은 계속 돌고 있었죠. 화면에는 아무것도 나오지 않습니다. 게다가 그 잘못된 함수를 호출하는 순간은 제가 카메라 앞에서 어떤 동작을 하느냐에 따라 달라지니 에러가 랜덤하게 발생하는 것처럼 보였던 겁니다. (위에서, 싱글스레드로 바꿔보기도 했다고 썼는데, 이 경우에도 랜덤 발생으로 보였던 겁니다. 게다가 프로젝트 듀가 급하니 마음도 급했던지 차분하게 생각하지 못했던 것도 문제였죠.)
그래서......인생이란 삽질인 것입니다. OTL
여러분, 저같이 애꿎은 사람 희생시키지 마시고 예외 처리할 땐 어느 예외를 받을 것인지 항상 확실하게 지정하는 습관을 들입시다~ ㅠ_ㅠ
연휴 휴유증 +
머리아픈 이야기 2008/02/11 11:48지난 화요일은 기쁨의 시간이었지요.
설날의 명절에 가족들과 함께 한다는 생각에서도 그랬지만, 그보다 매일 반복되는 출근 퇴근의 지겨움 속에서 휴가라 느낄만큼의 긴 연휴가 기다리고 있다는 생각에서 였습니다.
어떻게 지나갔는지 모르게 빠르게 지나가버렸네요.
많이 먹어서 배탈이 난 사람들도 있었을듯 싶은데요,
사실 새벽까지 운전하고 밀리는 고속도로를 내려가서는 첫 연휴의 명절 첫날은 잠에서 헤어나올질 못했답니다.
그리곤 틈을 타, 서로 밀릴거라 눈치만 보고 있던 명절 다음날인 금요일 오전 재빠르게 다시 올라왔지요.
다행이 밀리는 길 없이 올라올 수 있었습니다.
뉴스를 보니 토요일 일요일에 오히려 더 밀렸다고 하더라구요.
사람들의 심리란, 지금쯤 밀리지 않겠지 라고 모두들 같은 생각에 금요일엔 출발하지 않고 미루고 미뤄 토요일에 다들 출발했던 모양입니다.
그렇게 주말은 집에서 보내고 있는데 어젯밤엔 안타까운 소식이 들리더라구요.
다들 들어서 아시겠지만, 화재가 있었습니다. 다행이 명판은 건진듯 싶은데 1호를 태워먹으면서 서로서로 무슨 그리들 변명이 많은것인지 오늘 아침엔 화가 치밀어 오를 정도였습니다.
미리 미리 이런일이 없게 했으면 좋았겠지만, 일이 터지고 나니 뒤물러서서 한다는 말이..
서로 인정할건 인정하고 잘못했으면 용서를 빌고 앞으로는 다시는 그런일이 없도록 하자는 의사를 표현해야하는데 이래서 이렇게 된것이니 사실상 내가 잘못한건 없다 라고 외치는 그 사람들이 더 원망스럽기만 합니다.
긴 연휴를 마치고 월요일에 안그래도 월요병에 난리인데 연휴까지 겹쳐서 몽롱하게 축 쳐저 있는데, 이런소식까지..
어찌나 아침엔 나오기 싫던지 출근하는 차 안에선 다시금 일탈하고 싶은 충동이 생기더라구요.
이를 어째, 이젠 여름 휴가가 있기전까진 별다는 연휴없이 매일매일 일요일만을 손꼽아 기다려야한다는 안타까움만 앞서네요.
이렇게 오늘도 반나절 지나갔다~ 으히
근데 오후는 더더욱 길게만 느껴져~
아이디어
머리아픈 이야기 2007/12/25 23:34가끔 엄청나게 오래된 일을 한참을 돌아와서 해결하게 된다.
텍스트큐브가 태터툴즈였던 시절, 작년 중순즈음엔가 fastCGI 환경 지원에 대한 요청이 들어온 적이 있었다. 당시에는 서버에 fastCGI 환경을 쉽게 구축하지 못하였고, 그래서 자연히 뒤로 밀리게 되었다. 이후 조금씩 workaround들을 통하여 구현을 해 놓았지만 역시 제대로 돌아가지는 못하고 있었다.
작년 말에는 '외국계 호스팅에서 태터툴즈가 잘 안돌아간다' 는 문의를 받았다. 직접 서버의 권한을 받아 들어가 본 결과 서버측에서 mod_rewrite에 대하여 선처리를 미리 해 둔 상태였다. 이 경우를 처리하기 위해서는 rewrite 모듈[footnote]아파치 웹서버 등에 들어있는, 주소를 처리해서 미리 정해놓은 인터페이스로 연결해주는 모듈이다. 텍스트큐브의 글들의 주소가 괴상한 숫자등이 아니라 읽을 수 있는 문자가 되도록 도와주는 모듈.[/footnote] 에 대한 의존도를 확 줄여야 했다. 이런 경우에 주로 사용하는 방법은 rewrite 모듈의 모든 결과를 하나의 파일로 보내고, 그 파일이 요청을 모두 해석해서 처리하는 방식이다. 그러나 당시 간단하게 테스트 해 본 결과 그림파일이나 음악파일 등등등 까지도 모두 php 엔진을 거쳐서 내보내기 때문에 서버에 무리가 있었다. 소스도 엄청나게 고쳐야 했다. 기존의 방식을 고수하기가 힘들어 보였다. 소스를 대대적으로 개수하기에는 언제나 시점의 무리가 있어서 계속 그 일은 뒤로뒤로 밀려왔다.
그러면서 1년이 넘는 시간이 지났고, 잘은 모르지만 머릿속 어딘가에서 그 생각이 계속 돌아가고 있었나보다. rewrite 모듈이 없는 상황에서 돌아가는 예외 처리를 추가한다거나, fastCGI를 지원하는 예외 처리를 추가한다거나 하는 식으로 대응해 가다가 사흘쯤 전 샤워하다가 아이디어가 떠올랐다. define으로 상수를 정의하는데, 그 상수를 두 번 정의할 경우 어느쪽이 무시되는가? 에 대한 생각이었다. 실험해 보니 처음 define만이 유지되었다. 그 때부터는 문제가 연속적으로 죽 풀렸다.
텍스트큐브는 /lib/suri.php 를 통하여 현재 주소 체계를 해석하고, 어떤 부분이 주소이고 어떤 부분이 파라미터인지 파악해 낸다. 그리고 각 인터페이스 (blog 하위의 디렉토리들은 사실 인터페이스라고 부르는 것이 더 적당하다.) 에서 필요한 라이브러리를 통째로 불러낸다. 과거에는 불가능했지만, 두달 사이에 이루어졌던 컴포넌트 및 라이브러리의 독립화로 인하여 라이브러리를 불러오는 시점의 의존성이 사라졌다. 따라서 suri가 실제로 동작하기 이전이라면 주소 처리 부분을 기존의 suri가 이해하기 좋게 만들어서 suri에 코드 한 줄을 추가하여 호환성을 유지할 수도 있을 것이다. 또한 각 인터페이스에서는 모든 포함관계의 기준이 되는 ROOT를 미리 정의하는데, 인터페이스 파일이 불려지기 이전에 ROOT를 일률적으로 정의해 버리면 이후의 모든 파일 포함관계들도 전부 수정 없이 이식할 수 있지 않을까.
그래서 크리스마스 이브 전날부터 크리스마스 기간 내내 그 부분을 구현하였다. 일단 (못 고치면 블로그 못쓴다-는 자신에게로의 압박을 위해서) 개인 서버의 아파치 웹서버를 fastCGI 기반으로 변경하였다. rewrite 모듈이 보내주는 값을 해석하는 부분은 최소한의 크기로, 또한 앞에서 처리해야 유리한 루틴은 최대한 앞에서 처리하는 식으로 작성하였다. 덕분에 기존 코드는 거의 손을 대지 않은채로, fastCGI나 다양한 rewrite module들에 대한 대응이 가능해졌다.
말이 길었다. 결론은 간단하다. 아이디어는 하늘에서 떨어지지는 않는다. 그렇다고 아이디어를 낼려고 머리 싸매고 있다고 튀어 나오는 것도 아니다. 문제를 완벽히 이해할 때 까지 생각하고 곱씹는 과정에서 문제의 한계라고 스스로 생각하고 있는 무엇인가를 넘기위한 뇌의 싸이코 댄스가 시작된다. 그 댄스 중 일부가 실제로 먹히면 그 댄스에 아이디어라는 이름이 붙게 된다.
아이디어는 사고의 형태에 붙는 명칭이 아니라 이미 일어난 사고에 붙이는 자격이다.
요즘 잠수타고 있는 이유
머리아픈 이야기 2007/12/10 14:01....랄까, 역시 전산과에서 빡세기로 소문난 운영체제 과목 플젝이 주 원인입니다. 이거 때문에 수리물리 숙제도 매번 딜레이하고.. ㅠ_ㅠ 이른바 Heisenbug의 세계를 아주 그냥 몸소 체험하고 있습니다.;
긴 말은 필요 없을 것 같고 스크린샷 한장으로 대체합니다.;
대망의 Virtual Memory 구현 중
오픈소스 활동을 바라보며
머리아픈 이야기 2007/11/16 02:17왜 저는 여기에 글을 쓰면 거의 항상 심각한 글만 쓰게 되는 걸까요.. -_-;;
각설하고 오늘도 이야기 하나 풀어볼까 합니다.
얼마 전 제가 있는 동아리인 SPARCS에서 워크샵이 있었습니다. 그때 제가 발표한 주제가 "학생으로서 오픈소스 활동에 참여하기"였지요. 워낙에 벼락치기로 준비했던 발표라서 원했던 수준의 퀄리티는 나오지 못했지만 다행히 발표에 대한 평가는 좋았던 것 같습니다.
그 발표에서 중점을 두어 이야기한 내용 중에 '오픈소스 참여자들은 굉장한 신뢰 기반의 커뮤니티를 이룬다'는 것이 있습니다. 그럴 수밖에 없는 것이, 얼굴도 모른 채 이뤄지는 온라인 상의 만남으로 시작하여 공통의 관심사와 필요성에 의해 엮어지는 대개의 오픈소스 프로젝트를 생각해보면 다른 참여자들에게 일정 수준 이상의 권한을 부여하는 것은 그 사람이 이상한 짓을 하지 않을 것이다(-_-)라는 믿음이 있어야만 가능합니다.
발표할 때 지난 봄학기 때 들었던 소프트웨어공학개론 수업의 내용이 실제 오픈소스 활동에서는 도움이 별로 되지 않은 것 같다는 것을 언급했었는데 끝나고 나서 당시 조교를 했던 한 선배분과 술자리에서 얘기를 했습니다.
그 선배의 말을 들어보니 오픈소스 커뮤니티는 소프트웨어공학 쪽에서도 꽤 관심있게 바라보고 있는 것 중에 하나라고 하더군요. 그말인즉슨, 오픈소스 커뮤니티는 회사와 같은 조직에서 이루어지는 개발 활동과 많은 차이를 보인다는 것이었습니다. 밥벌어 먹고 살려고 하는 활동이 아니라는 점, 따라서 강제력이 거의 없다는 점, 스스로 재미있어서 말리는(!) 일이라는 점이 기존 소프트웨어공학에서 깔고 있는 가정으로는 설명이 안 되는 거지요.
당장 니들웍스만 보더라도, '코드로 대화가 가능하다' 수준에 도달해버렸으니 문서화가 의미 없게 됩니다. -_-; 물론 사용자들을 위한 매뉴얼 작성이나, 신규 멤버의 유입을 위해 어느 정도의 문서화가 필요하고, 그것을 위해 현재 graphittie님이 열심히 프로젝트를 진행 중이시지요.; 뭐 꼭 그런 것뿐만 아니라 SE에서 제시하는 다양한 방법론들이 오픈소스 커뮤니티에서는 다소 다르게 적용되는 부분들이 있는 것 같습니다.
한편, 신뢰에 기반한 커뮤니티가라는 점이 좋게 말하자면 그렇지만 나쁘게 말하자면 폐쇄적이라는 뜻도 됩니다. 일정 수준 이상의 신뢰를 얻어 핵심 멤버로 참여하기 위해서는 그만큼 많은 노력과 시간을 들여야 한다는 뜻이고 신규 개발자의 유입을 막는 걸림돌로 작용할 수 있습니다. 그래도 어느 정도 궤도에 오른 오픈소스 프로젝트의 경우는 그 자체로서 매력을 가지고 있기 때문에 참여를 원하는 사람들이 계속 생겨나지만, 그 단계에 다다르기 전에 최초 개발자들이 개인 사정으로 바빠진다거나 하여 흐지부지되는 경우는 망하기 딱 좋은 조건이 되죠.
무엇이든 지나치면 안 되는 것 같습니다. 신뢰가 필요하긴 하지만 그것이 지나치면 폐쇄적으로 변할 수 있겠지요.
오픈소스를 보면서 IT 기술이 가져다 준 의식의 변화가 정말 대단하다는 생각이 듭니다. 생전 얼굴도 모르는 사람들끼리 하나의 목표를 향해 일하면서 결과물을 낼 수 있다는 것은 인류 역사에 있어 정말 대단한 것이 아닐 수 없습니다. 물론 그래도 사람-_-인지라 프로젝트가 진행되면서 오프라인 모임을 가지며 서로 끈끈한 유대 관계를 형성하게 되기는 합니다만 근본적으로 그러한 출발은 대개 온라인에서 이루어지지요. 그리고 그런 사람들 사이의 유대가 형성될 수 있다는 것 자체가 예전엔 불가능했던 것이기도 하구요.
이제 막 인터넷이 대중화되기 시작한 지 10년이 지났습니다. 그 사이에 우리의 사고 방식에 몰아친 변화를 생각하면 가히 놀랄 만한 일입니다. 오픈소스를 비롯하여, 앞으로는 또 어떤 패러다임과 사상이 등장하게 될까요? 또한 그것을 받아들이고 유용하게 사용하기 위해 우리는 어떻게 변해야 할까요?
- 텍스트큐브 공지사항 블.... 6
- AVATAR. 9
- 도움닫기. 3
- 컴퓨터 길들이기. 3
- 새해인사 올려요. 2
-
지적사춘기의 끝.
아침놀 Blog 2010 -
판도라의 상자를 연 듯 하다.
Sleepy Tiger 2010 -
<아바타>와 카메론의 사이비....
The Dispossessed 2010 -
성급한 일반화의 오류.
Sleepy Tiger 2010 -
걸작! 아바타.
Sleepy Tiger 2010
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
비밀방문자 2014
inureyes 2014
비밀방문자 2013
화사함 2012
LonnieNa 2010