Ultimate Multisite 101

Ultimate Multisite는 고객에게 WaaS 또는 웹사이트를 서비스로 제공할 수 있게 해 주는 WordPress Multisite 플러그인입니다. Ultimate Multisite가 귀하의 비즈니스와 고객에게 어떻게 도움이 되는지 알아보기 전에 우리가 습득해야 할 기초 지식이 있습니다.

The WordPress Multisite

대부분의 사람들은 표준 WordPress 설치에 익숙합니다. 호스팅 제공업체의 제어판을 통해 설치하거나, 모험가라면 새 웹 서버와 데이터베이스를 설정하고 핵심 파일을 다운로드한 뒤 설치 과정을 시작합니다.

이 방식은 전 세계 수백만 개의 WordPress 사이트에 적용되지만, 에이전시나 호스팅 제공업체의 관점에서 볼 때 볼륨에 대해 잠시 논의해 보겠습니다.

자동화된 제어판을 통해 한 개 또는 백 개의 WordPress 사이트를 만드는 것은 쉽지만, 이러한 사이트들의 관리를 맡게 되면 곧 문제가 발생하기 시작합니다. 관리되지 않은 상태에서는 악성코드의 주요 타깃이 됩니다. 관리는 노력과 자원을 필요로 하며, WordPress 사이트의 관리와 행정을 간소화해 주는 외부 도구와 플러그인이 존재하지만, 고객이 관리 권한을 유지한다는 사실은 이러한 노력이 쉽게 무력화될 수 있음을 의미합니다.

WordPress의 핵심에는 'Multisite'라는 단순한 기능이 제공되며, 이는 2010년 WordPress 3.0 출시 시점으로 거슬러 올라갑니다. 그 이후로 새로운 기능 도입과 보안 강화에 초점을 맞춘 여러 개정이 이루어졌습니다.

본질적으로 WordPress 멀티사이트는 다음과 같이 생각할 수 있습니다: 한 대학이 단일 WordPress 설치를 유지하지만, 각 학부는 자체 WordPress 사이트를 관리합니다.

이 문장을 분해해 보려면 Ultimate Multisite 문서뿐 아니라 WordPress 커뮤니티 전반에 존재하는 기본 용어를 살펴보겠습니다.

The Network

WordPress 관점에서 멀티사이트 네트워크는 여러 하위 사이트를 단일 대시보드에서 관리할 수 있는 환경입니다. 호스팅 제공업체마다 멀티사이트 네트워크를 만드는 방식이 다르지만, 최종 결과는 일반적으로 wp-config.php 파일에 몇 가지 추가 지시문을 삽입하여 WordPress가 이 특정 모드에서 운영되고 있음을 알리는 것입니다.

멀티사이트 네트워크와 독립형 WordPress 설치 사이에는 몇 가지 뚜렷한 차이가 있으며, 이를 간략히 논의하겠습니다.

Subdomain vs. Subdirectory

가장 즉각적인 결정 중 하나는 멀티사이트 설치가 서브디렉터리 또는 _서브도메인_으로 운영될지 여부입니다. Ultimate Multisite는 두 선택 모두에서 동일하게 잘 작동하지만, 두 구성 간에는 일부 아키텍처 차이가 있습니다.

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

두 옵션 모두 완전히 유효한 선택이지만, _서브도메인_을 사용하면 여러 가지 이점이 있지만 아키텍처에 더 많은 사려와 계획이 필요합니다.

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

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

다른 옵션이 존재하지만, 이들은 범위와 적용이 제한적이며 적합성에 대한 추가 구성 및 고려가 필요합니다.

Plugins and Themes

WordPress가 제공하는 것과 마찬가지로, 고객 관점에서 손실되는 부분도 있습니다. 독립형 WordPress 설치에서 사이트 관리자가 악성 플러그인을 설치하거나 설치를 최신 상태로 유지하지 못하면, 이 행위의 유일한 피해자는 자신입니다. 그러나 멀티사이트 설치에서 사이트 관리자가 악성 플러그인을 설치하면 네트워크에 설치된 모든 사이트가 피해자가 됩니다.

이러한 이유로 멀티사이트로 구성될 때 WordPress는 사이트 관리자가 플러그인과 테마를 설치할 수 있는 권한을 제거하고 대신 이 권한을 새로 생성된 네트워크 관리자 또는 ‘슈퍼 관리자’ 역할로 이동시킵니다. 이 특권 역할은 네트워크 사이트의 관리자가 대시보드에서 플러그인 메뉴를 볼 수 있는지, 접근할 수 있는지, 그리고 그렇다면 플러그인 활성화 또는 비활성화 권한이 포함되는지를 결정할 수 있습니다.

이 범위에서 네트워크 관리자는 네트워크에 플러그인과 테마를 설치하고, 이러한 플러그인과 테마를 사용하도록 네트워크 사이트에 권한을 위임합니다. 사이트 관리자는 자신이 할당받지 않은 플러그인과 테마를 설치하거나 접근할 수 없습니다.

Users and Administrators

WordPress Multisite에서는 모든 네트워크 사이트가 동일한 데이터베이스를 공유하므로 동일한 사용자, 역할 및 권한을 공유합니다. 가장 적절한 개념은 모든 사용자가 특정 사이트가 아니라 네트워크의 구성원이라는 것입니다.

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

위의 진술을 반복하면, 사용자 계정이 사이트와 관련된 것처럼 보이지만 실제로는 네트워크에 할당되며 따라서 네트워크 전체에서 고유해야 합니다. 이로 인해 사용자 이름이 등록 불가한 경우가 있을 수 있습니다.

기업 시스템에서 외래 개념은 아니지만, 이 단일 사용자 등록 및 인증 소스는 사용자 관리가 다소 쉬운 독립형 WordPress 설치에 익숙한 사람들에게는 종종 이해하기 어려운 개념입니다.

Media

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

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

Permalinks

이전에 언급했듯이 _서브도메인_이 _서브디렉터리_보다 뚜렷한 이점이 있으며, 여기서는 경로가 그 이유입니다.

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

게시물의 경우, 네트워크 사이트와 충돌을 방지하기 위해 메인 사이트에 필수 /blog/ 경로가 추가됩니다. 이는 ‘Post name’과 같은 예쁜 퍼머링크가 domain.name/blog/post-name/ 형태로 표시됨을 의미합니다.

서브도메인 구성에서는 이 작업이 필요하지 않습니다. 각 네트워크 사이트는 완전한 도메인 분리를 통해 이익을 얻으며, 따라서 단일 경로에 의존할 필요가 없습니다. 대신 각 사이트는 자신의 _서브도메인_을 기반으로 별도의 경로를 유지합니다.

Static Pages

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

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

서브도메인 구성에서는 _서브도메인_이 네트워크 사이트에 고유하고 메인 사이트와 아무런 관련이 없기 때문에 명명 충돌 가능성이 완화됩니다.

Registration

WordPress Multisite의 네트워크 설정에서는 새로운 사용자 등록 옵션이 여러 개 제공되어 신규 및 기존 사용자가 사이트를 생성할 수 있습니다.

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

사용자 계정이 생성될 때 해당 계정은 네트워크 수준에서 생성됩니다. 따라서 특정 사이트에 속하는 대신 네트워크에 속합니다. 이는 몇 가지 뚜렷한 장점과 단점을 가집니다.

예를 들어, 귀하의 WordPress Multisite가 뉴스와 정보를 제공하는 비즈니스라면, 멀티사이트를 구축한 뒤 금융, 기술, 엔터테인먼트 및 기타 관심 분야에 대한 네트워크 사이트를 생성하고 플러그인과 테마를 전반적으로 제어합니다. 각 네트워크 사이트는 맞춤형 포스트 타입이나 일반 포스트 카테고리보다 네트워크 사이트의 모양, 느낌 및 사용자 경험을 훨씬 더 많이 제어할 수 있습니다.

이 범위에서 사용자가 로그인하면 네트워크에 로그인하고 궁극적으로 각 네트워크 사이트에도 로그인하여 원활한 경험을 제공합니다. 새 사이트가 구독 기반이라면 이는 이상적인 솔루션이자 결과가 될 것입니다.

그러나 멀티사이트의 의도된 성격과 목적이 서로 관계가 아니라면, 외부 또는 추가 플러그인이 사용자 역할을 조작하는 데 거의 항상 필요합니다.

Domain and SSL

우리의 주목을 거의 끌지 못하는 WordPress Multisite 설치, 즉 Wordpress.com에 대해 이야기해 보겠습니다. 이는 WordPress 멀티사이트의 가장 광범위한 예시이며, 맞춤화 및 목적 달성을 위해 광범위한 기능을 보여줍니다.

