LAMP(Linux®, Apache, MySQL, PHP/Perl) 아키텍처를 활용하는 응용 프로그램은 끊임없이 개발되고 배포되고 있습니다. 하지만 때로 서버 관리자는 다른 사람이 작성했다는 이유만으로 응용 프로그램 자체에 대한 통제권이 거의 없습니다. 기사 셋으로 이뤄진 이번 연재물은 응용 프로그램 성능을 향상시킬 서버 환경 설정 항목을 다룹니다. 연재 마지막인 세 번째 기사에서는 최대 성능을 발휘하도록 데이터베이스 계층을 조율하는 데 초점을 맞춥니다.

MySQL 조율에 대해

MySQL 서버를 빠르게 하기 위한 방법은 세 가지가 있는데, 효율이 낮은 쪽에서 높아지는 쪽으로 나열하면 다음과 같다.

1. 하드웨어로 문제를 푼다.
2. MySQL 프로세스 설정을 조율한다.
3. 질의를 최적화한다.

DB2®로 이주 MySQL에서 IBM® DB2®로 이주하는 명쾌하고 비용이 들지 않는 방법을 찾고 싶은가? "MySQL 또는 PostgreSQL에서 DB2 Express-C로의 마이그레이션 (영문)" 기사에서는 이주 도구를 활용해 쉽게 이전하는 방법을 보여준다. 공짜 DB2 Express-C를 내려받아 지금 바로 시도해보자.

하드웨어로 문제를 푸는 방법이 가장 먼저 떠오른다. 특히 데이터베이스가 자원을 잡아먹는 괴물이라는 사실을 감안하면 말이다. 하지만 이 해법에는 한계가 있다. 현실을 고려할 때 CPU나 디스크 속력은 두 배로, 메모리 용량은 네 배에서 여덟 배 정도만 늘일 수 있다.

두 번째로 좋은 방법은 mysqld라는 MySQL 서버 조율이다. 이 프로세스 조율은 올바른 위치에 메모리를 할당하고 어떤 부하가 걸릴지 mysqld에 알려주는 조정 기법을 의미한다. 디스크 속력을 좀 더 빠르게 만드는 대신, 필요한 디스크 접근 횟수를 줄이는 편이 유리하다. 비슷하게, MySQL 프로세스가 올바르게 동작하도록 만드는 조율은 개발자가 임시 디스크 테이블과 파일 여닫기 같은 배경 작업에 신경을 쓰는 대신 질의에 대한 서비스에 좀 더 많은 시간을 보낼 수 있음을 의미한다. mysqld 조율은 이번 기사에서 주로 다룰 내용이다.

최고로 좋은 방법은 질의 최적화다. 이는 적절한 색인을 테이블에 만들어 놓고, MySQL의 장점을 최대로 활용하는 방향으로 질의를 작성하는 조율 기법을 의미한다. 이번 기사에서 질의 조율을 다루지는 않지만(이 주제로 책을 써도 되겠다), mysqld 환경 설정을 변경해 조율이 필요한 질의를 보고하도록 만든다.

중요한 조율 순서를 제시하긴 했지만, 그렇다고 해서 적절히 조율을 마친 질의를 위해 하드웨어나 mysqld 설정을 무시하라는 말은 아니다. 느린 기계는 느린 기계일 뿐이며, 제대로 작성한 질의를 돌리더라도 부하가 걸려 실패하는 경우를 목격했는데, mysqld가 질의를 서비스하는 대신 바쁘게 움직이느라 시간을 소모하고 있었기 때문이었다.

LAMP(Linux®, Apache, MySQL, PHP/Perl) 아키텍처를 활용하는 응용 프로그램은 끊임없이 개발되고 배포되고 있습니다. 하지만 때로 다른 사람이 작성했다는 이유만으로 응용 프로그램 자체에 대한 통제권이 서버 관리자에게는 없습니다. 기사 셋으로 이뤄진 이번 연재물은 응용 프로그램 성능을 향상시킬 서버 환경 설정 항목을 다룹니다. 첫 번째 기사는 LAMP 아키텍처, 성능 기법, 기본적인 리눅스 커널, 디스크, 파일 시스템 미조정을 다룹니다. 이어지는 기사에서는 아파치, MySQL, PHP 컴포넌트를 조율하는 방법을 다룹니다.

