System Compleat.

'nginx'에 해당되는 글 7건

  1. Global, 혹은 Cache 에 대한 시스템적 고민 (2)
  2. NginX - Useful Proxy

Global, 혹은 Cache 에 대한 시스템적 고민

Techs
( 정윤진, yjjeong@rsupport.com )

간혹 그런 생각이든다.
'과연 시스템적으로 단순한 웹 서비스 구조에서 글로벌을 감안 할때, 메인 시스템 인프라와 같은 규모의 시스템이 지역적으로 필요 할 것인가'

이에 대한 답은 서비스의 동작에 따라 다르겠지만, 단순 컨텐츠의 경우 CDN 등을 이용하는 숱하고 숱한 방법들은 이미 많다.
하지만, 정적 컨텐츠 이외의 동적 컨텐츠가 많은 지역별 거점을 중심으로 운용되는 서비스의 경우에 시장성이 불투명하지만 일부 고객을 위해 서비스를 지속해야 하는경우, 제일 고민 되는 부분은 역시 시스템 및 관리를 위한 비용, 소위 말하는 TCO 가 관건이 되지 않을까.

미국에 메인 센터가 있고, 유럽에 일부 고객이 발생되기 시작한 시점에 사업 규모로서는 유럽에 미국만큼 큰 센터를 두는게 맞겠지만, 아직 얼마만큼의 고객이 확보 될지 모르는 지역에 대규모의 인프라 비용을 투자하는건 아무래도 리스크가 따르기 마련이다.

이런 경우의 해법이 무엇일까 하는 부분은 서비스의 유형별로 많이 다르겠지만, 일반적 웹 서비스에서 이런 질문은 이렇게 치환 될 수 있을 것이다.
'네트웍 회선 품질이 현저한 지역에 고품질의 서비스가 필요한 경우, 어떻게 해결 할 수 있을까?'

파일 전송을 주로 하는 서비스라면 CDN 과 같은 글로벌 업체를 통하는 방법외에는 답을 찾기 쉽지 않다. 하지만 채팅이나, image 서버를 별도로 구성한 웹 서비스의 경우, css 나 js, html 등의 몇 kb 전송에도 수초가 걸리는 상황이라면,  답은 Proxy 에서 찾을 수 있지 않을까.

웹 - WAS - DB 의 경우에는, GeoIP 를 사용할 수 있는 DNS 또는 웹 서버를 사용하여 웹 서버 자체를 글로벌하게 운용하여 답을 찾을 수도 있다.  또는, 웹 서버 자체가 많이 무겁다면, 효율적으로 Cache 를 수행하는 NginX 나 Varnish 등을 통해 적절한 프락싱을 통해 비슷한 해답을 얻을 수도 있을 것이다.

앞에서의 예와 같이, 미국에 수억의 시스템이 있다.  이를 일본과 유럽에 서비스 하고 싶다면, 일본과 미국에 저렴한 서버 호스팅 또는 , 가능한 경우 Amazon 의 EC2 와 같은 서비스에 서버를 한대 둔다.  여기에 NginX 나 Varnish 를 올리고, 필요한 경우 memcached 등과 같은 로직에 녹여 낼 수 있는 캐슁 툴 및 opcode 레벨의 cache 를 지원하는 각종 자원을 사용하거나, 아니면 아주 단순하게 squid 등의 오래된 고전적인 proxy를 통하여, OS 또는 시스템의 자체 Cache 를 믿고 서비스 하는 방법- 


뭐, 이미 이러한 방법을 수행하고 있는 업체도 많겠지만 중요한건 저렴한 비용으로 어느정도 동적인 컨텐츠에 대한 지역별 분산을 노릴 수 있는 잇점이 있다. 

