Ultimate Multisite 101

Ultimate Multisite는 고객에게 WaaS 또는 Websites as a Service를 제공할 수 있게 해 주는 WordPress Multisite plugin입니다. Ultimate Multisite가 귀하의 비즈니스와 고객에게 어떻게 도움이 될 수 있는지 본격적으로 알아보기 전에, 먼저 습득해야 할 기초 지식이 있습니다.

WordPress Multisite

우리 대부분은 표준적인 WordPress 설치에 익숙합니다. 호스팅 제공업체의 제어판을 통해 만들거나, 용감한 경우 새 웹 서버와 데이터베이스를 설정하고, 코어 파일을 다운로드한 뒤 설치 과정을 시작합니다.

이 방식은 전 세계 수백만 개의 WordPress 사이트에서 잘 작동하지만, 에이전시나 호스팅 제공업체의 관점에서 잠시 규모에 대해 이야기해 보겠습니다.

자동화된 제어판을 통해 WordPress 사이트 하나, 심지어 백 개를 만드는 것은 매우 쉽지만, 이러한 사이트들을 관리해야 하는 상황이 되면 곧 문제가 드러나기 시작합니다. 관리되지 않은 채 방치하면 악성코드의 주요 표적이 됩니다. 관리는 노력과 리소스를 필요로 하며, WordPress 사이트의 관리와 운영을 간소화하는 데 도움이 되는 외부 도구와 plugin이 있기는 하지만, 고객이 관리자 접근 권한을 유지한다는 사실 때문에 이러한 노력은 쉽게 무력화될 수 있습니다.

WordPress는 코어 안에 단순히 ‘Multisite’라고 불리는 기능을 제공하며, 그 기원은 WordPress 3.0이 출시된 2010년으로 거슬러 올라갑니다. 그 이후로 새로운 기능을 도입하고 보안을 강화하기 위한 여러 차례의 개정이 이루어졌습니다.

본질적으로 WordPress multisite는 다음과 같이 생각할 수 있습니다. 한 대학교가 WordPress의 단일 설치를 유지하지만, 각 학부는 자체 WordPress 사이트를 운영합니다.

이 설명을 더 잘 이해하기 위해, Ultimate Multisite 문서뿐 아니라 WordPress 커뮤니티 전반에서 사용되는 몇 가지 기본 용어를 살펴보겠습니다.

네트워크

WordPress 관점에서 multisite network는 여러 하위 사이트를 하나의 Dashboard에서 관리할 수 있는 곳입니다. multisite network를 만드는 방식은 호스팅 제공업체마다 다르지만, 최종 결과는 대개 WordPress가 이 특정 모드로 작동하고 있음을 알 수 있도록 wp-config.php 파일에 몇 가지 추가 지시문을 넣는 것입니다.

multisite network와 독립형 WordPress 설치 사이에는 몇 가지 뚜렷한 차이가 있으며, 이를 간단히 살펴보겠습니다.

하위 도메인 vs. 하위 디렉터리

가장 먼저 내려야 할 결정 중 하나는 multisite 설치가 _하위 디렉터리_로 작동할지, 아니면 _하위 도메인_으로 작동할지입니다. Ultimate Multisite는 두 선택지 모두에서 동일하게 잘 작동하지만, 두 구성 사이에는 몇 가지 아키텍처상의 차이가 있습니다.

하위 디렉터리 구성에서는 네트워크 사이트가 기본 도메인 이름을 기반으로 한 경로를 상속합니다. 예를 들어 ‘site1’이라는 이름의 네트워크 사이트는 전체 URL이 https://domain.com/site1 이 됩니다. 하위 도메인 구성에서는 네트워크 사이트가 기본 도메인 이름에서 파생된 자체 _하위 도메인_을 갖습니다. 따라서 ‘site1’이라는 이름의 사이트는 전체 URL이 https://site1.domain.com/ 이 됩니다.

두 옵션 모두 완전히 유효한 선택이지만, 하위 도메인 사용은 여러 장점을 제공하는 동시에 그 아키텍처에 대해 더 많은 고민과 계획을 필요로 합니다.

DNS 관점에서 하위 디렉터리 사용은 비교적 단순한 과제입니다. 네트워크 사이트는 단순히 상위 경로의 자식이므로, 기본 도메인 이름에 대해 단 하나의 도메인 이름 항목만 존재하면 됩니다. _하위 도메인_의 경우 과제는 조금 더 복잡하며, 각 네트워크 사이트마다 별도의 CNAME 항목을 두거나 DNS 레코드에 와일드카드(*) 항목을 두어야 합니다.

