SlideShare una empresa de Scribd logo
1 de 17
Nginx
Load Balancing
이재훈(jhlee@ymtech.kr)
2016-06-09
목 차
• NGINX 란?
• NGINX vs APACHE
• NGINX 특징
• NGINX 사용 사례
• LB(Load Balancing) 란?
• LB(Load Balancing) 장점
• LB(Load Balancing) 알고리즘
• 테스트 구성도
• NGINX 설치 및 실행
• LB(Load Balancing) 설정
• VM 간의 테스트
2
NGINX 란?
• 오픈 소스 기반의 reverse proxy 서버로 HTTP 뿐만 아니라 HTTPS, SMTP, POP3,
IMAP 프로토콜을 지원한다.
• 웹 서버 소프트웨어로, 가벼움과 높은 성능을 목표로 하고, 적은 수의 thread로 많
은 클라이언트 처리할 수 있다.
• 비동기(ASYNC) 이벤트 기반(ioctl, send, recv, epoll)
• 더 적은 자원으로 더 빠르게 데이터를 서비스 한다.
3
NGINX vs APARCHE
• NGINX
– 하나의 프로세스(또는 쓰레드)에서 이벤트 처리
• 메모리를 적게 할당
• 비 동기 처리(Block이 되더라도 대기하지 않음)
– 백엔드와 ajp 통신이 어렵고, 모듈 개발이 어려우며, Aparche Http 서버처럼 다양한 모
듈이 없다. (단점)
– 윈도우용 Nginx는 native win32 api를 이용하며, select()연결만 사용하기 때문에 향상된
성능을 기대하기는 어렵고, 이외의 몇몇 제약 때문에 아직 베타버전으로 간주된다.
• APARCHE
– 요청 하나당 프로세스(또는 쓰레드)가 처리하는 구조
• 프로세스가 Block 되는 경우 처리 완료될 때까지 대기
• 프로세스(또는 쓰레드) 메모리를 많이 할당
– 다양한 다중 처리 모듈
4
NGINX 특징
• HTTP 프록시와 웹 서버 기능
– 정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능.
– 캐싱을 통한 리버스 프록시
– 로드 밸런싱
– 고장 진단
– SSL 지원
– 캐싱을 통한 FastCGI 지원
– Name-, IP-기반 가상서버
– FLV 스트리밍
– MP4 스트리밍 모듈을 이용한 MP4 스트리밍
– 웹페이지 접근 인증
– gzip 압축
– 10000개의 동시 접속을 처리할 수 있는 능력
– URL 다시쓰기 (URL rewriting)
– 맞춤 로깅
– 서버 사이드 기능 포함
– WebDAV
• 메일 프록시 기능
– SMTP, POP3, IMAP 프록시
– STARTTLS 지원
– SSL 지원
5
6
NGINX 사용 사례
LB(Load Balancing) 란?
7
• 부하 분산
• 처리량을 최대화, 응답 시간을 최소화, 임의의 단일 리소스의 과부하 방지, 자원 사
용을 최적화하는 것을 목표로 한다.
• 안정성과 가용성 증가
• 멀티 레이어 스위치, DNS 서버, 서버 팜, NNPT(Network News Transfer
Protocol), 고 대역폭 파일전송 프로토콜 등에 사용된다.
Load Balancing
질의 요청
Client
Server
Server
Server
Client
Client
LB(Load Balancing) 장점
8
• 각 노드의 성능과 전체 시스템 성능을 향상시킨다.
– 저렴한 비용으로 다수의 서버를 증설하여 경제적으로 비용절감
– 확장성
– 높은 생산량과 신뢰성
• 작업 유휴 시간을 감소시킨다.
– 응답시간 최소화
– 자원 사용률 최대화
Load Balancing 알고리즘 종류
• Round Robin (순차방식)
• Least Connection (최소접속방식)
• Weighted Least Connection (가중치 최소접속방식)
• Fastest Least Connections (응답시간방식)
• Adaptive (최소대기방식)
• Fixed (고정방식)
9
• 각 서버 운영체제
– Ubuntu 14.04
• Dig Client (1대)
• LB(Load Balancing) 서버 (1대)
– Nginx (192.168.45.128:5000)
• DNS Server (3대)
– pDNS 서버
• 192.168.45.134:53
• 192.168.45.135:53
• 192.168.45.137:53
테스트 구성도
10
LB(Nginx)
http://192.168.45.128:5000
Dig 요청
DNS Server
DNS Server
DNS Server
Client
http://192.168.45.134:53
http://192.168.45.135:53
http://192.168.45.137:53
NGINX 설치 및 실행
• NGINX 설치
– $sudo apt-get update
– $sudo apt-get install nginx
• nginx 설치
• nginx 설치가 완료되면 자동으로 시작된다.
11
NGINX 설치 및 실행
• NGINX 실행
– $sudo service nginx start or $sudo /etc/init.d/nginx start $sudo apt-get install nginx
• nginx 실행
– $sudo service nginx stop or $sudo /etc/init.d/nginx stop
• nginx 정지
– $sudo service nginx restart or $sudo /etc/init.d/nginx restart
• nginx 재시작
– $sudo service nginx reload or $sudo /etc/init.d/nginx reload
• nginx 리로드
12
LB(Load Balancing) 설정 - 1
• nginx.conf 설정
– $cd /etc/nginx
• nginx 디렉토리로 이동
– $sudo vi nginx.conf
• LB 설정을 위하여 nginx.conf 파일 편집
13
LB(Load Balancing) 설정 - 2
① 로그 포맷
– 일반적인 Access 로그
• $body_bytes_sent : 응답헤더를 세지 않고 클라이언트로 보낸 바이트 수
• $bytes_sent : 응답헤더를 세지 않고 클라이언트로 보낸 바이트 수
• $connection : 연결된 일련 번호
• $connection_requests : 요청에 의해 연결된 현재 번호
• $msec : 로그에 milliseconds 시간을 남긴다.
• $request_length : 요청 길이
• $request_time : 요청 시간
• $status : 응답 상태
• $time_iso8601 : ISO 8601 표준 형식의 현지 시간
• $time_local : 공통 로그 형식의 현지 시간
• $remote_addr : 방문자의 IP_Address가 표시된다.
– nginx Load Balance Log_format 관련
• $upstream_addr : 로그 밸런싱에 응답하는 웹 서버
• $upstream_reponse_time : 로드 밸런싱 되는 웹 서버의 응답 시간
• $upstream_status : 서버 응답 코드
② upstream 설정
– 부하분산, 속도 개선과 같은 역할을 한다.
– 여러 서버가 순차적으로 일을 할 경우 서비스를 처리하는 서버를 의미
– 형태
upstream 이름 {
[ip_hash;]
server host 주소: 포트 [옵션];
.....
}
– 옵션
• ip_hash : 같은 방문자로부터 도착한 요청은 항상 같은 업스트림 서버가 처리 할 수 있게 한다.
• weight=n : 업스트림 서버의 비중을 나타낸다. 이 값을 2로 설정하면 그렇지 않은 서버에 비해 두배 더 자주 선택된다.
• max_fails=n : n으로 지정한 횟수만큼 실패가 일어나면 서버가 죽은 것으로 간주한다.
• fail_timeout=n : max_fails가 지정된 상태에서 이 값이 설정만큼 응답하지 않으면 죽은 것으로 간주한다.
• down : 해당 서버를 사용하지 않게 지정한다. ip_hash; 지시어가 설정된 상태에서만 유효하다.
• backup : 모든 서버가 동작하지 않을 때 backup으로 표시된 서버가 사용되고 그 전까지는 사용되지 않는다.
– 예제
• ip_hash를 통해 같은 같은 방문자일 경우 같은 ip서버를 호출한다.
• 서버 192.168.0.100:9000은 남들보다 2배 더 많이 호출된다.
• 서버 192.168.0.102:9000은 30초간의 timeout시간이 있으며 3번 실패 시 더이상 호출을 하지 않는다.
③ server (호스트)설정
– listen : 호스트 포트를 설정
– 서버 이름 설정(server_name)
– 초기 페이지 설정(index)
– location : 웹사이트의 특정 위치에 적용할 설정 그룹을 정의한다.
14
VM 간의 테스트 - 1
15
• pDNS 서버 구동 (3개)
VM 간의 테스트 -2
16
• Dig Client 요청
VM 간의 테스트 -3
17
• LB 서버 (nginx) Log 확인
• pDNS 서버 Log 확인

