Drupal 호스팅: 무엇이 실제로 잘 돌아가는가

“Drupal은 느리다”는 평판의 출처는 대부분 호스팅이며, 그것은 거의 언제나 소프트웨어의 문제가 아니라 구매 결정의 문제입니다. 사이트는 제대로 만들어지고, 그다음 PHP 파일 몇 개짜리 소개용 사이트를 기준으로 가격이 매겨진 요금제 위에서 오픈합니다. 그 결과 진지한 렌더 파이프라인을 가진 콘텐츠 관리 시스템이, 스스로 바꿀 수 없는 메모리 한도 안에서, 스스로 통제할 수 없는 오피코드 캐시 위에서, 자기 도구를 돌릴 셸도 없이 돌아가게 됩니다.

사람들이 머릿속에서 비교 대상으로 삼는 것은 WordPress이고, 그 비교가 틀렸습니다. WordPress가 거의 어떤 환경에서도 그럭저럭 돌아가는 이유는, 그 시장 점유율이 호스팅 업체들에게 거의 어떤 환경에서도 그럭저럭 돌아가게 만들라고 강요했기 때문입니다. Drupal의 전제는 다릅니다. 최신 PHP, 최근 버전의 데이터베이스, 진짜 캐시 백엔드, 명령줄, 그리고 코드베이스를 편집하는 폴더가 아니라 빌드 산출물로 다루는 배포 절차를 전제합니다.

Drupal이 호스트에 실제로 요구하는 것은 무엇인가? 사용 중인 릴리스의 하한선 이상인 PHP 버전, 최근 버전의 MySQL, MariaDB 또는 PostgreSQL, 실무 기준 256MB의 PHP 메모리, OPcache, Composer와 Drush를 위한 셸 접근, 진짜 cron 항목, 그리고 로그인 사용자가 생기는 순간부터는 외부 객체 캐시입니다. 저가 공유 호스팅은 이 가운데 서너 개에서 동시에 탈락합니다.

Drupal이 서버에 실제로 요구하는 것

공개된 요구 사항은 짧고 구체적이며 누구나 읽을 수 있지만, 결제 전에 그것을 읽는 사람은 거의 없습니다. 게다가 이 요구 사항은 버전마다 다르고, 지금은 그 차이가 특히 중요합니다. 하한선 중 두 가지가 2026년 12월에 움직이기 때문입니다.

PHP 버전 하한선은 협상 대상이 아니다

Drupal 11은 PHP 8.3을 최소 요건으로 하고 8.3, 8.4, 8.5를 지원합니다. Drupal 10은 8.1을 요구하며 8.4까지 지원하고, Drupal 12는 하한선을 다시 PHP 8.5로 올립니다. 이 숫자들은 Drupal 자체의 PHP 요구 사항 문서에서 온 것이고, 믿을 만한 목록은 그것뿐입니다.

이는 보기보다 무거운 문제입니다. PHP 브랜치 자체에도 만료가 있기 때문입니다. php.net의 지원 버전 페이지는 PHP 8.2의 보안 지원 종료를 2026년 12월 31일로, 8.3을 2027년 12월 31일로, 8.4를 2028년 12월 31일로 명시합니다. PHP 8.1은 이미 지났습니다. “PHP 8.1과 8.2 제공”을 광고하는 호스트는 지금 이미 패치되지 않거나 몇 달 안에 패치되지 않을 스택을 팔고 있는 셈입니다.

두 날짜는 겹칩니다. Drupal 10은 2026년 12월 9일에 수명을 다하고, 코어 릴리스 일정에 따르면 Drupal 12는 같은 주에 나옵니다. 호스트가 PHP 8.3 이상을 제공하지 못한다면 그 이후로는 지원되는 Drupal을 운영할 수 없습니다. 아직 10에 머물러 있다면 Drupal 마이그레이션 비용과 선택지, 기한을 다룬 글이 그것이 무슨 뜻인지 설명합니다.

데이터베이스 엔진과 진짜 최소 버전

데이터베이스 서버 요구 사항에 따르면 Drupal 11은 MariaDB 10.6 이상, MySQL 8.0 이상, PostgreSQL 16 이상, 또는 SQLite 3.45 이상을 원합니다. Drupal 10은 훨씬 너그러워서 MariaDB 10.3.7, MySQL 5.7.8, PostgreSQL 12, SQLite 3.26이면 됩니다. 업그레이드가 때때로 고객이 전혀 예상하지 못한 데이터베이스 업그레이드까지 불러오는 이유가 바로 이것입니다.

