Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pertimbangan desain

Bagian ini menjelaskan keputusan desain penting dan opsi konfigurasi untuk solusi Pengujian Beban Terdistribusi di AWS, termasuk aplikasi yang didukung, jenis pengujian, opsi penjadwalan, dan pertimbangan penerapan.

Aplikasi-aplikasi yang didukung

Solusi ini mendukung pengujian aplikasi berbasis cloud dan aplikasi lokal selama Anda memiliki konektivitas jaringan dari akun AWS ke aplikasi Anda. Solusi ini mendukung API yang menggunakan protokol HTTP atau HTTPS.

Jenis pengujian

Pengujian Beban Terdistribusi di AWS mendukung beberapa jenis pengujian: pengujian titik akhir HTTP sederhana, JMeter, k6, dan Locust. Setiap jenis pengujian kecuali titik akhir HTTP sederhana dapat berjalan di salah satu mode bentuk lalu lintas. Untuk informasi selengkapnya, lihat Mode bentuk lalu lintas.

Tes titik akhir HTTP sederhana

Konsol web menyediakan antarmuka Konfigurasi Titik Akhir HTTP yang memungkinkan Anda menguji titik akhir HTTP atau HTTPS apa pun tanpa menulis skrip khusus. Anda menentukan URL titik akhir, memilih metode HTTP (GET, POST, PUT, DELETE, dan seterusnya) dari menu dropdown, dan secara opsional menambahkan header permintaan kustom dan payload tubuh. Konfigurasi ini memungkinkan Anda menguji API dengan token otorisasi khusus, jenis konten, atau header HTTP lain dan badan permintaan yang diperlukan oleh aplikasi Anda.

Saat Anda mengonfigurasi titik akhir HTTP, solusi mengubah konfigurasi Anda menjadi rencana pengujian yang dijalankan oleh biner Apache JMeter yang dibundel melalui kerangka Taurus. Pengujian HTTP Endpoint sederhana tidak menerima arsip pengujian, sehingga mereka tidak dapat mengganti biner atau plugin JMeter yang dibundel. Jika Anda perlu menjalankan pengujian titik akhir HTTP dengan JMeter yang ditambal, gunakan jenis pengujian JMeter sebagai gantinya. Untuk pertimbangan keamanan, lihat Apache JMeter.

Karena solusi menghasilkan rencana pengujian untuk jenis pengujian ini, pengujian Endpoint HTTP Sederhana hanya berjalan dalam mode Standar. Mode asli memerlukan skrip yang Anda unggah. Untuk informasi selengkapnya, lihat Mode bentuk lalu lintas.

Tes JMeter

Saat membuat skenario pengujian menggunakan konsol web, Anda dapat mengunggah skrip pengujian JMeter. Solusinya mengunggah skrip ke bucket skenario S3. Ketika tugas Amazon ECS berjalan, mereka mengunduh skrip JMeter dari S3 dan menjalankan pengujian.

Jika Anda memiliki file input JMeter, Anda dapat zip file input bersama dengan skrip JMeter. Anda dapat memilih file zip saat Anda membuat skenario pengujian.

Jika Anda ingin menyertakan plugin, semua file.jar yang disertakan dalam subdirektori /plugins dalam file zip yang dibundel akan disalin ke direktori ekstensi JMeter dan tersedia untuk pengujian beban.

Jika Anda menyertakan plugin JMeter, file.jar harus dibundel dalam subdirektori bernama /plugins dalam root file zip. Relatif terhadap root file zip, jalur ke file jar harus. /plugins/BUNDLED_PLUGIN.jar.

Untuk informasi selengkapnya tentang cara menggunakan skrip JMeter, lihat Panduan Pengguna JMeter.

tes k6

Solusinya mendukung pengujian berbasis kerangka kerja k6. Anda dapat mengunggah file uji k6 bersama dengan file input yang diperlukan dalam file arsip. Konsol web menampilkan pesan pengakuan lisensi saat Anda membuat pengujian k6 baru. Untuk detail lisensi dan keamanan, lihat Grafana k 6.

Tes belalang

Solusinya mendukung pengujian berbasis kerangka kerja Locust. Anda dapat mengunggah file uji Locust bersama dengan file input yang diperlukan dalam file arsip.