추가로 고려해야 할 영역은 SSL, 그리고 SSL 인증서의 발급과 사용입니다. 하위 디렉터리 구성에서는 네트워크 사이트가 단순히 기본 도메인 이름의 경로이므로 단일 도메인 인증서를 사용할 수 있습니다. 따라서 domain.com용 인증서는 https://domain.com/site1, https://domain.com/site2 등에도 충분히 SSL을 제공합니다.

하위 도메인 구성에서는 와일드카드 SSL 인증서를 사용하는 것이 가장 일반적인 옵션 중 하나입니다. 이 유형의 SSL 인증서는 하나의 도메인과 그 _하위 도메인_에 암호화를 제공합니다. 따라서 와일드카드 SSL 인증서는 https://site1.domain.com, https://site2.domain.com 및 https://domain.com 자체에 암호화를 제공합니다.

다른 옵션도 존재하지만, 이러한 옵션은 범위와 적용 면에서 제한적인 경우가 많으며, 적합성과 관련해 추가 구성과 검토가 필요합니다.

Plugins와 Themes

WordPress가 주는 것은 빼앗기도 합니다. 적어도 고객의 관점에서는 그렇습니다. 독립형 WordPress 설치에서 사이트 관리자가 나쁜 plugin을 설치하거나 설치 상태를 최신으로 유지하지 못하더라도, 그 행위의 유일한 피해자이자 희생자는 자신뿐입니다. 그러나 multisite 설치에서 사이트 관리자가 나쁜 plugin을 설치하면 네트워크에 설치된 모든 사이트가 피해자가 됩니다.

이러한 이유로 WordPress가 multisite로 구성되면, WordPress는 사이트 관리자에게서 plugin과 theme을 설치할 수 있는 기능을 제거하고, 대신 이 기능을 새로 생성된 네트워크 관리자 또는 ‘super admin’ 역할로 이동합니다. 이 권한 있는 역할은 그런 다음 네트워크 사이트의 관리자들이 Dashboard에서 plugin 메뉴를 보거나 접근할 수 있도록 허용할지, 허용한다면 그러한 권한이 plugin을 _활성화_하거나 _비활성화_하는 데까지 확장되는지 결정할 수 있습니다.

이 범위에서 네트워크 관리자는 네트워크에 plugin과 theme을 설치할 책임이 있으며, 이러한 plugin과 theme을 사용할 권한을 네트워크 사이트에 위임합니다. 사이트 관리자는 plugin과 theme을 설치할 수 없으며, 자신의 사이트에 할당되지 않은 plugin과 theme에 접근할 수 없습니다.

사용자와 관리자

WordPress Multisite에서는 모든 네트워크 사이트가 동일한 데이터베이스를 공유하므로 동일한 사용자, 역할, 기능을 공유합니다. 이를 가장 적절하게 이해하는 방식은 모든 사용자가 특정 사이트가 아니라 네트워크의 구성원이라고 생각하는 것입니다.

이러한 이해를 바탕으로 보면 사용자가 생성되도록 허용하는 것은 바람직하지 않을 수 있으며, 이러한 이유로 WordPress Multisite는 사이트 관리자에게서 이 기능을 제거하고 네트워크 관리자에게 이 기능을 이전합니다. 이어서 네트워크 관리자는 사이트 관리자가 자신의 사이트에 대한 사용자 계정을 만들 수 있도록 필요한 권한을 위임할 수 있습니다.

위의 내용을 다시 말하자면, 사용자 계정은 해당 사이트와 관련된 것처럼 보이지만 실제로는 네트워크에 할당되므로 네트워크 전체에서 고유해야 합니다. 이러한 이유로 사용자 이름을 등록할 수 없는 경우가 있을 수 있습니다.

기업 시스템에서는 낯선 개념이 아니지만, 사용자 등록과 인증의 이 단일 출처 개념은 사용자 관리가 다소 더 쉬운 독립형 WordPress 설치에 익숙한 사람들에게는 이해하기 어려운 경우가 많습니다.

미디어

WordPress Multisite에서 네트워크 사이트가 단일 데이터베이스를 공유하더라도, 미디어 파일에 대해서는 파일 시스템에서 별도의 경로를 유지합니다.