현대 인터넷에서는 SSL 사용이 거의 필수이며, WordPress 멀티사이트의 네트워크 관리자는 곧 이러한 도전에 직면하게 됩니다.

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

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

네트워크 관리자에게 이는 도메인 이름 구성과 SSL 인증서 발급 및 유지 관리 모두에서 추가적인 복잡성을 제시합니다.

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

Ultimate Multisite

독립형 WordPress 설치와 멀티사이트 설치 간의 차이를 이해한 뒤, Ultimate Multisite가 웹사이트를 서비스로 제공하는 궁극적인 무기라는 것을 살펴보겠습니다.

Introduction

Ultimate Multisite는 웹사이트를 서비스로 제공(WaaS)할 때 스위스 아미 나이프와 같습니다. Wix.com, Squarespace, WordPress.com을 떠올리고, 그 다음에는 자신만의 서비스를 소유하는 것을 상상해 보세요.

아래에서 Ultimate Multisite는 WordPress Multisite를 활용하지만, 멀티사이트 설치에서 네트워크 관리자가 직면하는 수많은 도전을 해결할 뿐만 아니라 광범위한 사용 사례를 지원할 수 있도록 기능을 향상시킵니다.

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

Use Cases

Case 1: An Agency

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

에이전시를 위해 Ultimate Multisite는 단일 플랫폼에서 여러 웹사이트를 호스팅하고 관리할 수 있는 능력으로 놀라운 가치 제안을 제공합니다. 특히 GeneratePress, Astra, OceanWP와 같은 특정 테마를 표준화하는 에이전시의 경우, Ultimate Multisite의 기능을 활용해 새 사이트마다 이러한 테마를 자동으로 활성화할 수 있습니다.

또한 일반 및 인기 플러그인에 대한 에이전시 가격 할인 혜택이 풍부한 경우, Ultimate Multisite를 사용하면 에이전시가 플러그인을 설치, 유지 관리 및 활용할 수 있는 공통 플랫폼을 제공함으로써 기존 투자를 활용할 수 있습니다.

대부분의 경우 구성을 사용하려는 것이 바람직하며, 다행히도 Ultimate Multisite는 Cloudflare 및 cPanel과 같은 인기 호스팅 제공업체 및 서비스와의 통합을 통해 도메인 매핑 및 SSL 인증서를 매우 쉽게 지원합니다.

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

사이트 생성에 대한 엄격한 통제를 선호하는 에이전시는 Ultimate Multisite의 간소화된 인터페이스를 통해 사이트를 생성하고 고객 및 플랜과 연결하는 편의성을 높이 평가할 것입니다.

Ultimate Multisite의 직관적인 인터페이스를 통해 제품별로 플러그인 및 테마에 대한 엄격한 제어가 유지되며, 플러그인 및 테마를 사용 가능하거나 숨기고 새 사이트에 인스턴스화될 때 활성화 상태를 설정할 수 있습니다.

테마는 유사한 기능을 제공하며, 사이트 생성 시 특정 테마를 활성화하거나 숨길 수 있습니다.

에이전시는 Ultimate Multisite를 통해 자신이 가장 잘하는 일, 즉 탁월한 웹사이트를 디자인하는 데 안심할 수 있습니다.

Case 2: Niche Provider

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

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

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

Ultimate Multisite의 혁신적인 기능 중 하나는 템플릿 사이트를 사용하는 것입니다. 템플릿 사이트는 테마가 설치 및 활성화되고 필요한 플러그인이 설치 및 활성화되며 샘플 게시물 또는 페이지가 생성된 사이트입니다. 고객이 템플릿을 기반으로 새 사이트를 만들면 템플릿의 내용과 설정이 새로 생성된 사이트에 복사됩니다.

틈새 사이트 및 서비스를 제공하는 경우, 이는 맞춤형 플러그인과 디자인으로 즉시 사용 가능한 사이트를 만들 수 있는 비할 데 없는 이점을 제공합니다. 고객은 서비스를 완료하기 위해 최소한의 입력만 제공하면 됩니다.

요구 사항에 따라 서브디렉터리 또는 서브도메인 구성이 적합할 수 있으며, 이 경우 아키텍처 선택은 _서브디렉터리_용 단순 SSL 인증서와 _서브도메인_용 와일드카드 SSL 인증서 중 하나가 됩니다.

Case 3: WordPress Web Hosting

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

