Ubuntu 14.04에서 WordPress 애플리케이션 서버용 레이어 4 로드 밸런서로 HAProxy를 사용하는 방법

소개

이 자습서에서는 HAProxy를 WordPress 서버, 특히 웹 애플리케이션 계층에 대한 계층 4 로드 밸런서로 사용하는 방법을 설명합니다. 애플리케이션 서버의 로드 밸런싱은 설정에 중복성을 추가하여 서버 장애 또는 네트워킹 문제의 경우 안정성을 높이고 읽기 성능을 향상시키기 위해 여러 서버에 로드를 분산시킵니다. 설정에 별도의 MySQL 데이터베이스 서버에 연결하는 WordPress 애플리케이션 서버가 포함되어 있다고 가정합니다(설정 방법에 대한 자습서의 전제 조건 참조).

단일 웹 서버 애플리케이션만 실행하는 경우 레이어 4 로드 밸런싱이 사이트에 적합합니다. 환경이 더 복잡한 경우(예: 단일 진입점이 있는 별도의 서버에서 WordPress와 정적 웹 서버를 실행하려는 경우) 애플리케이션 계층(계층 7) 로드 밸런싱을 살펴봐야 합니다.

이 자습서는 WordPress를 예로 들어 작성되었지만 일반적인 개념을 사용하여 다른 상태 비저장 웹 애플리케이션의 부하를 분산할 수 있습니다.

전제 조건

이 자습서를 계속하기 전에 별도의 데이터베이스 서버가 있는 WordPress 사이트 설정(또는 유사한 설정)에 대한 자습서를 완료해야 합니다. MySQL로 사이트 성능을 최적화하기 위해 원격 데이터베이스를 설정하는 방법

해당 자습서를 따라 별도의 웹 애플리케이션 및 데이터베이스 서버에 WordPress를 설정한 후에는 두 개의 VPS가 있어야 합니다. 우리는 여러 VPS를 다룰 것이기 때문에 참조 목적으로 두 개의 기존 VPS를 다음과 같이 부를 것입니다.

wordpress-1: WordPress 웹 애플리케이션 서버
mysql-1: WordPress용 MySQL 서버

현재 환경의 추상적 보기는 다음과 같습니다.

현재 환경 외에도 이 튜토리얼을 진행하는 동안 두 개의 추가 VPS가 필요합니다. 우리는 그들을 부를 것입니다:

wordpress-2: 두 번째 WordPress 웹 애플리케이션 서버
haproxy-www: 로드 밸런싱을 위한 HAProxy 서버

레이어 4 로드 밸런싱, 백엔드 또는 ACL과 같은 기본 로드 밸런싱 개념이나 용어에 익숙하지 않은 경우 여기에서 설명하는 문서를 참조하십시오. 기본 사항: HAProxy 및 부하 분산 개념 소개.

우리의 목표

이 튜토리얼을 마치면 다음과 같은 환경을 갖기를 원합니다.

즉, 사용자는 HAProxy 서버로 이동하여 WordPress 사이트에 액세스하고 로드 밸런싱된 WordPress 애플리케이션 서버에 라운드 로빈 방식으로 전달합니다. 두 개(또는 원하는 경우 그 이상)가 모두 MySQL 데이터베이스에 액세스합니다.

현재 환경 스냅샷

선택사항: 이 튜토리얼을 계속하기 전에 현재 환경의 스냅샷을 생성할 수 있습니다. 스냅샷은 이 자습서에서 두 가지 용도로 사용됩니다.

실수한 경우 작업 환경으로 되돌리기 위해
원래 서버의 일회성 복제를 수행하여 PHP 및 Nginx를 다시 설치하고 구성할 필요 없음

참고: 2016년 10월부터 스냅샷 비용은 파일 시스템 내에서 사용된 공간의 양을 기준으로 GB당 매월 $0.05입니다.

wordpress-1 및 mysql-1 VPS의 스냅샷을 찍습니다.

이제 스냅샷이 있으므로 나머지 환경을 구축할 준비가 되었습니다.

두 번째 웹 응용 프로그램 서버 만들기

