나쁜 소식 : Wordpress의 핵심 오픈 소스 기반은 단일 서버 (wp-content, 사용자 업로드 및 미디어 라이브러리에서 실행)에 대해 거의 가정하지 않습니다.
좋은 소식 : Azure를 포함한 거의 모든 클라우드 공급자에는 이러한 디자인 제한 사항을 해결할 수있는 추상화가 있습니다.
기본적으로 다음과 같은 문제를 해결하게됩니다.
- 두 개 이상의 "프론트 엔드"Wordpress 웹 / 앱 서버간에로드 밸런싱 트래픽. 사용자가 사이트에 로그인하도록 허용하지 않는 한 Wordpress는 대부분 Stateless이므로 어렵지 않습니다. 이는 DNS와로드 밸런서의 조합을 통해 수행됩니다. 앱 서버에 대해 2 개의 IP를 지원해야합니다. 1 세트는 인터넷을 통해 라우팅 가능한 서브넷에 연결되며 (아래에 설명되지 않은 방화벽으로 보호 되기는하지만) 다른 2 개는 격리 된 다른 서브넷에 있습니다. 다른 네트워크에는 데이터베이스 서버 인스턴스가 포함되지만 기본 개요는 다음과 같습니다.
/-(10.0.0.1-eth0) wp1.domain.com (10.0.1.1-eth2)
(공개 IP) wp.domain.com
\-(10.0.0.2-eth1) wp2.domain.com (10.0.1.2-eth3)
세션 관리 사용자가 사이트에 로그인하도록 허용 한 경우. 그렇다면 서버 1에 로그인 할 때 미래의 모든 요청이 해당 서버로 라우팅되거나 (고정 세션) 세션이 다른 메커니즘을 통해 관리되므로 액세스하는 서버가 중요하지 않은지 확인해야합니다. ( 예를 들어 Zend 서버 세션 클러스터링을 통해 ).
관리자 로그인 관리 일부 사용자가 콘텐츠를 관리하기 위해 백엔드에 로그인하도록 허용하는 경우 (위와 유사).
고 가용성 DB 시스템 선택. DB 충돌로 인해 전체 시스템이 다운되는 경우 프런트 엔드 서버가 두 대가 될 필요가 없습니다. ClearDB를 통해 MySQL Master / Slave 복제를 활용하거나 플러그인을 통해 WordPress를 수정하여 SQL Server를 활용 하여 고유 클러스터링 시스템을 사용해야 합니다 . 즉, DB 계층을 직접 관리하려면 (2 x App & 2 x DB) 최소 4 개의 VM이 필요합니다. 그 모습은 다음과 같습니다.
/-wp1.domain.com (10.0.1.1) \ --- / (10.0.1.3) db1.domain.com (10.0.2.3) \
wp.domain.com X |
\-wp2.domain.com (10.0.1.2) / --- \ (10.0.1.4) db2.domain.com (10.0.2.3) /
참고 -안정적인 페일 오버를 보장하고 시스템의 보안을 보호하기 위해 THIRD 네트워크 서브넷은 일반적으로 앱 서버가 통신하는 데 사용하는 다른 통신 네트워크와 분리 된 개인 채널을 통해 두 데이터베이스 노드를 서로 연결하는 데 사용됩니다. 데이터베이스 및 앱 서버는 외부 세계와 통신하는 데 사용합니다.
연결 풀링을 활성화하면 앱 서버 데이터베이스 연결의 성능과 안정성을 극대화 할 수 있습니다.
프런트 엔드 서버의로드를 최소화하기 위해 W3 Total Cache 또는 Super Cache와 같은 캐싱 플러그인을 활용합니다.
다음 안내서는 위의 각 과제를 해결하는 방법에 대한 특정 정보를 제공합니다. Azure에서 각각을 처리하는 방법에는 여러 가지가 있으므로 각 과제를 어떻게 공격할지 결정한 다음 스택을 위아래로 처리 할 때 이러한 각 선택 사항에 적용되는 제약 조건을 처리해야합니다.