System Compleat.

'Linux'에 해당되는 글 2건

  1. NAPI on Linux (1)
  2. Crossover Web Service.

NAPI on Linux

Techs

( younjin.jeong@gmail.com , 정윤진 )

이제는 오래되어 버린 기술이지만, 2006년 경의 2.6.1x 대 커널에서의 NAPI 사용으로 인한 시스템 부하 절감 및 네트워킹 성능 향상은 경이로운 것이었다.  무지막지한 인터럽트 증가로 인하여 static 파일을 서비스 하는 웹 서버가 죽을똥 살똥 하던 모습이란.

언젠가 한번은 적어야지 했는데, 마치 Memory Hole 관련 문제처럼 언젠가는 잊어버리지 않을까 싶어, 생각 난 김에 포스팅 한다.

오랜만에 보는 HOW-To 문서를 번역할 예정이며, 요새 커널 버전과는 매우 동떨어져 있지만.. 뭐 그래도 잘 설명 되었으니까.   문서 원본은 아래의 링크에서 참조 할 수 있다.
( http://www.cookinglinux.org/pub/netdev_docs/napi-howto.php3.html )


NAPI 에 대해 자세한 설명은, 아래의 더보기를 통해 보시도록..
(번역이 허접해도 용서를..)

더보기




결국, 이런저런 내용이 많지만, NAPI 의 핵심은 다음의 몇가지로 압축 될 수 있다.

1)
고부하 상태건 저부하 상태건 패킷의 유입으로 인한 하드웨어로 부터 ( 하드웨어 드라이버로 부터) 의
직접적인 인터럽트는 시스템에 심각한 부하를 일으킬 가능성이 있다.

2)
따라서 이와 같은 인터럽트는 NAPI 및 기타 하드웨어 ( NIC )의 인터럽트 제어를 통해 부하율을 낮출 수 있으나,
다소간의 지연이 발생 할 수 있다.

3)
NAPI 가 동작하는 기본적인 방식은 Polling 이며, 이를 쉽게 말하면 유입된 패킷이 발생할때 마다 인터럽트 하여
가져오는 것이 아니라 드라이버가 원하는 때에 적절한 스케줄링을 통하여 폴링으로 한꺼번에 가져온다.

4)
따라서 이러한 패킷을 저장하기 위한 공간이 필요하며, 이러한 공간이 포화가 된 경우/ 또는 시스템에서 처리
불가능한 경우 등에 대한 대비가 필요하다.

5)
NAPI 는 기본적으로 rx ring 에 동작한다.


로 압축 할 수 있겠다.


번역한 문서가 아주 옛날 버전이기는 하지만, 최신 문서 소개해 봐야 다 기본 내용은 거기서 거기.

실제 netpipe 등과 같은 툴을 통해 packet storming 이나 하드웨어 레벨의 테스팅을 하다 보면
쉽게 접하고 튜닝이 가능한 부분이며, 힘들어하는 시스템에 idle 을 조금이나마 안겨 줄 수 있는
방법이라 하겠다. 배포판 또는 드라이버별로 적용이 되고 안되는 등의 차이가 있는 듯 하니
궁금하면 dmesg 를 확인 해 보길 바란다.


오늘은 이만..


( younjin.jeong@gmail.com 정윤진 )

Crossover Web Service.

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

사용자 삽입 이미지

* 이미지 출처 : http://www.atbshop.co.uk/images/neversummer/ns_swift_iso.jpg


윈도우와  xNix 계열의 서비스를 구현 하면서, 가장 쉬운 것 같으면서 어려운 부분이
웹 서버 간 파일 공유 문제이다.
유닉스 계열의 서버에서는, 보안 및 마운트 관련 이슈만 몇가지 주의하면 큰 어려움 없이
NFS 와 같은 툴을 사용하여 얼마든지 많은 ( 충분한 규모의 ) 웹 서버군을 구성 할 수 있다.