Uji penamaan skrip

Saat Anda mengunggah satu .py file, solusi menyimpannya di bawah ID pengujian dan mereferensikannya secara langsung, sehingga file dapat memiliki nama apa pun. Saat Anda mengunggah .zip arsip, solusi mencari arsip untuk file bernamalocustfile.py. Jika arsip berisi skrip Python dengan nama lain, pengujian gagal selama startup kontainer dengan pesan tersebutNo test script (.py) in zip file.

Dependensi Python khusus

Wadah pengujian beban mencakup Locust dan dependensinya. Itu tidak termasuk paket Python pihak ketiga. Jika skrip Locust Anda mengimpor paket yang tidak ada di wadah, pengujian gagal. ModuleNotFoundError Untuk membuat paket tambahan tersedia, sertakan requirements.txt file di root ar .zip sip Anda. Wadah menginstal paket yang tercantum requirements.txt sebelum pengujian dimulai.

Anda dapat menyediakan dependensi dengan salah satu dari dua cara:

Contoh berikut menunjukkan tata letak arsip:

my-test.zip
├── locustfile.py         # Required — must use this name
├── requirements.txt      # Optional — packages to install
└── packages/             # Optional — wheels, for offline install only
    └── *.whl

K requirements.txt eduanya dan packages subdirektori harus berada di akar arsip, di sampinglocustfile.py. Hilangkan keduanya jika skrip Anda hanya mengimpor paket yang sudah disediakan container. packagesSubdirektori hanya berlaku bersama requirements.txt file; dengan sendirinya, itu diabaikan dan tidak ada paket yang diinstal.

Mempersiapkan roda untuk wadah

Wadah pengujian beban menjalankan Linux pada arsitektur x86_64 dengan Python 3.11. Roda yang dikompilasi untuk sistem operasi, arsitektur, atau versi Python yang berbeda tidak dapat diinstal. Paket yang ditulis dalam Python murni didistribusikan sebagai roda platform-independen dan berfungsi di mana saja, tetapi paket yang berisi ekstensi yang dikompilasi memerlukan roda yang dibuat untuk platform wadah. Karena wadah tidak menyertakan kompiler, ia tidak dapat membangun distribusi sumber pada startup tugas.

Jalankan perintah berikut untuk mengunduh roda yang kompatibel dengan platform wadah. Anda dapat menjalankan perintah ini dari sistem operasi apa pun, termasuk macOS dan Windows. Kemudian sertakan packages direktori yang dihasilkan dalam arsip Anda:

pip download -r requirements.txt \
  --dest packages \
  --platform manylinux2014_x86_64 \
  --python-version 3.11 \
  --only-binary=:all:

--python-versionOpsi --platform dan menargetkan wadah, bukan mesin tempat Anda menjalankan perintah. --only-binary=:all:Opsi ini menyebabkan perintah gagal daripada diam-diam kembali ke distribusi sumber yang tidak dapat dibuat oleh wadah. manylinux2014Tag menentukan roda yang kompatibel dengan glibc 2.17 dan yang lebih baru, yang mencakup versi container.

Untuk menggabungkan paket yang Anda pertahankan sendiri, buat roda dari direktori sumber paket Andapip wheel . --wheel-dir packages, lalu tambahkan nama paket kerequirements.txt.

Mode bentuk lalu lintas

Setiap pengujian berjalan di salah satu dari dua mode bentuk lalu lintas, Standar atau Asli. Mode menentukan tiga hal: sisi mana yang mengontrol beban, gambar wadah mana yang digunakan tugas Fargate, dan parameter beban mana yang dikirim solusi ke kerangka pengujian. Untuk panduan memilih mode saat Anda membuat pengujian, lihat Mode bentuk lalu lintas di bagian Gunakan solusi.

Modus standar

