2013년 1월 16일 수요일

반드시 알아야할 MySQL 특징 세 가지

Overview

MySQL 요구가 전보다 급증하고 있습니다. 이제 친숙해서 사용하는 간단한 소용량 DBMS 이 아닌, 많은 대형 업체에서도 사용되고 있기 때문에 많은 이슈가 되고 있습니다. 트위터, 페이스북, 구글, 야후 뿐만 아니라 최근들어 SNS 열풍으로 국내에도 MySQL 관련하여 엄청난 붐이 시작되려는 찰나인 듯 하네요.

KTH에 입사를 한 당시에 주력 DB는 Oracle이었습니다. 그러나 라이선스 비용 문제로 주력 DB 선정을 위한 저울질이 시작되었고, 그중 일반 개발자에게도 친숙한 MySQL을 선택했습니다.

MySQL 세가지 특성?

MySQL 3.X 버전으로 광고 시스템을 만든 적이 있습니다. 꽤나 오래된 얘기..
지금 생각하면 당시 광고 시스템에서 DB에 날리는 쿼리는 간단하기는 했지만, 상당한 트래픽을 무난히 견디는 것을 보고 감탄을 금치 않았습니다. 와~! 이거 물건인데? 제 첫 사용 소감이었습니다.하지만 “과연 MySQL에 대한 중요한 특성을 잘 알고 있었을까?” 라는 생각이 들었습니다.그때부터였다. MySQL이라는 녀석과 진지한 악수를 한번 해보고 싶다는 생각을 한 것이.. 그래서 여기저기 해외 사례도 기웃거리고, 서적도 진지하게 읽기 시작했죠. 읽으면서 틈틈이 벤치마킹도 수행해보고 나름의 지식 베이스를 늘려갔습니다.

단일 코어에서 Nested Loop Join 처리
다양한 스토리지 엔진
데이터 복제(Replication) 기능

1) 단일 코어에서 Nested Loop Join 처리

MySQL에서는 모든 SQL 처리를 단일 코어에서 Nested Loop Join 방식으로만 데이터를 처리합니다. 병렬 처리라는 것은 없습니다. 물론 일부 3rd스토리지 엔진을 플러그인으로 설치를 하면 병렬 처리가 가능하다고는 하지만, 기본적인 스토리지 엔진에는 단일 코어 수행합니다. 그렇기 때문에 MySQL 입장에서는 CPU코어 개수를 늘리는 Scale-Out보다는 오히려 단위 처리량이 좋은 CPU로 Scale-Up을 하는 것이 훨씬 유리합니다.

MySQL Single Core Processing

게다가 모든 데이터 처리를 Nested Loop Join(이하 NL join)으로 처리합니다. NL join이란 선행 테이블(A)의 조건 검색 결과 값 하나하나를 엑세스 하면서 연결할 테이블(B)에 대입하여 조인하는 방식입니다. 프로그램적으로 풀자면 2 중 While문과 유사하다고 볼 수 있습니다. 처리할 데이터가 적으면 수행 속도가 빠르지만, A테이블 또는 B테이블 중 하나라도 연산을 해야할 데이터가 많아지만 쿼리 효율이 기하급수적으로 떨어집니다.

출처 : http://dev.mysql.com/doc/refman/5.5/en/nested-loop-joins.html

Outer Join이든, Sub Query든, Inner Join이든 모두 NL-Join으로만 처리합니다. DW 또는 데이터 분석 도구보다는 단순 처리를 위한 OLTP 프로세싱에 적합한 DBMS입니다.

2) 다양한 스토리지 엔진

MySQL은 다양한 스토리지 엔진을 지원합니다. MyISAM, InnoDB, Archive, Memory, NDB, Federated 등 기본 엔진 뿐만 아니라 3rd Party 스토리지 엔진도 간단하게 플러그인 형식으로 설치를 할 수 있습니다.

제가 자주 사용하는 스토리지 엔진 세 가지(MyISAM, InnoDB, Archive) 세 가지에 관한 간단한 비교 표입니다.

MySQL Storage Engines 비교