Más contenido relacionado

La actualidad más candente

Webservice cache strategy
Webservice cache strategyWebservice cache strategy
Webservice cache strategy
DaeMyung Kang
 
서버인프라를지탱하는기술2_1-2
서버인프라를지탱하는기술2_1-2서버인프라를지탱하는기술2_1-2
서버인프라를지탱하는기술2_1-2
HyeonSeok Choi
 

La actualidad más candente (20)

Understanding of Apache kafka metrics for monitoring
Understanding of Apache kafka metrics for monitoring Understanding of Apache kafka metrics for monitoring
Understanding of Apache kafka metrics for monitoring
 
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
카프카(kafka) 성능 테스트 환경 구축 (JMeter, ELK)
 
Webservice cache strategy
Webservice cache strategyWebservice cache strategy
Webservice cache strategy
 
Web server
Web serverWeb server
Web server
 
모바일 메신저 아키텍쳐 소개
모바일 메신저 아키텍쳐 소개모바일 메신저 아키텍쳐 소개
모바일 메신저 아키텍쳐 소개
 
웹서버와 ProudNet 서버간 상호작용 가이드
웹서버와 ProudNet 서버간 상호작용 가이드웹서버와 ProudNet 서버간 상호작용 가이드
웹서버와 ProudNet 서버간 상호작용 가이드
 