하지만 윈도우에서는 (내가 지식이 짧은 탓도 있지만)  DFS 나 윈도우 2003 부터 지원하기 시작하는 NFS의 클라이언트를 사용하여 동일한 파일들의 서비스 처리가 가능하지만, 통상 윈도우 서버에서는 각 서버별로 소스를 서버 로컬에 위치시키고 사용하는 것이 일반적이다.

여기에는 여러가지 이유가 있는데, ASP.NET 이나 .NET Framwork 의 동작 구조 상 이렇게 처리하게 되는 경우 상대적으로 I/O에 소비되는 비용이 많아지게 되면서, IIS에서 보다 좋은 퍼포먼스를 위해 각 서버 로컬에 소스를 두는 형태로 운용 되어지곤 한다.

세련된 네트웍 장치인 L4 또는 Persistance 세팅을 한 LVS 등이 있다면 역시 별 문제가 되지 않지만, 윈도우 서버만으로 세션 공유를 처리하려면 문제가 되는 부분이 경험적으로 많았다.
( IIS7은 아직 잘 모르니까 패스 )  기본적으로 윈도우에서 지원하는 세션 공유의 타입은 두가지 정도 였던걸로 기억하는데, 하나는 DB를 사용( -ㅁ-;; ) 하는 방법 (out-process) 과 다른 하나는 ASP.NET 의 프로세스 레벨에서의 공유 (in-process) 의 두가지 지만, 이 중에도 in-process 공유 방법의 경우 그 이름에서 알 수 있듯이 프로세스 내부간 공유기 때문에 당연히 서버간 공유가 되지 않는다.

유닉스 계열의 서버의 경우, 최악의 경우지만 세션을 파일로 저장하도록 하고 세션이 끊기면 삭제하며 이 파일이 저장되는 디렉토리를 적절한 퍼미션으로 보호하고 NFS 내부 서버간 공유를 걸어주면 해결 할 수도 있다.  하지만 조금 더 좋은 방법을 사용하자면, repcached 와 같은 툴을 사용하여 세션을 아예 복제 가능한 메모리에 박아버려 서버간 공유 처리가 가능 해 질 수도 있다.  (물론 윈도우에서도 닷넷을 사용하여 가능하다. )

물론, NFS가 만능은 아니다.  NFS는 locking 에 대한 문제가 발생하곤 하는데, 이는 통상 동일한 파일에 대해 서로 다른 서버가 write 요청을 할 때 발생한다.  동일한 파일로의 read 요청은 얼마든지 많아도 ( 물론 충분히 바쁜 서버들의 규모에서 ) 웹 서버쪽에서는 한번만 읽으면 되고, read 의 경우 어느 서버가 언제 가져가도 큰 문제가 되지 않지만 서비스를 동일한 파일에 서로 다른 서버가 쓰기위해 접근하도록 설계 했다면, NFS 안쓰는게 낫다.
하지만 조금만 돌려서 이야기 하면, 결국 동일한 파일을 쓰지 않게만 설계 하면 NFS 서버의 Net I/O 및  Disk I/O 가 허용하는 범위 내에서는 아주 좋은 동작 성능을 확보 할 수 있겠다.
( 웹 서버가 웹 클라이언트 만큼 많지 않은 이상에야 -ㅁ-;; )


이 쉽게 보면 아주 기본적일것 같은 기능인 서버간 파일의 공유 라는 이슈는, 나에게 윈도우에서 큰 어려움으로 직면 했었다.  세상 어디의 어느 문서를 참조해도, IIS 6 이전에 이러한 문제들을 명쾌하게 해결 해 주는 건 없었다.

이러한 부분은 플랫폼에 따른 서비스 구성의 난점으로서, 최근에 윈도우 스토리지 서버를 사용하여 윈도우에서 NFS를 구성해 주고, 이를 리눅스 서버의 계정과 매핑하여 줌으로서 윈도우-리눅스 간 크로스 플랫폼 파일 공유도 지원 해 주긴 하지만,  이는 윈도우 스토리지 - 이기종 플랫폼 의 지원 형태이지  유닉스 또는 일반 스토리지 서버 - 윈도우 서버 간의 공유에 대한 해법은 아니다.