Ultimate Multisite는 WordPress 사이트 호스팅을 위한 종합적인 턴키 솔루션을 제공함으로써 이 분야에서 뛰어납니다. 솔루션에는 구독 서비스, 결제 수집, 체크아웃 양식, 할인 쿠폰 및 고객 커뮤니케이션을 제공하는 핵심 메커니즘이 포함됩니다.

WordPress Multisite를 올바르게 설치, 구성 및 유지 관리하는 데 필요한 대부분의 핵심 작업은 Ultimate Multisite에 의해 촉진되며, 네트워크 관리자는 서비스 또는 틈새와 관련된 측면(예: 제품 계층, 가격 및 서비스 제공)만 고려하면 됩니다.

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

다수의 외부 플러그인과 라이선스에 의존하지 않고, Ultimate Multisite는 Wix, Squarespace, WordPress.com 및 기타와 비교할 수 있는 풍부한 기능을 제공합니다.

Architecture Considerations

완전한 가이드는 아니지만, 다음 항목은 Ultimate Multisite 설치를 지원하기 위한 기술을 올바르게 선택하는 데 지침이 되어야 합니다.

Shared vs. Dedicated Hosting

불행히도 모든 호스팅 제공업체가 동일하지 않으며 일부는 극단적인 서버 밀도를 실천합니다. 저가 제공업체는 일반적으로 서버 밀도를 극대화하여 수익을 창출합니다. 따라서 귀하의 Ultimate Multisite 설치는 동일한 서버에서 수백 개의 사이트 중 하나일 수 있습니다.

제공업체에서 적절한 보호 조치를 마련하지 않으면 공유 서버의 사이트는 ‘소음 이웃’ 문제를 겪습니다. 즉, 동일한 서버에 있는 사이트가 많은 리소스를 소비하면 다른 사이트가 남은 리소스를 놓고 경쟁해야 합니다. 이는 종종 사이트가 느리거나 적시에 응답하지 못하는 형태로 나타납니다.

웹 호스팅 제공업체로서 귀하의 고객은 느린 속도, 낮은 페이지 순위 및 높은 이탈률을 경험하게 되어, 다른 곳에서 서비스를 찾게 되는 고객 이탈이 발생합니다.

요컨대, 저렴함이 좋은 것을 의미하지는 않습니다.

Ultimate Multisite는 여러 우수한 호스팅 제공업체와 함께 작동하며, 도메인 매핑 및 자동 SSL과 같은 기능을 제공하기 위해 환경과 잘 통합됩니다. 이러한 제공업체는 성능을 중시하며 공유 호스팅보다 높은 수준의 서비스를 제공합니다.

호환 가능한 제공업체 목록과 각 제공업체에 대한 완전한 설정 지침은 Compatible Providers 문서를 확인하십시오.

Performance Considerations

Ultimate Multisite는 느린 애플리케이션이 아니라 놀라울 정도로 빠릅니다. 그러나 이는 기본 애플리케이션과 인프라의 성능에 따라 달라지며, 접근 가능한 것만 활용할 수 있습니다.

예를 들어, 귀하는 100개의 사이트가 있는 Ultimate Multisite 설치의 네트워크 관리자입니다. 그 중 일부는 잘 운영되고 매일 많은 웹사이트 방문자를 끌어들입니다.

이 시나리오는 한 두 개에서 다섯 개 정도의 작은 규모에서는 다를 수 있지만, 곧 규모 문제가 드러날 것입니다.

방치하면 단일 Ultimate Multisite 사이트가 모든 사이트 방문자의 요청을 처리해야 합니다. 이러한 요청은 동적 PHP 페이지 또는 스타일시트, 자바스크립트 또는 미디어 파일과 같은 정적 자산일 수 있습니다. 한 개든 백 개든 관계없이 이러한 작업은 반복적이고 단조롭고 낭비적입니다. 모든 요청에 대해 동일한 정적 정보를 출력할 때 PHP 파일을 처리하기 위해 CPU와 메모리를 사용하는 것은 불필요합니다.

마찬가지로 PHP 또는 HTML 페이지에 대한 하나의 요청은 스크립트, 스타일시트 및 이미지 파일에 대한 여러 후속 요청을 생성합니다. 이러한 요청은 귀하의 Ultimate Multisite 서버를 직접 대상으로 합니다.

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