표준 WordPress 위치(wp-content/uploads)는 유지되지만, 그 경로는 네트워크 사이트의 고유 ID를 반영하도록 변경됩니다. 따라서 네트워크 사이트의 미디어 파일은 wp-contents/uploads/site/[id]로 나타납니다.

고유주소

앞서 하위 도메인 구성이 하위 디렉터리 구성보다 뚜렷한 장점이 있다고 언급했는데, 바로 여기서 그 장점이 드러납니다: 경로입니다.

하위 디렉터리 구성에서는 메인 사이트(네트워크가 설정될 때 생성된 첫 번째 사이트)와 네트워크 하위 사이트가 도메인 이름에서 이어지는 동일한 경로를 공유해야 합니다. 이는 많은 충돌 가능성을 가집니다.

글의 경우 네트워크 사이트와의 충돌을 방지하기 위해 메인 사이트에 필수 /blog/ 경로가 추가됩니다. 이는 ‘글 이름’과 같은 보기 좋은 고유주소가 domain.name/blog/post-name/ 형태로 표시된다는 뜻입니다.

하위 도메인 구성에서는 각 네트워크 사이트가 완전한 도메인 분리의 이점을 가지므로 단일 경로에 의존할 필요가 없기 때문에 이 조치가 필요하지 않습니다. 대신 각 사이트는 자신의 _하위 도메인_을 기반으로 고유한 별도 경로를 유지합니다.

정적 페이지

하위 디렉터리 구성에서는 메인 사이트와 네트워크 사이트가 동일한 경로를 공유하므로 이름 충돌 가능성이 정적 페이지까지 확장됩니다.

이를 방지하기 위해 WordPress는 특정 사이트 이름을 블랙리스트에 올려 첫 번째 사이트의 이름과 충돌하지 않도록 하는 수단을 제공합니다. 일반적으로 네트워크 관리자는 메인 사이트 페이지의 루트 경로를 입력합니다.

하위 도메인 구성에서는 _하위 도메인_이 네트워크 사이트에 고유하며 메인 사이트와 어떤 식으로도 관련되지 않기 때문에 이름 충돌 가능성이 완화됩니다.

등록

WordPress Multisite의 네트워크 설정 내에서는 여러 새로운 사용자 등록 옵션을 사용할 수 있으며, 이를 통해 신규 및 기존 사용자가 사이트를 만들 수 있습니다.

독립형 WordPress 설치와 달리, 네트워크 사이트는 사용자 등록을 허용하거나 해당 등록을 역할에 할당하는 익숙한 옵션을 유지하지 않습니다.

사용자 계정이 생성되면 해당 계정은 네트워크 수준에서 생성됩니다. 따라서 특정한 하나의 사이트에 속하는 대신 네트워크에 속합니다. 여기에는 몇 가지 뚜렷한 장점과 단점이 있습니다.

예를 들어, WordPress Multisite가 뉴스와 정보 사업을 위해 사용된다고 가정해 보겠습니다. 멀티사이트를 설정한 다음 금융, 기술, 엔터테인먼트 및 기타 관심 분야를 위한 네트워크 사이트를 만들면서 plugin과 theme에 대한 전반적인 제어를 유지할 수 있습니다. 각 네트워크 사이트는 custom post type이나 일반 글 카테고리보다 자신의 네트워크 사이트의 외형과 사용자 경험에 대해 훨씬 더 높은 수준의 제어권을 갖게 됩니다.

이 정도 범위에서는 사용자가 로그인할 때 네트워크에 로그인하며, 궁극적으로는 원활한 경험을 제공하기 위해 각 네트워크 사이트에도 로그인된 상태가 됩니다. 새 사이트가 구독 기반이라면 이것이 이상적인 해결책이자 결과가 될 것입니다.

그러나 멀티사이트의 의도된 성격과 목적이 서로 관계가 없는 별개의 네트워크 사이트를 제공하는 것이라면, 사용자 역할을 조작하기 위해 외부 또는 추가 plugin이 필요한 경우가 거의 항상 발생합니다.

도메인 및 SSL

우리의 주의를 거의 벗어나는 WordPress Multisite 설치에 대해 이야기해 보겠습니다 - Wordpress.com입니다. 이는 단연 Wordpress multisite의 가장 광범위한 예이며, 목적을 충족하도록 맞춤화하고 형성할 수 있는 그 방대한 능력을 보여 줍니다.

오늘날의 현대 인터넷에서는 SSL 사용이 거의 필수이며, WordPress multisite의 네트워크 관리자들은 곧 이러한 과제에 직면하게 됩니다.