MyISAM Storage Engine인덱스만 메모리에 올려서 테이블 잠금으로 데이터를 처리하는 스토리지 엔진으로 단순 백그라운드에서 로그 수집에 적합합니다. 동시 다발적으로 데이터 변경 작업을 수행하는 로직에는 절대 적합하지 않습니다. 특히 인덱스가 걸려있는 상태에서 대용량(500만 건 이상) 데이터 처리 시 단순 입력 상태에서도 테이블 잠금이 빈번하게 발생할 수 있다는 점을 명심하시기 바랍니다.
Archive Storage Engine원시 로그 수집에 최적인 스토리지 엔진입니다. 트랜잭션, 인덱스 모두 지원하지 않지만, 테이블에서 데이터 처리를 행 단위 잠금으로 수행하기 때문에 동시 다발적으로 데이터 입력 상황에도 상당히 좋은 퍼포먼스를 제공합니다. 게다가 메모리에서 데이터 압축을 수행하면서 실제적으로 디스크에 기록하기 때문에, InnoDB 대비 꽤 좋은 디스크 용량 효율이 있습니다. 게다가 파티셔닝을 지원하기 때문에 추후 로그 정리 시에도 상당히 간단하죠.
InnoDB Storage Engine현재 Oracle에서 가장 밀고 있는 스토리지 엔진으로 In-Memory 특성을 가지고 있습니다. 메모리에 인덱스/데이터 모두 올려서 데이터를 처리하기 때문에 데이터 접근 속도가 상당히 빠릅니다. 메모리가 많이 허용되면 엄청난 퍼포먼스를 발휘하는 엔진이죠. 게다가 트랜잭션을 제공하고, 동시 데이터 처리 시에도 행 단위 잠금으로 처리하기 때문에 실제적으로 InnoDB Storage Engine은 OLTP 성 대용량 처리에 가장 적합한 스토리지 엔진이라고 볼 수 있습니다.

위 세가지 엔진을 능숙하게 사용할 수만 있다면 서버 효율성을 상당 수준 이끌어 낼 수 있다고 생각하는데요. 그래서 간단하게 선정 기준을 다음과 같이 만들어 보았습니다.(지극히 개인적인 생각입니다.)

스토리지 엔진 선정 기준

3) 데이터 복제(Replication) 기능

MySQL은 물리적으로 독립적인 디스크 영역에 데이터를 복제(Replication)하여 데이터를 이중화할 수 있습니다. 하단 그림은 가장 대표적인 MySQL Replication Master-Slave구조를 나타낸 그림입니다. 마스터에서 데이터 변경이 작업이 일어나면, 해당 내역이 자동으로 슬레이브로 비동기적으로 전송되어 실제 마스터의 데이터 복사본을 유지하는 것을 의미합니다.

MySQL Replication 서버 구성

특정 데이터 디스크 Fail시에도 다른 물리적으로 독립적인 디스크에 데이터가 존재하기 때문에, DB 버그가 아니라면 유실은 거의 없습니다. 게다가 디스크 읽기 분산이 가능하기 때문에 읽기 트래픽이 상당히 큰 서비스에 큰 효율을 갖습니다. 대신 데이터 반영은 오직 하나의 노드, 마스터에서만 가능하기 때문에 쓰기 관련된 부하 분산이 불가능합니다. 그리고 마스터 자체 장애는 쓰기 관련 전체 장애로 발생한다는 점도 꼭 기억하세요.

마치며..

MySQL DBMS 사용 시 반드시 알아야하는 세가지 특성!! 꼭 잊지마세요.^^
차근차근 각 특성들을 상세하게 정리해서 공유드리도록 하겠습니다.
읽어주셔서 감사합니다.

출처 : http://gywn.net/2011/12/mysql-three-features/

[Apache 튜닝]apache prefork 와 worker 방식

Apache Multi-Processing Modules(MPM, 다중처리모듈)의 Prefork 와 Worker 방식의 비교
==> apache 서버가 클라이언트에게서 받아들인 요청을 처리하기 위해 "자식 process" 에게 분배하는 방식

Prefork 방식

- 하나의 자식 프로세스가 하나의 쓰레드를 갖는 구조로, 자식 프로세스는 1024까지 늘일 수 있다.
- 한개의 자식 프로세스는 한 개의 연결을 담당한다.
- 프로세스가 생성되는 구조이므로 당연히 worker보다는 많은 메모리를 사용함.
- 프로세스간 메모리를 직접 공유하지 않으므로, 메모리 공간이 독립적이어서 안정적임

httpd.conf에서 httpd-mpm.conf 파일을 include 시켜야 한다.

httpd-mpm.conf 파일에서

<IfModule mpm_prefork_module>
      StartServers 5
      MinSpareServers 5
      MaxSpareServers 10
      MaxClients 150
      MaxRequestsPerChild 0
</IfModule>

옵션 설명
StartServer: 아파치서버의 자식 프로세스 개수 지정

MinSpareServers, MaxSpareServers :
부하가 적어서 MinSpareServers 개수 보다 적었을 경우 최소한 이 개수 만큼 유지하려고 아파치가 노력하고
부하가 증가하여 프로세스 개수가 많아질 경우에 MaxSpareServers 개수 이하로 줄이려고 아파치는 노력한다.
즉, 절대적인 수치가 아니다.

MaxClient : 초기 시작시 실행가능한 최대 아파치 자식 프로세스의 개수를 지정
worker방식의 MaxClient 와는 전혀 다른 의미가 다르지만 결국 클라이언트의 요청을 처리하는 용량을 말하므로 사실상 유사.

MaxReqeustPerChild :클라이언트들의 요청 개수를 제한.
만약 자식 프로세스가 이 값만큼의 클라이언트 요청을 받았다면 이 자식 프로세스는 자동으로 죽게 된다.
0 인 경우 무한대임.

Maxclient 를 늘리기 위한 설정 ( Prefork 방식일 경우 )
1) apache 1.x 버전
Apache 소스 디렉토리/src/include/httpd.h 에서
define HARD_SERVER_LIMIT 256 ----> 512 혹은 1024 등으로 변경 저장후 컴파일

2) apache 2.x~ 2.2.x 버전
apache소스디렉토리/server/mpm/prefork/prefork.c 에서
define DEFAULT_SERVER_LIMIT 256 ----> 512 혹은 1024 등으로 변경후 재부팅

Worker 방식- 자식 프로세스들이 여러개의 쓰레드를 갖을 수 있으며, 각 쓰레드는 한번에 한 연결을 담당함.
- Prefork보다 메모리 사용량이 적음. 통신량이 많은 서버에 적절함.
- 쓰레드 간에 메모리 공간을 공유함. 리소스 경합이 발생하지 않도록 주의 필요. 특히 PHP를 쓰는 경우 유의하여야 함.

httpd.conf에서 httpd-mpm.conf 파일을 include 시켜야 한다.

httpd-mpm.conf 파일에서

    <IfModule mpm_worker_module>
        StartServers 2
        MaxClients 150
        MinSpareThreads 25
        MaxSpareThreads 75
        ThreadsPerChild 25
        MaxRequestsPerChild 0
    </IfModule>

옵션 설명

StartServers(Default 3) : 시작시에 생성되는 서버 프로세스의 개수, 자식 프로세스의 수는 부하에 따라 동적으로 변경되기 때문에 이 값은 큰 의미가 없다.

ServerLimit (default : 16)
    - 구성 가능한 child 프로세스의 제한 수.
    - 이 ServerLimit 값이 필요 이상 높게 설정 된다면, 불필요한 공유 메모리가 할당 되므로 적절한 설정 필요.
    - MaxClient 와 ThreadPerChild 에서 요구한 프로세스 수보다 높게 설정하지 말 것.

MaxClient (default : ServerLimit * ThreadsPerChild)
        - 동시에 처리될 최대 커넥션(request)의 수
        - MaxClients 수치를 초과한 후 온 요청들은 ListenBackLog에 의해 큐잉됨
        - ThreadsPerChild 옵션과 매우 긴밀하게 작용함
        - 동접자가 많을 경우, 이 MaxClient값을 증가시켜야 함.
        - OS의 FD(File Descriptor)값을 증가 시켜 MaxClient 의 상한값을 증가시키도록 할 것.

MinSpareThreads(default 75) : 최소 thread 개수
- 만약 서버에 idle 쓰레드가 충분하지 않다면 child 프로세스는 idle 쓰레드가 MinSpareThreads 보다 커질때까지 생성된다.

MaxSpareThreads(default 250) : 최대 thread개수
- 만약 서버에 너무 많은 idle 쓰레드가 존재하면 child 프로세스는 idle 쓰레드가 MaxSpareThreads 수보다 작아질 때까지 죽는다

ThreadPerChild : 개별 자식 프로세스가 지속적으로 가질 수 있는 Thread의 개수

MaxRequestPerChild : 자식 프로세스가 서비스할 수 있는 최대 요청 개수

ThreadLimit (default : 64)