리눅스, 아파치, MySQL, PHP(또는 펄)은 일정 목록부터 블로그와 전자 상거래 사이트에 이르기까지 많은 웹 응용 프로그램의 토대가 된다. 워드프레스와 플리그(Pligg)는 강력한 고성능 웹 사이트를 유지하는 공통 소프트웨어 패키지다. 이런 아키텍처는 LAMP라고 알려졌다. 거의 모든 리눅스 배포판에는 리눅스, 아파치, MySQL, PHP와 펄이 포함되어 있으므로 LAMP 소프트웨어 설치는 식은 죽먹기다.

설치가 쉽기 때문에 소프트웨어 실행까지 쉬워보일지도 모르겠지만, 이는 사실이 아니다. 궁극적으로 응용 프로그램 부하는 백엔드 서버에 포함된 설정값을 무력화하며, 결국 응용 프로그램 성능 저하가 일어난다. LAMP 설치는 지속적인 감시와 조율과 평가를 요구한다.

시스템을 조율하는 작업은 사람마다 의미가 달라진다. 이번 연재에서는 리눅스, 아파치, MySQL, PHP라는 LAMP 컴포넌트 조율에 초점을 맞춘다. 응용 프로그램 자체 조율은 또 다른 복잡한 문제다. 응용 프로그램과 백엔드 서버 사이에는 공생 관계가 있다. 잘못 조율된 서버는 최상의 응용 프로그램조차도 부하가 걸릴 경우 실패하도록 만들며, 잘못된 응용 프로그램을 앞에 놓고 서버 조율을 해봤자 굼벵이를 달팽이로 만들 뿐이다. 다행스럽게도 적절한 시스템 조율과 감시는 응용 프로그램에 존재하는 문제점을 찾아내준다.

리눅스(Linux®) 커널은 거대하고 복잡한 운영체제의 핵심이며, 커다란 몸집에도 불구하고 하위 시스템과 계층 구조를 사용해서 조직화되어 있습니다. 이 기사에서는 리눅스 커널의 일반적인 구조를 살펴보고 주요 하위 시스템과 핵심 인터페이스를 파악합니다. 좀더 깊이 파고 들고 싶다면 다른 IBM 기사를 읽어보세요.

이 기사의 목표는 리눅스 커널을 소개하고 아키텍처와 주요 컴포넌트를 살펴보는 데 있다. 우선 리눅스 커널 역사부터 간략하게 짚어보기 시작해 다음으로 3만 피트 상공에서 리눅스 커널 아키텍처를 살펴보고, 마지막으로 주요 하위 시스템을 검토하겠다. 리눅스 커널은 코드가 600만 행이 넘으므로 소개글을 너무 장황하지 않게 줄였다. 좀더 깊이 파고 들고 싶다면 참고자료를 살펴보자.

Office Open XML(OOXML)의 ISO 최종 투표에 즈음하여

한국 대표단에게 보내는 글

본 서명은 Microsoft가 제안하여 ECMA 376 표준이 된 Office Open XML(OOXML)의 ISO JTC-1 최종 투표를 앞두고 한국 대표단이 OOXML의 보완 사항을 신중히 검토하여 투표해 줄 것을 촉구 합니다.

앞서 2007년 9월 ISO JTC-1 위원회 1차 투표 시 아래와 같은 이유로 한국 대표단에게 1,000여명의 서명을 받아 OOXML 표준안에 대해 반대 투표를 해 줄 것을 촉구한 바 있습니다.

• OOXML안은 대체할만한 다른 표준안이 존재 한다.
• OOXML안은 불완전 하며 플랫폼 종속적이다.
• OOXML안은 모호한 특허 문제 때문에 제 3자 구현이 제한된다.
• OOXML안은 국내 다양한 S/W 개발 환경을 제한할 것이다.