서버인프라를지탱하는기술2_1-2
서버인프라를지탱하는기술2_1-2서버인프라를지탱하는기술2_1-2
서버인프라를지탱하는기술2_1-2
 
Advanced webpack
Advanced webpackAdvanced webpack
Advanced webpack
 
[온라인교육시리즈] 베어메탈서비스 소개 및 활용 - 현영환 클라우드 솔루션 아키텍트
[온라인교육시리즈] 베어메탈서비스 소개 및 활용 - 현영환 클라우드 솔루션 아키텍트[온라인교육시리즈] 베어메탈서비스 소개 및 활용 - 현영환 클라우드 솔루션 아키텍트
[온라인교육시리즈] 베어메탈서비스 소개 및 활용 - 현영환 클라우드 솔루션 아키텍트
 
HTTP 완벽가이드 7장 캐시
HTTP 완벽가이드 7장 캐시HTTP 완벽가이드 7장 캐시
HTTP 완벽가이드 7장 캐시
 
Kafka 자료 v0.1
Kafka 자료 v0.1Kafka 자료 v0.1
Kafka 자료 v0.1
 
[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis Cluster[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis Cluster
 
Journey for provisioning 20k over rbd volumes to kubernetes with openstack
Journey for provisioning 20k over rbd volumes to kubernetes with openstackJourney for provisioning 20k over rbd volumes to kubernetes with openstack
Journey for provisioning 20k over rbd volumes to kubernetes with openstack
 
카프카, 산전수전 노하우
카프카, 산전수전 노하우카프카, 산전수전 노하우
카프카, 산전수전 노하우
 
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
 
HTTP 완벽 가이드 / 20장 리다이렉션과 부하균형
HTTP 완벽 가이드 / 20장 리다이렉션과 부하균형HTTP 완벽 가이드 / 20장 리다이렉션과 부하균형
HTTP 완벽 가이드 / 20장 리다이렉션과 부하균형
 
Hanghae99 FinalProject Moyeora!
Hanghae99 FinalProject Moyeora!Hanghae99 FinalProject Moyeora!
Hanghae99 FinalProject Moyeora!
 
cbhoilab vagrant와 ansible 쿠버네티스 설치 v2
cbhoilab vagrant와 ansible 쿠버네티스 설치 v2cbhoilab vagrant와 ansible 쿠버네티스 설치 v2
cbhoilab vagrant와 ansible 쿠버네티스 설치 v2
 
FCGI, C++로 Restful 서버 개발
FCGI, C++로 Restful 서버 개발FCGI, C++로 Restful 서버 개발
FCGI, C++로 Restful 서버 개발
 
DV 환경에서 PG 연동하기 ('우리 안의 소리', 2015-11-19)
DV 환경에서 PG 연동하기 ('우리 안의 소리', 2015-11-19)DV 환경에서 PG 연동하기 ('우리 안의 소리', 2015-11-19)
DV 환경에서 PG 연동하기 ('우리 안의 소리', 2015-11-19)
 

Similar a 20170609 tech day_4th-nginx(lb)-이재훈

로그 수집, 집약
로그 수집, 집약로그 수집, 집약
로그 수집, 집약
kidoki
 
AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)
AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)
AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)
Brian Hong
 
AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017
AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017
AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017
Amazon Web Services Korea
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
Amazon Web Services Korea
 

Similar a 20170609 tech day_4th-nginx(lb)-이재훈 (20)

로그 수집, 집약
로그 수집, 집약로그 수집, 집약
로그 수집, 집약
 
Dropbox와 같은 시스템은 파일을 어떻게 저장할까?
Dropbox와 같은 시스템은 파일을 어떻게 저장할까?Dropbox와 같은 시스템은 파일을 어떻게 저장할까?
Dropbox와 같은 시스템은 파일을 어떻게 저장할까?
 
resource on openstack
 resource on openstack resource on openstack
resource on openstack
 
LTM
LTMLTM
LTM
 
XE 오픈 세미나(2014-02-22) - XE 서버 성능 개선
XE 오픈 세미나(2014-02-22) - XE 서버 성능 개선XE 오픈 세미나(2014-02-22) - XE 서버 성능 개선
XE 오픈 세미나(2014-02-22) - XE 서버 성능 개선
 
나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016
나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016
나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016
 
AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)
AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)
AWS와 함께 한 쿠키런 서버 Re-architecting 사례 (Gaming on AWS)
 
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
[Gaming on AWS] AWS와 함께 한 쿠키런 서버 Re-architecting 사례 - 데브시스터즈
 
L4교육자료
L4교육자료L4교육자료
L4교육자료
 
