Praktik Terbaik: Mengoptimalkan Jumlah Server Aplikasi

penting

AWS OpsWorks Stacks Layanan ini mencapai akhir masa pakai pada 26 Mei 2024 dan telah dinonaktifkan untuk pelanggan baru dan yang sudah ada. Kami sangat menyarankan pelanggan untuk memindahkan beban kerja mereka ke solusi lain sesegera mungkin. Jika Anda memiliki pertanyaan tentang migrasi, hubungi AWS Support Tim di AWS re:Post atau melalui AWS Dukungan Premium.

Tumpukan produksi biasanya mencakup beberapa server aplikasi yang didistribusikan di beberapa Availability Zone. Namun jumlah permintaan yang masuk dapat sangat bervariasi tergantung pada waktu hari atau hari dalam seminggu. Anda bisa menjalankan server yang cukup untuk menangani beban maksimum yang diantisipasi, tetapi kemudian sebagian besar waktu Anda akhirnya akan membayar lebih banyak kapasitas server daripada yang Anda butuhkan. Untuk menjalankan situs Anda secara efisien, praktik yang disarankan adalah mencocokkan jumlah server dengan volume permintaan saat ini.

AWS OpsWorks Stacks menyediakan tiga cara untuk mengelola jumlah instance server.

• Instance 24/7 dimulai secara manual dan dijalankan hingga dihentikan secara manual.

• Instans berbasis waktu secara otomatis dimulai dan dihentikan oleh AWS OpsWorks Stacks pada jadwal yang ditentukan pengguna.

• Instans berbasis beban secara otomatis dimulai dan dihentikan oleh AWS OpsWorks Stacks ketika melewati ambang batas untuk metrik beban yang ditentukan pengguna seperti CPU atau pemanfaatan memori.

catatan

Setelah Anda membuat dan mengonfigurasi waktu tumpukan dan instance berbasis beban, AWS OpsWorks Stacks secara otomatis memulai dan menghentikannya berdasarkan konfigurasi yang ditentukan. Anda tidak perlu menyentuhnya lagi kecuali Anda memutuskan untuk mengubah konfigurasi atau jumlah instance.

Rekomendasi: Jika Anda mengelola tumpukan dengan lebih dari beberapa instance server aplikasi, sebaiknya gunakan campuran ketiga jenis instans. Berikut ini adalah contoh bagaimana mengelola kapasitas server stack untuk menangani volume permintaan harian variabel dengan karakteristik sebagai berikut.

• Volume permintaan rata-rata bervariasi secara sinusoidal sepanjang hari.

• Volume permintaan rata-rata minimum membutuhkan lima instance server aplikasi.

• Volume permintaan rata-rata maksimum membutuhkan enam belas instance server aplikasi.

• Lonjakan volume permintaan biasanya dapat ditangani oleh satu atau dua instance server aplikasi.

Ini adalah model yang nyaman untuk tujuan diskusi, tetapi Anda dapat dengan mudah menyesuaikannya dengan variasi volume permintaan dan juga memperluasnya untuk menangani variasi mingguan. Diagram berikut menunjukkan cara menggunakan tiga jenis instance untuk mengelola volume permintaan ini.

Contoh ini memiliki karakteristik sebagai berikut:

• Tumpukan memiliki tiga instance 24/7, yang selalu aktif dan menangani beban dasar.

• Tumpukan memiliki 12 instance berbasis waktu, yang dikonfigurasi untuk menangani variasi harian rata-rata.

  Satu berjalan dari jam 10 malam hingga 2 pagi, dua lagi lari dari jam 8 malam hingga 10 malam dan 2 pagi hingga 4 pagi, dan seterusnya. Untuk mempermudah, diagram memodifikasi jumlah instance berbasis waktu setiap dua jam, tetapi Anda dapat memodifikasi angka setiap jam jika Anda menginginkan kontrol yang lebih halus.

• Tumpukan memiliki instance berbasis beban yang cukup untuk menangani lonjakan lalu lintas yang melebihi apa yang dapat ditangani oleh instance 24/7 dan berbasis waktu.

  AWS OpsWorks Tumpukan memulai instance berbasis beban hanya jika beban di semua server yang sedang berjalan melebihi metrik yang ditentukan. Biaya untuk instans yang tidak berjalan minimal (instans yang didukung Amazon EBS) atau tidak sama sekali (instans yang didukung toko instans), jadi praktik yang disarankan adalah membuat cukup banyak instans untuk menangani volume permintaan maksimum yang diantisipasi dengan nyaman. Untuk contoh ini, tumpukan harus memiliki setidaknya tiga instance berbasis beban.

catatan

Pastikan Anda memiliki ketiga jenis instans yang didistribusikan di beberapa Availability Zone untuk mengurangi dampak gangguan layanan apa pun.