Cara Amazon ECS Mengelola Sumber Daya CPU dan Memori

Pada 19 Agustus 2019, kami meluncurkan fitur Amazon Elastic Container Service (Amazon ECS) baru yang memungkinkan kontainer untuk mengkonfigurasi ruang swap yang tersedia di Linux. Kami ingin mengambil kesempatan ini untuk mundur dan berbicara lebih holistik bagaimana manajemen sumber daya ECS bekerja (termasuk perilaku fitur baru ini telah diperkenalkan). Secara khusus, kami ingin mengklarifikasi bagaimana CPU dan memory dapat dipesan dimuka dan dikonsumsi oleh container Linux yang dikerahkan oleh ECS dengan beberapa jenis peluncuran: EC2 dan AWS Fargate (Fargate). Container Windows, yang juga didukung oleh ECS, berada di luar lingkup tulisan ini.

Konsep-Konsep ECS

Di ECS, unit dasar penyebaran adalah task, sebuah konsep yang mencontohkan satu atau lebih container. Ini berarti bahwa ECS API beroperasi pada tingkat task, bukan pada tingkat individu suatu container. Di ECS, Anda tidak dapat menjalankan sebuah container: sebaliknya, Anda justru menjalankan task, yang, secara bergantian, menjalankan container-container Anda. Task berisi satu atau lebih container.

Diagram di bawah ini menguraikan hubungan antara container dan task:

Dokumentasi ECS resmi memiliki informasi lebih lanjut tentang konsep-konsep ini.

Tujuan dari posting blog ini adalah untuk membahas pilihan apa yang Anda miliki (dan aturan apa yang harus mereka atasi) dalam hal manajemen sumber daya. Secara khusus, kita akan membahas bagaimana CPU dan sumber daya Memory didefinisikan pada tingkat task dan tingkat container berhubungan dengan sumber daya CPU dan memori yang tersedia di EC2 dan Fargate.

Pengantar Launch Type ECS Tersedia

ECS memiliki dua model yang berbeda untuk menjalankan container Anda, yang kita sebut launch type (yaitu jenis peluncuran). Yang pertama adalah untuk menjalankan task ECS di atas EC2 yang Anda miliki, kelola, dan bayar, tetapi Anda tidak perlu membayar per task. Yang kedua adalah dengan menggunakan Fargate, lingkungan serverless untuk container yang sepenuhnya dikelola oleh AWS. Ini memungkinkan pelanggan untuk menjalankan container tanpa harus mengelola infrastruktur yang mendasarinya. Dengan Fargate, pelanggan hanya akan dikenakan biaya untuk task yang mereka jalankan.

Diagram ini menguraikan secara visual apa yang terjadi ketika Anda meluncurkan task dengan launch type EC2:

Diagram ini menguraikan secara visual apa yang terjadi ketika Anda meluncurkan task dengan launch type Fargate:

Salah satu poin penting untuk memperhitungkan dalam konteks tulisan blog ini adalah bahwa “setiap task Fargate memiliki batas isolasi sendiri dan tidak berbagi sumber daya dengan dengan task lain, sumber daya tersebut adalah kernel yang mendasarinya, sumber daya CPU, memori, atau elastic network interface .” Ini berarti bahwa, sementara dengan launch type EC2 Anda dapat memiliki lebih dari satu task yang berjalan di atas kernel Linux yang sama dan berbagi sumber daya kernel satu sama lain, lain halnya dengan launch type Fargate setiap task memiliki kernel Linux khusus, yang tidak berbagi CPU, memori, atau Elastic Network Interface (ENI) dengan task lainnya. Sementara perbandingan holistik antara dua launch type yang berbeda berada di luar lingkup tulisan blog ini, menggunakan salah satu dari launch type ini memiliki sejumlah konsekuensi dalam bagaimana sumber daya CPU dan memori yang dapat dipesan pada saat awal dan dikonsumsi oleh container.

Latar belakang umum pada container dan bagaimana mereka mengakses CPU dan memori

Sebelum kita bahas secrara detail bagaimana ECS bekerja, mari kita menghabiskan beberapa waktu pengaturan panggung mengenai apa yang diharapkan dari perilaku container default pada umumnya.

Ada dua aturan umum praktis dengan container:

1. kecuali dibatasi, container yang akan dimulai pada host tertentu (sistem operasi) mendapat akses ke semua CPU dan kapasitas memori yang tersedia pada host itu.
2. kecuali jika tidak dilindungi dan dijamin, semua container yang berjalan pada host tertentu (sistem operasi) berbagi CPU, memori, dan sumber daya lainnya dengan cara yang sama bahwa proses lain yang berjalan pada host yang berbagi sumber daya tersebut.

