CMS 재해 방지: 웹사이트 다운타임을 방지하는 방법

사이트가 다운된 것으로 간주된다는 것은 실제로 무엇을 의미합니까?

종종 그것은 당신이 누구에게 묻느냐에 달려 있습니다.

웹사이트가 다운된 것으로 간주된다는 것은 다음과 같은 여러 가지를 의미할 수 있습니다.

• 웹사이트를 완전히 사용할 수 없습니다.
• 웹 사이트는 온라인이지만 사용할 수 없을 정도로 느립니다.
• 웹사이트에서 특정 사용자 또는 위치에 대해 오류 메시지가 표시됩니다.
• 웹사이트는 대부분의 방문자를 위해 작동하지만 일부 방문자는 예를 들어 콘텐츠를 생성, 편집 또는 게시하기 위해 CMS에 로그인할 수 없습니다.

원인이나 정도에 관계없이 웹 사이트 다운타임의 영향은 전자 상거래 주문 손실 및 좌절된 사용자에서 고객 신뢰 약화에 이르기까지 심각할 수 있습니다.

CMS 재해 방지 시리즈의 세 번째에서는 웹 사이트 다운타임의 근본 원인과 이를 방지하기 위한 지속적인 모니터링 및 기타 요소의 역할을 살펴봅니다.

첫째, 지속적인 모니터링의 역할

우리는 웹사이트의 다양한 측면을 모니터링하므로 완전히 관리되는 WordPress VIP 플랫폼을 구성하는 여러 계층에서 무언가가 제대로 작동하지 않을 때 알 수 있습니다. 이러한 레이어에는 다음이 포함됩니다.

• 네트워크 연결
• 로드 밸런서
• 웹 서버
• 개체 캐싱(Memcached)
• 데이터베이스
• 엘라스틱서치
• 파일 서비스(CDN)

웹사이트 안정성에 영향을 줄 수 있는 향후 문제를 예상할 수 있도록 문제를 조기에 발견하려고 노력합니다. 서로 다른 시스템 구성 요소의 상호 참조 로그를 통해 웹 사이트가 불안정하다고 보고된 기간을 검토할 수 있습니다. 단일 문제가 아니라 여러 요인의 조합이 가동 중지 시간의 원인이 될 수 있으므로 시스템과 애플리케이션 모두에서 데이터를 비교하기 위해 여러 도구를 사용합니다.

대부분의 경우 웹사이트 불안정은 애플리케이션 코드, 즉 사용자 지정 또는 타사 WordPress 테마 및 플러그인 코드의 결과입니다. 다음은 불안정한 사이트를 조사할 때 확인하는 몇 가지 사항과 각각을 완화하는 방법입니다.

캐싱이 충분하지 않음

사이트의 성능과 안정성을 보장하기 위해 할 수 있는 가장 중요한 일은 캐시할 수 있는 전체 페이지가 캐시되었는지 확인하는 것입니다. 캐시되지 않은 페이지는 요청될 때마다 서버에 구축해야 하므로 프로세스가 느리고 오류가 발생하기 쉽습니다.

WordPress VIP 답변:

WordPress VIP 플랫폼은 최종 사용자에게 가장 가까운 콘텐츠를 저장하고 제공하는 데 각각 사용되는 에지 캐시 서버의 글로벌 네트워크를 통해 강력한 페이지 캐싱을 제공합니다. 에지 캐시 서버의 응답 시간은 거의 항상 페이지 캐싱을 우회하고 원본 서버에 도달하는 것보다 훨씬 빠릅니다.

캐싱 과제

그들은 개인화되고 완전한 대화형 경험을 요구하기 때문에 일부 사이트, 특히 전자 상거래 사이트는 단순히 페이지 캐시 수준에서 캐시할 수 없습니다.

JavaScript를 통해 추가된 동적 기능(예: 로그인 상태, 장바구니)과 함께 정적 페이지가 에지 캐시에서 제공되는 절충안이 종종 발견될 수 있습니다. 그런 다음 JavaScript의 비동기 요청을 사용하여 전체 페이지 로드보다 훨씬 낮은 오버헤드로 설계된 WordPress REST API 엔드포인트와 통신할 수 있습니다.

또는 여기에서 개체 캐싱이 작동합니다. 페이지는 동적으로 유지될 수 있지만 페이지의 일부와 페이지에서 사용되는 모든 데이터는 데이터베이스를 쿼리할 필요가 없도록 개체 캐시에 저장 및 검색할 수 있습니다.

WordPress VIP 답변:

각 WordPress VIP 애플리케이션 환경에는 번개처럼 빠르고 효율적인 검색을 위해 메모리에 개체 캐시 데이터를 저장하는 전용 Memcached 클러스터가 있습니다.

테스트되지 않은 코드 배포

이것은 웹사이트 다운타임의 또 다른 일반적인 원인이며 순수한 원인과 결과를 기반으로 진단하기가 매우 쉽습니다.