이제 원래 웹 애플리케이션 서버와 부하를 공유할 두 번째 VPS를 생성해야 합니다. 이에 대한 두 가지 옵션이 있습니다.

원래 VPS wordpress-1
처음부터 새 VPS를 만들고 wordpress-1과 동일한 소프트웨어 및 구성을 사용하여 수동으로 설정합니다.

어느 방법을 사용하든 가능하다면 비공개 네트워킹 옵션을 선택해야 합니다. 이 튜토리얼에서 사용되는 모든 VPS에는 개인 네트워킹이 권장됩니다.

사설 네트워킹 옵션이 없는 경우 사설 IP 주소를 VPS의 공용 IP 주소로 대체하십시오. 애플리케이션과 데이터베이스 서버 간에 암호화되지 않은 데이터베이스 암호와 같은 중요한 데이터를 전송할 때 공용 IP 주소를 사용하는 것은 정보가 공용 인터넷을 통해 이동하기 때문에 좋은 습관이 아닙니다.

옵션 1: 스냅샷으로 새 VPS 생성

wordpress-1에서 찍은 스냅샷을 사용하여 wordpress-2라는 새 VPS를 만듭니다.

이 방법을 선택한 경우 "옵션 2\를 "웹 응용 프로그램 파일 동기화\ 섹션으로 건너뜁니다.

옵션 2: 처음부터 새 VPS 생성

이것은 \옵션 1의 대안입니다.

wordpress-1의 스냅샷을 사용하는 대신 처음부터 wordpress-2 서버를 설정하려면 동일한 소프트웨어를 설치해야 합니다. 원래 WordPress 서버를 설치하고 구성한 방법이 기억나지 않는 경우 필수 문서의 웹 서버 설정 섹션을 참조하십시오.

빠른 참조를 위해 설치 또는 복제해야 하는 관련 소프트웨어 및 구성 파일 목록은 다음과 같습니다.

소프트웨어:

MySQL 클라이언트
엔진엑스
PHP

이 소프트웨어를 설치하려면 wordpress-2 서버에서 다음을 실행하십시오.

sudo apt-get update
sudo apt-get install mysql-client
sudo apt-get install nginx php5-fpm php5-mysql

원래 애플리케이션 서버와 일치하도록 편집하거나 생성해야 하는 구성 파일:

/etc/php5/fpm/php.ini
/etc/php5/fpm/pool.d/www.conf
/etc/nginx/sites-available/example.com
/etc/nginx/sites-enabled/example.com

소프트웨어 구성을 마치면 다음 명령을 사용하여 PHP와 Nginx를 다시 시작하는 것을 잊지 마십시오.

sudo service php5-fpm restart
sudo service nginx restart

새 애플리케이션 서버 설치 및 구성을 완료한 후 WordPress 애플리케이션 파일을 동기화해야 합니다.

웹 애플리케이션 파일 동기화

애플리케이션의 부하를 분산하기 전에 새 서버의 웹 애플리케이션 파일이 원래 WordPress 서버와 동기화되었는지 확인해야 합니다. 이러한 파일의 위치는 WordPress 및 몇 가지 다른 파일을 설치한 위치에 따라 다릅니다. WordPress를 실행하는 데 필요한 php 파일 외에도 WordPress 인터페이스를 통해 업로드된 파일 및 설치 플러그인은 업로드 또는 설치 시 동기화가 필요합니다. 전제 조건 문서에서 /var/www/example.com에 WordPress를 설치했습니다. 모든 예제에 대해 이 위치를 사용하지만 실제 WordPress 설치 경로로 대체해야 합니다.

서버 간에 파일을 동기화하는 방법에는 여러 가지가 있습니다. NFS 또는 glusterFS가 모두 적합한 옵션입니다. 파일 시스템 전체에서 일관성을 유지하면서 각 응용 프로그램 서버가 자체 응용 프로그램 파일 복사본을 저장할 수 있기 때문에 glusterFS를 사용하여 동기화 요구 사항을 충족할 것입니다. 다음은 대상 공유 스토리지의 개념도입니다.

