REL05-BP06 Menjadikan layanan stateless jika memungkinkan - AWS Well-Architected Framework
Panduan implementasiSumber daya

REL05-BP06 Menjadikan layanan stateless jika memungkinkan

Layanan seharusnya tidak memerlukan state, atau seharusnya mengalihkan state sedemikian rupa sehingga di antara permintaan klien yang berbeda, tidak ada dependensi di penyimpanan data lokal di disk dan memori. Ini memungkinkan server diganti sesuka hati tanpa menyebabkan dampak ketersediaan. Amazon ElastiCache atau Amazon DynamoDB merupakan tujuan yang baik untuk state yang dialihkan.

Pada aplikasi web stateless ini, state sesi dialihkan ke Amazon ElastiCache.

Gambar 7: Pada aplikasi web stateless ini, state sesi dialihkan ke Amazon ElastiCache.

Ketika pengguna atau layanan berinteraksi dengan aplikasi, mereka sering melakukan serangkaian interaksi yang membentuk sesi. Sesi adalah data unik bagi pengguna yang lama berada di antara permintaan ketika mereka menggunakan aplikasi. Aplikasi stateless adalah aplikasi yang tidak memerlukan pengetahuan tentang interaksi sebelumnya dan tidak menyimpan informasi sesi.

Setelah dirancang menjadi stateless, Anda dapat menggunakan layanan komputasi nirserver, seperti AWS Lambda atau AWS Fargate.

Selain penggantian server, manfaat lain aplikasi stateless adalah kemampuannya untuk menyesuaikan skala secara horizontal karena sumber daya komputasi yang tersedia (seperti instans EC2 dan fungsi AWS Lambda) dapat melayani permintaan apa pun.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Sedang

Panduan implementasi

  • Menjadikan aplikasi Anda stateless. Aplikasi stateless memungkinkan penskalaan horizontal dan toleran terhadap kegagalan simpul individual.

    • Hapus state yang sebenarnya dapat disimpan di parameter permintaan.

    • Setelah memeriksa apakah state diperlukan, pindahkan pelacakan state apa pun ke cache multi-zona yang tangguh atau penyimpanan data seperti Amazon ElastiCache, Amazon RDS, Amazon DynamoDB atau solusi data terdistribusi pihak ketiga. Simpan state yang tidak dapat dipindah ke penyimpanan data tangguh.

      • Beberapa data (seperti cookie) dapat diteruskan di header atau parameter kueri.

      • Lakukan pemfaktoran ulang untuk menghapus state yang dapat dengan cepat diteruskan di permintaan.

      • Beberapa data mungkin tidak terlalu diperlukan per permintaan dan dapat diambil sesuai permintaan.

      • Hapus data yang dapat diambil secara asinkron.

      • Tentukan penyimpanan data yang memenuhi kebutuhan state yang diperlukan.

      • Pertimbangkan basis data NoSQL untuk data non-rasional.

Sumber daya

Dokumen terkait: