Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Tingkat web Stateless 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 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 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.