아직 테스트 해 보진 않았지만, 일본에서 네이버와 같은 ( 네이버는 URL 구조가 좀 복잡하지만 ) 웹 서비스에 대해 squid 만 돌려 보아도 그 효과는 순식간에 나타난다.
뭐, 일부 사람들은 CDN 과 같은거 아니냐  라고 할 수 도 있지만, 틀린말은 아니다.
다만 CDN 을 운용하면서 발생 하는 비용이  직접 서버를 간단하게 구성해서 운용하는 비용보다 저렴 하지는 않을 것으로 생각된다.

똑같은 요청을 반복해서 처리 ( 단순 Static 한 컨텐츠가 아닌, 일부 동적인 자원에 대해서도 장기적으로는 동일한 요청에 대한 응답이므로 ) 하는 정도로 시장성이 충분 해 질 때 까지 지역적 서비스를 선별적으로 빠르게 할 수 있다면, ( 물론 로그인과 같은 DB Connect 가 발생하는 액션은 여전히 느리겠지만 ) Comet 이나 간단한 채팅,  css 또는 html, php 와 같은 자원에 대해서는 환상적인 현지 고객의 만족을 얻어 낼 수 있을 것이다.


역시, 오픈소스는 조합하기 나름인가 보다.

NginX - Useful Proxy

Techs

정윤진 ( yjjeong@rsupport.co.kr )

비교적 시스템적으로 간단한 현실세계의 웹 서비스 구조는, 요 몇년 전 부터 비약적으로
발전하고 있다.  글로벌 서비스의 영향 및 지역적으로 다른 망 속도의 영향, 서비스 구조의 복잡성 증가 등으로 인해  각종 스토리지 및 데이터베이스 튜닝,  서버 자원에 대한 업그레이드
만으로는 이제 힘든 시기가 되었다.

따라서 복잡한 로직의 경우에 분산 시스템 구조를 도입하는것이 필연 적이며, 이에 대해서 동일 목적의 서버간 그룹화 하고 더 나아가서는 특정 부하유발 구간 ( 병목구간 ) 에 더 많은 리소스를 투입하여 세분화된 분산 구조를 적용해 준다면, 더 좋은 서비스 퍼포먼스를 기대 할 수 있다.

기존의 APM 구조의 경우 필요한 모듈을 모두 가져다 붙이면 서버는 무겁게 동작하게 되고
따라서 웹서버와 이미지 서버의 분리와 같은 방법등이 등장하였으며, L4 를 사용한 서버 로드밸런싱, Apache 를 대신할 lighttpd 등과 같은 Light Weight 웹 서버등이 그것이다.  물론
규모에 따라 CDN 을 도입 할 수도 있겠지만, 이는 네임 서버의 커스터마이징 또는 상용 솔루션
( 이를테면 F5 Networks 의 Big-IP GTM 와 같은 ) 을 사용하여 자금력이 있는 경우 직접
CDN 비슷한 효과를 낼 수 있다.

이번 프로젝트에 사용했던 이 놀라운 웹서버는, 주 목적이 L7 Level 의 Proxing 이다.
실제 서버 구성은 AJ  ( Andrew J. Kim ) 가 거의 다 했지만. ㅋㅋ;

Nginx 홈페이지에서 말하고 있는 대략적인 기능은 다음과 같다.