[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
 
SQL-on-Hadoop with Apache Tajo, and application case of SK Telecom
SQL-on-Hadoop with Apache Tajo,  and application case of SK TelecomSQL-on-Hadoop with Apache Tajo,  and application case of SK Telecom
SQL-on-Hadoop with Apache Tajo, and application case of SK Telecom
 
Kubernetes
Kubernetes Kubernetes
Kubernetes
 
AWS를 활용한 글로벌 아키텍처 운용 전략 - 김상필 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced
AWS를 활용한 글로벌 아키텍처 운용 전략 - 김상필 솔루션즈 아키텍트:: AWS Cloud Track 2 AdvancedAWS를 활용한 글로벌 아키텍처 운용 전략 - 김상필 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced
AWS를 활용한 글로벌 아키텍처 운용 전략 - 김상필 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced
 
2017 k8s and OpenStack-Helm
2017 k8s and OpenStack-Helm2017 k8s and OpenStack-Helm
2017 k8s and OpenStack-Helm
 
AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017
AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017
AWS DMS를 통한 오라클 DB 마이그레이션 방법 - AWS Summit Seoul 2017
 
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 GamingCloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
 
서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
 
Npac(엔팩) 가이드
Npac(엔팩) 가이드Npac(엔팩) 가이드
Npac(엔팩) 가이드
 
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
 

Más de ymtech

Más de ymtech (20)

20171120 tech day-11th-소프트웨어 테스팅2-서현용
20171120 tech day-11th-소프트웨어 테스팅2-서현용20171120 tech day-11th-소프트웨어 테스팅2-서현용
20171120 tech day-11th-소프트웨어 테스팅2-서현용
 
20170908 tech day-9th-재미없는 java runtime process 디버그-김성중
20170908 tech day-9th-재미없는 java runtime process 디버그-김성중20170908 tech day-9th-재미없는 java runtime process 디버그-김성중
20170908 tech day-9th-재미없는 java runtime process 디버그-김성중
 
20170713 tech day_7th_pxe 부팅-김주한
20170713 tech day_7th_pxe 부팅-김주한20170713 tech day_7th_pxe 부팅-김주한
20170713 tech day_7th_pxe 부팅-김주한
 
20170519 tech day-3rd-highcharts를 이용한 차트 구현-김영석
20170519 tech day-3rd-highcharts를 이용한 차트 구현-김영석20170519 tech day-3rd-highcharts를 이용한 차트 구현-김영석
20170519 tech day-3rd-highcharts를 이용한 차트 구현-김영석
 
20170414 techday 2nd_uiux디자인-최민희
20170414 techday 2nd_uiux디자인-최민희20170414 techday 2nd_uiux디자인-최민희
20170414 techday 2nd_uiux디자인-최민희
 
20170310 tech day-1st-maven을 이용한 프로그램 빌드-박준홍
20170310 tech day-1st-maven을 이용한 프로그램 빌드-박준홍20170310 tech day-1st-maven을 이용한 프로그램 빌드-박준홍
20170310 tech day-1st-maven을 이용한 프로그램 빌드-박준홍
 
Mikrotic CCR1036 라우팅 설정
Mikrotic CCR1036 라우팅 설정Mikrotic CCR1036 라우팅 설정
Mikrotic CCR1036 라우팅 설정
 
Cubietruck 리눅스 이미지 설치
Cubietruck 리눅스 이미지 설치Cubietruck 리눅스 이미지 설치
Cubietruck 리눅스 이미지 설치
 
Installation Openstack Swift
Installation Openstack SwiftInstallation Openstack Swift
Installation Openstack Swift
 
Welcome to keystone the open stack identity service_v1.0.0-20141208-1212
Welcome to keystone the open stack identity service_v1.0.0-20141208-1212Welcome to keystone the open stack identity service_v1.0.0-20141208-1212
Welcome to keystone the open stack identity service_v1.0.0-20141208-1212
 
Ubuntu Host AP Setting
Ubuntu Host AP SettingUbuntu Host AP Setting
Ubuntu Host AP Setting
 
Intel Galileo Linux Setting
Intel Galileo Linux SettingIntel Galileo Linux Setting
Intel Galileo Linux Setting
 
MarsBoard RK3066 Linux 설치
MarsBoard RK3066 Linux 설치MarsBoard RK3066 Linux 설치
MarsBoard RK3066 Linux 설치
 
HP 3800-24G-2SFP OpenFlow Setting
HP 3800-24G-2SFP OpenFlow SettingHP 3800-24G-2SFP OpenFlow Setting
HP 3800-24G-2SFP OpenFlow Setting
 
Openstack Instance Resize
Openstack Instance ResizeOpenstack Instance Resize
Openstack Instance Resize
 
Openstack live migration
Openstack live migrationOpenstack live migration
Openstack live migration
 
SDN OpenFlow Load Balancer 시나리오
SDN OpenFlow Load Balancer 시나리오SDN OpenFlow Load Balancer 시나리오
SDN OpenFlow Load Balancer 시나리오
 
TR-069 클라이언트 검토자료8편
TR-069 클라이언트 검토자료8편TR-069 클라이언트 검토자료8편
TR-069 클라이언트 검토자료8편
 
TR-069 클라이언트 검토자료7편
TR-069 클라이언트 검토자료7편TR-069 클라이언트 검토자료7편
TR-069 클라이언트 검토자료7편
 
TR-069 클라이언트-검토자료6편
TR-069 클라이언트-검토자료6편TR-069 클라이언트-검토자료6편
TR-069 클라이언트-검토자료6편
 

20170609 tech day_4th-nginx(lb)-이재훈

  • 2. 목 차 • NGINX 란? • NGINX vs APACHE • NGINX 특징 • NGINX 사용 사례 • LB(Load Balancing) 란? • LB(Load Balancing) 장점 • LB(Load Balancing) 알고리즘 • 테스트 구성도 • NGINX 설치 및 실행 • LB(Load Balancing) 설정 • VM 간의 테스트 2
  • 3. NGINX 란? • 오픈 소스 기반의 reverse proxy 서버로 HTTP 뿐만 아니라 HTTPS, SMTP, POP3, IMAP 프로토콜을 지원한다. • 웹 서버 소프트웨어로, 가벼움과 높은 성능을 목표로 하고, 적은 수의 thread로 많 은 클라이언트 처리할 수 있다. • 비동기(ASYNC) 이벤트 기반(ioctl, send, recv, epoll) • 더 적은 자원으로 더 빠르게 데이터를 서비스 한다. 3
  • 4. NGINX vs APARCHE • NGINX – 하나의 프로세스(또는 쓰레드)에서 이벤트 처리 • 메모리를 적게 할당 • 비 동기 처리(Block이 되더라도 대기하지 않음) – 백엔드와 ajp 통신이 어렵고, 모듈 개발이 어려우며, Aparche Http 서버처럼 다양한 모 듈이 없다. (단점) – 윈도우용 Nginx는 native win32 api를 이용하며, select()연결만 사용하기 때문에 향상된 성능을 기대하기는 어렵고, 이외의 몇몇 제약 때문에 아직 베타버전으로 간주된다. • APARCHE – 요청 하나당 프로세스(또는 쓰레드)가 처리하는 구조 • 프로세스가 Block 되는 경우 처리 완료될 때까지 대기 • 프로세스(또는 쓰레드) 메모리를 많이 할당 – 다양한 다중 처리 모듈 4
  • 5. NGINX 특징 • HTTP 프록시와 웹 서버 기능 – 정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능. – 캐싱을 통한 리버스 프록시 – 로드 밸런싱 – 고장 진단 – SSL 지원 – 캐싱을 통한 FastCGI 지원 – Name-, IP-기반 가상서버 – FLV 스트리밍 – MP4 스트리밍 모듈을 이용한 MP4 스트리밍 – 웹페이지 접근 인증 – gzip 압축 – 10000개의 동시 접속을 처리할 수 있는 능력 – URL 다시쓰기 (URL rewriting) – 맞춤 로깅 – 서버 사이드 기능 포함 – WebDAV • 메일 프록시 기능 – SMTP, POP3, IMAP 프록시 – STARTTLS 지원 – SSL 지원 5
  • 7. LB(Load Balancing) 란? 7 • 부하 분산 • 처리량을 최대화, 응답 시간을 최소화, 임의의 단일 리소스의 과부하 방지, 자원 사 용을 최적화하는 것을 목표로 한다. • 안정성과 가용성 증가 • 멀티 레이어 스위치, DNS 서버, 서버 팜, NNPT(Network News Transfer Protocol), 고 대역폭 파일전송 프로토콜 등에 사용된다. Load Balancing 질의 요청 Client Server Server Server Client Client
  • 8. LB(Load Balancing) 장점 8 • 각 노드의 성능과 전체 시스템 성능을 향상시킨다. – 저렴한 비용으로 다수의 서버를 증설하여 경제적으로 비용절감 – 확장성 – 높은 생산량과 신뢰성 • 작업 유휴 시간을 감소시킨다. – 응답시간 최소화 – 자원 사용률 최대화
  • 9. Load Balancing 알고리즘 종류 • Round Robin (순차방식) • Least Connection (최소접속방식) • Weighted Least Connection (가중치 최소접속방식) • Fastest Least Connections (응답시간방식) • Adaptive (최소대기방식) • Fixed (고정방식) 9
  • 10. • 각 서버 운영체제 – Ubuntu 14.04 • Dig Client (1대) • LB(Load Balancing) 서버 (1대) – Nginx (192.168.45.128:5000) • DNS Server (3대) – pDNS 서버 • 192.168.45.134:53 • 192.168.45.135:53 • 192.168.45.137:53 테스트 구성도 10 LB(Nginx) http://192.168.45.128:5000 Dig 요청 DNS Server DNS Server DNS Server Client http://192.168.45.134:53 http://192.168.45.135:53 http://192.168.45.137:53
  • 11. NGINX 설치 및 실행 • NGINX 설치 – $sudo apt-get update – $sudo apt-get install nginx • nginx 설치 • nginx 설치가 완료되면 자동으로 시작된다. 11
  • 12. NGINX 설치 및 실행 • NGINX 실행 – $sudo service nginx start or $sudo /etc/init.d/nginx start $sudo apt-get install nginx • nginx 실행 – $sudo service nginx stop or $sudo /etc/init.d/nginx stop • nginx 정지 – $sudo service nginx restart or $sudo /etc/init.d/nginx restart • nginx 재시작 – $sudo service nginx reload or $sudo /etc/init.d/nginx reload • nginx 리로드 12
  • 13. LB(Load Balancing) 설정 - 1 • nginx.conf 설정 – $cd /etc/nginx • nginx 디렉토리로 이동 – $sudo vi nginx.conf • LB 설정을 위하여 nginx.conf 파일 편집 13
  • 14. LB(Load Balancing) 설정 - 2 ① 로그 포맷 – 일반적인 Access 로그 • $body_bytes_sent : 응답헤더를 세지 않고 클라이언트로 보낸 바이트 수 • $bytes_sent : 응답헤더를 세지 않고 클라이언트로 보낸 바이트 수 • $connection : 연결된 일련 번호 • $connection_requests : 요청에 의해 연결된 현재 번호 • $msec : 로그에 milliseconds 시간을 남긴다. • $request_length : 요청 길이 • $request_time : 요청 시간 • $status : 응답 상태 • $time_iso8601 : ISO 8601 표준 형식의 현지 시간 • $time_local : 공통 로그 형식의 현지 시간 • $remote_addr : 방문자의 IP_Address가 표시된다. – nginx Load Balance Log_format 관련 • $upstream_addr : 로그 밸런싱에 응답하는 웹 서버 • $upstream_reponse_time : 로드 밸런싱 되는 웹 서버의 응답 시간 • $upstream_status : 서버 응답 코드 ② upstream 설정 – 부하분산, 속도 개선과 같은 역할을 한다. – 여러 서버가 순차적으로 일을 할 경우 서비스를 처리하는 서버를 의미 – 형태 upstream 이름 { [ip_hash;] server host 주소: 포트 [옵션]; ..... } – 옵션 • ip_hash : 같은 방문자로부터 도착한 요청은 항상 같은 업스트림 서버가 처리 할 수 있게 한다. • weight=n : 업스트림 서버의 비중을 나타낸다. 이 값을 2로 설정하면 그렇지 않은 서버에 비해 두배 더 자주 선택된다. • max_fails=n : n으로 지정한 횟수만큼 실패가 일어나면 서버가 죽은 것으로 간주한다. • fail_timeout=n : max_fails가 지정된 상태에서 이 값이 설정만큼 응답하지 않으면 죽은 것으로 간주한다. • down : 해당 서버를 사용하지 않게 지정한다. ip_hash; 지시어가 설정된 상태에서만 유효하다. • backup : 모든 서버가 동작하지 않을 때 backup으로 표시된 서버가 사용되고 그 전까지는 사용되지 않는다. – 예제 • ip_hash를 통해 같은 같은 방문자일 경우 같은 ip서버를 호출한다. • 서버 192.168.0.100:9000은 남들보다 2배 더 많이 호출된다. • 서버 192.168.0.102:9000은 30초간의 timeout시간이 있으며 3번 실패 시 더이상 호출을 하지 않는다. ③ server (호스트)설정 – listen : 호스트 포트를 설정 – 서버 이름 설정(server_name) – 초기 페이지 설정(index) – location : 웹사이트의 특정 위치에 적용할 설정 그룹을 정의한다. 14
  • 15. VM 간의 테스트 - 1 15 • pDNS 서버 구동 (3개)
  • 16. VM 간의 테스트 -2 16 • Dig Client 요청
  • 17. VM 간의 테스트 -3 17 • LB 서버 (nginx) Log 확인 • pDNS 서버 Log 확인

Notas del editor

  1. Nginx 란? 러시아 개발자 (lgor Sysoev)가 혼자서 만든 프로젝트이지만, 메모리와 성능이 좋아 입소문으로 많이 알려짐. 2002년부터 시작되어 최근 사용하는 곳이 급속히 증가. 오픈 소스기반의 리버스 프록시 서버로 HTTP뿐만 아니라, HTTPS, SMTP, POP3, IMAP 프로토콜을 지원한다. 웹 서버 소프트웨어로, 가벼움과 높은 성능을 목표로 하고, 적은 수의 쓰레드로도 많은 클라이언트를 처리할 수 있다. 아파치와 대표적으로 다른 점은 쓰레드 기반이 아닌 이벤트 기반이라는 것이다. 여기서 말하는 이벤트 기반이란 Event Driven Architecture(EDA)라고 하는데 아파치같은경우는 하나의 쓰레드에 하나의 클라이언트를 처리한다면 정보를 읽거나 쓴 후 가공해서 클라이언트에 전달할 때까지 쓰레드의 대기시간이 많고 클라이언트개수만큼 스레드가 생성되어야 한다. 하지만 EDA방식에서는 Event(요청이나 응답결과를 모두 생성했을 때)가 발생되었을때 이벤트를 처리하게 해서 더 적은 쓰레드로 CPU가 놀지 않고 일하게 할수 있다 라는 것이다. 또한 이러한 구조는 서버에 많은 부하가 생길 경우의 성능을 예측하기가 쉽다.
  2. 성능 성능은 접속자가 어느 정도 이상 되고 다양한 사이트가 운영되면 차이가 많이 난다. 동접자가 많을수록 체감할 수 있고, 물론 설정을 시스템에 맞게 잘 해야 효과가 극대화 된다. 서버가 리눅스 일 경우 그리고 멀티코어일 경우 엔진엑스와 아파치의 차이가 많이 난다. 한국에서 엔진엑스를 많이 안쓰는 이유는 아직 정형화된 한글 문서들이 없기 때문이다. 호스팅 서비스의 경우 rewrite 관련 부분을 사용하는 호스팅 사용자가 많은 경우 상당히 귀찮아 질 수 있다. 보통 접속자가 많은 사이트 (토렌트, 유머 등등) 인 경우 엔진엑스를 많이 쓰고 있는 추세이다.
  3. 특히 nginx는 http://wordpress.com 에 적용되면서 많이 유명해졌다. 현재 Nginx를 쓰는 유명한 곳으로는 페이스북, Netflix, WordPress.com, 깃헙 (Github), 사운드클라우드 (Soundcloud), Zynga, Sourceforge 등이 있으며, 한국에서는 네이버 첫페이지, 백과사전, 일베저장소, 엔하위키 미러,카카오톡 공지사항 서버,XpressEngine 공식 홈페이지등이 있다.
  4. Load Balancing 알고리즘 종류 Round Robin (순차방식) - 사용자의 요구를 차례대로 각 서버에 균등하게 분배하는 방식으로 서버 커넥션 수나 응답시간에 상관없이 그룹내의 모든 서버를 동일하게 처리하여 일반적인 구성에 있어서 다른 알고리즘에 비해서 가장 빠르다는 장점을 가진다. Least Connection (최소접속방식) - 오픈 커넥션이 가장 적은 서버로 사용자 요구를 연결하는 방식으로 모든 서버가 균등한 트래픽을 유지하기 위해서 처리 속도가 빠른 서버가 더 많은 접속을 받게 된다. 최소접속 알고리즘은 서버들의 성능이 비슷하게 구성되었을 경우에 가장 효과적인 트래픽 분산이 가능하다. Weighted Least Connection (가중치 최소접속방식) - 최소접속 알고리즘에 서버의 성능 가중치를 추가한 것으로, 요구가 동일한 경우 가중치가 높은 서버에서 더 많은 요구를 받게 설계되어 있다. Fastest Least Connections (응답시간방식) - (Fastest Response Time), 가장 빨리 응답하는 서버에 이용자 요구를 연결하는 방법, 응답시간은 각 서버가 패킷 형태의 요구를 송수신하는데 걸리는 시간을 측정한 것이다. Adaptive (최소대기방식) - Open 또는 Pending 커넥션을 적게 가지고 잇는 서버로 네트웍 커넥션 방향을 지정한다. Pending 커넥션은 Full TCP Handshake를 완성하지 않은 것으로, 이것은 초당 클라이언트 Thread의 수가 증가할 때 더욱 잘 수행된다. Fixed (고정방식) - 어떤 서버가 커넥션 요청을 받는지를 결정하기 위해 각 유입요청의 소스 IP 주소를 사용한다. - 여러 종류의 주소로부터 많은 양의 요구가 있을 경우 더 잘 작동한다. - 동일한 게이트웨이를 통하여 들어오는 많은 요구보다 여러 종류의 혼합된 소스 IP 주소의 요구일 경우 더 잘 수행한다.