하위 도메인 구성에서는 사이트가 루트 도메인 이름을 기반으로 생성됩니다. 따라서 ‘site1’이라는 레이블이 붙은 사이트는 ‘site1.domain.com’으로 생성됩니다. 와일드카드 SSL 인증서를 사용하면 네트워크 관리자는 이 과제를 성공적으로 해결하고 네트워크에 SSL 암호화 기능을 제공할 수 있습니다.

WordPress Multisite에는 네트워크 사이트를 사용자 지정 도메인 이름 또는 네트워크의 루트 도메인과 다른 도메인 이름에 연결할 수 있는 도메인 매핑 기능이 포함되어 있습니다.

네트워크 관리자에게 이는 도메인 이름 구성뿐만 아니라 SSL 인증서의 발급 및 유지 관리에서도 추가적인 복잡성의 층을 제공합니다.

이러한 범위에서 WordPress Multisite는 www.anotherdomain.com을 ‘site1’에 매핑할 수 있는 수단을 제공하지만, 네트워크 관리자는 DNS 항목을 외부에서 관리하고 SSL 인증서를 구현해야 하는 과제를 안게 됩니다.

Ultimate Multisite

독립형 WordPress 설치와 Multisite 설치의 차이를 이해했으니, Ultimate Multisite가 Websites as a Service를 제공하기 위한 궁극의 무기인 이유를 살펴보겠습니다.

소개

Ultimate Multisite는 Website as a Service(WaaS)를 만들 때 필요한 스위스 군용 칼과 같습니다. Wix.com, Squarespace, WordPress.com을 떠올린 다음, 자신만의 서비스를 소유하는 것을 생각해 보세요.

내부적으로 Ultimate Multisite는 WordPress Multisite를 활용하지만, Multisite 설치에서 네트워크 관리자가 마주하는 수많은 과제를 해결할 뿐만 아니라 기능을 강화하여 매우 다양한 사용 사례를 지원할 수 있는 방식으로 이를 수행합니다.

다음 섹션에서는 몇 가지 일반적인 사용 사례와 해당 사례를 지원하는 데 필요한 고려 사항을 살펴보겠습니다.

사용 사례

사례 1: 에이전시

일반적으로 에이전시의 핵심 역량은 웹사이트 디자인에 있으며, 호스팅이나 마케팅과 같은 요소는 추가 서비스로 나열됩니다.

에이전시에게 Ultimate Multisite는 단일 플랫폼에서 여러 웹사이트를 호스팅하고 관리할 수 있는 능력으로 놀라운 가치 제안을 제공합니다. 특히 GeneratePress, Astra, OceanWP 또는 기타 특정 theme을 중심으로 디자인을 표준화하는 에이전시는 각 새 site마다 이러한 theme을 자동으로 활성화하는 Ultimate Multisite의 기능을 활용할 수 있습니다.

마찬가지로 일반적이고 인기 있는 plugin에 대한 에이전시 가격 거래가 풍부한 상황에서, Ultimate Multisite를 사용하면 에이전시가 plugin을 설치, 유지 관리하고 활용할 수 있는 공통 플랫폼을 제공함으로써 기존 투자를 활용할 수 있습니다.

대부분의 경우 구성 사용이 바람직할 것이며, 다행히 Ultimate Multisite는 여러 인기 호스팅 제공업체뿐만 아니라 Cloudflare 및 cPanel과 같은 서비스와의 통합을 통해 도메인 매핑과 SSL 인증서를 매우 쉽게 처리할 수 있게 해줍니다.

따라서 이러한 제공업체 중 하나를 활용하거나 Ultimate Multisite를 Cloudflare 뒤에 배치하면 도메인 및 SSL 인증서 관리와 같은 요소가 어느 정도 간단해집니다.

site 생성에 대한 엄격한 제어를 유지하고자 하는 에이전시는 Ultimate Multisite의 간소화된 인터페이스를 통해 site를 만들고 고객 및 plan과 연결하는 일이 얼마나 쉬운지 높이 평가할 것입니다.

plugin 및 theme에 대한 엄격한 제어는 Ultimate Multisite의 직관적인 인터페이스를 통해 product별로 유지되며, plugin과 theme을 사용 가능하게 하거나 숨길 수 있고 새 site로 인스턴스화될 때의 활성화 상태도 제어할 수 있습니다.

theme도 유사한 기능을 제공하여 site 생성 시 특정 theme을 활성화하거나 숨길 수 있습니다.

에이전시는 Ultimate Multisite를 통해 자신들이 가장 잘하는 일, 즉 뛰어난 웹사이트 디자인에 집중할 수 있다는 안도감을 얻을 것입니다.

사례 2: 틈새 제공업체

“한 가지 일을 하고 그것을 잘하라”는 오래된 말이 있습니다. 많은 전문가에게 이는 하나의 핵심 아이디어를 중심으로 product 또는 서비스를 만드는 것을 의미합니다.

아마도 당신은 클럽에 웹사이트를 홍보하는 열정적인 골퍼일 수도 있고, 클랜에 웹사이트를 제공하는 열정적인 e스포츠 게이머일 수도 있습니다. 혹은 레스토랑에 예약 서비스를 홍보하는 개인일 수도 있겠죠?

여러 이유로 공통 프레임워크와 플랫폼을 기반으로 서비스를 제공하고자 할 것입니다. 필요한 기능을 제공하기 위해 맞춤형 plugin을 설계했거나 투자했을 수도 있고, 업계 모범 사례가 디자인에 대해 어떤 형태의 표준화된 접근 방식을 요구하는 경우일 수도 있습니다.

Ultimate Multisite의 혁신적인 기능 중 하나는 템플릿 site를 사용하는 것입니다. 템플릿 site란 theme이 설치 및 활성화되고, 필요한 plugin이 설치 및 활성화되며, 샘플 게시물이나 페이지가 생성된 site입니다. 고객이 템플릿을 기반으로 새 site를 만들면 템플릿의 콘텐츠와 설정이 새로 생성된 site로 복사됩니다.

틈새 site 및 서비스 제공업체에게 이는 사용자 지정 plugin과 디자인이 준비된 site를 즉시 만들 수 있는 능력에서 비교할 수 없는 이점을 제공합니다. 고객은 서비스를 완료하기 위해 최소한의 입력만 제공하면 됩니다.

요구 사항에 따라 subdirectory 또는 subdomain 구성 모두 적합할 수 있으며, 이 경우 아키텍처 선택지는 _subdirectories_를 위한 단순 SSL 인증서 또는 _subdomains_를 위한 와일드카드 SSL 인증서가 됩니다.

사례 3: WordPress 웹 호스팅

WordPress site를 호스팅하는 방법은 무수히 많지만, WordPress가 사전 설치된 웹 공간을 고객에게 제공하는 것만큼 간단한 경우는 드뭅니다. 이는 의미 있는 서비스를 제공하기 위해 여러 결정과 고려 사항이 함께 맞물려야 하기 때문입니다.

Ultimate Multisite는 WordPress site 호스팅을 위한 포괄적인 턴키 솔루션을 제공함으로써 이 영역에서 뛰어난 성능을 발휘합니다. 솔루션에는 subscription 서비스, 결제 수금, checkout 양식, 할인 바우처 및 고객 커뮤니케이션을 제공하기 위한 핵심 메커니즘이 포함되어 있습니다.

WordPress Multisite를 올바르게 설치, 구성 및 유지 관리하는 데 필요한 많은 핵심 작업은 Ultimate Multisite를 통해 처리되므로, 네트워크 관리자는 product 등급, 가격 책정 및 서비스 제공과 같이 자신의 서비스나 틈새와 관련된 요소만 고려하면 됩니다.

Ultimate Multisite와 통합하려는 개발자를 위해 이 솔루션은 포괄적인 RESTful API와 이벤트 알림을 위한 Webhooks도 제공합니다.

수많은 외부 plugin과 license에 의존하지 않고, Ultimate Multisite는 Wix, Squarespace, WordPress.com 및 기타 서비스에 견줄 수 있는 풍부한 기능의 솔루션을 제공합니다.

아키텍처 고려 사항

포괄적인 가이드는 아니지만, 다음 항목들은 Ultimate Multisite 설치를 지원하기 위한 올바른 기술 선택에 지침이 될 것입니다.

공유 Hosting vs. 전용 Hosting

안타깝게도 모든 hosting 제공업체가 동일한 것은 아니며, 일부는 극단적인 서버 밀도를 운용합니다. 저가 제공업체는 일반적으로 서버 밀도를 최대화하여 수익을 창출합니다. 따라서 귀하의 Ultimate Multisite 설치는 같은 서버에 있는 수백 개의 사이트 중 하나일 수 있습니다.

제공업체가 적절한 보호 장치를 마련하지 않은 경우, 공유 서버의 사이트들은 ‘시끄러운 이웃’ 문제를 겪습니다. 즉, 같은 서버의 한 사이트가 너무 많은 리소스를 소비하여 다른 사이트들이 남은 리소스를 두고 경쟁해야 하는 상황입니다. 이는 종종 사이트가 느리거나 제때 응답하지 못하는 형태로 나타납니다.

직접 웹 hosting 제공업체로서 이러한 연쇄 효과는 고객이 느린 속도, 낮은 페이지 순위, 높은 이탈률을 경험하게 됨을 의미하며, 결국 고객이 다른 곳에서 서비스를 찾으면서 고객 이탈로 이어지는 경우가 많습니다.

간단히 말해, 싸다고 좋은 것은 아닙니다.

Ultimate Multisite는 여러 우수한 hosting 제공업체와 함께 작동하는 것으로 알려져 있으며, domain mapping 및 자동 SSL과 같은 기능을 제공하기 위해 해당 환경과 잘 통합됩니다. 이러한 제공업체는 성능을 중시하며 공유 hosting보다 더 높은 수준의 서비스를 제공합니다.

호환 가능한 제공업체 목록과 각 제공업체의 전체 설정 지침은 Compatible Providers 문서를 확인하세요.

성능 고려 사항

Ultimate Multisite는 느린 애플리케이션이 아니라, 오히려 놀라울 정도로 빠릅니다. 그러나 기반 애플리케이션과 인프라만큼만 성능을 발휘하며, 접근할 수 있는 것만 활용할 수 있습니다.

이렇게 생각해 보세요: 귀하는 100개의 사이트가 있는 Ultimate Multisite 설치의 network administrator입니다. 그중 일부 사이트는 잘 운영되고 있으며 매일 많은 website 방문자를 끌어들입니다.

이 시나리오는 한 개에서 다섯 개 정도의 더 작은 규모라면 다르겠지만, 머지않아 규모의 문제가 분명해질 것입니다.

방치하면 단일 Ultimate Multisite 사이트가 모든 사이트 방문자의 요청을 처리해야 합니다. 이러한 요청은 동적 PHP 페이지일 수도 있고, stylesheet, javascript 또는 media file과 같은 정적 자산일 수도 있습니다. 사이트가 하나이든 백 개이든, 이러한 작업은 반복적이고 단조로우며 낭비적입니다. 모든 요청에 대해 출력이 동일한 정적 정보인 경우 PHP 파일을 처리하는 데 CPU 성능과 메모리를 사용하는 것은 불필요합니다.

마찬가지로 PHP 또는 HTML 페이지에 대한 하나의 요청은 이어서 script, stylesheet, image file에 대한 여러 후속 요청을 생성합니다. 이러한 요청은 귀하의 Ultimate Multisite 서버로 직접 향합니다.

서버를 업그레이드하면 이 문제를 쉽게 해결할 수 있지만, 두 번째 문제인 지리적 지연 시간은 해결하지 못합니다. 여러 위치의 여러 서버만이 이 문제를 제대로 해결할 수 있습니다.

이러한 이유로 대부분의 network administrator는 정적 페이지 요청을 처리하기 위해 front-end caching 솔루션과 content distribution network (CDN)를 사용합니다. 요청이 서버에 도달하기 전에 이러한 요청을 처리하고 자산을 제공하면 처리 리소스를 절약하고, 지연을 제거하며, 불필요한 업그레이드를 피하고, 기술 투자를 극대화할 수 있습니다.

Ultimate Multisite에는 정교한 Cloudflare add-on이 포함되어 있어 network administrator가 설치를 Cloudflare 뒤에 배치하고 caching 기능뿐 아니라 DNS hosting, SSL certificate 및 보안 메커니즘도 활용할 수 있습니다.

백업

백업에 대한 조언을 50명에게 물으면 백업 전략에 대해 50가지 다른 의견을 받을 수 있습니다. 답은, 상황에 따라 다릅니다.

논쟁의 여지가 없는 것은 백업이 필요하며, 특히 관리형 서비스를 제공하는 제공업체가 이를 관리하지 않는다는 것은 거의 상상하기 어렵다는 점입니다. 결과적으로 고객은 network administrator가 이 서비스를 제공하고 관리하기를 기대할 것입니다. network administrator가 누구에게 의존할지는 완전히 다른 문제입니다.