이에 한국 대표단은 1차 투표에 반대표를 행사하면서 총 23가지의 수정 요청 사항을 제출 하였으며, 이제 마지막 투표를 앞두고 있습니다. 이에 아래 서명을 한 한국 소프트웨어 개발자 일동은 아래의 사항에 동의 합니다.

1. 한국 대표단이 제기한 수정 요청 사항에 동의 한다.

한국 대표단의 수정 요구 사항을 요약 하면 크게 아래 4가지 사항과 같습니다.

1. OOXML 표준안이 기존 ODF와 플러그인이 아니라 표준 스펙 그 자체로 호환성을 유지하도록 수정해야 한다.
2. OOXML 표준안의 IE 기반 기술 규격이 리눅스나 Firefox, Safari, Opera 등의 브라우저도 지원 해야 한다.
3. OOXML 표준안 중 12개의 MS Office 레거시 스펙을 좀 더 자세하게 설명해야 한다.
4. OOXML 표준안 중 VML 및 DrawingML 등 기존 표준이 있는 부분을 삭제해야 한다.

2. 한국 대표단의 신중한 기술적 검토를 요청 한다.

한국 대표단이 1차 투표 이후 수정 보완된 OOXML 표준안이 당시 요청한 수정 요청 사항과 부합 하는 지 정확하게 검토해 주실 것을 요청 드립니다.

1. OOXML 표준안에 대한 기술적 검토가 충분히 이루어 지길 기대한다.
2. OOXML 표준안에 대한 수정 요청 사항이 충분히 받아들여졌는지 검토해주길 기대한다.
3. OOXML 표준안에 대한 수정 요청 사항이 100% 받아들여지지 않았을 경우 최종 투표에서도 반대 투표를 해주길 촉구한다.

2008 년 3 월 25 일

시스템 사용량이 적어진 한밤중에 작업을 실행할 필요가 있거나 일일이나 주간 단위로 작업을 수행할 필요가 있지만, 잠도 자야겠고 다른 활동도 하면서 삶을 즐기고 싶습니다. 작업 일정 관리가 필요한 또 다른 좋은 이유는 반복적인 과업을 자동으로 수행하도록 만들거나 매번 동일한 방식으로 과업을 수행하도록 만들고 싶기 때문입니다. 여기서 소개하는 팁은 주기적으로나 일회성으로 미래 작업 일정을 관리하는 cron과 at 기능을 활용하도록 도와줍니다.

리눅스(Linux®)와 유닉스(UNIX®) 시스템은 일회성이거나 반복적인 미래 작업 일정을 관리하도록 만들어준다. LPI exam 102 prep: Administrative tasks에서 발췌한 이번 기사에서는 주기적으로 작업 일정을 관리하는 방법과 미래에 작업을 수행하는 방법을 보여준다.

많 은 시스템 관리 작업은 리눅스 시스템에서 종종 주기적으로 수행해야만 한다. 이런 작업에는 로그 파일을 회전시켜서 파일 시스템이 가득 차지 않도록 만들기, 자료 백업하기, 시스템 시각을 동기화하기 위한 서버 연결과 같은 작업을 포함한다. 이런 관리 작업에 대한 세부 사항은 위에서 언급한 튜토리얼을 참조하기 바란다. 이번 팁에서는 리눅스에서 사용 가능한 작업 일정 관리 패키지인 cron, crontab, anacron, at 명령을 다룬다. 시스템이 잠들거나 꺼져 있더라도, anancron은 다음 번에 깨어날 때 작업을 따라잡도록 도와준다.

Java™, PHP, 루비로 웹 개발을 할 때 이클립스(Eclipse)를 사용하는 방법에 관한 3부로 이루어진 "이클립스 유로파로 웹 개발하기" 의 Part 1에서는 이클립스 최신 버전인 유로파를 이용해 어떻게 자바 웹 애플리케이션을 신속하게 개발할 수 있는지에 대해, Part 2에서는 PHP 애플리케이션을 PDT(PHP Development Toolkit) 플러그인을 이용하여 얼마나 쉽게 개발할 수 있는지를 다루었습니다. 이번 Part 3에서는 RDT와 RadRails 이클립스 플러그인들에 대해 다룰 것이며 이 플러그인들을 설치하는 방법과 사용하는 방법에 대해 살펴보겠습니다. 앞으로 많은 루비 온 레일스(Ruby on Rails) 개발 작업들을 RadRails를 통해 하는 방법을 배울 것입니다.