- child 프로세스의 라이프주기 동안 ThreadsPerChild 의 최대 설정값을 설정한다.
- ThreadLimit 가 ThreadsPerChild 보다 훨씬 높게 설정된다면, 여분의 미사용 공유 메모리가 할당될 것이다.
- ThreadLimit 과 ThreadsPerChild 모두 시스템이 감당할 수 있는 값 보다 높게 설정하면,
아파치가 기동되지 않거나 시스템이 불안정하게 될 수 있다.
- 이 값은 최대 예상 ThreadsPerChild 의 설정보다 높게 설정하면 안된다.

Maxclient 를 늘리기 위한 설정 ( Worker 방식일 경우 - 2.x버전에 한정됨)
1) Maxclient 는 StartServers * ThreadsPerChild 로 정해짐
      ( MaxClient = StartServer * ThreadsPerChild )
    => worker 방식은 각각의 자식프로세스별로 여러개의 thread를 생성해서 요청을 처리하기 때문
2) Maxclient 를 늘리기 위한 설정
    apache소스디렉토리/server/mpm/worker/worker.c 파일 을 수정
    ( define DEFAULT_SERVER_LIMIT 16 값을 늘려준다 )

* 참고1.

대부분 prefork 방식이 기본적으로 사용되며, 사용자가 많은 경우에는 worker방식을 사용한다.
요즘 몇 몇 사이트에서 사용자 폭주로 인하여 worker 방식을 사용하는 경우가 간혹 있다.

*참고2.

apache 설치 시에 아래와 같이, 반드시 --with-mpm=worker 옵션을 설정 하고 설치한다.
이 옵션을 주지 않을 경우, Default인 Prefork방식으로 설치된다(Linux에 한함)

================================================================
./configure --prefix=/home/paint/apache-2.2.15 --enable-mods-shared=all --enable-module=so --enable-so --with-mpm=worker
================================================================

* 참고3.

현재 worker 모듈 설치 되었는지 확인하는 방법

- "httpd -l" 명령으로 현재 설치된 Apache가 worker방식으로 설치되었는지 확인할 수 있다.

============================================

# httpd -l

Compiled in modules:
core.c
worker.c <----------------------요거임
http_core.c
mod_so.c

============================================

또는, httpd -V 명령으로 확인 가능하다. (V는 대문자)

============================================

# httpd -V

Server version: Apache/2.2.15 (Unix)

Server built: Jun 30 2010 16:59:45
Server's Module Magic Number: 20051115:24

Server loaded: APR 1.4.2, APR-Util 1.3.9

Compiled using: APR 1.4.2, APR-Util 1.3.9

Architecture: 32-bit

Server MPM: Worker <------------------------요거

threaded: yes (fixed thread count)

forked: yes (variable process count)

Server compiled with....

-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/home/paint/apache-2.2.15"
-D SUEXEC_BIN="/home/paint/apache-2.2.15/bin/suexec"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"

=============================================

출처 : http://blog.naver.com/sugyoo?Redirect=Log&logNo=20119924250

[출처] [Apache 튜닝]apache prefork 와 worker 방식|작성자 부탄가스

2013년 1월 6일 일요일

PHP 5.3 설치... 중 발생하는 오류 처리

원 설치 옵션

PHP-5.3.15 다운로드(bz2로 다운로드)
[root@localhost]# wget http://kr1.php.net/distributions/php-5.3.15.tar.bz2

[root@localhost]# ./configure --prefix=/home/apps/php --with-apxs2=/home/apps/apache/bin/apxs --disable-debug --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-exif --with-curl --with-gd=/usr --with-gdbm --enable-gd-native-ttf --enable-gd-jis-conv --with-freetype-dir=/usr --with-png-dir=/usr --with-jpeg-dir=/usr --with-xpm-dir=/usr --with-gettext --with-iconv --enable-pcntl --with-readline --with-openssl --with-bz2 --with-zlib --with-mcrypt --with-mhash --enable-mbstring=all --enable-mbregex --enable-libxml --with-xmlrpc --enable-ftp --enable-dba --disable-ipv6 --with-libdir=lib64 --with-pear --with-mysql=shared,/home/db/mysql

QDBM 문제
yum install gdbm-devel gd-devel
yum install libXpm libXpm-devel
yum install libtool-ltdl-devel

설치

libXpm 문제
설치 옵션 중
--with-libdir=lib64
추가

libmcrypt 문제

wget http://ftp.riken.jp/Linux/fedora/epel/RPM-GPG-KEY-EPEL-6

http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

rpm -ivh epel-release-6-8.noarch.rpm