웹사이트에 테스트되지 않은 코드가 방금 배포되어 즉각적인 사이트 문제가 발생했다면 원인이 있을 수 있습니다. 가능한 경우 의심되는 코드를 최대한 빨리 이전 버전으로 되돌리십시오.

이 상황을 피하기 위해 가장 좋은 것은? 프로덕션에 릴리스하기 전에 별도의 개발 또는 스테이징 환경에서 모든 코드를 철저히 테스트하십시오.

WordPress VIP 답변:

모든 사이트 배포가 GitHub를 통해 이루어지기 때문에 WordPress VIP 고객은 GitHub 개정 기록에 안전하게 저장된 새 코드 변경 사항을 잃지 않고 코드를 쉽게 되돌릴 수 있습니다. 선택적으로 긴급 상황에서 GitHub와 별도로 고객의 웹 사이트를 고객을 대신하여 이전 배포로 롤백할 수 있습니다.

환경과 관련하여 당사의 완전 관리형 서비스에서 호스팅되는 모든 애플리케이션은 별도의 개발 또는 스테이징 환경을 가질 수 있습니다. 프로덕션에서 데이터를 쉽게 동기화할 수 있으므로 프로덕션 웹 사이트에서와 동일한 양과 동일한 유형의 데이터에 대해 코드를 테스트할 수 있습니다.

PHP 오류

WordPress는 서버에서 PHP 코드를 사용합니다. PHP 오류는 "치명적"일 수 있습니다. 즉, 오류가 발생하면 웹 페이지, 스크립트 또는 명령 실행이 중지됩니다. 이것들은 거의 항상 어딘가에 보이는 오류로 나타나며 PHP 로그에 기록됩니다.

참고: PHP 7의 일부 PHP 경고는 PHP 8에서 치명적인 오류가 되므로 이러한 오류를 심각하게 받아들이는 것이 중요합니다.

WordPress VIP 답변(유용한 조언 포함):

당사 플랫폼은 모든 PHP 오류를 자동으로 기록하여 대시보드에서 WordPress VIP 고객과 엔지니어가 사용할 수 있도록 합니다.

전문가 팁 : 사이트가 제대로 작동하는 것처럼 보이더라도 모든 PHP 오류를 해결하고 수정하십시오. 안정적으로 보이는 사이트에서 정기적으로 PHP 오류로 가득 찬 로그(심지어 치명적인 오류도 포함)를 봅니다. 그러나 이것이 반드시 사이트가 올바르게 작동하고 있음을 의미하지는 않습니다. 사소한 오류 및 경고를 해결하여 PHP 로그를 명확하게 유지하면 디버깅 중에 더 심각한 오류를 쉽게 찾을 수 있습니다.

느린 MySQL 데이터베이스 쿼리

모든 WordPress 웹 사이트는 데이터베이스를 사용하여 웹 사이트 콘텐츠 및 구성 데이터를 저장합니다. 데이터베이스 쿼리는 웹 페이지의 콘텐츠 데이터를 가져오지만 때때로 이러한 쿼리가 비효율적으로 작성됩니다. 페이지 수가 수백 페이지에 불과한 사이트에서는 제대로 작동하지만 많은 양의 데이터를 처리할 때는 멈춥니다(당사 플랫폼의 일부 웹 사이트에는 수백만 개의 레코드가 저장되어 있음).

느린 쿼리는 데이터베이스 리소스를 묶고 SQL을 실행하는 페이지, 스크립트 또는 명령뿐만 아니라 전체 애플리케이션에서 사이트 안정성에 잠재적으로 영향을 미칩니다. 사이트는 단일 또는 다중 데이터베이스 쿼리(예: 실행하는 데 0.75초 이상 걸리는 쿼리)가 느리기 때문에 종종 어려움을 겪습니다.

WordPress VIP 답변:

WordPress VIP는 모든 데이터베이스 쓰기 쿼리가 발생하는 기본 데이터베이스와 하나 이상의 읽기 전용 복제본 데이터베이스를 특징으로 하는 전용 데이터베이스 클러스터를 각 애플리케이션에 제공하여 데이터베이스 병목 현상을 완화하는 데 도움이 됩니다. 이렇게 하면 발생할 수 있는 동시 데이터베이스 쿼리 수가 증가하여 사이트에 압력이 가해질 때 리소스 로드가 분산됩니다. 즉, 데이터베이스 리소스를 추가하는 것만으로 느린 데이터베이스 쿼리를 항상 해결할 수 있는 것은 아닙니다. 그렇기 때문에 Query Monitor 및 New Relic(당사 플랫폼에서 제공)을 사용하여 느린 데이터베이스 쿼리를 모니터링하도록 고객에게 조언합니다. 이는 데이터베이스에서 쿼리가 시작되는 위치를 강조 표시하므로 개발 팀이 성능을 최적화하기 위해 쿼리를 리팩토링할 수 있습니다.

마지막으로, 당사의 애플리케이션 지원 및 프리미어 엔지니어는 또한 귀하의 팀이 이러한 쿼리를 찾고 분석하는 데 도움을 줄 수 있으며 속도와 효율성을 위해 쿼리를 개선할 수 있는 방법을 제안할 수 있습니다.