혹자는 물론 삼바나 CIFS 를 말 할 수도 있겠지만, 이 IIS 라는 녀석은 나름 심오해서 웹 사이트의 가상 디렉토리가 응용 프로그램의 속성이 해제 되어야만 원활한 공유가 가능하겠다.
또한, AD 없이 각각 Standalone 의 웹 서버간에 이 동일한 디렉토리를 접근하도록 해 주려면, IIS가 설치되면 기본적으로 설정되는 계정들에 대한 서버 로그인 정보를 메타데이터 수정이라는 다소 복잡한 방법을 통해 ( 물론 MS Resource Kit 에 제공된다 ) 적용 해 주어야 한다.


이러한 다소 복잡 다단한 설정들에도 불구하고, IIS 에서의 가상 디렉토리 공유는 모든 웹서버에서 동일한 디렉토리로의 ( 다른 서버의 ) File Write 를 제공 함으로서 비교적 NFS와 유사한 기능 구현이 가능하다.  하지만 역시, 웹 소스는 서버별 로컬에 주는게 좋다.  ( 향후 Deploy 에서 다시 설명 )  이러한 기능을 구현 할 수 있다는 것 만으로도 웬지 뿌듯함을 느꼈다면 유닉스 엔지니어들이 비웃을까.


DFS 도 어느정도 답이 될 수 있을것 같기는 하다.  다만, 내가 아직 DFS의 기능에 대해 확실히 꿰고 있는 것은 아니니까 이거는 나중에 따로 공부가 완료되면 정리를 하도록 하고.

NTFS에 대해서 더 잘 알았다면 뭔가 멋지게 쓸 수 있을 테지만, 나와 같은 통상의 유닉스 계열에서 시작한 사람들은 왜 윈도우에서는 Hadoop 과 같은 FS를 지원 하지 않는 거지 하는 불만만 날이 갈 수록 심해지게 된다.  그러지 말자.  안되는건 안되고 되는건 되니까.

멋진 Reverse-Proxy 와 함께라면,  IIS 서버를 일종의 WAS 서버로 사용하는것도 가능해 진다.  예전부터 꿈꿔 왔던 거지만,  기존의 웹 서버와 고전적인 WAS 만을 생각한다면 절대 불가능한 이야기지만, uri 별 분리 구성을 취한다면 ( 예전에 썼던거 다시 우려먹는 느낌 ) 완전 멋진  크로스플랫폼 서비스가 가능해 지는 거다.

lighttpd + memcached + eAccelerator 의 심플한 이미지 또는 light weight 웹 서버와 함께, 백단의 .NET 기반의 훌륭한 ( 비지니스 로직의 구현 및 일반적인 백엔드 레벨에서의 jsp 와는 다른, php 보다 복잡 해 질 수 있는) WAS 가 동작 해 준다면, ( DB의 선택 폭은 잘 나가는 모든 DBMS가 되는 것이다! )   서비스 처리량 및 응답성에서 타의 추종을 불허하는
완죵 멋진 구성이 가능 해 질 것이다.


물론 발생하는 로직의 구조상 유닉스 계열의 웹 서버간 특정 부분의 구현에 대해서는, 글쎄 고민하기 나름이랄까.


뭔가 또 이상한 글을 써 버렸지만, 골자는 그거다.
하나의 플랫폼만 고집 할 수는 없다.  필요하다면, 또는 돈으로 떡칠해도 감당 안되는 규모로 가게 되면, 대응 할 수 있는 유연성을 높이기 위한 플랫폼 선택은 시작에 불과하다는 것.

맨날 뜬구름만 잡는 것 같아서, 담번에는 윈도 서버들이 가지고 있는 쓸만한 툴들에 대해서 사례를 통해 좀 구체적으로 적어보아야 겠다.



( 정윤진, bluebird_dba@naver.com )