기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 탄력적 배포 단일 서버 배포가 웹 사이트에 충분하지 않을 수 있는 많은 시나리오가 있습니다. 이러한 상황에서는 확장 가능한 다중 서버 아키텍처가 필요합니다. **Topics** + [ # 참조 아키텍처 ](reference-architecture.md) + [ # 웹 계층 크기 조정 ](scaling-the-web-tier.md) + [ # 상태 비저장 웹 계층 ](stateless-web-tier.md) # 참조 아키텍처 에서 GitHub 사용할 수 있는 [참조 AWS 아키텍처 WordPress 호스팅](https://github.com/awslabs/aws-refarch-wordpress)은 WordPress 에 배포하기 위한 모범 사례를 간략하게 설명하고 빠르게 시작하고 실행할 수 있는 AWS CloudFormation 템플릿 세트를 AWS 포함합니다. 다음 아키텍처는 해당 참조 아키텍처를 기반으로 합니다. 이 섹션의 나머지 부분에서는 아키텍처 선택의 이유를 검토합니다. AMI 의 기반은 2021년 7월에 Amazon Linux1에서 Amazon Linux2로 GitHub 변경되었습니다. Linux2 하지만 S3의 배포 템플릿은 아직 변경되지 않았습니다. S3에서 템플릿과 함께 참조 아키텍처를 배포하는 데 문제가 있는 GitHub 경우 에서 템플릿을 사용하는 것이 좋습니다. ![\[WordPress 에서 호스팅하기 위한 참조 아키텍처 AWS\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/best-practices-wordpress/images/image4.png) * WordPress 에서 호스팅하기 위한 참조 아키텍처 AWS * **아키텍처 구성 요소** 참조 아키텍처는 의 WordPress 웹 사이트에 대한 전체 모범 사례 배포를 보여줍니다AWS. + Amazon**(1)에서 CloudFront **엣지 캐싱으로 시작하여 최종 사용자와 가까운 콘텐츠를 캐싱하여 더 빠르게 ****전송할 수 있습니다. + CloudFront 는 **S3 버킷**(2)에서 정적 콘텐츠를 가져오고 웹 인스턴스 앞에 있는 **Application Load Balancer**(4)에서 동적 콘텐츠를 가져옵니다. + 웹 인스턴스는 **Amazon EC2****인스턴스**(6)의 **Auto Scaling 그룹에서** 실행됩니다. + ** ElastiCache **클러스터(7)는 자주 쿼리되는 데이터를 캐싱하여 응답 ****속도를 높입니다. **Amazon Aurora** MySQL 인스턴스(8)는 데이터베이스를 호스팅합니다 WordPress. + 인스턴스는 WordPress EC2 각 가용 영역의 **EFS 탑재 대상**(9)을 통해 **Amazon EFS** 파일 시스템의 공유 WordPress 데이터에 액세스합니다. + **Internet Gateway**(3)를 사용하면 VPC 와 인터넷의 리소스 간에 통신할 수 있습니다. + 각 가용 영역의**NAT 게이트웨이**(5)를 사용하면 프라이빗 서브넷(앱 및 데이터)의 EC2 인스턴스가 인터넷에 액세스할 수 있습니다. **Amazon VPC** 내에는 퍼블릭(**퍼블릭** 서브넷 ****)과 프라이빗(**앱 서브넷** 및 **데이터 서브넷 **)의 두 가지 유형의 서브넷이 있습니다. 퍼블릭 서브넷에 배포된 리소스는 퍼블릭 IP 주소를 수신하고 인터넷에서 공개적으로 볼 수 있습니다. **Application Load Balancer**(4)와 관리를 위한 Bastion 호스트가 여기에 배포됩니다. 프라이빗 서브넷에 배포된 리소스는 프라이빗 IP 주소만 수신하므로 인터넷에서 공개적으로 볼 수 없으므로 해당 리소스의 보안이 향상됩니다. **WordPress 웹** **서버 인스턴스**(6), **ElastiCache 클러스터 인스턴스**(7), **Aurora MySQL 데이터베이스 인스턴스**(8) 및 **EFS 탑재 대상**(9)은 모두 프라이빗 서브넷에 배포됩니다. 이 섹션의 나머지 부분에서는 이러한 각 고려 사항에 대해 자세히 설명합니다. # 웹 계층 크기 조정 단일 서버 아키텍처를 확장 가능한 다중 서버 아키텍처로 발전시키려면 다섯 가지 주요 구성 요소를 사용해야 합니다. + Amazon EC2 인스턴스 + Amazon Machine 이미지(AMIs) + 로드 밸런서 + 자동 크기 조정 + 상태 확인 AWS 는 다양한 EC2 인스턴스 유형을 제공하므로 성능과 비용 모두에 가장 적합한 서버 구성을 선택할 수 있습니다. 일반적으로 컴퓨팅 최적화(예: C4) 인스턴스 유형은 WordPress 웹 서버에 적합한 선택일 수 있습니다. AWS 리전 내 여러 가용 영역에 인스턴스를 배포하여 전체 아키텍처의 신뢰성을 높일 수 있습니다. EC2 인스턴스를 완벽하게 제어할 수 있으므로 루트 액세스 권한으로 로그인하여 WordPress 웹 사이트를 실행하는 데 필요한 모든 소프트웨어 구성 요소를 설치하고 구성할 수 있습니다. 완료되면 해당 구성을 로 저장할 수 AMI있습니다. 이 구성을 사용하여 모든 사용자 지정을 통해 새 인스턴스를 시작할 수 있습니다. 최종 사용자 요청을 여러 웹 서버 노드에 배포하려면 로드 밸런싱 솔루션이 필요합니다. AWS 는 트래픽을 여러 EC2 인스턴스에 분산하는 고가용성 서비스인 [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 통해 이 기능을 제공합니다. 웹 사이트는 HTTP 또는 를 통해 사용자에게 콘텐츠를 제공하기 때문에 필요한 경우 콘텐츠 라우팅과 여러 도메인에서 여러 WordPress 웹 사이트를 실행할 수 있는 기능을 갖춘 애플리케이션 계층 로드 밸런서인 Application Load Balancer를 사용하는 HTTPS것이 좋습니다. Elastic Load Balancing은 AWS 리전 내의 여러 가용 영역에 걸쳐 요청 배포를 지원합니다. Application Load Balancer가 실패한 개별 인스턴스로 트래픽을 자동으로 전송하지 않도록 상태 확인을 구성할 수도 있습니다(예: 하드웨어 문제 또는 소프트웨어 충돌로 인해). AWS 에서는 상태 확인을 위해 WordPress 관리자 로그인 페이지(`/wp-login.php`)를 사용하는 것이 좋습니다. 이 페이지는 웹 서버가 실행 중이고 웹 서버가 PHP 파일을 올바르게 제공하도록 구성되어 있는지 모두 확인하기 때문입니다. 데이터베이스 및 캐시 리소스와 같은 다른 종속 리소스를 확인하는 사용자 지정 상태 확인 페이지를 빌드하도록 선택할 수 있습니다. 자세한 내용은 *Application Load Balancer* *Guide*의 [대상 그룹에 대한 상태 확인을 참조하세요](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html). 탄력성은 AWS 클라우드의 주요 특성입니다. 필요할 때 더 많은 컴퓨팅 용량(예: 웹 서버)을 시작하고 그렇지 않을 때는 더 적게 실행할 수 있습니다. [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)은 수동 개입 없이 정의한 조건에 따라 Amazon EC2 용량을 늘리거나 줄일 수 있도록 이 프로비저닝을 자동화하는 데 도움이 되는 AWS 서비스입니다. Amazon EC2 Auto Scaling을 구성하여 수요 급증 중에 사용 중인 EC2 인스턴스 수가 원활하게 증가하여 성능을 유지하고 트래픽이 감소하면 자동으로 감소하여 비용을 최소화할 수 있습니다. Elastic Load Balancing은 로드 밸런싱 교체에서 Amazon EC2 호스트의 동적 추가 및 제거도 지원합니다. 또한 Elastic Load Balancing 자체는 로드 밸런싱 용량을 동적으로 늘리고 줄여 수동 개입 없이 트래픽 수요에 맞게 조정할 수 있습니다. # 상태 비저장 웹 계층 자동 조정 구성에서 여러 웹 서버를 활용하려면 웹 계층이 상태 비저장 상태여야 합니다. 상태 비저장 애플리케이션은 이전 상호 작용에 대한 지식이 필요하지 않고 세션 정보를 저장하지 않는 애플리케이션입니다. 의 경우 WordPress요청을 처리한 웹 서버에 관계없이 모든 최종 사용자가 동일한 응답을 받는다는 의미입니다. 사용 가능한 컴퓨팅 리소스(즉, 웹 서버 인스턴스)에서 요청을 서비스할 수 있으므로 상태 비저장 애플리케이션은 수평으로 확장할 수 있습니다. 해당 용량이 더 이상 필요하지 않은 경우 개별 리소스를 안전하게 종료할 수 있습니다(실행 중인 태스크가 드레이닝된 후). 이러한 리소스는 동료의 존재를 인식할 필요가 없습니다. 필요한 것은 워크로드를 배포하는 방법뿐입니다. 사용자 세션 데이터 스토리지의 경우 WordPress 코어는 클라이언트의 웹 브라우저에 저장된 쿠키에 의존하기 때문에 완전히 상태 비저장 상태입니다. 대신 기본 세션에 의존하는 사용자 지정 코드(예: WordPress 플러그인)를 설치하지 않는 한 PHP 세션 스토리지는 문제가 되지 않습니다. 그러나 WordPress 는 원래 단일 서버에서 실행되도록 설계되었습니다. 따라서 서버의 로컬 파일 시스템에 일부 데이터를 저장합니다. 다중 서버 구성 WordPress 에서 를 실행할 때 웹 서버 간에 불일치가 있기 때문에 문제가 발생합니다. 예를 들어 사용자가 새 이미지를 업로드하면 서버 중 하나에만 저장됩니다. 이는 중요한 데이터를 공유 스토리지로 이동하기 위해 기본 WordPress 실행 구성을 개선해야 하는 이유를 보여줍니다. 모범 사례 아키텍처에는 웹 서버 외부에 별도의 계층으로 데이터베이스가 있으며 공유 스토리지를 사용하여 사용자 업로드, 테마 및 플러그인을 저장합니다. # 공유 스토리지(Amazon S3 및 Amazon EFS) 기본적으로 는 로컬 파일 시스템에 사용자 업로드를 WordPress 저장하므로 상태 비저장이 아닙니다. 따라서 웹 서버의 부하를 줄이고 웹 계층을 상태 비저장 상태로 만들려면 WordPress 설치 및 모든 사용자 사용자 지정(구성, 플러그인, 테마 및 사용자 생성 업로드 등)을 공유 데이터 플랫폼으로 이동해야 합니다. [Amazon Elastic File System](https://aws.amazon.com/efs/details/)(Amazon EFS)은 EC2 인스턴스와 함께 사용할 수 있는 확장 가능한 네트워크 파일 시스템을 제공합니다. Amazon EFS 파일 시스템은 제약 없는 수의 스토리지 서버에 분산되어 파일 시스템이 탄력적으로 확장되고 EC2 인스턴스에서 대규모 병렬 액세스를 허용합니다. Amazon의 분산 설계는 기존 파일 서버에 내재된 병목 현상과 제약을 EFS 방지합니다. 전체 WordPress 설치 디렉터리를 EFS 파일 시스템으로 이동하고 부팅할 때 각 EC2 인스턴스에 탑재하면 WordPress 사이트와 모든 데이터가 하나의 EC2 인스턴스에 종속되지 않는 분산 파일 시스템에 자동으로 저장되므로 웹 계층이 완전히 상태 비저장 상태가 됩니다. 이 아키텍처의 이점은 새 인스턴스를 시작할 때마다 플러그인과 테마를 설치할 필요가 없으며 WordPress 인스턴스의 설치 및 복구 속도를 크게 높일 수 있다는 것입니다. 또한 이 문서의 배포 [고려 사항](appendix-a-cloudfront-configuration.md) 섹션에 설명된 WordPress대로 에서 플러그인 및 테마에 대한 변경 사항을 배포하는 것이 더 쉽습니다. EFS 파일 시스템에서 실행할 때 웹 사이트의 성능을 최적화하려면 Amazon 및 [AWS 참조 아키텍처 WordPress](https://github.com/awslabs/aws-refarch-wordpress#opcache)EFSOPcache에서 권장 구성 설정을 확인하세요. 또한 이미지, CSS및 JavaScript 파일과 같은 모든 정적 자산을 CloudFront 캐싱이 앞에 있는 S3 버킷으로 오프로드할 수 있습니다. 이 백서의 [정적 콘텐츠](accelerating-content-delivery.md) 섹션에서 설명한 대로 다중 서버 아키텍처에서 이 작업을 수행하는 메커니즘은 단일 서버 아키텍처와 정확히 동일합니다. 이점은 단일 서버 아키텍처와 동일합니다. 정적 자산을 Amazon S3 및 에 제공하는 것과 관련된 작업을 오프로드하여 웹 서버 CloudFront가 동적 콘텐츠만 생성하는 데 집중하고 웹 서버당 더 많은 사용자 요청을 제공할 수 있습니다. # 데이터 계층(Amazon Aurora 및 Amazon ElastiCache) 분산되고 확장 가능하며 공유된 네트워크 파일 시스템에 저장된 WordPress 설치와 Amazon S3에서 제공되는 정적 자산을 사용하면 나머지 상태 저장 구성 요소인 데이터베이스에 집중할 수 있습니다. 스토리지 계층과 마찬가지로 데이터베이스는 단일 서버에 의존해서는 안 되므로 웹 서버 중 하나에서 호스팅할 수 없습니다. 대신 Amazon Aurora에서 WordPress 데이터베이스를 호스팅합니다. [Amazon Aurora](https://aws.amazon.com/rds/aurora)는 클라우드용으로 구축된 MySQL and PostgreSQL 호환 관계형 데이터베이스로, 고급 상용 데이터베이스의 성능과 가용성을 오픈 소스 데이터베이스의 단순성과 비용 효율성과 결합합니다. Aurora MySQL는 데이터베이스 엔진을 가 지원하는 특수 설계된 분산 스토리지 시스템과 긴밀하게 통합하여 내SQL 성능과 가용성을 높입니다SSD. 내결함성 및 자체 복구 기능을 갖추고 있으며, 3개의 가용 영역에 걸쳐 6개의 데이터 사본을 복제하고, 99.99% 이상의 가용성을 위해 설계되었으며, Amazon S3에서 데이터를 지속적으로 백업합니다. Amazon Aurora는 충돌 복구 또는 데이터베이스 캐시 재구축 없이 데이터베이스 충돌을 자동으로 감지하고 다시 시작하도록 설계되었습니다. Amazon Aurora는 메모리 최적화 및 버스트 가능한 [인스턴스를 포함하여 다양한 애플리케이션 프로파일에 적합한 다양한 인스턴스 유형을](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html) 제공합니다. 데이터베이스의 성능을 개선하기 위해 대규모 인스턴스 유형을 선택하여 더 많은 CPU 및 메모리 리소스를 제공할 수 있습니다. Amazon Aurora는 기본 인스턴스와 [Aurora 복제본](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html) 간의 장애 조치를 자동으로 처리하므로 애플리케이션이 수동 관리 개입 없이 데이터베이스 작업을 최대한 빨리 재개할 수 있습니다. 장애 조치에는 일반적으로 30초 미만이 소요됩니다. 하나 이상의 Aurora 복제본을 생성한 후 클러스터 엔드포인트를 사용하여 기본 인스턴스에 연결하여 기본 인스턴스가 실패할 경우 애플리케이션이 자동으로 장애 조치될 수 있도록 합니다. 3개의 가용 영역에서 지연 시간이 짧은 읽기 전용 복제본을 최대 15개까지 생성할 수 있습니다. 데이터베이스 규모가 조정됨에 따라 데이터베이스 캐시도 확장해야 합니다. 앞에서 [데이터베이스 캐싱](database-caching.md) 섹션에서 설명한 대로 ElastiCache 에는 가용성 향상을 위해 ElastiCache 클러스터의 여러 노드와 리전의 여러 가용 영역에 걸쳐 캐시를 확장하는 기능이 있습니다. ElastiCache 클러스터를 확장할 때 가 새 클러스터 노드를 추가할 때 사용하고 이전 클러스터 노드를 제거할 때 사용을 중지할 WordPress 수 있도록 구성 엔드포인트를 사용하여 연결하도록 캐싱 플러그인을 구성해야 합니다. 클러스터 [ElastiCache 클라이언트PHP](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html)를 사용하도록 웹 서버를 설정하고 이 변경 사항을 저장하도록 AMI를 업데이트해야 합니다.