yum reinstall libmcrypt.x86_64
yum reinstall libmcrypt-devel.x86_64

cp -R /home/apps/php/lib /home/apps/php/lib64

2013년 1월 3일 목요일

VirtualBox에 설치된 CentOS 6.3에 Putty를 이용한 접속하는 방법

Assumption

VirtualBox : 4.2.6
CentOS : 6.3

HDD : VDI 50GB

"새로만들기"로 CentOS VM 설치

설치 완료 후 ifconfig 확인
만약, lo만 뜬다면

# ifconfig -a
로 확인하여 eth0가 있는지 확인 후,

# ifup eth0
로 네트워크 활성화

# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /root/ifcfg-eth0.old
# sed -i 's/ONBOOT="no"/ONBOOT="yes"/g' /etc/sysconfig/network-scripts/ifcfg-eth0
# diff /root/ifcfg-eth0.old /etc/sysconfig/network-scripts/ifcfg-eth0

# ping google.com
인터넷이 되는지 확인

가상머신 종료

VirtualBox 설정에서 NIC 추가
어댑터2 -> 호스트 전용 어댑터 선택 -> 고급 -> 모두 허용

VM 가동 후 eth1 활성화
# cp /etc/sysconfig/network-script/ifcfg-eth0 /etc/sysconfig/network-script/ifcfg-eth1

# vim /etc/sysconfig/network-script/ifcfg-eth0
수정 IPADDR="192.168.56.101" #Host Computer의 VirtualBos Host-Olny Network의 IP가
192.168.56.1이기 때문에...

Putty에서 192.168.56.101로 접속

2013년 1월 2일 수요일

How to install "Wordpress"

Install APM

wget htp\://ko.wordpress.org/wordpress-3.5-ko_KR.tar.gz

tar xvfz wordpress-3.5-ko_KR.tar.gz -C /var/www/html

## Make db for WordPress ##

# mysql -u root -p

> CREATE DATABASE wordpressdb;
> CREATE USER wordpressuser@localhost;
> SET PASSWORD FOR wordpressuser@localhost=PASSWORD("wordpresspw");
> GRANT ALL PRIVILEGES ON wordpressdb.* TO wordpressuser@localhost IDENTIFIED BY 'wordpresspw';
> FLUSH PRIVILEGES;
> exit

# cd /var/www/html/wordpress
# cp wp-config-samle.php wp-config.php
# chmod 777 wp-config.php

## Give a Permission to apache to access /var/www ##

# groupadd www-users
# usermod -g www-users apache
# chown -R apache:www-users /var/www
# chmod 2775 /var/www
# chmod g+s /var/www

## Install Plugin to make wordpress site not to allow user without login

Plugin : Authenticator by Frank Bultge

2012년 12월 26일 수요일

IT 기본 용어

AP 서버 (Application Server)
- 애플리케이션 서버, 동적 콘텐츠를 반환하는 서버를 말함. 예를 들면 Apache + mod_perl 이 동작하는 웹 서
버나 Tomcat 과 같은 애플리케이션 컨테이너다 동작하는 서버.

CND (Content Delivery Network)
- 콘텐츠로 전송하기 위한 네트워크 시스템, 전송성능향상과 가용성 향상을 목적으로 한다. Akamai 등 몇몇 상용
서비스가 존재하며, 전 세계에 존재하는 캐시 서버 중에 클라이언트에 보다 가까운 캐시 서버를 선택해 서 전송
함으로써 성능향상 실현하는 것이 구성상 특징임

IPVS (IP Virtual Server)
- LVS (Linux Virtual Server) 프로젝트의 성과물로, 로드밸런서에 불가결한 (부하분산) 기능을 실현함

LVS (Linux Virtual Server)
- 리눅스에서 확장성이있고 가용성이 높은 시스템을 만드는 것을 목표로 하고 있는 프로젝트, 그 성과물 중 하나로
리눅스 로드 벨런서를 위한 IPVS 가 잇다. 본래는 프로젝트명이지만 관례적으로 LVS 를 리눅스로 만든 로드
밸런서 라는 의미로 스기도 한다.

Netfilter
- 리눅스 커널 상에서 네트워크 패킷을 조작하기 위한 프레임 워크, 패킷 필터링 등을 수행하는 iptables 나 로드
밸런스를 실현하기 위한 IPVS 도 Netfilter 의 기능을 이용하고 있다.