이 섹션에서 사용되는 glusterFS 용어에 익숙하지 않은 경우 이 섹션의 기반이 되는 이 GlusterFS 자습서를 참조하십시오.

참고: 다음 하위 섹션은 wordpress-1과 wordpress-2 서버 간에 자주 이동합니다. 적절한 서버에서 명령을 실행해야 합니다. 그렇지 않으면 문제가 발생합니다!

호스트 파일 편집

참고: 내부 DNS가 있고 VPS의 개인 IP 주소에 대한 레코드가 있는 경우 이 단계를 건너뛰고 나머지 glusterFS 설정 명령 및 구성을 해당 호스트 이름으로 대체하십시오.

그렇지 않으면 wordpress-1 및 wordpress-2 VPS에서:

/etc/hosts 편집:

sudo vi /etc/hosts

다음 두 줄을 추가하여 강조 표시된 단어를 응용 프로그램 서버의 IP 각 IP 주소로 대체합니다.

<예비>

저장하고 종료합니다.

GlusterFS 설치 및 복제된 볼륨 구성

wordpress-1 및 wordpress-2 VPS에서:

apt-get을 사용하여 glusterFS 서버 소프트웨어를 설치합니다.

sudo apt-get install glusterfs-server

wordpress-1에서 다음 명령을 실행하여 wordpress-2와 피어링합니다.

sudo gluster peer probe wordpress-2

wordpress-2에서 다음 명령을 실행하여 wordpress-1과 피어링합니다.

sudo gluster peer probe wordpress-1

wordpress-1 및 wordpress-2에서 glusterFS가 관리하는 파일을 저장할 위치를 생성하려면 다음을 실행합니다.

sudo mkdir /gluster-storage

wordpress-1에서 두 애플리케이션 서버의 /gluster-storage에 데이터를 저장할 volume1이라는 복제 glusterFS 볼륨을 생성하려면 다음을 실행합니다.

<예비>

다시 wordpress-1에서 다음 명령을 실행하여 방금 생성한 glusterFS 볼륨 volume1을 시작합니다.

<예비>

wordpress-1에서 방금 생성하고 시작한 glusterFS 볼륨에 대한 정보를 보려면 다음을 실행하십시오.

sudo gluster volume info

각 WordPress 서버에 대해 하나씩 두 개의 glusterFS "bricks\가 있는 것을 볼 수 있습니다.

이제 glusterFS 볼륨이 실행 중이므로 복제 파일 시스템으로 사용할 수 있도록 마운트하겠습니다.

공유 저장소 마운트

먼저 wordpress-1에 파일 시스템을 마운트합시다.

wordpress-1에서 공유 파일 시스템이 부팅 시 마운트되도록 fstab을 편집합니다.

sudo vi /etc/fstab

/storage-pool을 마운트 지점으로 사용하려면 파일 끝에 다음 행을 추가하십시오. 이것을 자유롭게 대체하십시오(여기와 이 glusterFS 설정의 나머지 부분).

<예비>

저장하고 종료합니다.

wordpress-1에서 이제 glusterFS 볼륨을 /storage_pool 파일 시스템에 마운트할 수 있습니다.

<예비>

그러면 wordpress-1 VPS에 공유 볼륨 /storage-pool이 마운트됩니다. df -h를 실행할 수 있으며 마운트된 파일 시스템으로 나열되어야 합니다. 다음으로 유사한 프로세스를 따라 wordpress-2에 공유 저장소를 마운트합니다.

wordpress-2에서 공유 파일 시스템이 부팅 시 마운트되도록 fstab을 편집합니다.

sudo vi /etc/fstab

/storage-pool을 마운트 지점으로 사용하려면 파일 끝에 다음 행을 추가하십시오. 다른 값을 사용한 경우 여기에서 대체해야 합니다.

<예비>

wordpress-2에서 이제 glusterFS 볼륨을 /storage_pool 파일 시스템에 마운트할 수 있습니다.

sudo mkdir /storage-pool
sudo mount /storage-pool