Tugas Fargate menggunakan gambar dengan Taurus diinstal. Taurus menerima jumlah tugas, konkurensi, ramp-up, dan durasi penahanan Anda dari solusi. Ini menerjemahkan nilai-nilai ini ke dalam kontrol beban kerangka kerja yang mendasarinya sendiri. Taurus diutamakan daripada beban yang dinyatakan skrip Anda. Ini menulis ulang atau mengabaikan blok opsi k6, LocustLoadTestShape, atau grup utas JMeter. Pengguna virtual yang dihasilkan Wilayah adalah jumlah tugas dikalikan dengan konkurensi untuk setiap tugas. Bentuk itu sama untuk setiap kerangka kerja. Ini adalah bagaimana solusi menjalankan setiap pengujian sebelum versi 4.3.0.

Modus asli

Tugas Fargate menggunakan gambar khusus untuk kerangka pengujian, yang tidak termasuk Taurus. Alih-alih menulis konfigurasi Taurus, solusinya memanggil kerangka kerja secara langsung:jmeter -n -t,k6 run, atau. locust --headless Ini tidak melewati parameter beban. Skrip Anda adalah satu-satunya otoritas pada lalu lintas yang dihasilkannya.

Dua konsekuensi mengikuti dari desain itu, dan keduanya memengaruhi cara Anda mengukur tes:

Tes penjadwalan

Solusinya menyediakan tiga opsi waktu eksekusi untuk menjalankan uji beban:

Ketika Anda memilih Run Once, Anda menentukan waktu berjalan dalam format 24 jam dan tanggal berjalan ketika uji beban harus mulai berjalan.

Bila Anda memilih Run on a Schedule, Anda dapat memasukkan ekspresi cron secara manual atau memilih dari pola cron umum (seperti setiap jam, setiap hari pada waktu tertentu, hari kerja, atau bulanan). Ekspresi cron menggunakan format jadwal berbutir halus dengan bidang untuk menit, jam, hari dalam bulan, bulan, hari dalam seminggu, dan tahun. Anda juga harus menentukan tanggal kedaluwarsa, yang menentukan kapan pengujian yang dijadwalkan harus berhenti berjalan. Untuk informasi selengkapnya tentang aturan validasi penjadwalan, lihat bagian Kendala penjadwalan pada panduan ini.

Tes bersamaan

Setiap kali uji beban berjalan, fungsi AWS Lambda yang menjalankan tugas membuat das CloudWatch bor Amazon yang diberi nama EcsLoadTesting-<testId>-<region> di setiap Wilayah tempat pengujian berjalan. CloudWatch Dasbor menampilkan output gabungan dari semua tugas yang berjalan di cluster Amazon ECS secara real time: waktu respons rata-rata, jumlah pengguna bersamaan, jumlah permintaan yang berhasil, dan jumlah permintaan yang gagal. Solusi menggabungkan setiap metrik per detik dan memperbarui dasbor setiap menit.

Proses selanjutnya dari skenario pengujian yang sama memperbarui dasbor yang sama, sehingga akun Anda berisi satu dasbor untuk setiap skenario pengujian di setiap Wilayah. Dasbor ini tetap ada di akun Anda setelah pengujian selesai. Mereka dikenakan biaya bulanan sampai Anda menghapusnya. Solusi menghapus dasbor skenario saat Anda menghapus skenario pengujian (misalnya, melalui konsol web). Dasbor tidak dihapus saat Anda menghapus tumpukan solusi CloudFormation . Untuk informasi selengkapnya, lihat bagian Biaya dan bagian Menghapus sumber daya yang disimpan Menghapus sumber daya yang disimpan secara manual secara manual dari panduan ini.

Manajemen pengguna

Selama konfigurasi awal, Anda memberikan nama pengguna dan alamat email yang digunakan Amazon Cognito untuk memberi Anda akses ke konsol web solusi. Konsol tidak menyediakan administrasi pengguna. Untuk menambahkan pengguna tambahan, Anda harus menggunakan konsol Amazon Cognito. Untuk informasi selengkapnya, lihat M engelola Pengguna di Kumpulan Pengguna di Panduan Pengembang Amazon Cognito.

Untuk memigrasikan pengguna yang sudah ada ke kumpulan pengguna Amazon Cognito, lihat Pen dekatan blog AWS untuk memigrasikan pengguna ke kumpulan pengguna Amazon Cognito.

Federasi penyedia identitas