두 가지 세부 사항이 자주 빠집니다. MySQL과 MariaDB에서는 스토리지 엔진이 반드시 InnoDB여야 합니다. Drupal이 트랜잭션과 행 수준 잠금에 의존하기 때문입니다. PostgreSQL에서는 설치 전에 Drupal이 쓸 데이터베이스에 pg_trgm 확장을 생성해 두어야 하고, CREATE EXTENSION을 실행하게 해주지 않는 관리형 데이터베이스 서비스는 쓸 수 없습니다.

SQLite는 실제로 지원되며 로컬 개발에는 충분합니다. 다만 여러 편집자가 동시에 콘텐츠를 저장하기 시작하면 운영 환경의 답이 되지는 못합니다. 먼저 한계에 부딪히는 것이 쓰기 동시성이기 때문입니다.

메모리, 확장, 웹 서버

Drupal 문서상의 최소값은 PHP 메모리 64MB이고, 그 아래에서는 경고를 표시합니다. 같은 문서는 운영 환경에서 128MB나 256MB가 일반적이며 미디어가 많은 설치는 더 필요하다고 적고 있습니다. 실무에서는 256MB를 작업 기준값으로 잡고, 명령줄용으로는 더 올릴 것을 예상하십시오. 메모리를 많이 쓰는 것은 페이지 서빙이 아니라 Composer와 대규모 마이그레이션이기 때문입니다.

확장 목록은 평범하지만 그래도 확인할 가치가 있습니다. 데이터베이스 드라이버가 포함된 PDO, XML, JSON, mbstring, cURL, 외부 HTTPS를 위한 OpenSSL, 그리고 이미지 파생본을 만들 GD 또는 ImageMagick입니다. Drupal 12는 여기에 비밀번호 해싱용 Argon2를 추가하는데, 아주 오래된 PHP 빌드에는 없는 항목이 하나 더 늘어나는 셈입니다.

웹 서버 쪽에서 Drupal은 Apache 2.4.7 이상과 Nginx 1.1 이상을 지원하며, Drupal 11.0.0부터 Microsoft IIS를 지원하지 않습니다. Apache에서는 깨끗한 URL을 위해 mod_rewrite가 필요하고, 함께 배포되는 .htaccess가 적용되도록 AllowOverride All도 필요합니다. 마지막 항목이 사람들을 자주 잡습니다. Drupal의 보호 규칙 일부는 .htaccess에만 존재하므로, Nginx로 배포한다면 서버 설정에서 그것들을 손으로 재현해야 합니다. 정해진 절차이지만 정해진 듯이 건너뛰기도 하는 단계이고, 서버 보안 감사에서 우리가 가장 먼저 확인하는 것 중 하나입니다.

공유 호스팅이 Drupal에서 실패하는 이유

공유 호스팅이 나쁜 호스팅인 것은 아닙니다. 형태가 다른 애플리케이션에 맞춰 최적화되어 있을 뿐이고, Drupal은 그 제약에 부딪혀 예측 가능한 네 지점에서 깨집니다.

셸이 없으면 Composer도 Drush도 없다

현대의 Drupal은 Composer 프로젝트입니다. 코어, 컨트리뷰트 모듈, 그리고 그것들의 PHP 의존성은 모두 Composer가 해결하며, 일단 Composer가 모듈 하나를 관리하기 시작하면 코어까지 함께 관리해야 합니다. Composer와 수동 파일 업데이트를 섞는 것이, 사이트가 결국 아무것도 업데이트하지 못하게 되는 전형적인 경로입니다.

파일 관리자가 딸린 제어판으로는 그 일을 할 수 없습니다. FTP 클라이언트로도 안 됩니다. SSH가 없으면 Drush도 함께 잃는데, 캐시 재구축, 설정 가져오기, 데이터베이스 업데이트, 사용자 비밀번호 재설정은 실제로 모두 Drush로 수행하는 작업입니다. drush cr를 실행할 수 없는 사이트는, 복구를 위한 모든 단계가 지원 티켓으로 바뀌는 사이트입니다.

