Strategi penjadwalan Pengontrol penyebaran Terminologi penyebaran

Pengontrol dan strategi penyebaran layanan Amazon ECS

Sebelum Anda menerapkan layanan Anda, tentukan opsi untuk menyebarkannya, dan fitur yang digunakan layanan.

Strategi penjadwalan

Ada dua strategi penjadwal layanan yang tersedia:

REPLICAStrategi penjadwalan replika menempatkan dan mempertahankan jumlah tugas yang diinginkan di seluruh cluster Anda. Secara default tugas tersebar di seluruh Availability Zone. Anda dapat menggunakan strategi penempatan tugas dan kendala untuk menyesuaikan keputusan penempatan tugas. Untuk informasi selengkapnya, lihat Strategi penjadwalan replika.
DAEMON—Strategi penjadwalan daemon menerapkan tepat satu tugas pada setiap instance kontainer aktif yang memenuhi semua batasan penempatan tugas yang Anda tentukan di cluster Anda. Saat menggunakan strategi ini, tidak perlu menentukan jumlah tugas yang diinginkan, strategi penempatan tugas, atau menggunakan kebijakan Auto Scaling Layanan. Untuk informasi selengkapnya, lihat Strategi penjadwalan daemon.

catatan
Tugas Fargate tidak mendukung strategi pen DAEMON jadwalan.

Strategi penjadwalan replika

Strategi penjadwalan replika menempatkan dan mempertahankan jumlah tugas yang diinginkan di klaster Anda.

Untuk layanan yang menjalankan tugas di Fargate, saat penjadwal layanan meluncurkan tugas baru atau berhenti menjalankan tugas, penjadwal layanan menggunakan upaya terbaik untuk menjaga keseimbangan di seluruh Zona Ketersediaan. Anda tidak perlu menentukan strategi atau batasan penempatan tugas.

Saat membuat layanan yang menjalankan tugas pada instans EC2, Anda dapat secara opsional menentukan strategi dan batasan penempatan tugas untuk menyesuaikan keputusan penempatan tugas. Jika tidak ada strategi atau batasan penempatan tugas yang ditentukan, maka secara default penjadwal layanan menyebarkan tugas di seluruh Zona Ketersediaan. Penjadwal layanan menggunakan logika berikut:

Menentukan instance kontainer mana di cluster Anda yang dapat mendukung definisi tugas layanan Anda (misalnya, CPU, memori, port, dan atribut instance kontainer yang diperlukan).
Menentukan instance kontainer mana yang memenuhi batasan penempatan apa pun yang ditentukan untuk layanan.
Bila Anda memiliki layanan replika yang bergantung pada layanan daemon (misalnya, tugas router log daemon yang perlu dijalankan sebelum tugas dapat menggunakan logging), buat batasan penempatan tugas yang memastikan bahwa tugas layanan daemon ditempatkan pada instance EC2 sebelum tugas layanan replika. Untuk informasi selengkapnya, lihat Contoh batasan penempatan tugas Amazon ECS.
Ketika ada strategi penempatan yang ditentukan, gunakan strategi itu untuk memilih instance dari kandidat yang tersisa.
Jika tidak ada strategi penempatan yang ditentukan, gunakan logika berikut untuk menyeimbangkan tugas di seluruh Zona Ketersediaan di cluster Anda:
- Mengurutkan instance kontainer yang valid. Memberikan prioritas pada instans yang memiliki jumlah tugas yang berjalan paling sedikit untuk layanan ini di Zona Ketersediaan masing-masing. Misalnya, jika zona A memiliki satu tugas layanan berjalan, sedangkan zona B dan C masing-masing tidak memliki tugas layanan berjalan, maka instans kontainer yang valid, baik di zona B ataupun C dianggap optimal untuk penempatan.
- Menempatkan tugas layanan baru pada instance kontainer yang valid di Zona Ketersediaan optimal berdasarkan langkah sebelumnya. Mendukung instance kontainer dengan jumlah tugas yang berjalan paling sedikit untuk layanan ini.

Kami menyarankan Anda menggunakan fitur penyeimbangan kembali layanan saat menggunakan REPLICA strategi karena ini membantu memastikan ketersediaan tinggi untuk layanan Anda.

Strategi penjadwalan daemon

Strategi penjadwalan daemon men-deploy tepat satu tugas untuk setiap instans kontainer aktif yang memenuhi semua batasan penempatan tugas yang ditentukan di klaster Anda. Penjadwal layanan mengevaluasi batasan penempatan tugas untuk menjalankan tugas, dan menghentikan tugas yang tidak memenuhi batasan penempatan. Saat menggunakan strategi ini, Anda tidak perlu menentukan jumlah tugas yang diinginkan, strategi penempatan tugas, atau menggunakan kebijakan Penskalaan Otomatis Layanan.

Amazon ECS menyimpan sumber daya komputasi instance kontainer termasuk CPU, memori, dan antarmuka jaringan untuk tugas daemon. Saat Anda meluncurkan layanan daemon pada cluster dengan layanan replika lainnya, Amazon ECS memprioritaskan tugas daemon. Ini berarti bahwa tugas daemon adalah tugas pertama yang diluncurkan pada instance dan tugas terakhir yang berhenti setelah semua tugas replika dihentikan. Strategi ini memastikan bahwa sumber daya tidak digunakan oleh tugas replika yang tertunda dan tersedia untuk tugas daemon.

Penjadwal layanan daemon tidak menempatkan tugas apa pun pada instance yang memiliki DRAINING status. Jika instance container beralih ke DRAINING status, tugas daemon di atasnya dihentikan. Penjadwal layanan juga memantau saat instans kontainer baru ditambahkan ke klaster Anda dan menambahkan tugas daemon ke dalamnya.

Saat Anda menentukan konfigurasi penerapan, nilai untuk maximumPercent parameter harus 100 (ditentukan sebagai persentase), yang merupakan nilai default yang digunakan jika tidak disetel. Nilai default untuk minimumHealthyPercent parameter adalah 0 (ditentukan sebagai persentase).

Anda harus memulai ulang layanan saat mengubah batasan penempatan untuk layanan daemon. Amazon ECS secara dinamis memperbarui sumber daya yang dicadangkan pada instans yang memenuhi syarat untuk tugas daemon. Untuk instans yang sudah ada, penjadwal mencoba menempatkan tugas pada instans.

Penerapan baru dimulai ketika ada perubahan pada ukuran tugas atau reservasi sumber daya kontainer dalam definisi tugas. Penerapan baru juga dimulai saat memperbarui layanan atau menetapkan revisi yang berbeda dari definisi tugas. Amazon ECS mengambil reservasi CPU dan memori yang diperbarui untuk daemon, dan kemudian memblokir kapasitas itu untuk tugas daemon.

Jika sumber daya tidak mencukupi untuk salah satu kasus di atas, hal-hal berikut akan terjadi:

Penempatan tugas gagal.
Sebuah CloudWatch peristiwa dihasilkan.
Amazon ECS terus mencoba dan menjadwalkan tugas pada instans dengan menunggu sumber daya tersedia.
Amazon ECS membebaskan instans cadangan yang tidak lagi memenuhi kriteria batasan penempatan dan menghentikan tugas daemon yang sesuai.

Strategi penjadwalan daemon dapat digunakan dalam kasus-kasus berikut:

Menjalankan kontainer aplikasi
Menjalankan kontainer dukungan untuk tugas pencatatan, pemantauan dan pelacakan

Tugas menggunakan Fargate CODE_DEPLOY atau tipe pengontrol EXTERNAL penerapan atau tidak mendukung strategi penjadwalan daemon.

Saat penjadwal layanan berhenti menjalankan tugas, penjadwal layanan mencoba untuk menjaga keseimbangan di seluruh Availability Zone di klaster Anda. Penjadwal menggunakan logika berikut:

Jika strategi penempatan ditentukan, gunakan strategi tersebut untuk memilih tugas mana yang akan diakhiri. Misalnya, jika layanan memiliki strategi penyebaran Zona Ketersediaan yang ditentukan, tugas dipilih yang meninggalkan tugas yang tersisa dengan spread terbaik.
Jika tidak ada strategi penempatan yang ditentukan, gunakan logika berikut untuk menjaga keseimbangan di seluruh Zona Ketersediaan di cluster Anda:
- Urutkan instance kontainer yang valid. Berikan prioritas pada instans yang memiliki jumlah tugas berjalan terbesar untuk layanan ini di Zona Ketersediaan masing-masing. Misalnya, jika zona A memiliki satu tugas layanan yang sedang berjalan dan zona B dan C masing-masing memiliki dua tugas layanan yang sedang berjalan, instance kontainer di zona B atau C dianggap optimal untuk penghentian.
- Hentikan tugas pada instance kontainer di Zona Ketersediaan optimal berdasarkan langkah sebelumnya. Memilih instance kontainer dengan jumlah tugas berjalan terbesar untuk layanan ini.

Pengontrol penyebaran

Pengontrol penerapan adalah mekanisme yang menentukan bagaimana tugas diterapkan untuk layanan Anda. Opsi yang valid adalah:

ECS

Saat Anda membuat layanan yang menggunakan pengontrol ECS penerapan, Anda dapat memilih antara strategi penerapan berikut:
- ROLLING: Saat Anda membuat layanan yang menggunakan strategi penyebaran pembaruan (ROLLING) ber gulir, penjadwal layanan Amazon ECS menggantikan tugas yang sedang berjalan dengan tugas baru. Jumlah tugas yang ditambahkan atau dihapus Amazon ECS dari layanan selama pembaruan bergulir dikendalikan oleh konfigurasi penyebaran layanan.
  
  Penerapan pembaruan bergulir paling cocok untuk skenario berikut:
  - Pembaruan layanan bertahap: Anda perlu memperbarui layanan Anda secara bertahap tanpa membuat seluruh layanan offline sekaligus.
  - Persyaratan sumber daya terbatas: Anda ingin menghindari biaya sumber daya tambahan untuk menjalankan dua lingkungan lengkap secara bersamaan (seperti yang dipersyaratkan oleh blue/green penerapan).
  - Waktu penerapan yang dapat diterima: Aplikasi Anda dapat mentolerir proses penerapan yang lebih lama, karena pembaruan bergulir menggantikan tugas satu per satu.
  - Tidak perlu rollback instan: Layanan Anda dapat mentolerir proses rollback yang memakan waktu beberapa menit, bukan detik.
  - Proses penerapan sederhana: Anda lebih suka pendekatan penerapan langsung tanpa kerumitan mengelola beberapa lingkungan, kelompok target, dan pendengar.
  - Tidak ada persyaratan penyeimbang beban: Layanan Anda tidak menggunakan atau memerlukan penyeimbang beban, Penyeimbang Beban Aplikasi, Penyeimbang Beban Jaringan, atau Koneksi Layanan (yang diperlukan untuk penerapan). blue/green
  - Aplikasi stateful: Aplikasi Anda mempertahankan status yang membuatnya sulit untuk menjalankan dua lingkungan paralel.
  - Sensitivitas biaya: Anda ingin meminimalkan biaya penerapan dengan tidak menjalankan lingkungan duplikat selama penerapan.
  Pembaruan bergulir adalah strategi penerapan default untuk layanan dan memberikan keseimbangan antara keamanan penerapan dan efisiensi sumber daya untuk banyak skenario aplikasi umum.
- BLUE_GREENStrategi blue/green penerapan (BLUE_GREEN) adalah metodologi rilis yang mengurangi waktu henti dan risiko dengan menjalankan dua lingkungan produksi identik yang disebut biru dan hijau. Dengan penerapan Amazon ECS blue/green , Anda dapat memvalidasi revisi layanan baru sebelum mengarahkan lalu lintas produksi ke mereka. Pendekatan ini memberikan cara yang lebih aman untuk menerapkan perubahan dengan kemampuan untuk memutar kembali dengan cepat jika diperlukan.
  
  Penerapan Amazon blue/green ECS paling cocok untuk skenario berikut:
  - Validasi layanan: Ketika Anda perlu memvalidasi revisi layanan baru sebelum mengarahkan lalu lintas produksi ke mereka
  - Nol downtime: Saat layanan Anda memerlukan penerapan zero-downtime
  - Kembalikan instan: Ketika Anda membutuhkan kemampuan untuk memutar kembali dengan cepat jika masalah terdeteksi
  - Persyaratan penyeimbang beban: Saat layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect
- LINEAR: Strategi pener apan linier (LINEAR) secara bertahap menggeser lalu lintas dari lingkungan produksi saat ini ke lingkungan baru dengan persentase kenaikan yang sama selama periode waktu tertentu. Dengan penerapan linier Amazon ECS, Anda dapat mengontrol kecepatan pergeseran lalu lintas dan memvalidasi revisi layanan baru dengan peningkatan jumlah lalu lintas produksi.
  
  Penerapan linear Amazon ECS paling cocok untuk skenario berikut:
  - Validasi bertahap: Ketika Anda ingin secara bertahap memvalidasi versi layanan baru Anda dengan peningkatan lalu lintas
  - Pemantauan kinerja: Saat Anda membutuhkan waktu untuk memantau metrik dan kinerja selama penerapan
  - Minimalisasi risiko: Ketika Anda ingin meminimalkan risiko dengan mengekspos versi baru ke lalu lintas produksi secara bertahap
  - Persyaratan penyeimbang beban: Saat layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect
- CANARY: Strategi penyebaran can ary (CANARY) menggeser persentase kecil lalu lintas ke revisi layanan baru terlebih dahulu, kemudian menggeser lalu lintas yang tersisa sekaligus setelah periode waktu tertentu. Ini memungkinkan Anda untuk menguji versi baru dengan subset pengguna sebelum penerapan penuh.
  
  Penerapan burung kenari Amazon ECS paling cocok untuk skenario berikut:
  - Pengujian fitur: Ketika Anda ingin menguji fitur baru dengan sebagian kecil pengguna sebelum peluncuran penuh
  - Validasi produksi: Ketika Anda perlu memvalidasi kinerja dan fungsionalitas dengan lalu lintas produksi nyata
  - Kontrol radius ledakan: Saat Anda ingin meminimalkan radius ledakan jika masalah ditemukan di versi baru
  - Persyaratan penyeimbang beban: Saat layanan Anda menggunakan Application Load Balancer, Network Load Balancer, atau Service Connect
Eksternal

Gunakan pengontrol penyebaran pihak ketiga.
Blue/green penyebaran (didukung oleh AWS CodeDeploy)

CodeDeploy menginstal versi aplikasi yang diperbarui sebagai set tugas pengganti baru dan mengalihkan lalu lintas produksi dari set tugas aplikasi asli ke set tugas pengganti. Kumpulan tugas asli dihentikan setelah penerapan berhasil. Gunakan pengontrol penerapan ini untuk memverifikasi penerapan layanan baru sebelum mengirim lalu lintas produksi ke layanan tersebut.

Terminologi penyebaran

Istilah-istilah berikut digunakan di seluruh dokumentasi penyebaran Amazon ECS:

Blue-green penyebaran: Strategi penerapan yang menciptakan lingkungan baru (hijau) di samping lingkungan yang ada (biru), kemudian mengalihkan lalu lintas dari biru ke hijau setelah validasi.
Penyebaran Canary: Strategi penerapan yang merutekan sebagian kecil lalu lintas ke versi baru sambil mempertahankan mayoritas pada versi stabil untuk validasi.
Penyebaran linier: Strategi penyebaran yang secara bertahap mengalihkan lalu lintas dari versi lama ke versi baru dengan peningkatan yang sama dari waktu ke waktu.
Penyebaran bergulir: Strategi penerapan yang menggantikan instance versi lama dengan instance versi baru satu per satu.
Set tugas: Kumpulan tugas yang menjalankan definisi tugas yang sama dalam layanan selama penerapan.
Grup target: Pengelompokan logis target yang menerima lalu lintas dari penyeimbang beban selama penerapan.
Pengendali deployment: Metode yang digunakan untuk menerapkan versi baru layanan Anda, seperti Amazon ECS, CodeDeploy, atau pengontrol eksternal.
Rollback: Proses mengembalikan ke versi aplikasi sebelumnya ketika masalah terdeteksi selama penerapan.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Layanan

Deteksi kegagalan deployment Amazon ECS