기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 상태 비저장 웹 계층
<a name="stateless-web-tier"></a>

 자동 조정 구성에서 여러 웹 서버를 활용하려면 웹 계층이 상태 비저장 상태여야 합니다. 상태 비저장 애플리케이션은 이전 상호 작용에 대한 지식이 필요하지 않고 세션 정보를 저장하지 않는 애플리케이션입니다. 의 경우 WordPress요청을 처리한 웹 서버에 관계없이 모든 최종 사용자가 동일한 응답을 받는다는 의미입니다. 사용 가능한 컴퓨팅 리소스(즉, 웹 서버 인스턴스)에서 요청을 서비스할 수 있으므로 상태 비저장 애플리케이션은 수평으로 확장할 수 있습니다. 해당 용량이 더 이상 필요하지 않은 경우 개별 리소스를 안전하게 종료할 수 있습니다(실행 중인 태스크가 드레이닝된 후). 이러한 리소스는 동료의 존재를 인식할 필요가 없습니다. 필요한 것은 워크로드를 배포하는 방법뿐입니다.

 사용자 세션 데이터 스토리지의 경우 WordPress 코어는 클라이언트의 웹 브라우저에 저장된 쿠키에 의존하기 때문에 완전히 상태 비저장 상태입니다. 대신 기본 세션에 의존하는 사용자 지정 코드(예: WordPress 플러그인)를 설치하지 않는 한 PHP 세션 스토리지는 문제가 되지 않습니다.

 그러나 WordPress 는 원래 단일 서버에서 실행되도록 설계되었습니다. 따라서 서버의 로컬 파일 시스템에 일부 데이터를 저장합니다. 다중 서버 구성 WordPress 에서 를 실행할 때 웹 서버 간에 불일치가 있기 때문에 문제가 발생합니다. 예를 들어 사용자가 새 이미지를 업로드하면 서버 중 하나에만 저장됩니다.

 이는 중요한 데이터를 공유 스토리지로 이동하기 위해 기본 WordPress 실행 구성을 개선해야 하는 이유를 보여줍니다. 모범 사례 아키텍처에는 웹 서버 외부에 별도의 계층으로 데이터베이스가 있으며 공유 스토리지를 사용하여 사용자 업로드, 테마 및 플러그인을 저장합니다.

# 공유 스토리지(Amazon S3 및 Amazon EFS)
<a name="shared-storage-amazon-s3-and-amazon-efs"></a>

 기본적으로 는 로컬 파일 시스템에 사용자 업로드를 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)
<a name="data-tier-amazon-aurora-and-amazon-elasticache"></a>

 분산되고 확장 가능하며 공유된 네트워크 파일 시스템에 저장된 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를 업데이트해야 합니다.