보이지도 않고 바꿀 수도 없는 한도

공유 계정에서는 memory_limit을 다른 사람이 정합니다. 보통 128MB, 때로는 그보다 낮으며, 512MB가 필요한 단 한 번의 마이그레이션을 위해 그것을 올릴 방법은 없습니다.

더 큰 문제는 OPcache입니다. OPcache는 미리 컴파일된 스크립트 바이트코드를 공유 메모리에 보관해 PHP가 요청마다 파일을 다시 파싱하지 않도록 해주는데, 공유 호스트에서는 그 메모리 풀을 수백 개의 계정이 함께 씁니다. Drupal은 PHP 파일이 수천 개이므로 서로 다투는 그 풀에서 무거운 세입자이고, 그래서 밀려납니다. 증상은 누군가 방문한 뒤 1분 동안은 빠르다가 한 시간 뒤에는 다시 느려지는 사이트입니다.

그리고 아예 없는 것들이 있습니다. Redis도 없고, Memcached도 없고, PHP 프로세스 매니저에 대한 통제권도 없으며, 오래 도는 큐 워커를 돌릴 방법도 없습니다.

사실상 돌지 않는 cron

Drupal의 자동 cron 모듈은 기본값으로 세 시간마다, 사이트를 방문한 최종 사용자에 의해 실행됩니다. 방문이 많은 사이트에서 이것은 가끔 어떤 방문자가 자기 페이지 로딩 시간으로 검색 인덱싱 비용을 대신 치른다는 뜻입니다. 한산한 사이트에서 이것은 cron이 사실상 돌지 않는다는 뜻이고, 그래서 검색 인덱스는 낡아가고 로그 테이블은 정리되지 않으며 나와 있는 보안 업데이트도 확인되지 않습니다.

문서는 대신 외부에서 cron을 트리거하라고 권합니다. 그러면 항상 정해진 시각에 돌고 자원도 덜 쓰기 때문입니다. 그러려면 진짜 crontab 항목이 필요한데, 가장 싼 등급은 그것을 제공하지 않습니다.

캐시 계층과 방문자가 실제로 맞는 계층

Drupal의 캐시는 사람들이 생각하는 것보다 층이 많고, 그 층들은 서로의 대안이 아닙니다. 쌓여 있으면서 위층이 놓친 것을 아래층이 받아냅니다.

OPcache는 Drupal 아래에 있다

OPcache는 Drupal의 기능이 아닙니다. 인터프리터 수준에서 컴파일된 PHP 바이트코드를 캐시하므로 Drupal의 어떤 캐시가 적중하든 말든 모든 요청에 적용됩니다. 이것을 틀리면 그 위의 무엇으로도 만회할 수 없습니다. 모든 요청이 라우터에 닿기 전에 프레임워크를 다시 컴파일하는 비용을 치르기 때문입니다. 공유 메모리는 넉넉하게 잡고, 운영 환경에서는 타임스탬프 검증을 끄십시오. 운영 환경에서 파일 집합은 배포 때만 바뀝니다.

Internal Page Cache와 Dynamic Page Cache

Internal Page Cache는 코어 모듈이고 기본으로 켜져 있으며 익명 사용자만 담당합니다. 모든 익명 방문자가 같은 페이지를 본다고 가정하고, 첫 요청에서 응답 전체를 저장한 뒤 그것을 재사용합니다. 개인화가 없는 마케팅 사이트라면 거의 모든 일을 이 계층이 합니다.

Dynamic Page Cache도 코어이고 역시 기본으로 켜져 있으며, 인증된 사용자를 포함해 누구에게나 캐시합니다. 렌더 시스템이 페이지에서 진짜로 개인적인 부분만 플레이스홀더로 바꾸고 그 주변을 전부 캐시하는 방식입니다. 로그인 상태의 Drupal 페이지도 대부분 캐시될 수 있는 이유가 이것이며, 실제로 동적인 것은 사용자 메뉴와 블록 몇 개뿐입니다.

BigPipe와 렌더 캐시

그 둘 아래에 렌더 캐시가 있고, 개별 블록, 필드, 뷰 결과, 엔티티 렌더 결과를 캐시합니다. 페이지 캐시를 놓친 페이지도 대개는 데이터베이스에서 다시 만들어지는 것이 아니라 렌더 캐시 적중을 모아 조립됩니다.