NIC (Network Interface Card)
- 본래는 네트워크 기능을 추가하기 위한 카드를 가리키는 용어지만, 확장카드 나 온보드 를 가리지 않고 네트워크
인터페이스를 총칭해서 사용되기도 한다. LAN 카드, 네트워크 카드, 네트워크 어댑터라고도 한다.

OSI 참조 모델
- 데이터 통신을 위한 네트워크 계층을 설명한 모델, 7개 계층 으로 되어있다.
- 자주 접하는 레이어는 다음과 같다.
- 레이어 7 (애플리케이션 계층) : HTTP 나 SMTP 와 같은 통신 프로토콜
- 레이어 4 (트랜스포트 계층) : TCP 나 UDP
- 레이어 3 (네트워크 계층) : IP 나 ARP, ICMP
- 레이어 2 (데이터 링크 계층) : Ethernet 등

VIP (Virtual IP Address)
- 물리적인 서버나 NIC 가 아니라 유동적인 서비스나 역할에 할당된 IP주소를 말함. 예를 들면, 로드밸런서의 경
우에는 클라이언트의 요청을 받아들이는 IP주소를 VIP 라고 함,
이 IP주소는 HTTP 등의 서비스에 관련된 것이기 때문이며, 또한 다중화를 위해 Active/Backup 구성을 할
경우에는 유일한 마스터가 되는 Active 측의 로드 밸런서가 이 IP를 인계하기 때문에다.
가상 주소, 가상 IP 라고도 한다.

가용성 (Availability)
- 시스템을 정지시키지 않음을 뜻함. 가용성이 높다 라고 하면 해당 서비스는 거의 멈추지 않는다 라는 의미다.
또한 문맥에 따라서는 가동률이 높다 거나 연중 가동시간이 길다 라는 의미로도 사용된다.

다중화 (Redundancy)
- 시스템의 구성요소를 여러 개 배치해서 하나가 고장 나서 정지해도 바로 교체 해서 서비스가 멈추지 않도록 하는
것을 말하며, RAID 가 그 전형적인 예, 이중화라고도 한다.

네트워크 부트 (Network Boot)
- 네트워크를 통해 부팅에 필요한 부트로더나 커널 이미지 등을 전달받아 기동는 것, PXE는 네트워크 부트를 실현
하기 위한 구성중 하나.

네트워크 세그먼트 (Network Segment)
- 브로드캐스트 패킷이전달되는 범위의 네트워크를 말함. "충돌 도메인"과 동일한 의미 였지만, 전 이중화 구성에
서는 충돌이 발생하지 않으므로 "네트워크 세그먼트=충돌 도메인" 이라고 하기 어려워졌다.

단일장애점 (Single Point of Failure)
- 장애가 발생하면 시스템 전체가 정지해버리는 부분, 시스템의 급소 SPOF (Single Point Of Failure) 라고도 한
다. 예를 들어, RAID 나 전원과 같은 서버 내의 요소를 아무리 다중화 하더라도 모든 서버가 한대의 스위칭 허브
에 연결 되어있다면, 시스템 전체를 볼 때 그 스위치는 단일장애점 이 된다.

데몬 (Daemon)
- 백 그라운드에서 지속적으로 실행되면서 특정 작업을 수행하는 프로그램, 예를 들어 Httpd 나 Bind 등..

데이터 센터 (Data Center)
- 서버 등의 기기를 수용하기 위해 만들어진 전용시설의 명칭, 공조, 정전대책, 소화, 지진대책과 같이 24시간
365일 서비스를 수행하기 위해 필요한 설비가 갖춰져 있다.

라운드 로빈 (Round Robin)
- 여러 개의 노드에 대해 순서대로 할당하거나 분산하는 것.
예를 들면, 하나의 FQDN (Fully Qualified Domain Name - 전체 주소 도메인명)에 복수의 A 레코드 (IP주소)
를 할당해서 엑세스를 분산하는 DNS 라운드 로빈 이나, 복수의 서버에 순차적으로 요청을 분산하는 로드 벨런
서의 밸런스 알고리즘 등이 있다.

로드 밸런서 (Load Balancer)
- 클라이언트와 서버 사이에 위치해서 클라이언트의 요청을 백엔드(Backend)의 여러 서버로 적절하게 분산하는
역할을 하는 장치, 다르게 표현하면, 여러 서버를 묶어서 하나의 고성능 가상서버에 준하는 성능을 내기 위한
장치, 부하분산기 라고도 한다.