이러한 이유로 대부분의 네트워크 관리자는 정적 페이지 요청을 충족하기 위해 프런트엔드 캐싱 솔루션과 콘텐츠 배포 네트워크(CDN)를 사용합니다. 이러한 요청을 충족하고 요청이 서버에 도달하기 전에 자산을 제공하면 처리 리소스를 절약하고 지연을 없애며 불필요한 업그레이드를 방지하고 기술 투자를 극대화합니다.

Ultimate Multisite는 정교한 Cloudflare 애드온을 포함하여 네트워크 관리자가 설치를 Cloudflare 뒤에 두고 캐싱 기능뿐 아니라 DNS 호스팅, SSL 인증서 및 보안 메커니즘을 활용할 수 있도록 합니다.

Backups

백업에 대해 50명에게 조언을 구하고 50개의 다른 백업 전략 의견을 받을 수 있습니다. 답은 상황에 따라 다릅니다.

백업이 필요하다는 것과 이를 제공하는 관리형 서비스를 제공하는 공급업체가 거의 없다는 것은 논란의 여지가 없습니다. 따라서 고객은 네트워크 관리자가 이 서비스를 제공하고 관리하기를 기대합니다. 네트워크 관리자가 누구를 찾는지는 전혀 다른 문제입니다.

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

이해를 바탕으로 백업을 달성하는 방법과 귀하의 환경에 가장 적합한 방법은 귀하의 요구 사항과 호스팅 제공업체가 해당 요구 사항을 충족할 수 있는 능력에 크게 좌우됩니다. 그러나 가장 의견이 강한 것부터 덜 강한 것까지 순서대로 아래 옵션은 일부 지침을 제공해야 합니다.

Snapshots

스냅샷은 백업에 대한 은은한 총알입니다. 복원하려는 경우를 제외하고는 쉽고 단순하며 '그대로 작동'합니다. 그러나 공급업체의 도움이 필요하며, 대부분 VPS(가상 사설 서버) 또는 유사한 환경에만 적용됩니다. 'Compatible Providers' 문서에 나열된 여러 공급업체는 네트워크 관리자가 추가 개입이나 고려 없이 백업을 제공합니다.

전통적인 백업이 파일과 데이터베이스를 대상으로 하는 반면, 스냅샷은 전체 디스크를 대상으로 합니다. 이는 사이트 데이터뿐 아니라 운영 체제와 구성을 스냅샷에 캡처한다는 의미입니다. 많은 경우 이는 새로운 시스템을 거의 즉시 스냅샷에서 생성하고 고장난 인스턴스를 대체하기 위해 운영에 투입할 수 있는 뚜렷한 이점입니다. 마찬가지로 파일을 복구하려면 스냅샷 이미지를 디스크로 기존 인스턴스에 연결하기만 하면 파일에 접근하고 복사할 수 있습니다.

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

External Scripts

WordPress와 MySQL 리소스를 백업하기 위한 외부 스크립트와 솔루션이 부족하지 않은 것처럼 보이며, 이는 WordPress 파일 시스템과 데이터베이스를 활용하는 WordPress 플러그인인 Ultimate Multisite에 잘 작동합니다. 따라서 WordPress 사이트를 백업하는 솔루션은 Ultimate Multisite의 요구를 충분히 충족합니다.

우리는 특정 스크립트를 다른 스크립트보다 추천할 수 없으며, 일반적인 조언은 여러 백업 및 복원 테스트를 실행하여 결과가 원하는지 확인하고, 차등 백업 전략이 적용되는 경우 스크립트와 기능을 지속적으로 평가하여 '확실히 확실히' 하는 것입니다.

이 스크립트는 실행 중에 시스템 부하를 증가시킬 수 있으므로 이를 고려해야 합니다.

Plugins

WordPress에서 플러그인으로 해결할 수 없는 문제가 거의 없습니다. 외부 스크립트 관리를 선호하지 않는다면 플러그인이 다음으로 좋은 옵션일 수 있습니다.

플러그인은 옵션과 기능이 다양하지만 대부분 동일한 기능을 수행합니다. 즉, WordPress 파일과 데이터베이스 내용을 복사하는 것입니다. 이후 기능은 다르며, 일부 플러그인은 백업을 Google Drive, Dropbox와 같은 외부 서비스 또는 S3, Wasabi와 같은 호환 가능한 객체 저장소 서비스로 전송할 수 있습니다. 보다 포괄적인 플러그인은 차등 백업 또는 변경된 데이터만 백업하는 전략을 제공하여 외부 저장소 비용을 절감합니다.