남은 부분은 BigPipe가 맡습니다. Drupal 8.1부터 코어에 있었고 8.3부터 안정 버전이며 8.5부터 표준 설치 프로파일에 들어 있습니다. 모든 플레이스홀더가 해결되기를 기다리는 대신 캐시 가능한 페이지를 즉시 내보내고 개인화된 조각을 그 뒤에 흘려 보냅니다. 설정이 필요 없고, 익명 사용자보다 인증된 사용자에게 훨씬 도움이 됩니다.

그래서 잘 구성된 사이트의 익명 방문자는 Internal Page Cache나 그 앞의 CDN에 맞고 이 대부분을 건드리지 않습니다. 로그인한 편집자는 요청마다 Dynamic Page Cache, 렌더 캐시, BigPipe에 맞습니다. 인증된 트래픽의 비용이 훨씬 큰 이유가 이것입니다.

외부 객체 캐시

위의 모든 계층은 항목을 저장할 곳이 필요합니다. 기본값은 데이터베이스의 캐시 테이블이고, 그것은 캐시 읽기가 같은 서버에서 콘텐츠 쿼리와 경쟁한다는 뜻입니다.

Redis 모듈은 캐시, 잠금, 플러드, 큐 백엔드를 Redis나 Valkey 같은 호환 스토어로 옮기며, PhpRedis 확장, Relay 확장, 또는 순수 PHP인 Predis 라이브러리를 쓸 수 있습니다. Memcached는 동등한 대안입니다. 작은 익명 사이트에서는 이것으로 달라지는 것이 별로 없습니다. 로그인 사용자가 있는 사이트에서는 대개 지금 얻을 수 있는 가장 큰 개선인데, 가장 시끄러운 쓰기 부하를 데이터베이스에서 걷어내고 잠금을 싸게 만들기 때문입니다.

Drupal 앞의 리버스 프록시와 CDN

Varnish나 Nginx 같은 리버스 프록시, 또는 CDN은 PHP가 관여하기도 전에 요청에 답합니다. 익명 트래픽에서 이것은 한 자릿수 밀리초로 페이지를 내보내느냐, 수백 밀리초를 쓰느냐의 차이입니다. 동시에 사람들이 가장 두려워하는 계층이기도 한데, 뉴스 사이트나 쇼핑몰에서 낡은 캐시는 눈에 보이는 실패이기 때문입니다.

CDN을 안전하게 만드는 것은 캐시 태그다

Drupal의 답은 캐시 태그입니다. 캐시 태그는 데이터 의존성을 서술하며 node:5, user:3, node_list 같은 문자열로 씁니다. 캐시된 항목은 자신이 어떤 태그에 의존하는지 기록하므로, 5번 노드를 편집하면 그것을 참조한 캐시 조각과 페이지와 뷰가 어디에 있든 모두 무효화됩니다.

중요한 것은 Drupal이 그 태그를 바깥으로 내보낼 수 있다는 점입니다. 컨트리뷰트 모듈이 Fastly용 Surrogate-Key 헤더나 Cloudflare용 Cache-Tag 헤더로 태그를 실어 보내고, Drupal이 지시하면 CDN이 태그 단위로 퍼지합니다. 그러면 CDN은 시간에 거는 도박에서 이벤트 기반 캐시로 바뀝니다. 편집이 몇 초 안에 영향받은 URL만 정확히 퍼지하므로 긴 유효 기간을 설정할 수 있습니다.

헤더 예산에는 주의하십시오. Cloudflare의 캐시 태그 퍼지 문서는 Cache-Tag 헤더 총량을 필드 이름을 뺀 뒤 16KB, 대략 1,000개의 고유 태그로 제한하며, API 호출에서는 태그당 최대 1,024자, 대시보드 퍼지는 한 번에 100개까지입니다. 많은 엔티티를 나열하는 Drupal 뷰는 그보다 훨씬 많은 태그를 만들 수 있으므로, 모든 것을 나열하는 페이지는 모듈에서 태그를 줄이거나 해시하도록 설정하지 않는 한 조용히 헤더를 넘겨 버립니다.

Drupal 호스팅 고르기: 네 등급을 솔직하게

현실적인 선택지는 넷이고, 어느 것이 맞는지는 인증된 트래픽이 있는지, 그리고 서버를 운영할 사람이 있는지로 정해집니다. 아래 구간은 영국 고객이 우리 경험상 실제로 지불하는 수준이며 부가가치세를 제외한 값이고, 특정 업체의 견적이 아니라 참고치입니다.

공유 호스팅

운영 환경에서 Drupal을 돌리는 누구에게도 맞지 않습니다. 셸 접근, 메모리, 오피코드 캐시, 객체 캐시, cron에서 동시에 탈락합니다. 예산이 정말 여기서 막힌다면, 비슷한 가격의 작은 비관리형 인스턴스가 돈을 더 잘 쓰는 방법입니다.

비관리형 VPS 또는 클라우드 인스턴스

월 대략 GBP 20에서 GBP 120이면 완전한 root 권한을 가진 머신을 얻고, 이것이 Drupal 사이트의 대다수에 맞습니다. PHP 버전을 고르고, OPcache 크기를 잡고, Redis를 설치하고, crontab을 걸고, Nginx를 제대로 구성할 수 있습니다. 얻지 못하는 것은 그 일을 해주고, 패치하고, 모니터링하고, 새벽 두 시에 복구해 줄 사람입니다. 이 등급이 맞는 경우는 개발자나 에이전시와 유지보수 계약이 있는 경우이고, 진짜 비용은 인스턴스가 아니라 그 계약입니다.

매니지드 Drupal 전문 플랫폼

매니지드 Drupal 호스팅은 작은 사이트 기준 월 GBP 40 근처에서 시작해 트래픽과 환경 수, 지원 등급에 따라 빠르게 올라갑니다. 사는 것은 이미 올바르게 정해져 있는 스택과 Git 기반 배포, 스테이징 환경, 백업, 그리고 Drupal을 이해하는 사람이 전화를 받는다는 사실입니다. 대안이 아무도 없는 것이라면 값을 합니다. 월 4,000회 방문하는 소개용 사이트에 플랫폼 가격을 낸다면 값을 못 합니다.

완전한 맞춤 인프라

분리된 데이터베이스, 전용 캐시 노드, 로드 밸런서 뒤의 애플리케이션 서버들, 파일을 위한 객체 스토리지. 이 구성이 말이 되기 시작하는 지점은 대략 월 GBP 400 위이고, 그것도 인증된 트래픽이나 시스템 연동, 규제 준수 요건 때문에 매니지드 등급이 불편해질 때뿐입니다. 가장 강력한 등급이자 가장 부담이 큰 등급인데, 이제 패치와 모니터링과 재해 복구가 전부 여러분의 몫이기 때문입니다. 그 복잡성이 애플리케이션 쪽에서 어디서 오는지는 Drupal 웹 개발 가이드에서 다룹니다.

배포: 서버에서 파일을 편집하지 않는다

Composer가 의존성 트리 전체를 해결하는 이상, 서버의 코드베이스는 결과물이지 작업 공간이 아닙니다. 모듈 파일을 그 자리에서 고치면 다음 composer update가 덮어쓰고, 운영 코드가 Git의 어떤 상태와도 일치하지 않게 됩니다.

제정신인 릴리스 절차는 산출물을 다른 곳에서 만듭니다. 커밋된 composer.lock으로 CI에서 composer install을 돌리면 빌드는 재현 가능해지고, 운영 호스트는 Composer도, 의존성 해결용 PHP 메모리도, vendor에 대한 쓰기 권한도 필요 없어집니다. 결과물을 배포하고, 데이터베이스 업데이트를 돌리고, 설정을 가져오고, 캐시를 재구축합니다. 롤백은 이전 산출물을 가리키는 것으로 끝납니다.

이것은 호스팅 문제도 조용히 정리해 줍니다. FTP로 파일을 편집하라고 기대하는 호스트는 사양서에 무엇이 적혀 있든 Drupal의 유지보수 방식과 맞지 않습니다.

설정 동기화는 어디에 들어가는가

Drupal은 활성 설정을 데이터베이스에 두고 그것을 YAML 파일로 내보내며, 콘텐츠 타입과 필드, 뷰, 각종 설정이 환경 사이를 오가는 방식이 바로 이것입니다. 설정 관리 문서는 원본과 대상의 사이트 UUID가 일치해야 한다고 설명하는데, 첫 가져오기가 실패하는 흔한 이유가 그것입니다.

