LAMP 시스템 조율, Part 1: LAMP 아키텍처 이해 (한글)
LAMP 시스템 동작 원리, 성능 측정 방법, 기반 운영체제 조율 방법 요약： LAMP(Linux®, Apache, MySQL, PHP/Perl) 아키텍처를 활용하는 응용 프로그램은 끊임없이 개발되고 배포되고 있습니다. 하지만 때로 다른 사람이 작성했다는 이유만으로 응용 프로그램 자체에 대한 통제권이 서버 관리자에게는 없습니다. 기사 셋으로 이뤄진 이번 연재물은 응용 프로그램 성능을 향상시킬 서버 환경 설정 항목을 다룹니다. 첫 번째 기사는 LAMP 아키텍처, 성능 기법, 기본적인 리눅스 커널, 디스크, 파일 시스템 미조정을 다룹니다. 이어지는 기사에서는 아파치, MySQL, PHP 컴포넌트를 조율하는 방법을 다룹니다.
설치가 쉽기 때문에 소프트웨어 실행까지 쉬워보일지도 모르겠지만, 이는 사실이 아니다. 궁극적으로 응용 프로그램 부하는 백엔드 서버에 포함된 설정값을 무력화하며, 결국 응용 프로그램 성능 저하가 일어난다. LAMP 설치는 지속적인 감시와 조율과 평가를 요구한다.
시스템을 조율하는 작업은 사람마다 의미가 달라진다. 이번 연재에서는 리눅스, 아파치, MySQL, PHP라는 LAMP 컴포넌트 조율에 초점을 맞춘다. 응용 프로그램 자체 조율은 또 다른 복잡한 문제다. 응용 프로그램과 백엔드 서버 사이에는 공생 관계가 있다. 잘못 조율된 서버는 최상의 응용 프로그램조차도 부하가 걸릴 경우 실패하도록 만들며, 잘못된 응용 프로그램을 앞에 놓고 서버 조율을 해봤자 굼벵이를 달팽이로 만들 뿐이다. 다행스럽게도 적절한 시스템 조율과 감시는 응용 프로그램에 존재하는 문제점을 찾아내준다.
LAMP 아키텍처
시스템 조율 과정에서 첫 단계는 동작 원리 이해다. 가장 단순한 수준에서 보면 LAMP 기반 응용 프로그램은 리눅스 호스트에서 동작하는 아파치 웹 서버 일부로 동작하는 PHP와 같은 스크립트 언어로 작성된다.
PHP 응용 프로그램은 요청받은 URL을 통해 클라이언트로부터 폼 정보를 얻으며, 세션 정보를 포착해 수행할 작업을 결정한다. 필요하다면 서버는 (역시 리눅스에서 동작하는) MySQL 데이터베이스에서 자료를 끌어 당겨 HTML 탬플릿에 맞춰 정보를 결합한 다음 클라이언트에 반환한다. 이런 과정은 사용자가 응용 프로그램을 탐색하는 과정에서 계속 반복되며, 시스템에 여러 사람이 접근할 경우 병렬로 진행된다. 자료 흐름이 일방향이 아닌 이유는 세션 자료 형태, (투표를 비롯한) 통계 수집, 댓글이나 사이트 개선 내용과 같이 사용자가 제출한 내용 형태로 데이터베이스 갱신이 일어날 수 있기 때문이다. 또한 동적 구성 요소는 물론이고 이미지, 자바스크립트 코드, CSS와 같은 정적인 구성 요소도 존재한다.
LAMP 시스템을 통한 요청 흐름을 살펴본 다음에는, 속력이 느려지는 지점을 찾기 시작한다. 데이터베이스는 동적 정보를 만들어내므로 클라이언트는 질의에 반응하는 동안 지연을 느낀다. 웹 서버는 스크립트를 번개처럼 수행할 수 있어야 하며, 다중 병렬 요청을 처리할 수 있어야 한다. 최종적으로 기반 운영체제는 응용 프로그램을 원활하게 지원해야 한다. 네트워크를 통해 여러 서버 사이에서 파일을 공유하도록 만들 경우 잠재적인 병목이 생긴다.
성능 측정
지속적인 성능 측정은 두 가지 측면에서 도움을 준다. 첫 번째로 측정은 좋든 나쁘든 경향을 파악하는 데 도움을 준다. 간단한 예를 들자면, 웹 서버에서 CPU 사용량을 관찰하는 방법으로 부하가 걸릴 때를 알 수 있다. 비슷하게 과거에 사용했던 전체 대역폭을 관찰하고 이를 통해 미래에 일어날 대역폭을 보간법으로 추정해보면 네트워크 업그레이드가 필요할 시점을 결정할 수 있다. 이런 측정은 다른 측정과 비교해서 관찰하면 최상의 효과를 얻는다. 예를 들어, 사용자가 응용 프로그램이 느리다고 불평할 때, 디스크 용량이 가득 차 있을지도 모른다.
성능 측정을 두 번째로 활용하는 방법은 조율이 상황을 좋게 만들었는지 나쁘게 만들었는지 판단하는 것이다. 변화 직전과 직후에 측정한 결과를 비교함으로써 이런 판단이 가능하다. 물론 효과를 높이려면 한번에 항목 하나만 변경하며, 변경 효과를 결정하기 위해 적절한 척도를 사용해야 한다. 한번에 하나만 변경하는 이유는 명백하다. 결국 동시에 두 가지를 변경하면 서로 방해할 가능성이 높기 때문이다. 척도 결정 방식은 더욱 미묘하다.
응용 프로그램 사용 관점에서 영향을 미치는 내역을 관찰하기 위해 고른 척도는 아주 중요하다. 변경 목표가 데이터베이스 메모리 사용량 감소라면, 다양한 버퍼 제거는 틀림없이 도움을 주지만 응용 프로그램 성능과 질의 속력을 희생해야 한다. 그 대신 척도 중 하나가 응용 프로그램 반응 시간이라면 단순히 데이터베이스 메모리 사용량을 넘어서 다른 조율 가능성이 열리게 된다.
응용 프로그램 반응 속력은 다양한 방법으로 측정이 가능하다. 아마도 가장 손쉬운 방법은 Listing 1에 나오는
curl 명령이다.Listing 1. 웹 사이트 반응 속력을 측정하기 위해 cURL 사용하기
$ curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total}\
http://www.canada.com
0.081:0.272:0.779
|
Listing 1은 인기 있는 뉴스 사이트를 살펴보기 위해 사용한
curl 명령어를 보여준다. 일반적으로 HTML 코드인 결과물은 -o 매개변수로 /dev/null로 보내지며, -s는 상태 정보를 보여주지 않는다. -w 매개변수는 curl에게 표 1에서 기술한 타이머와 같은 몇몇 상태 정보를 출력하게 만든다.표 1.
curl이 사용한 타이머| 타이머 | 설명 |
|---|---|
| time_connect | 서버로 TCP 연결이 이뤄질 때까지 걸린 시간 |
| time_starttransfer | 요청 이후 웹 서버가 첫 바이트를 반환할 때까지 걸린 시간 |
| time_total | 요청을 완료할 때까지 걸린 시간 |
각 타이머는 DNS 탐색 전인 트랜잭션 시작 시점에 상대적이다. 따라서 요청 이후 웹 서버가 요청을 처리해 자료를 되돌려주기 시작하는 데 걸린 시간은 0.272 - 0.081 = 0.191초다. 클라이언트는 서버에서 자료를 내려받는 동안 0.779 - 0.272 = 0.507초를 소비했다.
curl 자료를 관찰하며 시간 경과에 따라 변화 추이를 살펴보면 사이트가 사용자에게 반응을 얼마나 제대로 하는지 아이디어를 얻을 수 있다.물론 웹 사이트는 단순히 페이지 하나가 아니다. 이미지, 자바스크립트 코드, CSS, 다뤄야 할 쿠키 등을 포함한다.
curl은 단일 구성 요소에 대한 반응 시간을 측정하는 데 유용하지만 종종 전체 페이지를 얼마나 빨리 가져오는지 알아야 하는 경우도 있다.파이어폭스를 위한 템퍼 데이터 확장(참고자료 절에서 링크를 살펴본다)은 웹 브라우저가 만들어내는 모든 요청과 각 요청마다 자료가 날아오는 데 걸리는 시간을 표시한다. 이 확장을 사용하라면 Tools > Tamper Data를 선택해서 Ongoing requests 윈도우를 연다. 의심스러운 페이지를 불러서 브라우저가 각각 요청한 상태와 함께 구성 요소가 날아오는 데 걸리는 시간 정보를 살펴본다. 그림 1은 developerWorks 홈 페이지를 여는 과정에서 나온 결과를 보여준다.
그림 1. developerWorks 홈페이지를 여는 과정에서 사용한 요청 사항 분해
각 행은 항목 별로 여는 데 걸리는 시간을 보여준다. 요청을 시작한 시각, 여는 데 걸린 시간, 크기, 결과와 같은 다양한 자료를 출력한다. Duration 열은 구성 요소 자체를 여는 데 걸린 시간을 나열하는 반면에, Total Duration 열은 하위 구성 요소까지 모두 여는 데 걸린 시간을 보여준다. 그림 1에서 main 페이지를 여는 데 516밀리초가 걸린 반면, 모든 구성 요소를 열어 전체 페이지를 출력하는 데 걸린 시간은 5101밀리초다.
Tamper Data 확장을 활용하는 또 다른 방법으로 페이지를 여는 데 걸리는 시간을 그래프로 표현한다. Ongoing reqeusts 윈도우에서 상단 아무 곳에서 오른쪽 마우스 버튼을 누르고 Graph all을 선택하자. 그림 2는 그림 1에서 얻은 자료를 시각적으로 표현한 모습이다.
그림 2. developerWorks 홈 페이지를 열기 위해 사용한 요청을 시각적으로 표현한 모습
그림 2에서 각 요청 별 주기는 어두운 청색으로 출력했으며, 페이지가 열리는 시작 시점에 상대적으로 보여준다. 따라서 전체 페이지를 여는 과정에서 어떤 요청이 병목인지를 볼 수 있다.
페이지 열기와 사용자 경험에 초점을 맞춤에도 불구하고 디스크, 메모리, CPU, 네트워크와 같은 핵심 시스템 척도를 외면하지 않도록 주의해야 한다. 다양한 유틸리티가 이런 정보 수집을 위해 준비되어 있다. 가장 도움을 주는 도구는
sar, vmstat, iostat다. 참고자료 절을 참조해서 각 도구에 대한 세부 정보를 파악하자.기본 시스템 미세 조율
시스템에서 아파치, MySQL, PHP 구성 요소를 조율하기 앞서 기반 리눅스 구성 요소가 제대로 동작하는지를 확인할 시간을 확보해야 한다. 필요한 서비스만 수행하도록 동작 중인 서비스 목록을 이미 줄여놓았어야 함은 말할 나위도 없다. 훌륭한 보안 실천법일 뿐만 아니라 CPU 사이클과 메모리를 절약하는 좋은 방법이다.
간단한 커널 조율
대다수 리눅스 배포판은 버퍼와 기타 TCP 매개변수를 보수적으로 정의하고 있다. 네트워크 성능 향상을 위해 좀더 많은 메모리를 할당하도록 이런 매개변수를 바꿔야 한다. 커널 매개변수는
/proc에서 값을 읽고 쓰는 방법으로 proc 인터페이스를 통해 설정한다. 다행스럽게도 sysctl 프로그램은 /etc/sysctl.conf에서 값을 읽어서 필요에 따라 /proc에 설정하는 방식으로 작업을 좀더 쉽게 만든다. Listing 2는 인터넷 서버에 사용해야 하는 좀더 공격적인 네트워크 설정을 보여준다.Listing 2. 좀더 공격적인 네트워크 설정을 담은 /etc/sysctl.conf
# 필요할 때 TCP syncookies를 사용한다 net.ipv4.tcp_syncookies = 1 # TCP 윈도우 스케일링을 활성화한다 net.ipv4.tcp_window_scaling = 1 # TCP 최대 버퍼 크기를 늘인다 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # 리눅스 자동 조율 TCP 버퍼 제약을 늘인다 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 # 가용 포트 숫자를 늘인다 net.ipv4.ip_local_port_range = 1024 65000 |
이미
/etc/sysctl.conf에 존재하는 내용에 이 파일 내용을 추가한다. 첫 번째 설정은 TCP SYN 쿠키를 활성화한다. 패킷에 SYN 비트를 설정하는 방식으로 새로운 TCP 연결이 클라이언트에서 들어올 때, 서버는 절반이 열린 연결을 위한 항목을 만들고 SYN-ACK 패킷으로 반응한다. 일반적인 연산 과정에서, 원격 클라이언트는 ACK 패킷으로 반응하며, 절반이 열린 연결을 완전히 열린 연결로 바꾼다. SYN flood라는 기법은 ACK 패킷을 절대로 되돌려주지 않음으로써 서버가 들어오는 연결을 처리할 공간이 없어지도록 만드는 방법이다. SYN 쿠키 기능은 이런 조건을 감지해서 큐에 공간을 보존하기 위한 우아한 방법을 사용해 문제를 해결한다(세부 설명은 참고자료 절을 참조한다). 대다수 시스템에는 이런 기능이 기본적으로 활성화되어 있지만 설정이 되어 있는지 확인하는 편이 좋겠다.TCP 윈도우 스케일을 활성화하면 클라이언트가 높은 속력으로 자료를 내려받을 수 있다. TCP는 기본적으로 64킬로바이트까지 다중 패킷에 대해 원격지에서 ACK를 받지 않고 보내도록 허용하는데, 지연 시간이 높은 컴퓨터끼리 대화할 때는 패킷을 꽉꽉 채워야 한다. 윈도우 스케일은 윈도우 크기를 늘이도록 헤더에 사용되는 특별한 비트를 활성화한다.
다음 네 가지 환경 설정 항목은 TCP 송수신 버퍼를 늘인다. 이렇게 하면 응용 프로그램이 자료를 좀더 빨리 보낼 필요가 없어지므로 다른 요청에 대응할 수 있으며, 서버가 바쁠 때 원격 클라이언트가 자료를 송신하는 능력도 높인다.
마지막 환경 설정 항목은 사용 가능한 지역 포트 수를 늘여서, 한번에 서비스가 가능한 연결 최대 개수를 늘인다.
이런 설정 값은 다음번 컴퓨터를 재시작하거나
sysctl -p /etc/sysctl.conf를 다음에 수행하는 시점에서 반영된다.최대 성능을 위한 디스크 설정
디스크는 LAMP 아키텍처에서 핵심적인 역할을 맡는다. 정적 파일, 템플릿, 코드는 디스크에 저장되어 있으며 자료 테이블과 색인은 데이터베이스를 구성한다. 특히 데이터베이스에 적합한 대다수 권장 조율이 디스크 접근을 피하는 쪽에 맞춰져 있는 이유는 디스크에 접근하면 상대적으로 지연 시간이 길어지기 때문이다. 따라서 디스크 하드웨어 최적화에 공을 들이는 편이 유리하다.
가장 먼저 고려할 사항은 파일 시스템에서
atime 감사 기록을 비활성화했는지 확인하는 작업이다. atime은 파일에 마지막으로 접근한 시각이며, 기반 파일 시스템은 누군가 파일에 접근할 때마다 타임스탬프를 기록해야 한다. atime은 시스템 관리자가 거의 사용하지 않으므로 이를 비활성화하면 디스크 접근 시간을 줄일 수 있다. /etc/fstab의 네 번째 열에 noatime 옵션을 추가하는 방법으로 atime 기록을 막아버린다. Listing 3은 에제 환경 설정을 보여준다.Listing 3.
noatime을 활성화하는 방법을 보여주는 예제 fstab /dev/VolGroup00/LogVol00 / ext3 defaults,noatime 1 1 LABEL=/boot /boot ext3 defaults,noatime 1 2 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 LABEL=SWAP-hdb2 swap swap defaults 0 0 LABEL=SWAP-hda3 swap swap defaults 0 0 |
Listing 3에서 단지 ext3 파일 시스템만 수정했는데,
noatime은 디스크에 저장된 파일 시스템에만 도움이 되기 때문이다. 이런 변화를 적용하기 위해 컴퓨터를 다시 시작할 필요는 없다. 각 파일 시스템을 다시 마운트하면 끝난다. 예를 들어, 루트 파일 시스템을 다시 마운트하려면 mount / -o remount 명령을 내린다.다양한 디스크 하드웨어 조합이 가능한데, 리눅스는 항상 디스크에 접근하는 최적화된 방법을 안정적으로 감지해내지는 못한다.
hdparm 명령은 IDE 디스크 접근에 사용하는 방법을 확인하고 설정하는 데 사용한다. hdparm -t /path/to/device는 벤치마크에 활용 가능한 속력 테스트를 수행한다. 안정적인 결과를 얻으려면, 이 명령을 수행하는 동안 시스템은 놀고 있어야 한다. Listing 4는 hda에 수행한 속력 테스트 결과를 보여준다.Listing 4.
/dev/hda에 수행한 속력 테스트 # hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 182 MB in 3.02 seconds = 60.31 MB/sec |
테스트 결과를 보면 디스크는 초당 대략 60MB 정도 자료를 읽는다.
디스크 조율 옵션을 파고 들기 전에, 경고 한 마디 하고 넘어가겠다. 잘못된 설정 값은 파일 시스템을 망가뜨릴지도 모른다. 때로 하드웨어와 호환되지 않는 옵션을 선택하면 경고가 나오지만 때로는 그냥 넘어간다. 이런 이유로 인해, 시스템에 실제 적용하기 앞서 전반적으로 테스트를 수행해야 한다. 서버를 표준 하드웨어로 통일하면 이런 문제를 해결할 수 있다.
표 2에 자주 사용하는 몇몇 공통 옵션을 정리했다.
표 2.
hdparm을 위한 공통 옵션 | 옵션 | 설명 |
|---|---|
| -vi | 사용 중인 설정 값과 지원하는 설정 값을 결정하기 위해 드라이브에 질의를 던진다. |
| -c | (E)IDE 32비트 I/O 지원을 질의/활성화한다. hdparm -c 1 /dev/hda 명령으로 활성화한다. |
| -m | 인터럽트 모드 당 다중 섹터를 질의/설정한다. 설정값이 0보다 크면 인터럽트 당 해당 숫자만큼 섹터를 전송한다. |
| -d 1 -X | DMA를 활성화하고 IDE 전송 모드를 설정한다. hdparm 매뉴얼 페이지를 참조해 -X 뒤에 붙는 숫자를 확인하자. 최고 빠른 모드를 사용할 계획이 아니라면 -vi 옵션으로 충분하다. |
불행하게도 광 채널이나 SCSI 시스템을 위한 조율 방법은 디바이스 별로 다르다.
rc.local과 같은 시동 스크립트에 필요한 설정을 추가하기 바란다.네트워크 파일 시스템 조율
NFS는 네트워크를 경유해 디스크 볼륨을 공유하는 수단이다. NFS는 동일한 자료 복사본을 호스트마다 유지하며 변경 내역을 모든 노드에 반영하는 과정에 도움을 준다. 기본적으로 NFS는 대용량 저장 장치로 설정되어 있지 않다.
각 클라이언트는 원격 파일 시스템을 마운트할 때
rsize=32768,wsize=32768,intr,noatime 옵션을 붙여야 하는데, 다음 사항을 염두에 두자.- 대규모 읽기/쓰기 블록 크기를 사용한다(상황에 따라 바뀌며, 이 경우에는 32KB다)
- NFS는 중단 상황에서 인터럽트가 걸릴 수 있다.
-
atime은 주기적으로 갱신되지 않는다.
Listing 3에서 제시한 설정값을
/etc/fstab에 넣어둘 수 있다. automounter를 사용한다면 적절한 /etc/auto.* 파일을 살펴보자.서버 단에서 NFS 커널 스레드가 클라이언트 요청을 모두 다룰 수 있을 정도로 충분한지 확인하는 과정이 중요하다. 기본적으로 스레드 하나만 시작하지만, 레드햇과 페도라 시스템은 8부터 시작한다. 바쁜 NFS 서버를 위해, 이 값을 32나 64와 같은 높은 값으로 시작하도록 만들자. 클라이언트 쪽 RPC(Remote Procedure Call) 통계를 보여주는
nfsstat -rc 명령으로 NFS 서비스 중단이 일어나지 않는지 클라이언트 단에서 평가할 수 있다. Listing 5는 웹 서버에 대한 클라이언트 통계를 보여준다.Lisgint 5. NFS 클라이언트의 RPC 통계 보기
# nfsstat -rc Client rpc stats: calls retrans authrefrsh 1465903813 0 0 |
둘째 열인
retrans가 0인데, 마지막 시동 후 재전송이 필요하지 않음을 보여준다. 이 숫자가 증가하면 NFS 커널 스레드를 높여야 한다. rpc.nfsd에 원하는 스레드 숫자를 넘기면 되는데, 예를 들어 rpc.nfsd 128은 스레드 128개로 시작한다. 이런 조정은 언제든지 가능하다. 다시 한번 말하지만 시스템에서 NFS를 시작하는 시동 스크립트를 바꿔야 한다.NFS에 대한 마지막 정리로 끝을 내겠다. 가능하면 NFSv2를 피해야 하는 이유는 v3이나 v4보다 성능이 떨어지기 때문이다. 현대적인 리눅스 배포판에서는 문제가 되지 않지만 혹시 NFSv2 호출이 이뤄지는지 서버 단에서
nfsstat으로 점검할 필요가 있다.미리 보기
이번 기사는 LAMP 기본기와 LAMP 설치를 위한 몇 가지 간단한 리눅스 조율 과정을 살펴보았다. NFS 커널 스레드를 제외하고, 이번 기사에서 다룬 매개변수를 설정한 다음 잊어버려도 좋다. 다음에 이어지는 연재 기사에서는 아파치, MySQL, PHP 조율에 초점을 맞춘다. APM 조율이 리눅스 조율과 다른 이유는 소통량이 증가하고 read/write 분포가 바뀌고 응용 프로그램이 발전함에 따라 계속해서 매개변수를 조율할 필요가 있기 때문이다.
참고자료
교육
- "Easy system monitoring with SAR" (developerWorks, 2006년 2월)은
sar를 사용한 핵심 시스템 척도 추적 지침을 제공한다.
- "Expose Web performance problems with the RRDtool" (developerWorks, 2006년 3월)은 Sean이 쓴 튜토리얼로 장기적인 분석 과정에서 사용하는 cURL 기법과 그래프 그리는 방법을 다룬다.
- In Monitoring Virtual Memory with vmstat (Linux Journal, 2005년 10월)은 리눅스 시스템에서 페이징 활동 내역을 관찰하는 방법을 다룬다.
- NFS가 낯설 경우, To Protect and Serve: Providing Data to Your Cluster (Prentice Hall Professional Technical Reference, 2005년 2월)는 NFS와 automounter에 대한 좋은 소개글로 대규모 NFS 배포에 도움을 준다.
- "TCP and Linux' Pluggable Congestion Control Algorithms" (Linux Gazette, 2007년 2월)는 리눅스에서 지원하는 TCP 혼잡 통제 기법을 구현하는 여러 알고리즘을 설명하며, 더 중요하게는 네트워크 세션에서 손실이나 지연에 대한 중요성과 영향을 설명한다.
- 초반에 설명한 TCP SYN cookies는 SYN flood와 관련한 DOS 공격에 대응하는 방법을 설명한다. 멋진 글이다.
- developerWorks 리눅스 영역에서 리눅스 개발자를 위한 더 많은 참고 자료를 찾을 수 있다.
- developerWorks 기술 행사와 웹 캐스트를 놓치지 말기 바란다.
- 파이어폭스를 위한 Tamper Data 확장은 동적으로 HTTP 헤더를 살피고 변경하도록 만들어주며, 페이지 구성 요소를 여는 과정을 요약한 그래프를 그려준다.
- IBM 평가판 소프트웨어: developerWorks에서 직접 내려 받아 다음번 리눅스 프로젝트에 활용하자.
블로그, 포럼, 포드캐스트, 새로운 developerWorks space에 있는 새로운 공동체 토픽을 통해 developerWorks 공동체에 참여한다.
댓글 없음:
댓글 쓰기