플러그인을 선택할 때는 멀티사이트를 인식하는지 확인하십시오. 백업이 실행되는 동안 운영 방식으로 인해 프로세스가 완료될 때까지 서버에 일시적인 부하가 예상됩니다.

Domain and SSL

멀티사이트 서브도메인 모드에서 도메인 이름에 대해 이미 많은 논의가 이루어졌습니다. 네트워크 관리자를 위한 거의 보편적인 솔루션은 와일드카드 DNS 항목을 활용하는 것입니다.

이 유형의 DNS 항목은 ‘site1.domain.com’ 및 ‘site2.domain.com’과 같은 _서브도메인_을 1.2.3.4 IP 주소로 성공적으로 해석하여 Ultimate Multisite를 지원하고, 더 큰 범위에서 서브도메인 모드를 사용하는 WordPress Multisite를 지원합니다.

HTTP의 경우 대상 호스트가 HTTP 헤더에서 읽히므로 이 방식이 완벽하게 작동할 수 있지만, 오늘날 보안 HTTPS 트랜잭션이 거의 필수적인 만큼 웹이 그렇게 단순하지는 않습니다.

다행히 SSL 인증서에 대한 쉬운 옵션이 있습니다. 서브디렉터리 모드에서는 일반 도메인 인증서를 사용할 수 있습니다. 이는 무료 LetsEncrypt 서비스나 다른 소스를 사용하는 호스팅 제공업체에서 쉽게 무료로 제공됩니다. 그렇지 않으면 인증서 서명 요청을 생성할 수 있다면 권한 기관에서 상업적으로 제공됩니다.

서브도메인 모드에서는 와일드카드 SSL 인증서를 사용하면 와일드카드 도메인과 완벽하게 매칭되며, 추가 구성이 필요 없이 루트 도메인과 모든 _서브도메인_에 대해 인증서가 권한을 가집니다.

그러나 와일드카드 SSL 인증서는 Cloudflare와 같은 서비스에서 작동하지 않을 수 있으므로, 엔터프라이즈 플랜에 가입하거나 항목을 DNS 전용으로 설정해야 합니다. 이 경우 모든 캐싱 및 최적화가 우회됩니다.

기본적으로 Ultimate Multisite는 WordPress 멀티사이트의 요구 사항에 대한 광범위한 경험을 보여주는 이 문제에 대한 솔루션을 제공합니다. 이 간단한 애드온을 활성화하면 Ultimate Multisite가 Cloudflare 자격 증명을 사용하여 Cloudflare에 네트워크 사이트용 DNS 항목을 자동으로 추가하고 모드를 ‘프록시됨’으로 설정합니다. 이렇게 하면 생성될 때마다 각 네트워크 하위 사이트가 Cloudflare의 완전한 보호 및 SSL을 포함한 혜택을 누릴 수 있습니다.

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

많은 경우 Cloudflare 사용이 쉬운 옵션입니다. 고객은 도메인을 Cloudflare에 배치하고, CNAME을 Ultimate Multisite의 루트 도메인으로 가리키고, Ultimate Multisite에서 도메인을 매핑하여 맞춤 도메인 이름을 활용하기 시작하면 됩니다.

이 외에도 대체 솔루션을 찾아야 하므로 Ultimate Multisite는 호환 가능한 공급업체 목록을 권장합니다. 이는 DNS 및 SSL 설정 과정이 비트리비얼한 과정일 수 있기 때문입니다. 그러나 Ultimate Multisite가 이러한 공급업체와 통합되면 복잡성이 크게 제거되고 절차가 자동화됩니다.

Plugins

고객 또는 네트워크 사이트에 기능을 제공하기 위해 추가 플러그인이 필요할 가능성이 높습니다. 모든 플러그인이 WordPress Multisite 및 Ultimate Multisite와 호환됩니까? 이는 상황에 따라 다릅니다.

대부분의 플러그인은 WordPress Multisite에 설치할 수 있지만, 활성화 및 라이선스는 저자마다 다릅니다.

문제는 일부 플러그인이 도메인별 라이선스를 요구하는 방식에 있습니다. 이는 일부 플러그인에 대해 네트워크 관리자가 새 사이트마다 각 플러그인에 대한 라이선스를 수동으로 활성화해야 함을 의미합니다.

따라서 플러그인 저자에게 플러그인이 WordPress Multisite와 어떻게 작동하는지, 라이선스를 부여하기 위해 필요한 특별 요구 사항이나 절차가 있는지 확인하는 것이 가장 좋습니다.