8. Reverse Proxy 도입의 이점
• HTTP 요청의 내용에 따라 시스템의 동작 제어
• 시스템 전체의 메모리 사용효율 향상
• 웹 서버가 응답하는 데이터의 버퍼링 역할
13년 4월 7일 일요일
9. 요청의 내용에 따라 시스템의 동작 제어
• 요청 URL에 각기 다른 서버에 분배 가능
• IP주소를 이용한 제어
ex) 접속 IP에 따라 특정 경로 접속 제한
• User-Agent에 의한 제어
ex) 수집 봇의 경우 캐쉬된 페이지 사용
• URL 다시 쓰기
ex) short url
13년 4월 7일 일요일
10. 시스템 전체의 메모리 사용효율 향상
동적 컨텐츠를 생성하는 AP Server(Application Server)와
웹 서버를 분리하여 사용함으로써 메모리 효율성을 향상 시킴
13년 4월 7일 일요일
11. 일반적인 AP 서버의 특징
• AP Server 는 많은 메모리를 사용
사용된 프로그램을 메모리에 상주시켜 응답 시간을 높임
ex) Java, mod_perl, mod_php
• 일반적으로 하나의 요청당 하나의 프로세스/스레드를 사용
어플리케이션 설계가 쉽고 편함
13년 4월 7일 일요일
12. AP 서버에서 모든 요청 처리
동적으로 생성된 페이지 내에 이미지가 30개 정도일 경우
동적 요청 1회 + 정적 요청 30회
30회의 정적 요청에도 대량의 메모리 소비
- 동일한 프로세스 및 스레드로 처리 됨
13년 4월 7일 일요일
13. 서버를 분할할 경우
정적 컨텐츠는 메모리 소비량이 적은 웹 서버가 처리
시스템 전체의 메모리 사용 효율이 높아짐.
• 요청된 URL이 정적 컨텐츠 경로일 경우 웹 서버로
• 그 밖의 URL일 경우 동적 컨텐츠 요청이므로 AP 서버로
13년 4월 7일 일요일
14. 2대의 서버로 서비스할 경우
Reverse Proxy가 웹 서버이므로
정적 컨텐츠를 직접 처리
13년 4월 7일 일요일
15. 웹 서버가 응답하는 데이터의 버퍼링 역할
HTTP Keep-alive?
특정 클라이언트가 한번에 다수의 컨텐츠를
동일한 서버로 부터 얻고자 할 경우 사용
• 장점: Connection에 대한 오버헤드를 줄임
• 단점: 웹 서버에 부하를 야기
프로세스가 일정시간 동안 클라이언트의 응답을 위해서 점유됨
13년 4월 7일 일요일
16. Keep-Alive를 ON할 경우
다수의 스레드가 Keep-Alive를 위해 소비되어
추가적인 클라이언트의 요청을 처리 못함
OFF 할 경우 클라이언트에서 볼때 체감 속도가 저하 됨
13년 4월 7일 일요일
17. Keep-Alive를 처리를 분리
Reverse Proxy 역할을 하는 서버는 프로세스당
메모리 소비량이 많지 않음
• 클라이언트와 Reverse Proxy: Keep Alive ON
• Reverse Proxy와 AP 서버: Keep Alive OFF
13년 4월 7일 일요일
18. 아파치 모듈을 이용한 처리의 제어
Reverse Proxy 로 아파치를 선택한 경우
모듈을 내장해서 전후 처리가 가능
• mod_deflate: AP 서버의 응답을 압축
• mode_ssl: AP 서버의 응답을 SSL로 암호화
13년 4월 7일 일요일
19. 서버가 1대일 경우
동일한 호스트 내에 Reverse Proxy와
AP 서버를 실행해서 역할 분담하여 리소스 효율을 높임
13년 4월 7일 일요일
20. 서버가 1대일 경우
동일한 호스트 내에 Reverse Proxy와
AP 서버를 실행해서 역할 분담하여 리소스 효율을 높임
Reverse Proxy를 도입하지
않아야할 이유는 없다!
13년 4월 7일 일요일
21. 아파치를 사용한
Reverse Proxy의 도입
• Pre-fork 모델보다 Work 모델 사용
• 시스템 사양을 고려한 최대 프로세스/스레드
수 결정
• Keep-Alive 설정
• 필요한 모듈 로드
• Rewrite Rule 설정
13년 4월 7일 일요일
22. ETC.
• 진보된 Re-write Rule 설정
• 특정 호스트로부터 요청 금지
• 로봇으로부터의 요청에 대해 캐시 서버 경유
• AP 서버가 여러대인 경우 부하 분산
• mod_proxy_balancer를 사용하여 분산
• Reverse Proxy와 AP 사이에 LVS를 사용
13년 4월 7일 일요일
23. 2.2. 캐시 서버 도입
(Squid, Memcached)
13년 4월 7일 일요일
24. HTTP 프로토콜
• 느슨한 프로토콜
• State-less
• 프로토콜 레벨에서 캐시 기능을 내장
• Client: If-Modified-Since
• Server: 304 Not modified
13년 4월 7일 일요일
25. Squid 캐시 서버
• HTTP, HTTPS, FTP 등에서 이용되는 오픈소
스 캐시 서버
• Squid를 사용할 경우 임의의 웹 시스템에 캐시
를 내장 가능
• 일반적으로 클라이언트가 서버의 문서를 다운
로드한 것을 캐시할 목적으로 사용
13년 4월 7일 일요일
26. Squid의 사용 - Proxy
클라이언트가 다운로드한 문서를 Squid가 캐싱한 후,
또 다른 클라이언트가 같은 문서를 수신할때 사용
- 네트워크 대역이 절감되고, 클라이언트에서 고속으로 이용 가능
ex) CDN ...
13년 4월 7일 일요일
27. Squid의 사용 -
Reverse Proxy
서버의 부하를 분산
1. Squid는 클라이언트의 요청이 있으면 백엔드 서버로 질의
2. 서버로부터 수신한 문서를 Squid가 자신의 로컬 영역에 캐시
3. 다른 클라이언트로부터 요청이 있으면 캐시의 유효성을 확인 후 캐시를 반환
- 단 시간 내에 클라리언트들로부터 동일한 요청이 있을 경우 백엔드 서버에는 하나의 요청만 도달
13년 4월 7일 일요일
28. Squid는 무엇을
캐싱 하는가?
• HTTP 프로토콜의 캐시 기능을 전제
• URL이 주어진 문서는 기본적으로 캐싱 가능
• 동작
• 정적인 문서: 상당히 좋은 효율로 캐시, 원본 문서가 변경되면 캐시를 갱신
• 동적인 문서: 일정 주기로 캐시를 갱신
• 이슈: 상태를 갖는 동적 문서의 캐싱이 어려움
• 같은 URL이라도 쿠키에 따라 사용자의 출력이 다름
• state-less를 기반으로 하기 때문에 이를 해결 하기 어렵다
• HTTP 레벨에서 캐시가 어려울 경우, 애플리케이션 프로그램 레벨에서 캐
시를 사용 (Ex: Memcached)
13년 4월 7일 일요일
29. Memcached에 의한
캐시
• C언어로 작성된 고속 네트워크에 알맞은 분산 캐시 서버
• 스토리지로 OS 메모리를 이용
• 서버에서 Memcached를 실행하고 전용 클라이언트 라이브러리를 이
용해서 캐시 서버와 통신
• 다수의 언어 지원: Java, C, C++, Perl, Ruby, PHP ...
• 프로그램 내부에서 이용하는 방식
• Squid는 HTTP 프로토콜을 사용한 완성된 솔루션
• 프로그램 내에서 코딩 절차 필요
• key-value 구조로 저장하며, key만 알고 있으면 다른 프로그램에서도
접근 가능
13년 4월 7일 일요일
