System Compleat.

'아파치'에 해당되는 글 1건

  1. 시스템 관리자의 실패, 그리고 서비스.

시스템 관리자의 실패, 그리고 서비스.

Techs
( 정윤진, bluebird_dba@naver.com )


웹 서비스를 하는 많은 시스템에서, 사업의 성공과 함께 고객이 증가함에 따라 발생하는 많은 문제들이 있다.  보다 많은 고객에게 무정지 서비스를 하기위한 각 서비스 구성 요소의 이중화 부터, 서버의 추가에 따른 네트워크 장치의 추가, 대역폭의 확장 등 비용 들어가는 요소가 한두가지가 아니게 된다.

물론 이런 비용의 문제가 있다면 자연히 저렴하고 성능좋은 오픈소스 솔루션으로 눈을 돌리게 마련인데, 이 오픈소스 솔루션이라는게 그 좋은 성능만큼 손도 많이가고, 기본적으로 설치되는 패키지 들이 감당 해 낼 수 없는 어떤 한계 상황에 이르게 되면 소소한 튜닝 하나에 서비스의 명암이 엇갈리기도 한다.

여기 블로그에 내가 직접 설치해 보고, 또  그 성능을 온몸으로 확인했던 여러가지 툴 및 어플리케이션들이 '당연하게'  '잘' 동작 한다는 믿음에는 변함이 없지만, 이들과 맞물리는 요소에 따라 실패하게 될 수도 있다는 사실을 최근 뼈저리게 깨닫게 되었다.

사용자 삽입 이미지

BOTTLENECK a image from finsolinc.com





문제의 발단은 고객 서비스 규모의 증가에 따라 상거래 사이트의 특징상 수많은 이미지를 서비스하게 되는데, 이 감당하기 힘든 이미지의 규모 때문에 nginx 를 사용한 이미지 분리를 시도 하였는데, 결과는 참패였다.  참패의 원인은 몇가지가 있는데, 그중에서도 가장 주요한 부분이 바로 아파치의 mod_expire 였다.

HTTP 의 헤더를 조작하는 것이 많은 비용이 들어가는 일이라는 것은 평소에도 잘 알고있었지만, 이 헤더의 조작이 NFS 의 getattr() 호출의 빈번함과 함께 아파치의 Sending Reply 를 지연시켜 결국 사용 가능한 모든 소켓을 불태워 버림에 따라 nginx 는 nginx 대로, 아파치는 아파치 대로 부하상황에 사이트가 정상동작 하지 않게 되어버렸다.  스레드 기반에서의 ( mpm이 워커였다. 물론 prefork 도 동일한 설정에 상황은 마찬가지. ) locking 및 pending 의 무서움을 절실히 깨달았달까.

결국 문제는 찾아 내게 되었지만, 그 주범이 mod_expire 라는 사실에 허무하기 그지 없다. 고객의 사용 패턴에 따라 mod_expire 는 득이 될 수도, 실이 될 수도 있다.


아무리 간단한 서비스 구성에도 많은 요소들이 존재한다.  부하가 없을때에는 당연히 동작해 주는 그것들.  하지만 극한 상황이 되면 아주 작은 파라메터 하나, config 하나, sql 문장 하나가 서버를 멈추게 하고, DB를 멈추게 하는 무서운 적이 될 수 있음을 항상 기억해야 한다.

구성에 관한한 어지간해서는 실패한 경험이 별로 없는데, 이번건은 나에게 매우 큰 정신적 충격이었고,  역시 항상 장애에 대해 트레이닝 하지 않으면 당황하게 되는걸 보니 아직 많이 부족하다 싶다.  그렇게 당연한 인과 관계를 찾아내지 못했던게 참 ... 씁쓸하다고만 하기에는 부족한.


결국, 아파치의 체중조절에 들어갔다.  꼭 필요한 모듈만 올려서 경량화, ServerLimit 조절 같은 기본 구성부터  이미지 서버의 이벤트 폴링,  aio 및 sendfile 의 적용 등.

이제, 쓴맛을 볼만큼 봤으니 단맛을 찾아 내야 겠다.
2만 세션을 커버했다면, 이제 빡시게 준비해서 5만 세션 이상은 버티게 해야지.

대역폭을 병목구간으로 만들어 버리는, 그런 구조를 향하여.



( 정윤진,  bluebird_dba@naver.com )

P.S.

1.
nfs 의 마운트 옵션은 기억해 둘 만 하다.  getattr 비율이 40 또는 60% 이상이라면 서버의 로컬 캐시 타임을 늘리는 방법을 강구해 보도록 하자.

nfsstat -c
nfsstat -m


2.
apache2 구동중인 시스템에서 비교적 성능이 출중한 서버인경우에 위와 같은 상황에서
iowait 나 vmstat 에서 특이할 만한 값은 떨어지지 않는다.
server-status 를 적극 사용 하도록 하고, 리눅스라면 ps -eo wchan 을 참고 하도록 하자.

3.
nginx 는 꼬진 서버가 아니다.
다만 nginx 를 꼭 써야한다면, 기존의 웹서버 설정을 매우 디테일하게 살펴야 할 것이다.