이제 /storage-pool 파일 시스템에서 생성, 수정 또는 삭제된 모든 파일은 서버 중 하나가 일시적으로 중단되더라도 두 서버에서 동기화됩니다.

WordPress 파일을 공유 저장소로 이동

다음 단계는 wordpress-1의 WordPress 파일을 공유 저장소로 옮기는 것입니다. 강조 표시된 단어를 자신의 값으로 대체하십시오. /var/www/example.com은 WordPress 파일이 있는 위치(및 Nginx가 파일을 찾는 위치)를 나타내며 example.com 자체는 단순히 디렉토리의 기본 이름.

wordpress-1에서 다음 명령을 실행하여 WordPress 애플리케이션 파일을 공유 파일 시스템인 /storage-pool로 이동합니다.

<예비>

다음으로 다음을 실행하여 워드프레스 파일이 원래 저장된 공유 파일 시스템의 워드프레스 파일을 가리키는 심볼릭 링크를 생성하려고 합니다.

<예비>

이제 WordPress 파일은 공유 파일 시스템인 /storage-pool에 있으며 원래 위치인 /var/www/example.com을 통해 Nginx에서 여전히 액세스할 수 있습니다. .

새 애플리케이션 서버를 공유 스토리지로 지정

다음 단계는 공유 파일 시스템의 WordPress 파일을 가리키는 새 웹 응용 프로그램 서버에 심볼릭 링크를 만드는 것입니다.

스냅샷 옵션을 사용하여 wordpress-2를 만든 경우 wordpress-2에서 다음 명령을 실행합니다.

<예비>

*wordpress-2를 처음부터 생성한 경우 wordpress-2에서 다음 명령을 실행합니다.

<예비>

WordPress 응용 프로그램 파일을 동기화하기 위한 것입니다! 다음 단계는 새로운 응용 프로그램 서버인 wordpress-2에 데이터베이스에 대한 액세스 권한을 부여하는 것입니다.

새 데이터베이스 사용자 생성

MySQL은 사용자 이름과 소스 호스트로 사용자를 식별하기 때문에 새 애플리케이션 서버인 wordpress-2에서 연결할 수 있는 새 wordpressuser를 생성해야 합니다.

데이터베이스 VPS mysql-1에서 MySQL 콘솔에 연결합니다.

mysql -u root -p

다음 MySQL 문에서 강조 표시된 모든 단어를 환경에 적합한 단어로 바꿉니다.

wordpressuser: MySQL WordPress 사용자입니다. 이미 존재하는 사용자 이름과 동일한지 확인하십시오
wordpress_2_private_IP: wordpress-2 VPS의 비공개 IP
암호: MySQL WordPress 사용자의 암호입니다. 이미 존재하는 비밀번호와 동일한지 확인하세요(그리고 좋은 비밀번호여야 합니다!).

다음 명령문을 실행하여 새 WordPress 서버인 wordpress-2에서 연결할 수 있는 MySQL 사용자를 만듭니다.

<예비>

다시, wordpressuser, wordpress_2_private_IP를 자신의 값으로 대체하고 데이터베이스의 이름이 "wordpress\가 아닌 경우 변경해야 합니다. 그것도.

<예비>

이제 두 번째 웹 응용 프로그램 서버 wordpress-2가 데이터베이스 서버 mysql-1의 MySQL에 로그인할 수 있습니다.

아직 부하 분산되지 않음

실행 중인 두 개의 웹 응용 프로그램 서버가 있지만 각 서버는 해당 공용 IP 주소를 통해 액세스해야 하므로 응용 프로그램의 부하가 분산되지 않습니다. http://example.com/과 같은 동일한 URL을 통해 애플리케이션에 액세스하고 두 웹 애플리케이션 서버 간에 트래픽 균형을 유지하고자 합니다. 이것은 HAProxy가 들어오는 곳입니다.

HAProxy 설치

개인 네트워킹으로 새 VPS를 만듭니다. 이 자습서에서는 haproxy-www라고 합니다.

haproxy-www VPS에서 apt-get을 사용하여 HAProxy를 설치해 보겠습니다.

sudo apt-get update
sudo apt-get install haproxy