Perilaku ini tidak unik untuk container, tetapi agak normal dan diharapkan untuk proses Linux pada umumnya. Perlu ditekankan bahwa, secara default, container berperilaku seperti proses Linux lainnya sehubungan dengan akses ke sumber daya seperti CPU dan memori.

Pilihan manajemen sumber daya ECS

Kita akan belajar di seluruh tulisan blog ini bahwa ECS menyediakan mekanisme untuk kedua membatasi berapa banyak kapasitas…

1. … task (dan pada gilirannya, semua container) berhak untuk mengkonsumsi pada host tertentu serta cadangan berapa banyak kapasitas task (dan pada gilirannya, semua container) diharapkan tersedia.
2. … sebuah container berhak untuk mengkonsumsi dalam task serta cadangan berapa banyak kapasitas container diharapkan tersedia.

Bagi Anda yang baru untuk ECS, di bawah ini adalah contoh dari task definition yang mencakup container tunggal. Anda dapat memikirkan task definition sebagai konsep ECS yang mendefinisikan container yang Anda berniat untuk menjalankan. Anda akan melihat dalam dokumentasi register-task-definition bahwa pilihan definisi task kaya dan luas. Dalam contoh singkat ini kita telah berfokus pada aspek manajemen sumber daya bagaimana Anda dapat mengkonfigurasi task dan container dan dihapus banyak pilihan lain. Anda juga akan melihat bahwa contoh ini hanya kompatibel dengan launch type EC2: ini karena beberapa konfigurasi CPU dan memori (yaitu MaxSwap dan swappiness) tidak didukung dengan launch type Fargate.

{
    "family": "mywebsite", 
    "networkMode": "awsvpc",
    "cpu": "256", 
    "memory": "512", 
    "requiresCompatibilities": ["EC2"],  
    "containerDefinitions": [
        {
            "name": "mywebsite-nginx", 
            "image": "nginx:latest", 
            "essential": true,
            "cpu": 128,
            "memory": 256,
            "memoryReservation": 128,
            "linuxParameters": {
                "maxSwap": 512,
                "swappiness": 50
            }
        } 
    ]
}

Anda dapat mendaftarkan task ini menjalankan perintah berikut (di mana mywebsite.json adalah file dalam direktori lokal yang berisi JSON di atas):

aws ecs register-task-definition --cli-input-json file://mywebsite.json

Struktur JSON di atas melakukan hal berikut:

1. ini mendefinisikan sebuah task ECS disebut mywebsite yang memiliki sejumlah CPU dan kapasitas memori yang terkait dengannya (cadangan 256 unit CPU dan 512MB memori pada instance EC2 itu dimulai pada). Jika ini harus dimulai dengan launch type Fargate nilai-nilai ini akan digunakan untuk menentukan instance Linux berukuran benar pada saat run-tugas.
2. mendefinisikan container tunggal dalam task yang dibernama mywebsite-nginx. Container ini memiliki 128 unit CPU dan 256 MB memori yang terkait dengannya dengan reservasi 128-MB. Selain itu, fitur baru yang kami umumkan menambahkan konfigurasi tambahan yang memungkinkan kami untuk mengkonfigurasi sikap agresif sedang (average agressiveness) dengan ukuran swap maks 512 MB (swappiness menerima integer antara 0 dan 100).

Konfigurasi ini hanya untuk tujuan demonstrasi dan nilai-nilai yang telah kita gunakan tidak memiliki arti tertentu selain menggambarkan pilihan apa yang Anda miliki. Di sisa posting blog ini, kami akan menjelaskan bagaimana menggunakan opsi dan parameter ini dan apa yang terjadi di bawahnya ketika (jika) Anda menggunakannya pada task dan/atau pada tingkat container.

Untuk menjelaskan berbagai pilihan yang Anda miliki saat menggunakan tombol-tombol ini, kami akan menguraikan dua skenario:

1. Tingkat maksimum fleksibilitas: Anda dapat menggunakan pendekatan ini ketika tujuan Anda adalah untuk mengkonfigurasi jumlah paling sedikit pilihan, tingkat tertinggi sumber daya over-komitmen dan paling dekat dengan pengalaman container default dijelaskan di atas. Anda mungkin ingin mempertimbangkan pendekatan ini untuk lingkungan test/dev di mana Anda mungkin ingin mengoptimalkan untuk biaya bukan kinerja.
   Tingkat kontrol maksimum: Anda dapat menggunakan pendekatan ini ketika tujuan Anda adalah untuk memiliki tingkat tertinggi prediktabilitas kinerja dan tingkat fine-tuning tertinggi dalam hal sumber daya capping dan reservasi baik pada tingkat task dan container. Anda mungkin ingin mempertimbangkan pendekatan ini untuk lingkungan produksi yang sangat sensitif di mana Anda mungkin ingin mengoptimalkan untuk kinerja bukan biaya.