리소스 (Resource)
- CPU, 메모리, HDD 등 서버가 지닌 H/W 적인 자원

메모리 파일 시스템 (Memory File System)
- HDD 와 같은 영구 기억장치가 아닌 메모리상에 만든 파일 시스템, 디스크 상의 파일 시스템과 동일하게 사용할
수 있으나, 메모리상에 있기 대문에 재부팅하면 데이터가 사라지는 반면, R.W를 고속으로 수행가능한 장점.

부하 (Load)
- 여러 종류가 있으며 크게 CPU 부하 와 I/O 부하로 나눌 수 있다. 부하를 계산하기 위한 지표는 Load Average
등 몇가지가 있으며 부하를 계측하기 위한 명령어로는 top 나 vmstat 등 몇가지가 있다.

병목 (Bottleneck)
- 시스템 전체의 성능을 떨어뜨리는 원인이 되는 지점.

블록되다 (Blocked)
- 읽기 또는 쓰기 처리가 완료되기를 기다리기 위해 다른 처리를 할 수 없는 상태를 "I/O 대기로 블록되어 있다" 라
고 한다. 주로 디스크 I/O 나 네트워크 I/O 에 대해 사용된느 용어지만 입출력 처리 일반에서도 사용되기도함.

서버팜 (Server Farm)
- 수 많은 서버가 모여서 구성된 인프라 시스템을 말한다. 문맥에 따라서는 데이터 센터와 같은 시설을 나타내는
의미로 사용되기도 한다.

스위칭 허브 (Switching Hub)
- 현재 시장에 있는 거의 모든 허브는 리피터 허브가 아니라 브리지 기능을 지닌 스위칭 허브이다. L2 스위치 또는
그냥 스위치라고도 한다.

스케일 아웃 (Scale-out)
- 서버를 여러대 두고 분산함으로써 시스템 전체의 성능을 향상시키는 것

스케일 업 (Scale-Up)
- 단일 서버의 성능을 높임으로써 시스템 전체의 성능을 향상시키는 것

스테이징 환경 (Staging Environment)
- 실 서비스에 적용하기 전에 최종적인 동작을 확인하기 위한 환경

장애극복 (FailOver)
- 다중화된 시스템에서 Active 인 노드(서버나 네트워크 기기 등) 가 정지 했을 때 자동적으로 Backup 노드로
전환되는 것, 페일오버, 아울러, 자동이 아닌 수동으로 전환되는 것은 일반적으로 스위치 오버 라고 한다.

전송량 (Throughput)
- 네트워크 와 같이 데이터 통신 측면에서 사용할 경우, 단위시간당 데이터 전송량을 의미한다. 예를 들어 말하자
면 (같은 자동차라도 F1 머신보다 버스가 승차가능 인원이 많으므로 "전송량"이 크다) 라고 할수 있다.

지연시간 (Latency)
- 네트워크와 같이 데이터 통신 측면에서 사용할 경우, 데이터가 도달할 떄까지의 시간을 의미한다.

콘텐츠 (Contents)
- 웹 서비스와 관련해서 사용할 경우, 브라우저와 같은 클라이언트로 반환하는 HTML 이나 이미지 데이터를 의미
한다.

- 정적 콘텐츠 : 내용이 변화하지 않는 HTML 이나 이미지등
- 동적 콘텐츠 : 매 요청마다 내용이 다른 데이터 등
- 데이터 자체가 아니라 동적인 데이터를 출력하는 서버측 프로그램을 "동적 콘텐츠" 라고도 한다.

패킷 (Packet)
- 주로 IP에서 데이터의 최소 단위 묶음을 의미한다.

페일백 (Failback)
- Active 노드가 정지 한 후 장애극복된 상태에서 원래의 정상상태로 복귀하는 것.

프레임 (Frame)
- 주로 이더넷에서 데이터 데이터의 최소단위 묶음을 의미한다.

프로덕션 환경
- 실제 서비스를 하고 있는 환경

확장성 (Scalability)
- 이용자나 규모가 증대됨에 따라 시스템을 확장해서 대응할 수있는 능력의 정도를 나타낸다.

헬스체크 (Health Check)
- 모니터링이라고 보면된다.

[출처] [Info] 기본 용어|작성자 엔지니어 최

2012년 12월 25일 화요일

nginx - Reverse Proxy 설명 - 1

