Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Otomatisasi elastis
Ada banyak skenario di mana penyebaran server tunggal mungkin tidak cukup untuk situs web Anda. Dalam situasi ini, Anda memerlukan arsitektur multi-server yang dapat diskalakan.
**Topics**
+ [Arsitektur referensi](reference-architecture.md)
+ [Menskalakan tingkat web](scaling-the-web-tier.md)
+ [Tingkat web Stateless](stateless-web-tier.md)
# Arsitektur referensi
[Hosting WordPress pada arsitektur AWS referensi](https://github.com/awslabs/aws-refarch-wordpress) tersedia di GitHub menguraikan praktik terbaik untuk menerapkan WordPress AWS dan menyertakan serangkaian AWS CloudFormation templat untuk membuat Anda siap dan berjalan dengan cepat. Arsitektur berikut didasarkan pada arsitektur referensi itu. Sisa bagian ini akan meninjau alasan di balik pilihan arsitektur.
Berbasis AMI di GitHub diubah dari Amazon Linux1 menjadi Amazon Linux2 pada Juli 2021. Namun, templat penerapan di S3 belum diubah. Disarankan untuk menggunakan template di GitHub jika ada masalah untuk menyebarkan arsitektur referensi dengan template di S3.
![\[Arsitektur referensi untuk hosting WordPress di AWS\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/best-practices-wordpress/images/image4.png)
*Arsitektur referensi untuk hosting WordPress di AWS*
**Komponen arsitektur**
Arsitektur referensi menggambarkan penerapan praktik terbaik yang lengkap untuk WordPress situs web. AWS
+ Dimulai dengan edge caching di **Amazon CloudFront** (1) untuk menyimpan konten yang dekat dengan pengguna akhir untuk **** pengiriman yang lebih cepat.
+ CloudFront menarik konten statis dari **bucket S3** (2) dan konten dinamis dari **Application Load** Balancer (4) di depan instance web.
+ Instans web berjalan dalam grup **Auto Scaling** dari instans **EC2**Amazon**** (6).
+ ** ElastiCache **Cluster (7) menyimpan data yang sering ditanyakan untuk **** mempercepat respons.
**Amazon Aurora** My SQL instance (8) menghosting database. WordPress
+ WordPress EC2Instans mengakses WordPress data bersama pada sistem EFS file **Amazon** melalui **Target EFS Mount** (9) di setiap Availability Zone.
+ **Internet Gateway** (3) memungkinkan komunikasi antara sumber daya di Anda VPC dan internet.
+ **NATGateway** (5) di setiap Availability Zone memungkinkan EC2 instance di subnet pribadi (Aplikasi dan Data) untuk mengakses internet.
Di **Amazon VPC** ada dua jenis subnet: publik (**Public** **Subnet**) dan Private (**App Subnet dan **Data** Subnet**). Sumber daya yang digunakan ke subnet publik akan menerima alamat IP publik dan akan terlihat publik di internet. **Application Load Balancer** (4) dan host Bastion untuk administrasi digunakan di sini. Sumber daya yang digunakan ke subnet pribadi hanya menerima alamat IP pribadi dan karenanya tidak terlihat oleh publik di internet, meningkatkan keamanan sumber daya tersebut. **Instance server WordPress ** **web** (6), **instance ElastiCache cluster (7), instance SQL** **database Aurora My** (8), dan **EFSMount Targets** (9) semuanya digunakan dalam subnet pribadi.
Sisa bagian ini mencakup masing-masing pertimbangan ini secara lebih rinci.
# Menskalakan tingkat web
Untuk mengembangkan arsitektur server tunggal Anda menjadi arsitektur multi-server yang dapat diskalakan, Anda harus menggunakan lima komponen utama:
+ EC2Contoh Amazon
+ Amazon Machine Images (AMIs)
+ Penyeimbang beban
+ Penskalaan Otomatis
+ Pemeriksaan kondisi
AWSmenyediakan berbagai macam jenis EC2 instans sehingga Anda dapat memilih konfigurasi server terbaik untuk kinerja dan biaya. Secara umum, jenis instans yang dioptimalkan komputasi (misalnya, C4) mungkin merupakan pilihan yang baik untuk server web. WordPress Anda dapat menerapkan instans Anda di beberapa Availability Zone dalam suatu AWS Wilayah untuk meningkatkan keandalan arsitektur secara keseluruhan.
Karena Anda memiliki kontrol penuh atas EC2 instans Anda, Anda dapat masuk dengan akses root untuk menginstal dan mengkonfigurasi semua komponen perangkat lunak yang diperlukan untuk menjalankan WordPress situs web. Setelah selesai, Anda dapat menyimpan konfigurasi itu sebagaiAMI, yang dapat Anda gunakan untuk meluncurkan instans baru dengan semua kustomisasi yang telah Anda buat.
Untuk mendistribusikan permintaan pengguna akhir ke beberapa node server web, Anda memerlukan solusi load balancing. AWSmenyediakan kemampuan ini melalui [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/), layanan yang sangat tersedia yang mendistribusikan lalu lintas ke beberapa instance. EC2 Karena situs web Anda menyajikan konten kepada pengguna Anda melalui HTTP atauHTTPS, kami menyarankan Anda menggunakan Application Load Balancer, penyeimbang beban lapisan aplikasi dengan perutean konten dan kemampuan untuk menjalankan beberapa WordPress situs web pada domain yang berbeda, jika diperlukan.
Elastic Load Balancing mendukung distribusi permintaan di beberapa Availability Zone dalam suatu AWS Wilayah. Anda juga dapat mengonfigurasi pemeriksaan kesehatan sehingga Application Load Balancer secara otomatis berhenti mengirim lalu lintas ke instance individual yang gagal (misalnya, karena masalah perangkat keras atau kerusakan perangkat lunak). AWSmerekomendasikan menggunakan halaman login WordPress admin (`/wp-login.php`) untuk pemeriksaan kesehatan karena halaman ini mengonfirmasi bahwa server web sedang berjalan dan bahwa server web dikonfigurasi untuk melayani PHP file dengan benar.
Anda dapat memilih untuk membuat halaman pemeriksaan kesehatan khusus yang memeriksa sumber daya dependen lainnya, seperti sumber daya database dan cache. *Untuk informasi selengkapnya, lihat [Pemeriksaan Kesehatan untuk kelompok sasaran Anda di Panduan](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) *Application Load Balancer*.*
Elastisitas adalah karakteristik utama dari AWS Cloud. Anda dapat meluncurkan lebih banyak kapasitas komputasi (misalnya, server web) saat Anda membutuhkannya dan menjalankan lebih sedikit saat tidak. [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) adalah AWS layanan yang membantu Anda mengotomatiskan penyediaan ini untuk meningkatkan atau menurunkan EC2 kapasitas Amazon Anda sesuai dengan kondisi yang Anda tentukan tanpa memerlukan intervensi manual. Anda dapat mengonfigurasi Amazon EC2 Auto Scaling sehingga jumlah EC2 instans yang Anda gunakan meningkat dengan mulus selama lonjakan permintaan untuk mempertahankan kinerja dan menurun secara otomatis saat lalu lintas berkurang, sehingga dapat meminimalkan biaya.
Elastic Load Balancing juga mendukung penambahan dan penghapusan dinamis EC2 host Amazon dari rotasi load-balancing. Elastic Load Balancing sendiri juga secara dinamis meningkatkan dan mengurangi kapasitas load-balancing untuk menyesuaikan dengan permintaan lalu lintas tanpa intervensi manual.
# Tingkat web Stateless
Untuk memanfaatkan beberapa server web dalam konfigurasi penskalaan otomatis, tingkat web Anda harus stateless. Aplikasi stateless adalah aplikasi yang tidak memerlukan pengetahuan tentang interaksi sebelumnya dan tidak menyimpan informasi sesi. Dalam hal ini WordPress, ini berarti bahwa semua pengguna akhir menerima respons yang sama, terlepas dari server web mana yang memproses permintaan mereka. Aplikasi stateless dapat menskalakan secara horizontal karena permintaan apa pun dapat dilayani oleh sumber daya komputasi yang tersedia (yaitu, instance server web). Ketika kapasitas itu tidak lagi diperlukan, sumber daya individu apa pun dapat dihentikan dengan aman (setelah menjalankan tugas telah terkuras). Sumber daya tersebut tidak perlu menyadari kehadiran rekan-rekan mereka - semua yang diperlukan adalah cara untuk mendistribusikan beban kerja kepada mereka.
Ketika datang ke penyimpanan data sesi pengguna, WordPress inti sepenuhnya tanpa kewarganegaraan karena bergantung pada cookie yang disimpan di browser web klien. Penyimpanan sesi tidak menjadi perhatian kecuali Anda telah menginstal kode khusus apa pun (misalnya, WordPress plugin) yang bergantung pada PHP sesi asli.
Namun, WordPress awalnya dirancang untuk berjalan pada satu server. Akibatnya, ia menyimpan beberapa data pada sistem file lokal server. Saat berjalan WordPress dalam konfigurasi multi-server, ini menimbulkan masalah karena ada ketidakkonsistenan di seluruh server web. Misalnya, jika pengguna mengunggah gambar baru, itu hanya disimpan di salah satu server.
Ini menunjukkan mengapa kita perlu meningkatkan konfigurasi WordPress berjalan default untuk memindahkan data penting ke penyimpanan bersama. Arsitektur praktik terbaik memiliki database sebagai lapisan terpisah di luar server web dan memanfaatkan penyimpanan bersama untuk menyimpan unggahan pengguna, tema, dan plugin.
# Penyimpanan bersama (Amazon S3 dan Amazon) EFS
Secara default, WordPress menyimpan unggahan pengguna pada sistem file lokal dan karenanya tidak stateless. Oleh karena itu, kita perlu memindahkan WordPress instalasi dan semua penyesuaian pengguna (seperti konfigurasi, plugin, tema, dan unggahan yang dibuat pengguna) ke platform data bersama untuk membantu mengurangi beban pada server web dan membuat tingkat web tanpa kewarganegaraan.
[Amazon Elastic File System](https://aws.amazon.com/efs/details/) (AmazonEFS) menyediakan sistem file jaringan yang dapat diskalakan untuk digunakan dengan EC2 instance. Sistem EFS file Amazon didistribusikan di sejumlah server penyimpanan yang tidak dibatasi, memungkinkan sistem file tumbuh secara elastis dan memungkinkan akses paralel secara besar-besaran dari instance. EC2 Desain Amazon yang didistribusikan EFS menghindari kemacetan dan kendala yang melekat pada server file tradisional.
Dengan memindahkan seluruh direktori WordPress instalasi ke sistem EFS file dan memasangnya ke setiap EC2 instance Anda ketika mereka boot, WordPress situs Anda dan semua datanya secara otomatis disimpan pada sistem file terdistribusi yang tidak bergantung pada satu EC2 contoh, membuat tingkat web Anda sepenuhnya tanpa kewarganegaraan. Manfaat arsitektur ini adalah Anda tidak perlu menginstal plugin dan tema pada setiap peluncuran instance baru, dan Anda dapat secara signifikan mempercepat instalasi dan pemulihan WordPress instance. Juga lebih mudah untuk menerapkan perubahan pada plugin dan tema WordPress, seperti yang diuraikan di bagian [Pertimbangan Penerapan dokumen](appendix-a-cloudfront-configuration.md) ini.
Untuk memastikan kinerja optimal situs web Anda saat menjalankan dari sistem EFS file, periksa pengaturan konfigurasi yang disarankan untuk OPcache Amazon EFS dan [Arsitektur AWS Referensi untuk WordPress](https://github.com/awslabs/aws-refarch-wordpress#opcache).
Anda juga memiliki opsi untuk membongkar semua aset statis, seperti gambar,, dan JavaScript fileCSS, ke bucket S3 dengan CloudFront caching di depan. Mekanisme untuk melakukan ini dalam arsitektur multi-server persis sama dengan arsitektur server tunggal, seperti yang dibahas di bagian [Konten Statis](accelerating-content-delivery.md) dari whitepaper ini. Manfaatnya sama dengan arsitektur server tunggal — Anda dapat menurunkan pekerjaan yang terkait dengan melayani aset statis Anda ke Amazon S3 dan CloudFront, dengan demikian memungkinkan server web Anda untuk fokus pada menghasilkan konten dinamis saja dan melayani lebih banyak permintaan pengguna per server web.
# Tingkat data (Amazon Aurora dan Amazon) ElastiCache
Dengan WordPress penginstalan yang disimpan pada sistem file jaringan bersama yang terdistribusi, dapat diskalakan, dan aset statis yang dilayani dari Amazon S3, Anda dapat memusatkan perhatian pada komponen stateful yang tersisa: database. Seperti halnya tingkat penyimpanan, database tidak boleh bergantung pada server tunggal mana pun, sehingga tidak dapat di-host di salah satu server web. Sebagai gantinya, host WordPress database di Amazon Aurora.
[Amazon Aurora](https://aws.amazon.com/rds/aurora) adalah basis data relasional yang SQL kompatibel dengan My SQL dan Postgre yang dibangun untuk cloud yang menggabungkan performa dan ketersediaan database komersial kelas atas dengan kesederhanaan dan efektivitas biaya database sumber terbuka. Aurora My SQL meningkatkan SQL performa dan ketersediaan saya dengan secara erat mengintegrasikan mesin basis data dengan sistem penyimpanan terdistribusi yang dibangun khusus, didukung oleh. SSD Ini toleran terhadap kesalahan dan penyembuhan diri, mereplikasi enam salinan data Anda di tiga Availability Zone, dirancang untuk ketersediaan lebih dari 99,99%, dan terus mencadangkan data Anda di Amazon S3. Amazon Aurora dirancang untuk secara otomatis mendeteksi crash basis data dan melakukan restart tanpa perlu pemulihan crash atau membangun kembali cache basis data.
Amazon Aurora menyediakan sejumlah [jenis instans yang sesuai dengan profil aplikasi yang berbeda, termasuk instans](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html) yang dioptimalkan untuk memori dan burstable. Untuk meningkatkan kinerja database Anda, Anda dapat memilih jenis instans besar untuk menyediakan lebih banyak CPU dan sumber daya memori.
Amazon Aurora secara otomatis menangani failover antara instans utama dan [Replika Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html) sehingga aplikasi Anda dapat melanjutkan operasi basis data secepat mungkin tanpa intervensi administratif manual. Failover biasanya membutuhkan waktu kurang dari 30 detik.
Setelah Anda membuat setidaknya satu Replika Aurora, sambungkan ke instans utama Anda menggunakan titik akhir cluster untuk memungkinkan aplikasi Anda gagal secara otomatis jika instance utama gagal. Anda dapat membuat hingga 15 replika baca latensi rendah di tiga Availability Zone.
Saat skala basis data Anda, cache database Anda juga perlu diskalakan. Seperti yang dibahas sebelumnya di bagian [Caching Database](database-caching.md), ElastiCache memiliki fitur untuk menskalakan cache di beberapa node dalam sebuah ElastiCache cluster, dan di beberapa Availability Zone di Region untuk meningkatkan ketersediaan. Saat Anda menskalakan ElastiCache klaster Anda, pastikan Anda mengonfigurasi plugin caching Anda untuk terhubung menggunakan titik akhir konfigurasi sehingga WordPress dapat menggunakan node cluster baru saat ditambahkan dan berhenti menggunakan node cluster lama saat dihapus. Anda juga harus mengatur server web Anda untuk menggunakan [Klien ElastiCache Cluster PHP](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html) dan memperbarui Anda AMI untuk menyimpan perubahan ini.