Kasus penggunaan spesifik Anda mungkin jatuh langsung ke salah satu dari dua ekstrem ini atau bisa mendarat di tengah. Misalnya, Anda mungkin ingin memberikan sejumlah komitmen berlebihan untuk beban kerja produksi untuk dapat mengatasi puncak mendadak dan pendek dalam permintaan sumber daya.

Posting blog ini bermaksud untuk memberi Anda semua dasar-dasar untuk men-tweak task dan konfigurasi container untuk kasus penggunaan spesifik Anda.

Tingkat fleksibilitas maksimum

Gambar di bawah ini dimaksudkan untuk memanggil apa tingkat maksimum fleksibilitas dan tingkat minimal konfigurasi sumber daya untuk menyebarkan task–task (dan container terkait).

Pendekatan fleksibel yang paling mutlak adalah dengan menggunakan task-task yang tidak memiliki konfigurasi sumber daya CPU dan memori tertentu.

Dalam hal ini, task-task ini:

1. hanya dapat digunakan pada instance container EC2 (Fargate memerlukan konfigurasi sumber daya CPU dan memori tertentu untuk task)
2. harus memiliki container yang memiliki setidaknya baik batas memori lunak atau keras
3. tidak perlu memiliki container konfigurasi sumber daya CPU (container bersaing untuk host penuh daya CPU)

Catatan: ketika Anda tidak menentukan unit CPU untuk sebuah container, ECS secara intrinsik memberlakukan dua Linux CPU share untuk cgroup (minimum yang diperbolehkan). Harap dicatat bahwa “unit CPU” hanyalah sebuah konstruk ECS dan tidak ada di dunia kernel Linux. Cara unit CPU ditegakkan pada host Linux (melalui CPU Linux share dan konfigurasi cgroup) adalah detail implementasi kita jelajahi secara detail. Juga, perlu diingat bahwa Linux tidak peduli berapa banyak CPU yang Anda miliki atau berapa banyak CPU share absolut yang Anda tentukan. Linux hanya menggunakan jumlah semua CPU share didefinisikan di lokasi tertentu dalam hirarki sebagai angka sebuatan ketika menentukan sebagian kecil dari sumber daya CPU yang tersedia untuk cgroup tertentu selama pertikaian CPU.

Pendekatan yang sedikit kurang fleksibel adalah dengan menggunakan task-task yang memiliki CPU tertentu dan konfigurasi sumber daya memori. Sementara ini mengasumsikan beberapa tugas konfigurasi sumber daya, memungkinkan untuk pengalaman bebas konfigurasi yang lebih besar di tingkat container.

Sebenarnya, dalam kasus ini, tugas ini:

1. dapat digunakan pada instance container EC2 atau Fargate
2. dapat memiliki container yang tidak memiliki memori (atau CPU dalam hal ini) batas dikonfigurasi sama sekali

Ini adalah representasi grafis dari opsi konfigurasi minimal:

Gambaran ini dimaksudkan untuk menggambarkan tingkat maksimum penggunaan sumber daya fleksibilitas (atau tingkat minimum konfigurasi jika Anda akan) bahwa pengguna ECS harus mempertimbangkan.

Alasan penyebaran Fargate memerlukan konfiurasi task CPU dan memori adalah karena itu adalah konsep dasar penagihan untuk Fargate (Anda membayar untuk kapasitas compute yang diperlukan untuk menjalankan task daripada membayar untuk instance EC2). Seperti yang kita catat di atas, setiap task memiliki kernel Linux khusus sehingga ukuran task juga digunakan untuk mengalokasikan sumber daya fisik yang tepat.

Pendekatan yang paling fleksibel (tidak ada ukuran task) memiliki kelemahan bahwa pengguna kehilangan kontrol atas distribusi sumber daya (mengingat semua tugas dan container bersaing untuk sumber daya yang sama pada host pada instance container EC2). Keuntungan dari pendekatan ini namun adalah bahwa pengguna dapat menerapkan strategi over-subscription (pada instance container EC2) yang dapat menghasilkan penghematan yang baik dalam skenario tertentu.

Pendekatan lain (explicit task size atau task ukuran tetap) masih agak fleksibel karena memerlukan tidak ada parameter tunggal pada tingkat container untuk dikonfigurasi. Namun, sementara container masih dapat “over-subscribe” sumber daya dalam task, task-task itu sendiri tidak bisa “over-subscribe” sumber daya pada host. Lebih lanjut tentang ini di bagian berikutnya.

Tingkat maksimum CONTROL

ECS juga dapat memberikan lebih banyak kontrol tentang bagaimana sumber daya compute (seperti CPU dan Memory) dialokasikan untuk task-task dan/atau container.

Pada bagian ini kita akan mengeksplorasi bagaimana Anda dapat menyesuaikan setelan sumber daya ini dan konsekuensi terkait melakukannya. Untuk konsistensi dengan bagian sebelumnya, kita akan membagi ini menjadi beberapa subbagian yang berbeda:

apa yang terjadi ketika Anda tidak menetapkan ukuran task (konfigurasi hanya tersedia untuk launch type EC2)
apa yang terjadi ketika Anda mengatur ukuran task (konfigurasi yang tersedia untuk EC2 dan jenis peluncuran Fargate)

Catatan: sementara Anda dapat mengkonfigurasi ukuran task untuk dimensi tetapi tidak yang lain (misalnya, Anda mengkonfigurasi ukuran memori tetapi tidak ukuran CPU), demi kesederhanaan diskusi di bawah mengasumsikan bahwa baik Anda mengatur keduanya atau tidak sama sekali. Anda dapat dengan mudah mengekstrapolasi apa yang terjadi jika Anda hanya mengatur satu dimensi dengan menggabungkan dua skenario di bawah ini.

1 – Kontainer konfigurasi sumber daya tanpa ukuran task dikonfigurasi

Ini adalah bagaimana ECS telah bekerja secara historis. Sebagai pengingat, konfigurasi ini TIDAK didukung dengan launch type Fargate (yaitu, Anda tidak dapat menggunakan Fargate jika Anda tidak mengkonfigurasi ukuran task). Akibatnya, konfigurasi ini hanya tersedia dengan ECS pada EC2.

Dalam skenario ini, task ini hanya logical boundary tak terbatas dan semua sumber daya terkait adalah tentang konfigurasi container individu (di semua task-task) dan jumlah kapasitas fisik yang tersedia di tingkat instance container EC2.

Seperti yang kita mengisyaratkan pada bagian sebelumnya, container berjalan dalam task tersebut harus memiliki setidaknya baik batas memori lunak (memori untuk sebuah task yang di setel) atau batas memory fisik (memori fisik yang ada di host).

Ketika Anda menetapkan batas memori lunak , Anda pada dasarnya pemesanan kapasitas memori pada host task Anda. Tak usah dikatakan bahwa jumlah memori lunak semua container di semua task-task yang berjalan pada instance EC2 tertentu, tidak dapat melebihi memori fisik yang tersedia untuk instance itu. Karena Anda memesan memori, semua memori yang (terlepas dari penggunaan sebenarnya) harus ada untuk task-task (dan container) untuk dapat memulai. Perhatikan ini hanya memori fisik, bukan swap tambahan yang Anda mungkin telah dikonfigurasi melalui opsi MaxSwap yang baru kami mengumumkan. Sementara fitur baru memungkinkan container untuk swap jika dikonfigurasi dengan benar, itu tidak termasuk akuntansi untuk penggunaan swap dalam fase penjadwalan; swap tidak diperlakukan sebagai sumber daya untuk ECS scheduler.

Catatan: jika Anda berencana untuk menggunakan fitur swap baru pastikan Anda mengaktifkannya pada instance EC2 yang Anda gunakan. AMI yang dipakai dan dioptimalkan untuk ECS tidak memiliki swap diaktifkan secara default. Silakan lihat dokumentasi untuk daftar lengkap pertimbangan untuk menggunakan fitur baru ini.

Ketika Anda mengatur batas memori keras Anda menetapkan batas atas untuk container. Anda pada dasarnya mengatakan bahwa container tidak dapat menggunakan lebih dari jumlah memori. Mengingat Anda tidak memesan memori ini, satu-satunya kendala untuk memulai task adalah bahwa tidak ada container memiliki batas memori keras yang melebihi memori fisik yang tersedia untuk instance EC2. Dengan kata lain, Anda mengatakan “jika Anda akan pernah membutuhkan memori, Anda tidak akan bisa melampaui nilai ini pula.” Salah satu konsekuensi dari ini adalah bahwa, ketika Anda mengkonfigurasi baik batas memori lunak dan keras, jumlah semua batas memori keras dari semua container dari semua task-task mungkin melampaui jumlah memori fisik.

Ini adalah semua pilihan yang Anda miliki dan apa yang terjadi ketika Anda memilih salah satu dari mereka:

1. jika Anda hanya menetapkan soft limit (batas lembut), yang mewakili reservasi dan batas tertinggi diwakili oleh container misalnya total memori
2. jika Anda menetapkan batas lembut dan hard limit (batas keras), batas lembut mewakili reservasi dan batas tertinggi diwakili oleh batas keras yang Anda tetapkan.
3. jika Anda hanya mengatur hard limit, yang mewakili kedua reservasi dan batas tertinggi

Jika container mencoba untuk mengkonsumsi memori antara dua nilai ini (atau antara batas lembut dan kapasitas host jika batas keras tidak diatur), mereka dapat bersaing satu sama lain. Dalam hal ini, apa yang terjadi tergantung pada heuristik yang digunakan oleh pembunuh OOM kernel Linux (Out of Memory). ECS dan Docker keduanya tidak terlibat di sini; itu kernel Linux bereaksi terhadap tekanan memori. Jika sesuatu di atas batas lembut, itu lebih mungkin untuk dibunuh daripada sesuatu di bawah batas lembut, tapi mencari tahu proses mana yang terbunuh membutuhkan mengetahui semua proses lain pada sistem dan apa yang mereka lakukan dengan memori mereka juga. Sekali lagi fitur memori baru yang kami umumkan bisa datang untuk menyelamatkan di sini. Sementara perilaku OOM tidak berubah, sekarang container dapat dikonfigurasi untuk swap ke disk dalam skenario tekanan memori. Hal ini berpotensi dapat meringankan kebutuhan untuk pembunuh OOM untuk menendang di (jika container dikonfigurasi untuk swap).

Untuk sumber daya CPU, mekanismenya sedikit berbeda. Di ECS, CPU dapat dikonfigurasi dengan unit yang mirip dengan bagaimana memori lunak batas kerja. Sebagai dasar ECS menganggap setiap vCPU tersedia untuk instance container EC2 sebagai 1024 unit. Yaitu, host EC2 yang memiliki 8 VCPU memiliki 8×1024 = 8192 unit yang tersedia. Ketika Anda menetapkan unit CPU untuk container, Anda pada dasarnya memesan bahwa banyak kapasitas pada host. Tak usah dikatakan bahwa jumlah semua unit CPU di semua container di semua task-task yang berjalan pada instance EC2 tidak dapat melebihi jumlah total unit yang tersedia untuk host tersebut (8192 dalam contoh di atas). Seperti yang telah kita sebutkan di atas, unit CPU ini, dalam bahasa ECS, bisa diterapkan sebagai Linux CPU share untuk menegakkan perilaku. Dengan kata lain, “unit” adalah nomenklatur yang digunakan ECS untuk mengkonfigurasi perilaku, sementara “share” adalah teknologi yang digunakan kernel Linux untuk menerapkannya. Bagi sebagian besar pengguna ECS ini adalah detail yang seharusnya tidak mereka pedulikan namun penting untuk memperjelasnya.

Setelah itu, ada beberapa hal yang perlu dipertimbangkan di sini:

1. jika container tidak menggunakan unit CPU mereka dialokasikan, container lain dapat menggunakan kapasitas tersebut. Ketika kapasitas tidak digunakan, setiap container dapat meledak untuk menggunakan kapasitas cadangan tersebut. CPU berbagi mengontrol jumlah kapasitas CPU yang tersedia ketika ada CPU pertengkaran; yaitu, beberapa container mencoba untuk menggunakan CPU pada waktu yang sama.
2. jika ada kapasitas cadangan pada host (karena jumlah semua unit CPU di semua container di semua task-task kurang dari kapasitas yang tersedia pada host) kelebihan kapasitas pada host kembali dipartisi secara proporsional untuk semua container jika/ketika mereka membutuhkannya

Sebagai contoh, bayangkan Anda menjalankan task pada host dengan 8192 unit CPU. task ini memiliki dua container: Container A (yang Anda tugaskan 512 unit) dan ContainerB (yang Anda tugaskan 1024 unit). Ketika kedua container berjalan dengan uap penuh dan mengkonsumsi kapasitas cadangan mereka, mereka dapat mengakses daya CPU yang tidak terikat (8192-512-1024=6656 unit CPU). Cara bahwa kapasitas ini dibagi sebanding dengan unit ditugaskan untuk container (yang dapat Anda anggap sebagai bertindak sebagai beban): khususnya Container B bisa mendapatkan akses ke dua kali lebih banyak unit CPU (2/3 dari 6656= 4437 unit CPU) vs Container A (yang bisa mendapatkan akses ke 1/3 dari 6656 = 2219 unit CPU).

2 – Kontainer konfigurasi sumber daya dengan ukuran task yang dikonfigurasi secara eksplisit

Konfigurasi ini didukung dengan launch type EC2 dan launch type Fargate.

Dalam skenario khusus ini, task sendiri menjadi batas yang keras di sekitar container yang dapat berjalan di dalam task itu.