이 튜토리얼 내에서

Part 2에 서는 PHP를 개발함에 있어 IDE를 이용하여 얻을 수 있는 이점에 대해 이야기해 보았다. 대부분의 것들은 루비에도 똑같이 적용되며 루비 개발 툴킷(RDT)을 이용할 때 얻게 될 것이다. RDT는 구문 강조(syntax highlighting), 컬러링(coloring), 문법 검사, 코드 자동 완성, 포맷화(formatting) 그리고 프로젝트 구성 등 IDE의 기본적인 모든 기능을 제공한다. 또한 큰 프로젝트에 필수적인 루비 디버거(debugger)를 제공하고 있다. 그 외에도 정규표현식(regex) 편집기/테스터 같은 기능과 Test::Unit와 통합을 통한 단위 테스트 환경도 있다.

이번 튜토리얼에서는 RDT와 RadRails 플러그인을 소개할 것이다. 그리고 이것들을 설치하는 방법과 사용하는 방법에 대해 보여줄 것이다. 루비 온 레일스 개발 작업들을 RadRails를 통해 어떻게 하는지를 배우게 될 것이며 RadRails를 통해 레일스 애플리케이션 테스트와 디버그를 더 쉽게 하는 방법을 알게 될 것이다.

선수조건

이번 튜토리얼은 루비를 통한 웹 개발이다. 루비 온 레일스로 웹 개발을 한다는 말이나 다름 없다. 그래서 루비 온 레일스에 대해 약간의 경험이 있다고 가정한다. 이클립스에 익숙하다면 도움이 되겠지만 필수적이진 않다. 이번 튜토리얼은 처음 두 튜토리얼에서 자바와 PHP로 개발된 애플리케이션 위에서 개발된다. 자바와 루비 프로그래밍의 배경지식은 필수다. 이클립스 IDE에 익숙하다면 도움이 되겠지만 필수적이진 않다.

PHP 5는 XML(eXtensible Markup Language)을 읽는 클래스인 XMLReader를 새롭게 지원한다. SimpleXML이나 DOM(Document Object Model)과는 달리 XMLReader는 스트리밍 모드에서 동작한다. 즉, 문서를 처음부터 끝까지 읽어들인다는 뜻이다. 또한 문서를 끝까지 읽기 전에 이미 읽어들인 부분만으로도 작업이 가능하다. 따라서 속력이 매우 빠르고, 효율성이 높으며, 메모리가 크게 절약된다. 처리할 문서가 클수록 메모리 효율과 속력은 더욱 중요한 요인이다.

libxml 여기서 소개하는 XMLReader API는 Gnome 프로젝트의 C/C++용 libxml 라이브러리를 사용한다. 구체적으로 보면 libxml의 XmlTextReader API를 호출하는 PHP 레이어일 뿐이다. XmlTextReader는 .NET의 XmlTextReader와 XmlReader 클래스를 모델로 삼았다(코드를 공유하지는 않는다).

푸시(push) 모델을 사용하는 SAX(Simple API for XML)와는 달리, XMLReader는 풀(pull) 모델을 사용하는 구문분석기다. 즉, 여러분이 만든 프로그램에 통제권이 있다는 뜻이다. 구체적으로 설명하자면, 구문분석기가 프로그램으로 이벤트를 밀어주는 방식이 아니라, 프로그램에서 다음 이벤트를 명시적으로 가져오는 방식이다. 프로그램이 발생하는 이벤트에 반응하기보다 프로그램에서 내용을 요청한다고 보면 된다. 디자인 패턴 관점에서 보면, XMLReader는 Observer 패턴이 아니라 Iterator 패턴을 구현한 클래스라고 하겠다.