과도한 데이터베이스 쓰기

때로는 사용자 정의 로깅 또는 추적 코드와 같은 기능이 모든 요청에 ​​대해 데이터베이스를 업데이트합니다. 이는 다음 두 가지 이유로 인해 불안정해질 수 있습니다.

• 전술한 데이터베이스 복제본 : 모든 쓰기 쿼리는 기본 데이터베이스로 전달됩니다. 동일한 페이지 요청에서 동일한 테이블(또는 테이블)에 대한 후속 데이터베이스 쿼리도 그곳으로 전달됩니다. 데이터베이스 복제본을 활용하지 않으면 사이트의 확장성이 제한됩니다.
• 페이지 캐싱 우회 : 모든 페이지 요청에 대해 데이터베이스 쓰기가 발생하려면 페이지 캐싱을 우회해야 합니다. 그러나 그렇게 하면 첫 번째(최상의) 방어선이 손상되었음을 의미합니다.

WordPress VIP 답변:

이러한 상황에서는 기능을 리팩토링하는 것이 좋습니다. 예를 들어 콘텐츠 분석은 일반적으로 서버 측 코드가 아닌 페이지에서 JavaScript 스니펫을 사용하는 외부 서비스에 가장 잘 위임되며, 이는 캐싱과 잘 작동하지 않고 과도한 데이터베이스 쓰기를 초래할 수 있습니다.

다운타임의 기타 알려진 원인 및 이를 방지하는 방법

플러그인

환상적인 기능을 제공하는 수천 개의 인기 있고 유용한 타사 플러그인이 WordPress 생태계에 있습니다. 그러나 일부는 확장에 문제가 있어 수많은 콘텐츠와 트래픽이 있는 웹 사이트에 추가될 때 잠재적으로 가동 중지 문제로 이어질 수 있습니다.

WordPress VIP 답변:

좋은 생태계 관리자로서 우리는 정기적으로 공급업체에 연락하여 트래픽이 많은 환경에서 플러그인의 성능을 향상시키도록 제안합니다. 또한 플랫폼에서 대규모로 시도되고 테스트된 대체 플러그인을 제안할 수도 있습니다.

커스텀 로깅

사용자 지정 로깅은 프로덕션 사이트에서만 발생하는 것으로 보이는 버그 또는 문제를 추적할 수 있는 유일한 실행 가능한 방법인 강력한 디버깅 도구입니다. 그러나 트래픽이 많은 사이트에서 PHP로 구축된 사용자 정의 로깅이 과도한 데이터베이스 쓰기를 통해 속도를 늦추거나 사이트를 다운타임의 위험에 빠뜨리는 경우를 여러 번 목격했습니다.

WordPress VIP 답변:

고객의 경우 WordPress VIP 애플리케이션 대시보드의 상태 패널에서 표준 PHP 로그에 대한 액세스를 제공합니다. 거기에서 그들은 데이터베이스에 부정적인 영향을 미치지 않는 사용자 정의 오류(및 New Relic에도)를 기록할 수 있습니다.

원격 API 호출

일부 웹 사이트는 다른 애플리케이션 또는 서비스에 대한 서버 측 REST API 호출을 활용합니다. 이는 정상적인 상황에서는 매우 빠르지만 때로는 기본 애플리케이션 코드로 인해 응답이 느려지거나 시간이 초과되거나 오류가 발생합니다.

WordPress VIP 답변:

이러한 문제를 최소화하기 위해 "방어적 코딩"을 권장합니다. 원격 호출의 목적에 따라 다르지만 원격 요청이 실패하면 이전 요청의 캐시된 응답으로 대체하거나 최소한 "오류를 정상적으로 처리"하여 나머지 페이지가 여전히 로드. 이러한 시나리오를 처리하기 위해 다양한 도우미 기능을 제공합니다. 시간 제한을 낮게 유지하면 원격 API가 응답하지 않는 경우 PHP 리소스가 더 빨리 해제됩니다.

CMS 재해 방지 시리즈에서 자세히 알아보기

비즈니스가 진행 중일 때 CMS(컨텐츠 관리 시스템)가 열악한 디지털 경험을 제공하도록 하여 새로운 비즈니스를 다른 곳으로 보내고 브랜드를 손상시킬 여유가 없습니다. 웹사이트 성능을 개선하는 방법 에서 5가지 일반적인 속도 저하 원인과 민첩한 CMS를 사용하여 성능을 향상시키는 방법을 진단합니다.

트래픽이 많은 날은 축하의 원인이 되어야 합니다. 엔지니어가 사이트와 애플리케이션을 계속 가동시키려고 애쓰고 부하를 처리하고 평판을 손상시키지 않으려고 애쓰는 엔지니어에게는 악몽이 아닙니다. 높은 트래픽을 위한 WordPress 확장 에서 WordPress 웹 사이트가 이러한 트래픽 해일을 처리할 수 있도록 하는 네 가지 접근 방식을 살펴봅니다.