실무적으로 이것은 설정이 곧 코드라는 뜻입니다. 나머지와 함께 커밋되고 리뷰되고 배포되며, 가져오기 단계는 나중에 관리 화면에서 클릭하는 것이 아니라 릴리스의 일부로 실행됩니다. 호스팅도 그것을 뒷받침해야 합니다. 가져오기를 실행할 자리가 필요하고, 실패한 가져오기가 운영에 절반만 적용된 채 남지 않고 롤백될 수 있는 환경이 필요합니다.

파일, 미디어, 백업

Drupal에는 파일 시스템이 둘 있고 그 차이가 하중을 받습니다. 공개 쪽은 웹 루트 아래에 있고 웹 서버가 직접 서빙합니다. 비공개 쪽은 웹 루트 바깥에 있고, 비공개 파일에 대한 모든 요청은 접근 권한을 검사할 수 있도록 Drupal을 거칩니다.

따라서 비공개 파일은 공개 파일보다 훨씬 비쌉니다. 내려받을 때마다 PHP가 부팅되기 때문입니다. 큰 비공개 문서를 배포하는 사이트에는 정적 파일 서버라면 필요 없었을 여유가 필요합니다.

미디어를 객체 스토리지로 옮기기

파일이 애플리케이션 서버 위에 자리 잡는 순간 수평 확장과 재구축이 괴로워지고, 백업마다 미디어 라이브러리 전체를 함께 옮기게 됩니다. 공개 파일 시스템을 S3 호환 객체 스토리지로 옮기면 둘이 분리되고, CDN이 미디어를 직접 서빙할 수 있으며, 애플리케이션 서버는 진짜로 버릴 수 있는 것이 됩니다.

백업이 증명하지 못하는 것을 복구 테스트가 증명한다

백업은 파일이 존재한다는 것만 증명합니다. 복구 테스트는 그 파일이 온전하다는 것, 데이터베이스와 파일이 같은 시점의 것이라는 것, 자격 증명이 아직 유효하다는 것, 그리고 얼마나 오래 걸리는지를 증명합니다. 이것은 서로 다른 네 가지 실패 방식이고, 제어판의 초록색 체크 표시로는 그중 어느 것도 보이지 않습니다.

적어도 일 년에 두 번은 실제 시계로 재고 그 숫자를 적어 두십시오. 복구에 여섯 시간이 걸리는데 허용 범위가 한 시간이라면, 문제는 백업이 아니라 아키텍처입니다. 복구 시간은 호스팅 요구 사항이고, 장애 대응 중이 아니라 사양서 안에 있어야 합니다.

Drupal 호스트를 제대로 사이징하기

페이지뷰는 잘못된 단위입니다. CDN 뒤에서 월 200,000 익명 페이지뷰를 받는 사이트가 작은 인스턴스에서 여유로울 수 있는 반면, 월 8,000 페이지뷰인 사이트도 그 대부분이 로그인 상태라면 힘들어질 수 있습니다.

진짜 동인은 인증된 트래픽이다

익명 요청은 PHP를 건드리지 않고 페이지 캐시나 CDN이 답할 수 있지만 인증된 요청은 그럴 수 없습니다. 그 하나하나가 렌더 파이프라인을 돌리고, 엔티티마다 접근 권한을 확인하고, 플레이스홀더를 해결하고, 세션 데이터를 씁니다. 실무적인 질문은 방문이 몇 번이냐가 아니라, 동시에 로그인한 사용자가 몇 명이고 그 사용자들이 무엇을 볼 수 있게 되어 있느냐입니다.

편집자는 극단적인 사례입니다. 콘텐츠 관리 화면은 Drupal에서 가장 무거운 페이지에 속하고 정의상 캐시할 수 없으므로, 편집자 열두 명이 동시에 일하는 사이트에는 공개 트래픽만 봐서는 전혀 짐작할 수 없는 진짜 동시성 요구가 있습니다.

뷰, 택소노미, 큐 작업

인증된 트래픽 외에 확실한 비용 발생 지점이 몇 가지 있습니다. 필터와 관계가 많은 큰 뷰는 비싼 조인을 만들고, 깊은 택소노미 트리는 렌더할 때마다 용어 계층을 훑으며, 검색 인덱싱과 피드 가져오기, 미디어 파생본 생성 같은 cron 또는 큐 작업이 있습니다.

큐 워커는 가능하다면 방문자와 웹 서버 자원을 나눠 쓰지 않는 편이 좋습니다. 규모가 큰 사이트에서는 별도의 프로세스나 인스턴스에 두어, 밀린 가져오기 작업이 프런트엔드를 느리게 만들지 못하게 합니다. 이는 구매 시점에 내리는 아키텍처 결정이고, 매니지드 등급이 맞지 않게 되고 맞춤 인프라가 의미를 갖기 시작하는 지점이기도 합니다.

결정을 제대로 내리기

패턴은 일관됩니다. 호스팅이 작은 것이 아니라 형태가 틀린 것입니다. 셸이 없고, 객체 캐시가 없고, 오피코드 캐시는 남의 것이며, PHP 버전은 곧 지원에서 떨어집니다. 같은 사이트를 비슷한 가격의 제대로 명세된 인스턴스로 옮기는 편이 대개 어떤 프런트엔드 최적화보다도 낫습니다.

Mecanik은 웹사이트 개발 업무의 일부로 Drupal 인프라를 설계하고 구축하고 유지보수하며, 속도가 아니라 노출이 걱정일 때는 서버 보안 감사로 기존 스택을 점검합니다. 플랫폼이 아니라 사람이 필요하다면 Drupal 개발자 채용을 다룬 글이 무엇을 봐야 하는지 설명합니다.

자주 묻는 질문

Drupal 11의 최소 서버 요구 사항은 무엇인가요? PHP 8.3 이상, 데이터베이스는 MariaDB 10.6, MySQL 8.0, PostgreSQL 16 또는 SQLite 3.45입니다. 웹 서버 쪽은 Apache 2.4.7 또는 Nginx 1.1 이상이며, Drupal 11.0.0부터 Microsoft IIS는 지원되지 않습니다. Drupal은 PHP 메모리 64MB 아래에서 경고를 내지만, 운영 환경에서 현실적인 숫자는 256MB입니다.

Drupal을 공유 호스팅에서 운영할 수 있나요? 설치도 되고 페이지도 서빙되지만, 공유 호스팅은 대개 서너 개의 요구 사항에서 동시에 탈락합니다. Composer나 Drush를 위한 셸 접근이 없고, PHP 메모리 한도를 올릴 수 없고, Redis나 Memcached가 없으며, cron은 방문자가 마침 페이지를 열 때만 돕니다. Drupal이 느리다는 평판은 바로 이런 조건에서 나옵니다.

Drupal 호스팅 비용은 어느 정도가 적당한가요? 제대로 구성된 비관리형 인스턴스 위의 작은 Drupal 사이트는 아무도 운영해 주지 않는 상태에서 보통 월 GBP 20에서 GBP 120 사이입니다. 매니지드 Drupal 플랫폼은 흔히 GBP 40 근처에서 시작해 트래픽과 환경 수에 따라 수백 파운드까지 올라갑니다. 맞춤 인프라는 대략 GBP 400 위에서 말이 되기 시작합니다. 가장 싼 등급이 가장 싼 결과인 경우는 드뭅니다.

Drupal에 Redis가 필요한가요? 작은 익명 사이트라면 필요 없고 Internal Page Cache와 데이터베이스로 충분합니다. 로그인 사용자나 편집자, 회원 영역이 생기면 Redis나 Memcached 같은 외부 객체 캐시가 캐시 읽기와 잠금과 큐를 데이터베이스에서 걷어내며, 들인 돈 대비로는 대개 얻을 수 있는 가장 큰 개선입니다.

동적인 Drupal 사이트 앞에 CDN을 두어도 안전한가요? 시간이 아니라 캐시 태그로 무효화한다면 안전합니다. Drupal은 응답이 의존하는 모든 것에 node:5 같은 태그를 기록하고, 모듈이 그것을 Cache-Tag나 Surrogate-Key 헤더로 옮기므로 CDN은 편집이 영향을 준 페이지만 정확히 퍼지합니다. 태그 무효화가 없으면 낡은 페이지와 전혀 도움이 되지 않는 캐시 중에서 골라야 합니다.