이 섹션의 목적상, 백업은 백업이 시작된 시점의 시스템 상태에 대한 특정 시점 사본이라고 합의합시다. 간단히 말해, 백업 시점의 시스템 상태가 무엇이든 그 상태가 캡처되어 백업에 보관됩니다.

이러한 이해를 바탕으로 백업을 어떻게 달성할지와 귀하의 환경에 무엇이 최선인지는 주로 귀하의 요구 사항과 해당 요구 사항을 충족할 수 있는 hosting 제공업체의 능력에 달려 있습니다. 그러나 의견이 가장 강한 것부터 가장 덜한 것의 순서로, 아래 옵션들은 어느 정도 지침을 제공할 것입니다.

스냅샷

스냅샷은 쉽고, 복잡하지 않으며(복원하려고 하기 전까지는), ‘그냥 작동’하기 때문에 백업에 대한 만능 해결책입니다. 다만 제공업체의 도움이 어느 정도 필요하며, 대부분 VPS (Virtual Private Server) 또는 유사한 것을 사용하는 경우에만 적용됩니다. 당사의 ‘Compatible Providers’ 문서에 나열된 여러 제공업체는 network administrator의 추가 개입이나 고려가 필요 없는 백업을 제공합니다.

전통적인 백업이 파일과 database를 대상으로 하는 반면, 스냅샷은 전체 디스크를 대상으로 합니다. 이는 사이트의 데이터뿐 아니라 운영 체제와 configuration도 스냅샷에 캡처된다는 뜻입니다. 많은 사람에게 이는 분명한 장점입니다. 스냅샷에서 새 시스템을 거의 즉시 생성하여 문제가 있는 instance를 대체하도록 운영에 투입할 수 있기 때문입니다. 마찬가지로, 파일만 복구하는 과정은 스냅샷 이미지를 디스크로 기존 instance에 연결하기만 하면 파일에 접근하고 복사할 수 있습니다.

스냅샷은 hosting 제공업체에서 추가 비용이 발생할 수 있지만, 사고에 대비한 보험 정책입니다.

외부 Script

WordPress 및 MySQL 리소스를 백업하기 위한 외부 스크립트와 솔루션은 부족하지 않은 것으로 보이며, Ultimate Multisite는 WordPress 파일 시스템과 데이터베이스를 사용하는 WordPress plugin이므로 이러한 솔루션은 Ultimate Multisite에도 잘 작동할 것입니다. 따라서 WordPress 사이트를 백업하는 솔루션이라면 Ultimate Multisite의 요구 사항을 충분히 충족할 수 있습니다.

특정 스크립트를 다른 것보다 더 추천할 수는 없지만, 일반적인 조언은 여러 차례 백업 및 복원 테스트를 실행하여 원하는 결과가 나오는지 확인하고, 특히 어떤 형태의 차등 백업 전략이 적용되는 경우 해당 스크립트와 기능을 지속적으로 평가하여 ‘확실히 확실히’ 해 두는 것입니다.

이러한 스크립트는 실행 중 시스템 부하를 증가시키므로 이를 고려해야 합니다.

Plugins

WordPress에서 plugin으로 해결할 수 없는 문제는 거의 없으며, 외부 스크립트를 관리하는 것이 취향이 아니라면 plugin이 차선의 선택지일 수 있습니다.

plugin마다 옵션과 기능은 다르지만, 대부분 동일한 기능을 수행하며 이는 WordPress 파일과 데이터베이스 콘텐츠의 복사본을 만드는 것입니다. 그 이후의 기능은 달라지는데, 일부 plugin은 백업을 Google Drive나 Dropbox 같은 외부 서비스 또는 S3, Wasabi 등과 같은 호환 가능한 객체 스토리지 서비스로 전송할 수 있습니다. 더 포괄적인 plugin은 외부 스토리지 비용을 절감하기 위해 차등 백업 또는 변경된 데이터만 백업하는 일종의 전략을 제공합니다.

plugin을 선택할 때는 그것이 multisite를 인식하는지 반드시 확인하십시오. 백업이 실행되는 동안의 작동 특성상 프로세스가 완료될 때까지 서버에 일시적인 부하가 발생할 수 있습니다.

Domain 및 SSL

multisite subdomain 모드에서 도메인 이름과 관련해 이미 많은 논의가 있었습니다. 네트워크 관리자를 위한 거의 보편적인 솔루션은 와일드카드 DNS 항목을 사용하는 것입니다.

