수안이의 컴퓨터 연구실
신현삼 (sami@cnettech.co.kr )
개발적 측면에서 최적화
객체지향적 개발 방식
개발적 측면에서 가장 화두가 된 것은 객체지향적 코드의 활용이다. 이것은 이미 논의되고 활용된 지가 십년이 넘는다. 자바가 성장할 수 있는 원동력이었다고 해도 과언이 아니다. PHP도 객체지향적 개발을 위해 많은 클래스 작업과 함께 결과물을 도출해냈지만 완벽한 OOP를 지원하지 못함으로써 여기에 대한 한계점이 많았었다. 하지만 PHP 5가 베타 버전을 출시하면서 완전한 객체지향적 개발 방식을 도입할 수 있게 되었다. 이것은 두 가지의 의미로도 해석할 수 있다.
하나는 엔터프라이즈 개발이 가능하다는 점이다. 이 말은 완벽한 OOP 지원으로 PHP도 이제 자바의 영역으로만 인식되어온 엔터프라이즈급 개발 프로젝트를 수행할 수 있다는 점이고, 아직은 많은 보완이 필요하겠지만 머지않아 다수의 프로젝트가 발생할 것이라고 믿는다. 두 번째로는 개발자의 개발 방식의 변동을 들 수 있겠다. 이 말은 기존의 PHP 개발자는 현재까지 진행해온 방식으로도 개발을 진행할 수 있지만, OOP에 맞는 개발 방식을 선택함으로써 폭넓고 안정적인 개발 패턴을 수행할 수 있게 되었다는 뜻으로 해석할 수 있겠다. 이처럼 객체지향적 방식을 채택함으로써 최적화된 서비스를 개발할 수 있을 것이라고 생각한다.
재사용 코드 모듈화
코드 재사용은 다수의 프로젝트를 진행하는 개발자들에게 필수적인 안정화 조건이고 최적화 조건이다. 버그에 대한 처리, 조건에 대한 확장은 여러 페이지나 프로그램에서 요구된다. 이러한 요구 조건을 각 페이지마다 적용하고 튜닝을 하다보면 개발 시간보다 훨씬 오래 걸리고, 오류나 문제를 발생시킬 확률이 훨씬 높다. 뛰어난 개발자들을 보면 데이터 처리에 대한 모듈화를 정형적으로 해놓고, 이 모듈에 대한 확장을 다시 모듈화해 기능 확장을 아주 쉽게 하며 확장 모듈만 검증함으로써 코드의 안정을 가져오는 경우가 있다. 이렇게 했을 때 처음 만든 모듈의 개발 시간보다는 이후 재사용돼 만들어져 나오는 코드들이 개발 속도와 안정성에서 훨씬 우수하다. 모듈화는 결국 개발자의 끈기와 설계에 의해 이뤄지는 것이다. 다시 한번 자신의 반복되는 수행 과정을 살펴보고 업무 프로세스든 프로그램이든 모듈화시키는 것을 빼놓지 말자.
쿼리문 최적화
웹 서비스에서 가장 많이 나타나는 속도와 최적화의 문제는 무엇일까? 그것은 바로 쿼리이다. 쿼리의 인덱스나 주 키 그리고 서브 쿼리를 제대로 활용하는 것이 얼마나 중요한 것인지 알 수 있다. 필자는 얼마 전에 데이터가 50만건이 넘어선 사이트에서 조회가 PHP의 실행 시간(기본 30초로 설정)을 넘어 ‘max time out’ 에러가 나는 장애를 만났었다. 쿼리를 보니 인덱스를 제대로 활용하지 못한 쿼리를 사용하고 있었다. 실제로 쿼리는 던져보니 1분 정도 걸렸었다. 약간의 튜닝을 진행하고 나서 쿼리를 던져보니 0.00초가 나오는 것이었다. 아주 단순한 작업이면서도 충격적이었다. 쿼리에 대한 약간의 테스트(스트레스 테스트)를 진행해 보지 않은 과실이 이런 장애를 일으킨다는 소중한 교훈을 얻게 되었다. 쿼리에 대한 최적화를 반드시 염두에 두고 SQL문을 만들기를 바란다. 또한 시스템에 부하가 많이 가지 않는다면 인덱스를 많이 만들어 두는 것도 나중에 확장적 측면에서 괜찮을 듯 싶다.
파일 운용 기법의 최적화
웹 개발을 진행하다 보면 많은 문제가 페이지 로딩 속도와 관련되어 있다. 페이지 로딩에 대한 최적화는 어떻게 이뤄질까. 주 메뉴를 파일로 분리시켰을 경우를 생각해 보자. 방법은 다음과 같이 세 가지의 방법으로 나눌 수 있다.
이렇게 했을 때 속도 차이가 날까? 동적으로 자꾸 바뀌는 파일이 아니라 정적인 파일이라면 두 번째 방식이 가장 빠르다고 볼 수 있다. 사용자가 한번 호출하면 다음 페이지부터는 이 부분의 추가 로딩이 전혀 필요없기 때문이다.
시스템 측면에서 최적화
시스템과 관련있는 최적화 요소가 굉장히 많다. 이것은 시스템 운영의 최적화 조건을 성립시키기 위해 필수적인 것이다.
DB 서버 관리
데이터베이스 시스템 관리는 개발자나 운영자에게 아주 중요한 요소이다. 시스템은 시간이 지날수록 데이터베이스의 용량과 시스템의 부하를 일으키기 때문에 속도와 밀접한 관계를 가지게 된다. 데이터베이스 시스템에 대한 유지관리도 서비스 향상에 크게 도움이 된다. 예를 들면 MySQL의 쿼리 속도를 빠르게 하는 방법이다. 이것은 캐시를 사용해 쿼리를 빠르게 하여 속도를 향상시키는 방법으로 /etc/my. cnf 파일을 열어 다음과 같이 옵션을 바꾸면 된다.
이렇듯 MySQL뿐만 아니라 많은 데이터베이스 시스템은 시스템에 최적화될 수 있는 옵션을 제공하고 있다. 사용하는 데이터베이스의 운영 관련 조건을 잘 살펴봐야 한다.
로드밸런싱
대용량 서비스를 하게 됨으로써 필수 불가결로 로드밸런싱을 채택한다. 소프트웨어적인 로드밸런싱과 하드웨어적인 로드밸런싱이 있는데, 일반적으로 소프트웨어 로드밸런싱을 먼저 채택한 후 서비스가 더 커졌을 때 하드웨어적인 로드밸런싱을 채택한다. 앞서 말했듯이 시스템 설계에서 로드밸런싱을 고려한 시스템 분할이 있어야 한다. 보통 DB 서버의 앞단에 웹 서버를 두어서 로드밸런싱을 많이 시도한다. 이런 시스템에 대한 설계는 비용적인 측면과 밀접하기 때문에 시스템 운영자와 긴밀한 협의가 이뤄져야 한다.
로그 관리
로그 관리는 필수적인 조건을 가지고 있지만 중요한 정보가 아닐 때는 로그 옵션을 다양하게 주어서 서버의 성능을 조절해 주면 된다. 시스템 부하가 걸리거나 문제가 발생하는 사이트를 보면 로그가 꽉 차서 문제를 일으키는 경우가 허다하다. 또한 로그가 너무 많이 쌓여서 시스템이 아주 늦어지는 경우도 있다. 로그 관리부터 로그를 필요한 것만 쌓이게 하는 방법을 강구함으로써 예견된 장애를 미리 막아 원활한 서비스를 제공해야 할 것이다.
웹 서버 설정
웹 서버 설정은 개발자나 운영자의 중요한 학습과제이다. 웹 서버 설정을 잘하면 아주 쉽게 서비스의 성능을 향상시킬 수 있을뿐더러 문제 해결에도 많은 도움이 된다. 필자는 웹 서비스 첫 페이지로 로딩이 오래 걸리는 문제를 접했었다. 문제의 키는 웹 서버에 있었다. 웹 서버의 옵션을 보면 로깅을 사용하거나 필요 없는 로그를 남기거나 정보를 체크하는 여러 가지 옵션들이 있다. 이 옵션을 조절함으로써 문제를 해결할 수 있었다. 이처럼 웹 서버는 갈수록 강력해지고 많은 조건 및 옵션과 성능을 제시하고 있다. 필수적으로 시스템 운영과 개발에 참여하는 개발자들은 웹 서버 설정에 대해 많은 지식을 가져야 하겠다.
파일 백업
프로그램에 대한 백업은 개발자들이 자주 하면서도 귀찮아하는 일에 속한다. 하지만 이것만큼 중요한 일도 없을 것이다. 필자는 개발해 놓은 사이트에서 프로그램을 백업받지 않았는데 하드디스크 오류가 발생해 모든 프로그램이 삭제되는 경우를 접한 적이 있다. 사사로운 개발자의 실수가 엄청난 장애를 일으킬 수 있다는 것을 잊지 말도록 하자. 또한 주기적인 데이터베이스 및 로그, 프로그램을 백업하는 프로그램을 만들어서 사용하는 방법도 이러한 귀찮은 일들을 일시에 처리할 수 있는 지혜가 될 수도 있다.
고객의 요구 조건과 시스템 사양이 최우선
이번 호에서는 PHP로 시스템을 최적화시키는 방법에 대해 간단하게나마 다루었다. 시스템 최적화는 각 분야에서 세부적으로 책이 나올 정도로 중요하게 다뤄지고 있다. 시스템 최적화의 몫은 무엇보다 고객의 요구조건과 시스템 사양이 결정적인 역할을 한다. 더 세부적인 것은 자세한 서적을 참조하는 것이 좋을 것이다. 시스템을 구축하는 가장 기본적인 원칙이 안정성과 최적화라는 것을 잊지 말고 프로젝트를 진행하길 바란다. PHP는 이제 5.0의 시대를 맞이하면서 새롭게 도약하려고 하고 있다. 다음 회에서는 PHP 5의 실제 설치와 새롭게 바뀌는 아키텍처를 가지고 간단한 프로그래밍을 해보도록 하겠다. 바뀌는 시대에 빨리 적응하는 앞서가는 개발자가 되었으면 한다.
개발적 측면에서 최적화
객체지향적 개발 방식
개발적 측면에서 가장 화두가 된 것은 객체지향적 코드의 활용이다. 이것은 이미 논의되고 활용된 지가 십년이 넘는다. 자바가 성장할 수 있는 원동력이었다고 해도 과언이 아니다. PHP도 객체지향적 개발을 위해 많은 클래스 작업과 함께 결과물을 도출해냈지만 완벽한 OOP를 지원하지 못함으로써 여기에 대한 한계점이 많았었다. 하지만 PHP 5가 베타 버전을 출시하면서 완전한 객체지향적 개발 방식을 도입할 수 있게 되었다. 이것은 두 가지의 의미로도 해석할 수 있다.
하나는 엔터프라이즈 개발이 가능하다는 점이다. 이 말은 완벽한 OOP 지원으로 PHP도 이제 자바의 영역으로만 인식되어온 엔터프라이즈급 개발 프로젝트를 수행할 수 있다는 점이고, 아직은 많은 보완이 필요하겠지만 머지않아 다수의 프로젝트가 발생할 것이라고 믿는다. 두 번째로는 개발자의 개발 방식의 변동을 들 수 있겠다. 이 말은 기존의 PHP 개발자는 현재까지 진행해온 방식으로도 개발을 진행할 수 있지만, OOP에 맞는 개발 방식을 선택함으로써 폭넓고 안정적인 개발 패턴을 수행할 수 있게 되었다는 뜻으로 해석할 수 있겠다. 이처럼 객체지향적 방식을 채택함으로써 최적화된 서비스를 개발할 수 있을 것이라고 생각한다.
재사용 코드 모듈화
코드 재사용은 다수의 프로젝트를 진행하는 개발자들에게 필수적인 안정화 조건이고 최적화 조건이다. 버그에 대한 처리, 조건에 대한 확장은 여러 페이지나 프로그램에서 요구된다. 이러한 요구 조건을 각 페이지마다 적용하고 튜닝을 하다보면 개발 시간보다 훨씬 오래 걸리고, 오류나 문제를 발생시킬 확률이 훨씬 높다. 뛰어난 개발자들을 보면 데이터 처리에 대한 모듈화를 정형적으로 해놓고, 이 모듈에 대한 확장을 다시 모듈화해 기능 확장을 아주 쉽게 하며 확장 모듈만 검증함으로써 코드의 안정을 가져오는 경우가 있다. 이렇게 했을 때 처음 만든 모듈의 개발 시간보다는 이후 재사용돼 만들어져 나오는 코드들이 개발 속도와 안정성에서 훨씬 우수하다. 모듈화는 결국 개발자의 끈기와 설계에 의해 이뤄지는 것이다. 다시 한번 자신의 반복되는 수행 과정을 살펴보고 업무 프로세스든 프로그램이든 모듈화시키는 것을 빼놓지 말자.
쿼리문 최적화
웹 서비스에서 가장 많이 나타나는 속도와 최적화의 문제는 무엇일까? 그것은 바로 쿼리이다. 쿼리의 인덱스나 주 키 그리고 서브 쿼리를 제대로 활용하는 것이 얼마나 중요한 것인지 알 수 있다. 필자는 얼마 전에 데이터가 50만건이 넘어선 사이트에서 조회가 PHP의 실행 시간(기본 30초로 설정)을 넘어 ‘max time out’ 에러가 나는 장애를 만났었다. 쿼리를 보니 인덱스를 제대로 활용하지 못한 쿼리를 사용하고 있었다. 실제로 쿼리는 던져보니 1분 정도 걸렸었다. 약간의 튜닝을 진행하고 나서 쿼리를 던져보니 0.00초가 나오는 것이었다. 아주 단순한 작업이면서도 충격적이었다. 쿼리에 대한 약간의 테스트(스트레스 테스트)를 진행해 보지 않은 과실이 이런 장애를 일으킨다는 소중한 교훈을 얻게 되었다. 쿼리에 대한 최적화를 반드시 염두에 두고 SQL문을 만들기를 바란다. 또한 시스템에 부하가 많이 가지 않는다면 인덱스를 많이 만들어 두는 것도 나중에 확장적 측면에서 괜찮을 듯 싶다.
파일 운용 기법의 최적화
웹 개발을 진행하다 보면 많은 문제가 페이지 로딩 속도와 관련되어 있다. 페이지 로딩에 대한 최적화는 어떻게 이뤄질까. 주 메뉴를 파일로 분리시켰을 경우를 생각해 보자. 방법은 다음과 같이 세 가지의 방법으로 나눌 수 있다.
이렇게 했을 때 속도 차이가 날까? 동적으로 자꾸 바뀌는 파일이 아니라 정적인 파일이라면 두 번째 방식이 가장 빠르다고 볼 수 있다. 사용자가 한번 호출하면 다음 페이지부터는 이 부분의 추가 로딩이 전혀 필요없기 때문이다.
시스템 측면에서 최적화
시스템과 관련있는 최적화 요소가 굉장히 많다. 이것은 시스템 운영의 최적화 조건을 성립시키기 위해 필수적인 것이다.
DB 서버 관리
데이터베이스 시스템 관리는 개발자나 운영자에게 아주 중요한 요소이다. 시스템은 시간이 지날수록 데이터베이스의 용량과 시스템의 부하를 일으키기 때문에 속도와 밀접한 관계를 가지게 된다. 데이터베이스 시스템에 대한 유지관리도 서비스 향상에 크게 도움이 된다. 예를 들면 MySQL의 쿼리 속도를 빠르게 하는 방법이다. 이것은 캐시를 사용해 쿼리를 빠르게 하여 속도를 향상시키는 방법으로 /etc/my. cnf 파일을 열어 다음과 같이 옵션을 바꾸면 된다.
# The MySQL server
[mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
set-variable = key_buffer=16M
set-variable = max_allowed_packet=1M
set-variable = table_cache=64
set-variable = sort_buffer=512K
set-variable = net_buffer_length=8K
set-variable = myisam_sort_buffer_size=8M
set-variable = query_cache_limit=1048576 <==결과 값이 주어진 값보다 크면 캐시에 저장안함
set-variable = query_cache_size=16768060 <==캐시 크기
set-variable = query_cache_type=1
log-bin
server-id = 1
[mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
set-variable = key_buffer=16M
set-variable = max_allowed_packet=1M
set-variable = table_cache=64
set-variable = sort_buffer=512K
set-variable = net_buffer_length=8K
set-variable = myisam_sort_buffer_size=8M
set-variable = query_cache_limit=1048576 <==결과 값이 주어진 값보다 크면 캐시에 저장안함
set-variable = query_cache_size=16768060 <==캐시 크기
set-variable = query_cache_type=1
log-bin
server-id = 1
이렇듯 MySQL뿐만 아니라 많은 데이터베이스 시스템은 시스템에 최적화될 수 있는 옵션을 제공하고 있다. 사용하는 데이터베이스의 운영 관련 조건을 잘 살펴봐야 한다.
로드밸런싱
대용량 서비스를 하게 됨으로써 필수 불가결로 로드밸런싱을 채택한다. 소프트웨어적인 로드밸런싱과 하드웨어적인 로드밸런싱이 있는데, 일반적으로 소프트웨어 로드밸런싱을 먼저 채택한 후 서비스가 더 커졌을 때 하드웨어적인 로드밸런싱을 채택한다. 앞서 말했듯이 시스템 설계에서 로드밸런싱을 고려한 시스템 분할이 있어야 한다. 보통 DB 서버의 앞단에 웹 서버를 두어서 로드밸런싱을 많이 시도한다. 이런 시스템에 대한 설계는 비용적인 측면과 밀접하기 때문에 시스템 운영자와 긴밀한 협의가 이뤄져야 한다.
로그 관리
로그 관리는 필수적인 조건을 가지고 있지만 중요한 정보가 아닐 때는 로그 옵션을 다양하게 주어서 서버의 성능을 조절해 주면 된다. 시스템 부하가 걸리거나 문제가 발생하는 사이트를 보면 로그가 꽉 차서 문제를 일으키는 경우가 허다하다. 또한 로그가 너무 많이 쌓여서 시스템이 아주 늦어지는 경우도 있다. 로그 관리부터 로그를 필요한 것만 쌓이게 하는 방법을 강구함으로써 예견된 장애를 미리 막아 원활한 서비스를 제공해야 할 것이다.
웹 서버 설정
웹 서버 설정은 개발자나 운영자의 중요한 학습과제이다. 웹 서버 설정을 잘하면 아주 쉽게 서비스의 성능을 향상시킬 수 있을뿐더러 문제 해결에도 많은 도움이 된다. 필자는 웹 서비스 첫 페이지로 로딩이 오래 걸리는 문제를 접했었다. 문제의 키는 웹 서버에 있었다. 웹 서버의 옵션을 보면 로깅을 사용하거나 필요 없는 로그를 남기거나 정보를 체크하는 여러 가지 옵션들이 있다. 이 옵션을 조절함으로써 문제를 해결할 수 있었다. 이처럼 웹 서버는 갈수록 강력해지고 많은 조건 및 옵션과 성능을 제시하고 있다. 필수적으로 시스템 운영과 개발에 참여하는 개발자들은 웹 서버 설정에 대해 많은 지식을 가져야 하겠다.
파일 백업
프로그램에 대한 백업은 개발자들이 자주 하면서도 귀찮아하는 일에 속한다. 하지만 이것만큼 중요한 일도 없을 것이다. 필자는 개발해 놓은 사이트에서 프로그램을 백업받지 않았는데 하드디스크 오류가 발생해 모든 프로그램이 삭제되는 경우를 접한 적이 있다. 사사로운 개발자의 실수가 엄청난 장애를 일으킬 수 있다는 것을 잊지 말도록 하자. 또한 주기적인 데이터베이스 및 로그, 프로그램을 백업하는 프로그램을 만들어서 사용하는 방법도 이러한 귀찮은 일들을 일시에 처리할 수 있는 지혜가 될 수도 있다.
고객의 요구 조건과 시스템 사양이 최우선
이번 호에서는 PHP로 시스템을 최적화시키는 방법에 대해 간단하게나마 다루었다. 시스템 최적화는 각 분야에서 세부적으로 책이 나올 정도로 중요하게 다뤄지고 있다. 시스템 최적화의 몫은 무엇보다 고객의 요구조건과 시스템 사양이 결정적인 역할을 한다. 더 세부적인 것은 자세한 서적을 참조하는 것이 좋을 것이다. 시스템을 구축하는 가장 기본적인 원칙이 안정성과 최적화라는 것을 잊지 말고 프로젝트를 진행하길 바란다. PHP는 이제 5.0의 시대를 맞이하면서 새롭게 도약하려고 하고 있다. 다음 회에서는 PHP 5의 실제 설치와 새롭게 바뀌는 아키텍처를 가지고 간단한 프로그래밍을 해보도록 하겠다. 바뀌는 시대에 빨리 적응하는 앞서가는 개발자가 되었으면 한다.
"PHP" 카테고리의 다른 글
- PHP Tutorials (0)2008/05/01
- PHP Framework (0)2007/12/07
- PHP 최적화하기 - 2 (0)2006/01/26
- PHP 최적화하기 - 1 (0)2006/01/26
- PHP 네트워크 프로그래밍 - 3 (0)2006/01/26
Leave your greetings.