Basic HTTP features;

  • Handling of static files, index files, and autoindexing; open file descriptor cache;
  • Accelerated reverse proxying with caching; simple load balancing and fault tolerance;
  • Accelerated support with caching of remote FastCGI servers; simple load balancing and fault tolerance;
  • Modular architecture. Filters include gzipping, byte ranges, chunked responses, XSLT, and SSI. Multiple SSI inclusions within a single page can be processed in parallel if they are handled by FastCGI or proxied servers.
  • SSL and TLS SNI support.

    Mail proxy server features:

    • User redirection to IMAP/POP3 backend using an external HTTP authentication server;
    • User authentication using an external HTTP authentication server and connection redirection to internal SMTP backend;
    • Authentication methods:
      • POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
      • IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
      • SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;
    • SSL support;
    • STARTTLS and STLS support.

    Tested OS and platforms:

    • FreeBSD 3 — 7 / i386; FreeBSD 5 — 7 / amd64;
    • Linux 2.2 — 2.6 / i386; Linux 2.6 / amd64;
    • Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
    • MacOS X / ppc, i386;
    • Windows XP, 2003;

    Architecture and scalability:

    • one master process and several workers processes. The workers run as unprivileged user;
    • kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), event ports (Solaris 10), select, and poll support;
    • various kqueue features support including EV_CLEAR, EV_DISABLE (to disable event temporalily), NOTE_LOWAT, EV_EOF, number of available data, error codes;
    • sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5), sendfile64 (Linux 2.4.21+), and sendfilev (Solaris 8 7/01+) support;
    • accept-filter (FreeBSD 4.1+) and TCP_DEFER_ACCEPT (Linux 2.4+) support;
    • 10,000 inactive HTTP keep-alive connections take about 2.5M memory;
    • data copy operations are kept to a minimum.


    대략적인 시스템 구조를 그리면 다음과 같다.

    라우터 --- L4 --- NginX --- L2 --- Real SVRs

    이중화 하게 되면 부쩍 고민할 것들이 많아지겠지만 일단은 이런 구성이다.

    이 NginX 로 처리하고자 하는 것은, 비교적 적은 공인 IP 로 실제 내부 웹서버들에 대한
    요청 uri 의 라우팅이며 이를테면 이미지 서버가 아닌 웹 서버간에도 기능별 통합 및 분산을
    구현하고 memcached 까지 붙여주면 거의 날아 다닌다.

    linux 의 경우 기본적으로 epoll 및 sendfile 을 지원하기 때문에 성능에 대한 우려는 없으나,
    버전이 아직 0. 으로 다소 불안한 부분이 있을 수 있겠으나, 프로젝트 자체는 굉장히 오래된 것이어서 적절히 이중화 해 준다면 큰 효과를 볼 수 있을 것이다.
    이런말은 좀 그렇지만, 잘 구성할 수 있는 인력이 있는경우 F5 Big-IP LTM 에 Ram Cache 및
    Compress 의 feature 를 돈천만원씩 붇는 것 만큼 매력적이다.

    물론 php와 연동하는경우, xcache 및 fast-cgi 등을 원하는대로 가져다가 붙일 수도 있다.


    만약,  웹서버와 이미지 서버의 분리가 되어있고  웹서버가 수행 기능별 또는 플랫폼 별로
    분리를 해야 할 필요가 있다면 nginx 는 저렴한 비용으로 구축할 수 있는 가장 효과적인
    솔루션이 될 수 있다.  또는 내부 서버간 세션 공유 처리가 잘 되어 있다면, http 전용 서버와
    SSL 처리 전용 서버를 구분 할 수도 있다. 

    또는, 이미지 전용 도메인을 따로 따기가 힘든 경우, 이를 테면 image.a.com 과 같은 도메인
    으로 변경하려 하나  웹 소스가 난잡하거나, 도메인 변경이 쉽지 않은 경우에 다음과 같은
    내부 분산을 통해 효과를 거둘 수 있다.

    a.com/webroot  는 A 서버 그룹으로
    a.com/images   는 B 서버 그룹으로

    이 외에도, 별의 별 모듈이 다 있다.
    몇가지 쓸만한 것을 ( 직접 테스트 해 보진 않았지만~ ) 을 추려보면,

    GeoIP
    Gzip
    HTTP Limit Requests
    ..

    나머지는 아래의 wiki 를 참조 한다.  lighttpd 의 trac 과는 다르게,  굉장히 잘 정리 되어있어
    별도의 설명이 필요 없을 정도다.

    아무튼,
    이 놀라운 L7 Proxy ( 나는 그렇게 생각하고, 그렇게 쓴다. ) 에 대해서는 추후 몇몇 key config를 걸어 놓도록 하고, 실제 apache 와 nginx , lighttpd 등과의 비교를 시도해 보아야 겠다.

    http://wiki.nginx.org/Main
    http://nginx.net/