HAProxy 초기화 스크립트를 활성화해야 HAProxy가 VPS와 함께 시작 및 중지됩니다.

sudo vi /etc/default/haproxy

ENABLED 값을 1로 변경하여 HAProxy 초기화 스크립트를 활성화합니다.

ENABLED=1

저장하고 종료합니다. 이제 HAProxy가 VPS와 함께 시작 및 중지됩니다. 또한 이제 service 명령을 사용하여 HAProxy를 제어할 수 있습니다. 실행 중인지 확인해 보겠습니다.

user@haproxy-www:/etc/init.d$ sudo service haproxy status
haproxy not running.

실행되고 있지 않습니다. 사용하기 전에 구성해야 하므로 괜찮습니다. 다음으로 환경에 맞게 HAProxy를 구성해 보겠습니다.

HAProxy 구성

HAProxy의 구성 파일은 두 가지 주요 섹션으로 나뉩니다.

글로벌: 프로세스 전체 매개변수 설정
프록시: defaults, listen, frontend 및 backend 매개변수로 구성

다시 말하지만, HAProxy 또는 기본 로드 밸런싱 개념 및 용어에 익숙하지 않은 경우 다음 링크를 참조하십시오. HAProxy 및 로드 밸런싱 개념 소개

HAProxy 구성: 글로벌

모든 HAProxy 구성은 HAProxy VPS인 haproxy-www에서 수행해야 합니다.

먼저 기본 haproxy.cfg 파일의 복사본을 만들어 보겠습니다.

cd /etc/haproxy; sudo cp haproxy.cfg haproxy.cfg.orig

이제 텍스트 편집기에서 haproxy.cfg를 엽니다.

sudo vi /etc/haproxy/haproxy.cfg

global 및 defaults의 두 섹션이 이미 정의되어 있음을 알 수 있습니다. 먼저 일부 기본 매개변수를 약간 변경합니다.

defaults에서 다음 줄을 찾습니다.

mode    http
option  httplog

두 경우 모두 \http라는 단어를 tcp로 바꿉니다.

mode    tcp
option  tcplog

모드로 tcp를 선택하면 레이어 4 로드 밸런싱을 수행하도록 HAProxy가 구성됩니다. 우리의 경우 이는 특정 IP 주소 및 포트에서 들어오는 모든 트래픽이 동일한 백엔드로 전달됨을 의미합니다. 이 개념에 익숙하지 않은 경우 HAProxy 소개의 로드 밸런싱 유형 섹션을 읽어보십시오.

아직 구성 파일을 닫지 마십시오! 다음에 프록시 구성을 추가합니다.

HAProxy 구성: 프록시

가장 먼저 추가하고 싶은 것은 프런트엔드입니다. 기본 레이어 4 부하 분산 설정의 경우 프런트엔드는 특정 IP 주소 및 포트에서 트래픽을 수신한 다음 들어오는 트래픽을 지정된 백엔드로 전달합니다.

파일 끝에 www 프런트엔드를 추가해 보겠습니다. haproxy_www_public_IP를 haproxy-www VPS의 공용 IP로 바꾸십시오.

<예비>

다음은 위의 프런트엔드 구성 스니펫의 각 행이 의미하는 바에 대한 설명입니다.

프론트엔드 www: 들어오는 www 트래픽을 처리하는 데 사용할 것이므로 "www\라는 프런트엔드를 지정합니다.
bind haproxy_www_public_IP:80: haproxy_www_public_IP를 haproxy-www의 공용 IP 주소로 바꿉니다. 이렇게 하면 이 프런트엔드가 이 IP 주소 및 포트에서 들어오는 네트워크 트래픽을 처리할 것이라고 HAProxy에 알립니다.
default_backend wordpress-backend: 이 프런트엔드의 모든 트래픽이 다음 단계에서 정의할 wordpress-backend로 전달되도록 지정합니다.

프런트엔드 구성을 마친 후 다음 줄을 추가하여 백엔드를 계속 추가합니다. 강조 표시된 단어를 적절한 값으로 바꾸십시오.

<예비>