Mayoritas konsep yang kami gariskan di atas masih sah tetapi dalam hal ini ukuran task menggantikan secara virtual jumlah fisik kapasitas yang tersedia untuk host. Dengan kata lain, container (berjalan dalam task seperti itu) hanya dapat menggunakan kapasitas yang ditentukan oleh ukuran task, yang berarti mereka melihat task sebagai batas-batas mereka. Untuk menjadi benar, container masih melihat total kapasitas karena mereka dapat membaca/proc, tetapi bahwa total kapasitas tidak dapat digunakan untuk mereka.

Dari perspektif manajemen memori, perbedaan penting adalah bahwa container tidak perlu memiliki jenis batas memori dikonfigurasi. Dalam kasus ini, mereka semua bersaing untuk jumlah memori yang tersedia di tingkat task. Hal ini kecuali jika Anda menyetel sumber daya memori pada tingkat container, yang mungkin sesuatu yang Anda ingin atau perlu lakukan dalam skenario di mana Anda perlu kontrol penuh dari sumber daya semua jalan ke container tunggal. Ini pasti bisa dengan ECS.

Jika Anda mengkonfigurasi batas pada tingkat container, jumlah soft limit memori semua container yang berjalan di dalam task khusus ini tidak dapat melebihi ukuran memori task. Demikian pula, tidak ada container dapat memiliki hard limit memori yang melebihi ukuran memori task (meskipun jumlah semua hard limit dapat melebihi itu).

Ini adalah semua pilihan yang Anda miliki dan apa yang terjadi ketika Anda memilih salah satu dari mereka:

1. jika Anda hanya menetapkan soft limit, yang mewakili reservasi dan batas tertinggi diwakili oleh ukuran memori task
2. jika Anda menetapkan soft limit dan hard limit, batas lembut mewakili reservasi dan batas tertinggi diwakili oleh batas keras yang Anda tetapkan.
3. jika Anda hanya mengatur hard limit, yang mewakili kedua reservasi dan batas tertinggi

Bahkan dari perspektif manajemen sumber daya CPU algoritma mirip dengan apa yang telah kita bahas di bagian sebelumnya dengan perbedaan penting bahwa sekarang total anggaran unit CPU tidak lagi host EC2 secara keseluruhan melainkan ukuran task Anda dikonfigurasi. Jadi jika Anda mengkonfigurasi ukuran task untuk memiliki 1024 unit CPU, jumlah unit CPU dari semua container Anda berjalan dalam task yang tidak dapat melebihi 1024 dan kapasitas non dianggarkan antara 1024 didistribusikan kembali di semua container proporsional dengan anggaran mereka sudah memiliki.

Hal ini juga penting untuk memahami bahwa sementara ECS mengacu pada unit CPU sebagai jumlah kapasitas CPU yang Anda tetapkan untuk task-task serta container, cara mereka ditegakkan berbeda. Unit CPU yang ditugaskan untuk task-task ditegakkan oleh kernel Linux sebagai plafon CPU keras untuk task (sebenarnya container yang berjalan dalam task ini tidak dapat melebihi kuota yang ditetapkan untuk task). Di sisi lain, unit CPU ditugaskan untuk container diimplementasikan menggunakan Linux CPU share dalam task (yang lebih merupakan mekanisme tertimbang untuk menentukan prioritas akses CPU).

Catatan: pada saat penulisan ini, alokasi unit CPU pada tingkat task tidak dapat melebihi 10 VCPU (atau 10240 unit CPU). Ini berarti bahwa jika Anda ingin container untuk menggunakan lebih dari 10 VCPU Anda tidak harus menetapkan ukuran task (CPU).

Memahami semua pilihan

Tabel ini merupakan upaya untuk meringkas karakteristik dan perilaku kedua task-task dan container dalam dua skenario yang telah kami uraikan di atas: task-task dengan ukuran tertentu tidak ditetapkan dan task-task dengan set ukuran tertentu.

Aplikasi penjadwalan dan kinerja

Sejauh ini kita telah doubled-down pada menjelaskan konsekuensi teknis dari tweaking setelan dari berbagai pilihan yang tersedia. Namun, kita tidak boleh melupakan fakta bahwa segala sesuatu yang kita lakukan adalah untuk memberikan pengalaman kinerja aplikasi terbaik dengan biaya yang tepat untuk organisasi. Kinerja (Performance) dan biaya (Cost) adalah dua pilar Well-Architected Framework kami.

Aplikasi memerlukan sumber daya CPU dan memori untuk menjalankan dan segala sesuatu yang telah kita bahas sejauh ini menjelaskan cara untuk memenuhi sumber daya tersebut untuk aplikasi berkontainer yang berjalan di ECS. Parameter yang telah kita bahas juga memberikan ECS sarana yang dapat membuat keputusan penjadwalan.