오늘은 저의 전공에 맞게 조금 기술적인 이야기를 해볼까 합니다. 바로 Reverse Proxy 서버로 많이 사용되는 Nginx에 대해 소개하려고 하는데요, 프로그램 소개에 앞서 Reverse Proxy가 무엇인지 먼저 짚고 넘어가도록 하겠습니다.

일반적으로 웹 서비스나 모바일 백엔드(back-end) 시스템은 외부 인터넷과 연결이 되어 있고, 대부분 서버-클라이언트 모델로 동작합니다. 즉, 모바일 앱이나 웹 브라우저 등의 클라이언트에서 요청을 보내면 서버 컴퓨터에서 처리를 한 뒤 응답하는 방식이죠. Reverse Proxy는 서버 컴퓨터에서 이러한 응답을 받아서 내부 프로세스에 넘겨주는 역할을 합니다. 예를 들어 서버 컴퓨터에 Reverse Proxy 서비스에서 HTTP 요청을 받아 Django나 PHP, Node.js 등 내부 HTTP 처리 프로세스로 넘겨주도록 설정해둘 수 있습니다.

그냥 곧바로 요청을 처리하지 않고 Reverse Proxy를 거쳐서 처리하는 이유는 크게 2가지가 있습니다. 첫째로는 보안 이슈입니다. 대부분의 Reverse Proxy는 기본적인 악의적 공격들을 방어해주는 기능을 포함하고 있습니다. 둘째로, 로드 밸런싱(load balancing)이나 서비스 마이그레이션 등이 용이하다는 점입니다. 요청을 받아 특정 서비스로 전달해주는 지점이 하나밖에 없으므로, Reverse Proxy 설정만 바꾸어주면 바로 요청을 처리할 서비스가 변경됩니다. 여러 서비스(혹은 프로세스)를 띄워놓고 어떤 서비스 혹은 프로세스를 사용할지 그때그때 쉽게 설정해줄 수 있고, 버그를 수정한 버전의 서비스를 띄운 뒤 자연스럽게 이전 서비스를 죽일 수도 있습니다.

이제 Reverse Proxy들중 Apache의 mod_proxy와 더불어 가장 많이 사용되는 Nginx를 어떻게 설정하는지에 대해 살펴보겠습니다. 필자는 우분투(Ubuntu) 리눅스 배포판을 사용하므로 이에 맞추어 설명하도록 하겠습니다. 먼저 Nginx를 설치하고 실행합니다.

$ sudo apt-get install nginx

$ sudo /etc/init.d/nginx start

Nginx 프로세스가 실행된 것을 확인하고 나면 브라우저에서 해당 서버로 HTTP 요청을 보냈을 때 Welcome to Nginx 메시지를 확인할 수 있습니다. 그 다음으로 해줘야할 일은 Reverse Proxy 설정을 해주는 일입니다. Nginx의 설정 파일을 다음과 같이 생성합니다. (아래example 부분은 마음대로 변경해도 됩니다)

$ sudo touch /etc/nginx/sites-available/example.conf

$ sudo ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf

$ sudo mkdir /var/log/example

$ sudo vi /etc/nginx/sites-available/example.conf

만약 내부(localhost)의 HTTP 서비스가 8000번 서버에서 돌아가고 있고, 외부 HTTP 요청을 내부 서비스로 넘겨주도록 처리하려면 /etc/nginx/sites-available/example.conf 파일을 다음과 같이 설정합니다.

server {

listen 80;

access_log /var/log/example/access.log;

error_log /var/log/example/error.log;

location / {

proxy_pass_header Server;

proxy_set_header Host $http_host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Scheme $scheme;

proxy_pass http://127.0.0.1:8000;

}

}

아마도 이 상태로 Nginx를 재시작 하게되면 /etc/nginx/sites-available/default와 HTTP 요청이 겹치면서 우리가 만든 설정이 무시될 것입니다. 따라서 default 파일을 sites-available 디렉터리 밖으로 빼서 백업을 해주면 우리의 설정을 적용할 수 있습니다.

$ sudo mv /etc/nginx/sites-available/default /etc/nginx/default.conf.backup

$ sudo /etc/init.d/nginx reload

일반 HTTP 요청 이외에도 HTTPS(보안 인증된 HTTP)나 SMTP(이메일 전송 프로토콜)과 같은 다양한 요청에 대해서도 프록시 설정이 가능합니다. 다른 프로토콜 요청에 대해서는 이 글에서는 다루지 않습니다.

[출처] 빠르고 가벼운 Reverse Proxy, Nginx|작성자 Chris