Kumpulan pengguna Amazon Cognito solusi mendukung federasi dengan penyedia identitas eksternal (IdPs) menggunakan protokol SAML 2.0 atau OpenID Connect (OIDC). Federasi memungkinkan pengguna untuk masuk ke konsol web menggunakan kredenSIAL perusahaan atau organisasi yang ada, bukan kreden Cognito-native SIAL. Pengguna federasi menerima izin akses yang sama seperti pengguna yang dibuat langsung di kumpulan pengguna Cognito.

Solusinya sudah menerapkan kumpulan pengguna Cognito, domain, klien aplikasi, dan UI yang dihosting. Untuk mengaktifkan federasi, Anda hanya perlu mendaftarkan penyedia identitas Anda dan mengaktifkannya di klien aplikasi yang ada.

Jika Anda menerapkan integrasi Server MCP opsional, pengguna federasi juga dapat mengakses Server MCP menggunakan kredentif kumpulan pengguna Cognito yang sama.

Prasyarat

Sebelum mengkonfigurasi federasi, Anda memerlukan yang berikut:

Langkah 1: Konfigurasikan penyedia identitas Anda

Konfigurasikan penyedia identitas eksternal Anda dengan nilai-nilai berikut sehingga dapat berkomunikasi dengan kumpulan pengguna Cognito solusi.

Untuk penyedia identitas SAML:

Untuk penyedia identitas OIDC:

Untuk detail tentang kebutuhan IdP Anda, lihat Menambahkan penyedia identitas SAML ke kumpulan pengguna atau Men ambahkan penyedia identitas OIDC ke kumpulan pengguna di Panduan Pengembang Amazon Cognito.

Langkah 2: Daftarkan penyedia identitas di Cognito

Tambahkan penyedia identitas eksternal Anda ke kumpulan pengguna Cognito solusi yang ada menggunakan konsol Amazon Cognito.

Untuk petunjuk langkah demi langkah, lihat Men ambahkan login kumpulan pengguna melalui pihak ketiga di Panduan Pengembang Amazon Cognito.

Langkah 3: Konfigurasikan pemetaan atribut

Konfigurasikan pemetaan atribut antara klaim penyedia identitas Anda dan atribut kumpulan pengguna Cognito. Paling tidak, petakan klaim email pengguna dari penyedia eksternal ke email atribut Cognito. Pertimbangkan juga pemetaan name atau nickname jika penyedia identitas Anda menyediakannya.

Untuk petunjuk, lihat Menentukan pemetaan atribut penyedia identitas untuk kumpulan pengguna Anda di Panduan Pengembang Amazon Cognito.

Langkah 4: Aktifkan penyedia identitas pada klien aplikasi

Di konsol Amazon Cognito, temukan klien aplikasi yang dibuat oleh solusi dan aktifkan penyedia identitas baru Anda di bawah pengaturan UI yang dihosting.

Untuk petunjuk, lihat Mengon figurasi klien aplikasi kumpulan pengguna di Panduan Pengembang Amazon Cognito.

Menonaktifkan atau menghapus pengguna Cognito default

Setelah mengonfigurasi federasi, Anda mungkin ingin menonaktifkan atau menghapus pengguna default yang dibuat selama penerapan tumpukan. Ini opsional — pengguna default terus bekerja bersama login federasi.

Untuk menonaktifkan pengguna, navigasikan ke kumpulan pengguna Cognito solusi di konsol Amazon Cognito, pilih tab Pengguna, pilih pengguna, dan pilih Non aktifkan akses pengguna. Untuk menghapus pengguna, Anda harus menonaktifkannya terlebih dahulu, lalu pilih H apus pengguna. Menonaktifkan pengguna mencabut token mereka dan mencegah masuk sambil mempertahankan akun; menghapus secara permanen menghapusnya.

Untuk detail selengkapnya, lihat M engelola dan mencari akun pengguna di Panduan Pengembang Amazon Cognito.

Penyebaran regional

Solusi ini menggunakan Amazon Cognito yang hanya tersedia di Wilayah AWS tertentu. Oleh karena itu, Anda harus menerapkan solusi ini di Wilayah tempat Amazon Cognito tersedia. Untuk ketersediaan layanan terbaru menurut Wilayah, lihat Daftar Layanan Regional AWS.