Download pdf - 서버인프라를지탱하는기술2_1-2

서버/인프라를 지탱하는 기술Ch. 2 한 단계 높은 서버 인프라 기술

아꿈사chois79

13년 4월 7일 일요일

2.1. 리버스 프록시 도입(아파치 모듈)


부하 분산(Load Balancing)

앞 장에서는? L4를 사용하여 TCP 패킷 레벨의 부하를 분산

이 장에서는? Proxy를 사용하여 좀 더 높은 수준(L7: 어플리케이션)으로 부하를 분산


Proxy?사전적 의미: 대리, 대리인, 대용물


HTTP Proxy?

PC 사용자와 인터넷 사이에서 중계자 역할을 수행


Why to use HTTP Proxy?

보안, 성능, 전후 처리 ...


Reverse Proxy?

인터넷과 서버 사이에 놓여서 요청을 대리로 처리


Reverse Proxy 도입의 이점

• HTTP 요청의 내용에 따라 시스템의 동작 제어

• 시스템 전체의 메모리 사용효율 향상

• 웹 서버가 응답하는 데이터의 버퍼링 역할


요청의 내용에 따라 시스템의 동작 제어

• 요청 URL에 각기 다른 서버에 분배 가능• IP주소를 이용한 제어 ex) 접속 IP에 따라 특정 경로 접속 제한• User-Agent에 의한 제어 ex) 수집 봇의 경우 캐쉬된 페이지 사용 • URL 다시 쓰기 ex) short url


시스템 전체의 메모리 사용효율 향상

동적 컨텐츠를 생성하는 AP Server(Application Server)와 웹 서버를 분리하여 사용함으로써 메모리 효율성을 향상 시킴


일반적인 AP 서버의 특징

• AP Server 는 많은 메모리를 사용 사용된 프로그램을 메모리에 상주시켜 응답 시간을 높임 ex) Java, mod_perl, mod_php

• 일반적으로 하나의 요청당 하나의 프로세스/스레드를 사용 어플리케이션 설계가 쉽고 편함


AP 서버에서 모든 요청 처리

동적으로 생성된 페이지 내에 이미지가 30개 정도일 경우동적 요청 1회 + 정적 요청 30회

30회의 정적 요청에도 대량의 메모리 소비- 동일한 프로세스 및 스레드로 처리 됨


서버를 분할할 경우

정적 컨텐츠는 메모리 소비량이 적은 웹 서버가 처리시스템 전체의 메모리 사용 효율이 높아짐.

• 요청된 URL이 정적 컨텐츠 경로일 경우 웹 서버로• 그 밖의 URL일 경우 동적 컨텐츠 요청이므로 AP 서버로


2대의 서버로 서비스할 경우

Reverse Proxy가 웹 서버이므로 정적 컨텐츠를 직접 처리


웹 서버가 응답하는 데이터의 버퍼링 역할

HTTP Keep-alive?

특정 클라이언트가 한번에 다수의 컨텐츠를 동일한 서버로 부터 얻고자 할 경우 사용

• 장점: Connection에 대한 오버헤드를 줄임• 단점: 웹 서버에 부하를 야기 프로세스가 일정시간 동안 클라이언트의 응답을 위해서 점유됨


Keep-Alive를 ON할 경우다수의 스레드가 Keep-Alive를 위해 소비되어추가적인 클라이언트의 요청을 처리 못함

OFF 할 경우 클라이언트에서 볼때 체감 속도가 저하 됨


Keep-Alive를 처리를 분리

Reverse Proxy 역할을 하는 서버는 프로세스당메모리 소비량이 많지 않음

• 클라이언트와 Reverse Proxy: Keep Alive ON• Reverse Proxy와 AP 서버: Keep Alive OFF


아파치 모듈을 이용한 처리의 제어

Reverse Proxy 로 아파치를 선택한 경우 모듈을 내장해서 전후 처리가 가능

• mod_deflate: AP 서버의 응답을 압축• mode_ssl: AP 서버의 응답을 SSL로 암호화


서버가 1대일 경우

동일한 호스트 내에 Reverse Proxy와AP 서버를 실행해서 역할 분담하여 리소스 효율을 높임


서버가 1대일 경우

동일한 호스트 내에 Reverse Proxy와AP 서버를 실행해서 역할 분담하여 리소스 효율을 높임

Reverse Proxy를 도입하지 않아야할 이유는 없다!


아파치를 사용한

Reverse Proxy의 도입

• Pre-fork 모델보다 Work 모델 사용

• 시스템 사양을 고려한 최대 프로세스/스레드 수 결정

• Keep-Alive 설정

• 필요한 모듈 로드

• Rewrite Rule 설정


ETC.

• 진보된 Re-write Rule 설정

• 특정 호스트로부터 요청 금지

• 로봇으로부터의 요청에 대해 캐시 서버 경유

• AP 서버가 여러대인 경우 부하 분산

• mod_proxy_balancer를 사용하여 분산

• Reverse Proxy와 AP 사이에 LVS를 사용


2.2. 캐시 서버 도입(Squid, Memcached)


HTTP 프로토콜

• 느슨한 프로토콜

• State-less

• 프로토콜 레벨에서 캐시 기능을 내장

• Client: If-Modified-Since

• Server: 304 Not modified


Squid 캐시 서버

• HTTP, HTTPS, FTP 등에서 이용되는 오픈소스 캐시 서버

• Squid를 사용할 경우 임의의 웹 시스템에 캐시를 내장 가능

• 일반적으로 클라이언트가 서버의 문서를 다운로드한 것을 캐시할 목적으로 사용


Squid의 사용 - Proxy

클라이언트가 다운로드한 문서를 Squid가 캐싱한 후,또 다른 클라이언트가 같은 문서를 수신할때 사용

- 네트워크 대역이 절감되고, 클라이언트에서 고속으로 이용 가능 ex) CDN ...


Squid의 사용 - Reverse Proxy

서버의 부하를 분산1. Squid는 클라이언트의 요청이 있으면 백엔드 서버로 질의2. 서버로부터 수신한 문서를 Squid가 자신의 로컬 영역에 캐시3. 다른 클라이언트로부터 요청이 있으면 캐시의 유효성을 확인 후 캐시를 반환 - 단 시간 내에 클라리언트들로부터 동일한 요청이 있을 경우 백엔드 서버에는 하나의 요청만 도달


Squid는 무엇을 캐싱 하는가?

• HTTP 프로토콜의 캐시 기능을 전제

• URL이 주어진 문서는 기본적으로 캐싱 가능

• 동작

• 정적인 문서: 상당히 좋은 효율로 캐시, 원본 문서가 변경되면 캐시를 갱신

• 동적인 문서: 일정 주기로 캐시를 갱신

• 이슈: 상태를 갖는 동적 문서의 캐싱이 어려움

• 같은 URL이라도 쿠키에 따라 사용자의 출력이 다름

• state-less를 기반으로 하기 때문에 이를 해결 하기 어렵다

• HTTP 레벨에서 캐시가 어려울 경우, 애플리케이션 프로그램 레벨에서 캐시를 사용 (Ex: Memcached)


Memcached에 의한캐시

• C언어로 작성된 고속 네트워크에 알맞은 분산 캐시 서버

• 스토리지로 OS 메모리를 이용

• 서버에서 Memcached를 실행하고 전용 클라이언트 라이브러리를 이용해서 캐시 서버와 통신

• 다수의 언어 지원: Java, C, C++, Perl, Ruby, PHP ...

• 프로그램 내부에서 이용하는 방식

• Squid는 HTTP 프로토콜을 사용한 완성된 솔루션

• 프로그램 내에서 코딩 절차 필요

• key-value 구조로 저장하며, key만 알고 있으면 다른 프로그램에서도 접근 가능