이 유형의 DNS 항목은 ‘site1.domain.com’ 및 ‘site2.domain.com’과 같은 _subdomains_를 1.2.3.4의 IP 주소로 성공적으로 확인하므로, Ultimate Multisite와 더 넓게는 subdomain 모드를 사용하는 WordPress Multisite를 지원합니다.

대상 호스트는 HTTP 헤더에서 읽히므로 HTTP에서는 완벽하게 잘 작동할 수 있지만, 보안 HTTPS 트랜잭션이 거의 필수인 요즘 웹이 이렇게 단순한 경우는 드뭅니다.

다행히 SSL 인증서에는 쉬운 옵션이 있습니다. subdirectory 모드에서는 일반 도메인 인증서를 사용할 수 있습니다. 이러한 인증서는 무료 LetsEncrypt 서비스를 사용하거나 다른 출처를 이용하는 호스팅 제공업체에서 쉽게 무료로 제공됩니다. 그렇지 않은 경우 인증서 서명 요청을 생성할 수 있다면 인증 기관에서 상업적으로 구입할 수 있습니다.

subdomain 모드에서는 와일드카드 SSL 인증서를 사용하면 와일드카드 도메인과 완벽하게 짝을 이루며, 추가 구성 없이 루트 도메인과 모든 _subdomains_에 대해 인증서가 권한을 갖도록 할 수 있습니다.

하지만 엔터프라이즈 플랜이 아니거나 항목을 DNS 전용으로 설정하여 모든 캐싱과 최적화를 우회하지 않는 한, 와일드카드 SSL 인증서는 Cloudflare와 같은 서비스에서 작동하지 않을 수 있다는 점에 유의해야 합니다.

기본적으로 Ultimate Multisite는 WordPress multisite의 요구 사항에 대한 우리의 폭넓은 경험을 보여 주는 이 문제의 솔루션을 제공합니다. 이 간단한 add-on을 활성화하면 Ultimate Multisite가 사용자의 Cloudflare 자격 증명을 사용하여 Cloudflare에서 네트워크 사이트의 DNS 항목을 자동으로 추가하고 해당 모드를 ‘프록시됨’으로 설정합니다. 이런 방식으로 각 네트워크 하위 사이트는 생성될 때 SSL을 포함한 Cloudflare의 모든 보호와 이점을 갖게 됩니다.

Ultimate Multisite 설치의 성격과 목적에 따라 고객이 자신의 도메인을 사용해야 할 필요가 있을 수 있습니다. 이 경우 네트워크 관리자는 두 가지 문제를 해결해야 합니다. 첫째는 도메인 이름의 호스팅이고, 둘째는 해당 도메인의 SSL 인증서입니다.

많은 경우 Cloudflare 사용이 쉬운 옵션입니다. 고객은 자신의 도메인을 Cloudflare에 배치하고, CNAME을 Ultimate Multisite의 루트 도메인으로 지정한 다음, Ultimate Multisite에서 자신의 도메인을 매핑하기만 하면 사용자 지정 도메인 이름의 이점을 활용하기 시작할 수 있습니다.

이 외에는 대체 솔루션을 찾아야 하며, 이것이 Ultimate Multisite가 Compatible Providers 목록을 권장하는 이유입니다. 이는 DNS와 SSL을 설정하는 과정이 간단하지 않을 수 있기 때문입니다. 그러나 Ultimate Multisite가 이러한 제공업체와 통합되어 있으므로 복잡성이 크게 줄어들고 절차가 자동화됩니다.

Plugins

고객 또는 네트워크 사이트에 기능을 제공하기 위해 추가 plugin이 필요할 가능성이 매우 높습니다. 모든 plugin이 WordPress Multisite 및 Ultimate Multisite에서 작동할까요? 글쎄요, 상황에 따라 다릅니다.

대부분의 plugin은 WordPress Multisite에 설치할 수 있지만, 활성화 및 라이선스 방식은 작성자마다 다릅니다.

문제는 라이선스가 적용되는 방식에 있으며, 일부 plugin은 도메인별 라이선스를 요구합니다. 이는 일부 plugin의 경우 네트워크 관리자가 각각의 새 사이트에서 각 plugin의 라이선스를 수동으로 활성화해야 함을 의미합니다.

따라서 해당 plugin이 WordPress Multisite에서 어떻게 작동하는지, 그리고 라이선스를 부여하는 데 필요한 특별한 요구 사항이나 절차가 있는지 plugin 작성자에게 확인하는 것이 가장 좋을 수 있습니다.