다음은 위의 백엔드 구성 스니펫의 각 행이 의미하는 바에 대한 설명입니다.

backend wordpress-backend: \wordpress-backend라는 백엔드 지정
balance roundrobin: 이 백엔드가 "roundrobin\ 로드 밸런싱 알고리즘을 사용하도록 지정
mode tcp: 이 백엔드가 "tcp\ 또는 레이어 4 프록시를 사용하도록 지정
server wordpress-1 …: "wordpress-1\이라는 이름의 백엔드 서버, 사설 IP(대체해야 함) 및 수신 포트(이 경우 80)를 지정합니다. "check\ 옵션은 로드 밸런서가 이 서버에서 주기적으로 상태 점검을 수행하도록 합니다.
server wordpress-2 …: "wordpress-2\라는 백엔드 서버를 지정합니다.

이제 저장하고 종료합니다. 이제 HAProxy를 시작할 준비가 되었지만 먼저 로깅을 활성화하겠습니다.

HAProxy 로깅 활성화

HAProxy에서 로그인을 활성화하는 것은 매우 간단합니다. 먼저 rsyslog.conf 파일을 편집합니다.

sudo vi /etc/rsyslog.conf

그런 다음 다음 두 줄을 찾아 주석 처리를 제거하여 UDP syslog 수신을 활성화합니다. 완료되면 다음과 같이 표시됩니다.

$ModLoad imudp
$UDPServerRun 514
$UDPServerAddress 127.0.0.1

이제 rsyslog를 다시 시작하여 새 구성을 활성화하십시오.

sudo service rsyslog restart

이제 HAProxy 로깅이 활성화되었습니다! 로그 파일은 HAProxy가 시작되면 /var/log/haproxy.log에 생성됩니다.

HAProxy 및 PHP/Nginx 시작

haproxy-www에서 HAProxy를 시작하여 구성 변경 사항을 적용합니다.

sudo service haproxy restart

새 애플리케이션 서버를 설정하는 방법에 따라 PHP 및 Nginx를 다시 시작하여 WordPress 애플리케이션을 다시 시작해야 할 수도 있습니다.

wordpress-2에서 다음 명령을 실행하여 PHP와 Nginx를 다시 시작합니다.

sudo service php5-fpm restart
sudo service nginx restart

이제 WordPress는 두 애플리케이션 서버 모두에서 실행되어야 하며 로드 밸런싱됩니다. 그러나 마지막 구성 변경이 아직 남아 있습니다.

WordPress 구성 업데이트

이제 WordPress 애플리케이션의 URL이 변경되었으므로 WordPress에서 몇 가지 설정을 업데이트해야 합니다.

WordPress 서버에서 wp-config.php를 편집합니다. WordPress를 설치한 위치에 있습니다(자습서에서는 /var/www/example.com에 설치했지만 설치는 다를 수 있음).

<예비>

상단 근처에서 define(DB_NAME, wordpress);라고 적힌 줄을 찾고 그 위에 다음 줄을 추가하여 강조 표시된 값을 대체합니다.

<예비>

저장하고 종료합니다. 이제 WordPress URL은 wp-admin 대시보드에 액세스하려고 할 때 작동하는 원래 WordPress 서버 대신 로드 밸런서를 가리키도록 구성됩니다.

로드 밸런싱 완료!

웹 애플리케이션 서버가 이제 로드 밸런싱되었습니다! 로드 밸런싱된 WordPress는 이제 공개 IP 주소 또는 로드 밸런서 haproxy-www의 도메인 이름을 통해 사용자가 액세스할 수 있습니다!

결론

이제 사용자의 부하가 두 WordPress 서버 간에 분산됩니다. 또한 WordPress 애플리케이션 서버 중 하나가 다운되면 다른 WordPress 서버가 모든 트래픽을 전달하기 때문에 사이트를 계속 사용할 수 있습니다!

이 설정에서 사이트가 제대로 작동하려면 HAProxy 로드 밸런서 서버 haproxy-www와 데이터베이스 서버 mysql-1이 실행 중이어야 합니다.

작성: Mitchell Anicas