Bila menggunakan launch type Fargate, mekanik penjadwalan ini diminimalkan dan disederhanakan karena setiap task dijadwalkan pada kernel Linux khusus yang memiliki (setidaknya) kapasitas yang sama dikonfigurasi untuk task ECS. Juga, mengingat bahwa kemampuan memori swap tidak tersedia dengan launch type Fargate, akhirnya aplikasi yang berjalan di dalam task Fargate memiliki CPU dan kapasitas memori tepat seperti yang didefinisikan pada tingkat task.

Ketika menggunakan launch type EC2, mekanik penjadwalan dijalankan dalam kepenuhannya oleh ECS dan cara terbaik untuk menggambarkannya adalah dengan membayangkan bahwa proses ini mirip dengan cara Tetris bekerja: sejumlah task-task masuk ke corong penjadwalan ECS dan, berdasarkan karakteristik mereka, mereka dijadwalkan untuk berjalan pada instance EC2 sesuai dengan “slot” (CPU dan memori) mereka telah tersedia untuk tanah ini “batu bata.”

Secara khusus, bentuk dan ukuran setiap batu bata ditentukan oleh pemesanan yang terkait dengan task dan/atau container di dalamnya. Jika Anda berpikir tentang hal ini, konsep pemesanan secara efektif mengatakan ECS bahwa “task khusus ini membutuhkan banyak memori dan ini banyak CPU” dan ECS harus menemukan kapasitas cadangan cukup pada satu instance EC2 di cluster ECS untuk dapat memenuhi kebutuhan. Seperti yang telah kita diuraikan dalam sisa posting di atas, ukuran CPU task, ukuran memori task dan memori container soft limit semua berkontribusi untuk membentuk bentuk dan ukuran keseluruhan dari “batu bata.” Hard limit memori dan ukuran CPU container tidak berperan dalam membentuk dan ukuran batu bata. Mereka hanya baik mengekspresikan batas tertinggi atau prioritas ketika ada pertentangan tetapi tidak menetapkan persyaratan sumber daya yang kuat yang harus dipenuhi (seperti dilakukan oleh pemesanan).

Pada akhirnya, setelan-setelan ini ditambah fitur swapping yang baru-baru ini diumumkan memungkinkan pengguna untuk membentuk batu bata mereka (atau task–task) dengan cara yang dapat melayani persyaratan aplikasi mereka dengan lebih baik:

1. Jika Anda perlu aplikasi Anda untuk memiliki kinerja akhir dan diprediksi menggunakan tombol-tombol yang tersedia untuk menentukan bentuk yang tepat dan ukuran untuk task Anda dan memiliki ECS scheduler mencari tahu instance EC2 dapat menampung batu bata itu dengan bentuk dan ukuran tertentu. Kemungkinannya adalah bahwa task tidak dapat dijadwalkan jika kapasitas yang cukup tidak ditemukan oleh scheduler (ini dapat memicu peristiwa autoscale, jika dikonfigurasi dengan benar).
2. Jika Anda memerlukan aplikasi Anda untuk dijadwalkan, Anda tidak khawatir dengan kinerja yang dapat diprediksi atau Anda mencoba mengoptimalkan biaya, kemudian cobalah membuat bentuk dan ukuran bata Anda sekecil mungkin dan bekerja dengan pembatasan dan shares untuk memprioritaskan mereka. Apa yang Anda lakukan secara efektif di sini adalah over-subscribe sumber daya EC2 dengan cara yang membuatnya mudah bagi ECS untuk mengalokasikan batu bata ini pada slot contoh EC2. Kemungkinannya adalah bahwa task–task ini mungkin bersaing untuk sumber daya pada host EC2 meskipun, hanya karena Anda memesan kurang dari apa aplikasi akan benar-benar menggunakan dan meminta. Dalam kasus ini, ada peningkatan kemungkinan bahwa aplikasi Anda mungkin mengalami kinerja yang buruk atau mungkin terbunuh oleh kernel EC2 karena peristiwa Out of Memory. Jika hal ini terjadi, fitur swapping dapat mengurangi peristiwa penting ini dengan menggunakan disk sebagai area memori. Pada titik ini, aplikasi Anda mungkin semakin memperlambat tetapi tidak dibunuh jika ada cukup memori virtual yang tersedia.

Dalam analisis akhir, semua opsi konfigurasi ini memungkinkan Anda untuk melakukan adalah untuk mengoptimalkan penyebaran aplikasi Anda baik untuk kinerja atau untuk biaya (atau campuran dari mereka). pelanggan ECS menggunakan launch type EC2 mempertahankan tanggung jawab untuk menemukan strategi penyebaran yang lebih sesuai dengan kebutuhan organisasi mereka.

Kesimpulan

Dalam posting tulisan ini, kami telah mengambil kesempatan untuk meringkas bagaimana manajemen sumber daya (khusus untuk CPU dan memori) bekerja dengan ECS dengan semua jenis peluncuran yang tersedia sampai saat ini (EC2 dan Fargate). Pengenalan fitur baru dalam konteks ini adalah bukti investasi kami di ECS dan komitmen kepada pelanggan yang kami dengarkan.

Kami telah mengeksplorasi beberapa dasar-dasar ECS, kami menguraikan beberapa konsep dasar bagaimana container menggunakan sumber daya CPU dan memori pada host Linux dan kemudian kami mulai untuk memperbesar ke dalam pendekatan spesifik di ECS untuk mengkonfigurasi sumber daya ini.

Kami telah memperkenalkan beberapa skenario konfigurasi yang berbeda, yang lebih berorientasi pada kasus uji dan penggunaan pengembangan (di mana fleksibilitas dan komitmen berlebihan dari sumber daya penting) dan satu lagi yang lebih ditargetkan untuk beban kerja produksi (di mana kinerja dan prediktabilitas adalah aspek utama) .

Di masing-masing dua skenario ini, mengingat banyak pilihan konfigurasi dan alternatif, kami telah berfokus pada konfigurasi task-task dan kemudian diperbesar menjadi pilihan konfigurasi container. Pada keseluruhan, cara presentasi dokumen ini adalah sedemikian rupa sehingga bisa memberikan sebagian besar informasi tingkat rendah bagi pengguna untuk menerapkan task-task ad hoc yang tepat dan strategi konfigurasi container untuk kasus penggunaan spesifik dan kebutuhan masing-masing.

Makna teknis utama adalah sebagai berikut

Penyebaran task-task ECS di atas contoh EC2 memberikan tingkat fleksibilitas terbesar dalam bahwa:

• Anda dapat mendeploy task-task dengan ukuran tertentu serta task-task tanpa ukuran tertentu (atau campuran dari mereka)
• Anda dapat over-commit sumber daya karena container di task-task yang berbeda dapat berbagi sumber daya fisik yang sama
• container dalam task apapun (yang memiliki ukuran yang ditetapkan dan karenanya batas plafon) tidak dapat meledak penggunaan kapasitas di luar plafon task ini
• container tanpa batas eksplisit dalam task apapun tanpa ukuran yang disetel (dan karenanya tanpa batas langit-langit) dapat meledak penggunaan kapasitas mencuri sumber daya dari task-task lain. Hal ini berlaku bahkan jika task-task lain memiliki set ukuran, dengan asumsi tugas-tugas ini tidak memanfaatkan kapasitas yang
• Anda dapat mendeploy task-task yang sangat kecil (yang dapat meledak) baik tanpa ukuran atau dengan ukuran yang sangat kecil (periksa link ini untuk informasi tambahan tentang cara ukuran task)

Penyebaran ECS task-task di atas Fargate memberikan sedikit kurang fleksibilitas karena:

• Anda menyebarkan ke task dengan ukuran tertentu (yang memetakan 1:1 instance EC2 kapasitas tersebut)
• Anda tidak dapat over-commit sumber daya di berbagai task-task karena mereka memiliki set ukuran tertentu dan berjalan pada kernel Linux khusus (namun Anda masih dapat over-commit sumber daya di dalam task di antara container)
• Anda tidak dapat membuat task-task yang lebih kecil dari 1/4 dari vCPU dan 512 MB memori

Tak usah dikatakan bahwa proposisi nilai Fargate berjalan jauh melampaui pilihan manajemen sumber daya belaka. Fargate adalah lingkungan serverless untuk container yang memungkinkan pelanggan untuk fokus pada kebutuhan bisnis daripada menginvestasikan waktu untuk bekerja pada pengangkatan berat yang tidak berdiferensiasi untuk mengelola kapasitas compute. Selain ini menggunakan Fargate memungkinkan Anda untuk mendedikasikan kernel Linux untuk task Anda, yang menimbulkan bar postur keamanan Anda.

Jika Anda tertarik untuk mengimplementasikan Amazon Elastic Container Service dalam aplikasi Anda, Anda dapat menghubungi tim kami.

Artikel ini diterjemahkan dari artikel asli berjudul How Amazon ECS manages CPU and memory resources yang ditulis oleh Massimo Re Ferre, Principal Technologist di AWS dan Samuel Karp, Senior Software Development Engineer di AWS.