Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menggunakan penskalaan terkelola di Amazon EMR
**penting**
Kami sangat menyarankan Anda menggunakan rilis EMR Amazon terbaru (Amazon EMR 7.12.0) untuk penskalaan terkelola. Dalam beberapa rilis awal, Anda mungkin mengalami kegagalan aplikasi intermiten atau penundaan dalam penskalaan. Amazon EMR menyelesaikan masalah ini dengan rilis 5.x 5.30.2, 5.31.1, 5.32.1, 5.33.1 dan lebih tinggi, dan dengan rilis 6.x 6.1.1, 6.2.1, 6.3.1 dan lebih tinggi. Untuk informasi selengkapnya Ketersediaan wilayah dan rilis, lihat[Ketersediaan penskalaan terkelola](#emr-managed-scaling-availability).
## Ikhtisar
Dengan Amazon EMR versi 5.30.0 dan yang lebih tinggi (kecuali Amazon EMR 6.0.0), Anda dapat mengaktifkan penskalaan terkelola Amazon EMR. Penskalaan terkelola memungkinkan Anda secara otomatis menambah atau mengurangi jumlah instance atau unit di klaster berdasarkan beban kerja. Amazon EMR terus mengevaluasi metrik klaster untuk membuat keputusan penskalaan yang mengoptimalkan kluster Anda untuk biaya dan kecepatan. Penskalaan terkelola tersedia untuk cluster yang terdiri dari grup instans atau armada instance.
## Ketersediaan penskalaan terkelola
+ Berikut ini Wilayah AWS, penskalaan terkelola Amazon EMR tersedia dengan Amazon EMR 6.14.0 dan yang lebih tinggi:
+ Asia Pasifik (Taipei) (ap-timur-2)
+ Asia Pasifik (Melbourne) (ap-southeast-4)
+ Asia Pasifik (Malaysia) (ap-tenggara 5)
+ Asia Pasifik (Selandia Baru) (ap-tenggara 6)
+ Asia Pasifik (Thailand) (ap-tenggara 7)
+ Kanada Barat (Calgary) (ca-west-1)
+ Eropa (Spanyol) (eu-south-2)
+ Meksiko (Tengah) (mx-central-1)
+ Berikut ini Wilayah AWS, penskalaan terkelola Amazon EMR tersedia dengan Amazon EMR 5.30.0 dan 6.1.0 dan yang lebih tinggi:
+ AS Timur (Virginia Utara) (us-east-1)
+ US East (Ohio) (us-east-2)
+ AS Barat (Oregon) (us-west-2)
+ AS Barat (California Utara) (us-west-1)
+ Africa (Cape Town) (af-south-1)
+ Asia Pacific (Hong Kong) (ap-east-1)
+ Asia Pasifik (Mumbai) (ap-south-1)
+ Asia Pasifik (Hyderabad) (ap-south-2)
+ Asia Pasifik (Seoul) (ap-northeast-2)
+ Asia Pasifik (Singapura) (ap-southeast-1)
+ Asia Pasifik (Sydney) (ap-southeast-2)
+ Asia Pasifik (Jakarta) (ap-southeast-3)
+ Asia Pasifik (Tokyo) (ap-northeast-1)
+ Asia Pasifik (Osaka) (ap-northeast-3)
+ Kanada (Pusat) (ca-central-1)
+ Amerika Selatan (Sao Paulo) (sa-east-1)
+ Eropa (Frankfurt) (eu-central-1)
+ Eropa (Zurich) (eu-central-2)
+ Eropa (Irlandia) (eu-west-1)
+ Eropa (London) (eu-west-2)
+ Europe (Milan) (eu-south-1)
+ Eropa (Paris) (eu-west-3)
+ Eropa (Stockholm) (eu-north-1)
+ Israel (Tel Aviv) (il-central-1)
+ Timur Tengah (UEA) (me-central-1)
+ Tiongkok (Beijing) (cn-utara-1)
+ Tiongkok (Ningxia) (cn-barat laut-1)
+ AWS GovCloud (AS-Timur) (us-gov-east-1)
+ AWS GovCloud (AS-Barat) (us-gov-west-1)
+ Penskalaan terkelola Amazon EMR hanya berfungsi dengan aplikasi YARN, seperti Spark, Hadoop, Hive, dan Flink. Itu tidak mendukung aplikasi yang tidak didasarkan pada YARN, seperti Presto dan HBase.
## Parameter penskalaan terkelola
Anda harus mengonfigurasi parameter berikut untuk penskalaan terkelola. Batas hanya berlaku untuk simpul utama dan tugas. Anda tidak dapat menskalakan node utama setelah konfigurasi awal.
+ **Minimum** (`MinimumCapacityUnits`) - Batas bawah kapasitas EC2 yang diizinkan dalam sebuah klaster. Hal ini diukur melalui inti atau instans virtual central processing unit (vCPU) untuk grup instans. Hal ini diukur melalui unit untuk armada instans.
+ **Maksimum** (`MaximumCapacityUnits`) – Batas atas kapasitas EC2 yang diizinkan dalam sebuah klaster. Hal ini diukur melalui inti atau instans virtual central processing unit (vCPU) untuk grup instans. Hal ini diukur melalui unit untuk armada instans.
+ **Batas Sesuai Permintaan** (`MaximumOnDemandCapacityUnits`) (Opsional) — Batas atas kapasitas EC2 yang diizinkan untuk jenis pasar Sesuai Permintaan dalam sebuah klaster. Jika parameter ini tidak ditentukan, default ke nilai `MaximumCapacityUnits`.
+ Parameter ini digunakan untuk memisah alokasi kapasitas antara Instans Sesuai Permintaan dan Instans Spot. Misalnya, jika Anda menetapkan parameter minimum sebagai 2 instans, parameter maksimum sebagai 100 instans, batas Sesuai Permintaan sebagai 10 instans, maka penskalaan terkelola Amazon EMR menskalakan hingga 10 Instans Sesuai Permintaan dan mengalokasikan kapasitas yang tersisa ke Instans Spot. Untuk informasi selengkapnya, lihat [Skenario alokasi simpul](managed-scaling-allocation-strategy.md#node-allocation-scenarios).
+ **Simpul inti maksimum** (`MaximumCoreCapacityUnits`) (Opsional) - Batas atas kapasitas EC2 yang diizinkan untuk tipe simpul inti dalam sebuah klaster. Jika parameter ini tidak ditentukan, default ke nilai `MaximumCapacityUnits`.
+ Parameter ini digunakan untuk memisah alokasi kapasitas antara simpul inti dan simpul tugas. Misalnya, jika Anda menetapkan parameter minimum sebagai 2 instance, maksimum 100 instance, node inti maksimum sebagai 17 instance, maka Amazon EMR mengelola skala skala hingga 17 node inti dan mengalokasikan 83 instance yang tersisa ke node tugas. Untuk informasi selengkapnya, lihat [Skenario alokasi simpul](managed-scaling-allocation-strategy.md#node-allocation-scenarios).
Untuk informasi selengkapnya tentang parameter penskalaan terkelola, lihat [https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html).
## Pertimbangan untuk penskalaan terkelola Amazon EMR
+ Penskalaan terkelola didukung dalam rilis EMR Amazon terbatas Wilayah AWS dan. Untuk informasi selengkapnya, lihat [Ketersediaan penskalaan terkelola](#emr-managed-scaling-availability).
+ Anda harus mengonfigurasi parameter yang diperlukan untuk penskalaan terkelola Amazon EMR. Untuk informasi selengkapnya, lihat [Parameter penskalaan terkelola](#emr-managed-scaling-parameters).
+ Untuk menggunakan penskalaan terkelola, proses kolektor metrik harus dapat terhubung ke titik akhir API publik untuk penskalaan terkelola di API Gateway. Jika Anda menggunakan nama DNS pribadi dengan Amazon Virtual Private Cloud, penskalaan terkelola tidak akan berfungsi dengan baik. Untuk memastikan bahwa penskalaan terkelola berfungsi, kami sarankan Anda melakukan salah satu tindakan berikut:
+ Hapus titik akhir VPC antarmuka API Gateway dari VPC Amazon Anda.
+ Ikuti petunjuk di [Mengapa saya mendapatkan kesalahan HTTP 403 Forbidden saat menghubungkan ke API Gateway saya APIs dari VPC](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-vpc-connections/)? untuk menonaktifkan pengaturan nama DNS pribadi.
+ Luncurkan cluster Anda di subnet pribadi sebagai gantinya. Untuk informasi lebih lanjut, lihat topik di[Subnet privat](emr-clusters-in-a-vpc.md#emr-vpc-private-subnet).
+ Jika pekerjaan YARN Anda sebentar-sebentar lambat selama penurunan skala, dan log Manajer Sumber Daya YARN menunjukkan bahwa sebagian besar node Anda dicantumkan penolakan selama waktu itu, Anda dapat menyesuaikan ambang batas waktu penonaktifan.
Kurangi `spark.blacklist.decommissioning.timeout` dari satu jam menjadi satu menit untuk membuat node tersedia untuk wadah tertunda lainnya untuk melanjutkan pemrosesan tugas.
Anda juga harus menyetel `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs` ke nilai yang lebih besar untuk memastikan Amazon EMR tidak memaksa menghentikan node sementara “Spark Task” terpanjang masih berjalan di node. Default saat ini adalah 60 menit, yang berarti YARN menghentikan kontainer secara paksa setelah 60 menit setelah node memasuki status dekomisi.
Contoh berikut baris YARN Resource Manager Log menunjukkan node yang ditambahkan ke status dekomisi:
```
2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []
```
[Lihat [detail selengkapnya tentang cara Amazon EMR terintegrasi dengan daftar penolakan YARN selama penonaktifan node, kasus ketika node](https://aws.amazon.com/blogs/big-data/spark-enhancements-for-elasticity-and-resiliency-on-amazon-emr/)[di Amazon EMR dapat ditolak terdaftar](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-troubleshoot-error-resource-3.html), dan mengonfigurasi perilaku penonaktifan simpul Spark.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-decommissioning)
+ Untuk beban kerja Spark, menonaktifkan Spark Dynamic Resource Allocator (DRA) dengan mengubah properti Spark **spark.DynamicAllocation.enabled menjadi `FALSE` dapat menyebabkan masalah Penskalaan** Terkelola, di mana klaster dapat ditingkatkan lebih dari yang diperlukan untuk beban kerja Anda (hingga komputasi maksimum). Saat menggunakan Penskalaan Terkelola untuk beban kerja ini, sebaiknya Anda tetap mengaktifkan Spark DRA, yang merupakan status default properti ini.
+ Pemanfaatan volume EBS yang berlebihan dapat menyebabkan masalah Penskalaan Terkelola. Kami menyarankan Anda mempertahankan volume EBS di bawah 90% pemanfaatan. Untuk informasi selengkapnya, lihat [Opsi dan perilaku penyimpanan instans di Amazon EMR](emr-plan-storage.md).
+ CloudWatch Metrik Amazon sangat penting agar penskalaan terkelola Amazon EMR dapat beroperasi. Kami menyarankan Anda memantau CloudWatch metrik Amazon dengan cermat untuk memastikan data tidak hilang. Untuk informasi selengkapnya tentang cara mengonfigurasi CloudWatch alarm untuk mendeteksi metrik yang hilang, lihat Menggunakan alarm [Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
+ Operasi penskalaan terkelola pada klaster 5.30.0 dan 5.30.1 tanpa Presto yang diinstal dapat menyebabkan gagal aplikasi atau menyebabkan grup instans seragam atau armada instans tetap berada di negara `ARRESTED`, terutama ketika operasi menurunkan skala diikuti dengan cepat oleh operasi menaikkan skala.
Sebagai solusinya, pilih Presto sebagai aplikasi untuk diinstal saat Anda membuat cluster dengan Amazon EMR rilis 5.30.0 dan 5.30.1, bahkan jika pekerjaan Anda tidak memerlukan Presto.
+ Saat Anda menetapkan node inti maksimum dan batas On-Demand untuk penskalaan terkelola Amazon EMR, pertimbangkan perbedaan antara grup instans dan armada instans. Setiap grup instans terdiri dari tipe instans yang sama dan opsi pembelian yang sama untuk instans: Sesuai Permintaan atau Spot. Untuk setiap armada instans, Anda dapat menentukan hingga lima tipe instans, yang dapat disediakan sebagai instans Sesuai Permintaan dan instans Spot. Untuk informasi selengkapnya, lihat [Membuat sebuah klaster dengan armada instans atau grup instans seragam](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-group-configuration.html), [Opsi armada instans](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html#emr-instance-fleet-options), dan [Skenario alokasi simpul](managed-scaling-allocation-strategy.md#node-allocation-scenarios).
+ Dengan Amazon EMR 5.30.0 dan yang lebih tinggi, jika Anda menghapus aturan default **Izinkan Semua** keluar ke 0.0.0.0/ untuk grup keamanan master, Anda harus menambahkan aturan yang memungkinkan konektivitas TCP keluar ke grup keamanan Anda untuk akses layanan pada port 9443. Grup keamanan Anda untuk akses layanan juga harus mengizinkan lalu lintas TCP masuk pada port 9443 dari grup keamanan utama. Untuk informasi selengkapnya tentang mengonfigurasi grup keamanan, lihat [grup keamanan yang dikelola Amazon EMR untuk contoh utama (subnet pribadi)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-master-private).
+ Anda dapat menggunakan AWS CloudFormation untuk mengonfigurasi penskalaan terkelola Amazon EMR. Untuk informasi selengkapnya, lihat [AWS::EMR::Cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticmapreduce-cluster.html) di *AWS CloudFormation Panduan Pengguna*.
+ Jika Anda menggunakan node Spot, pertimbangkan untuk menggunakan label node untuk mencegah Amazon EMR menghapus proses aplikasi saat Amazon EMR menghapus node Spot. Untuk informasi selengkapnya tentang label node, lihat [Node tugas](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html#emr-plan-task).
+ Pelabelan node tidak didukung secara default di Amazon EMR rilis 6.15 atau lebih rendah. Untuk informasi selengkapnya, lihat [Memahami tipe simpul: node primer, inti, dan tugas.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html)
+ Jika Anda menggunakan Amazon EMR rilis 6.15 atau lebih rendah, Anda hanya dapat menetapkan label node berdasarkan jenis node, seperti inti dan node tugas. Namun, jika Anda menggunakan Amazon EMR rilis 7.0 atau yang lebih tinggi, Anda dapat mengonfigurasi label node berdasarkan jenis node dan tipe pasar, seperti On-Demand dan Spot.
+ Jika permintaan proses aplikasi meningkat dan permintaan pelaksana berkurang ketika Anda membatasi proses aplikasi ke node inti, Anda dapat menambahkan kembali node inti dan menghapus node tugas dalam operasi pengubahan ukuran yang sama. Untuk informasi selengkapnya, lihat [Memahami strategi dan skenario alokasi node](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html).
+ Amazon EMR tidak memberi label pada node tugas, jadi Anda tidak dapat menyetel properti YARN untuk membatasi proses aplikasi hanya untuk node tugas. Namun, jika Anda ingin menggunakan tipe pasar sebagai label node, Anda dapat menggunakan `SPOT` label `ON_DEMAND` atau untuk penempatan proses aplikasi. Kami tidak menyarankan menggunakan node Spot untuk proses utama aplikasi.
+ Saat menggunakan label node, total unit yang berjalan di klaster sementara dapat melebihi set komputasi maksimal dalam kebijakan penskalaan terkelola sementara Amazon EMR menonaktifkan beberapa instans Anda. Total unit yang diminta akan selalu berada di atau di bawah perhitungan maksimal polis Anda.
+ Penskalaan terkelola hanya mendukung label node `ON_DEMAND` dan `SPOT` atau `CORE` dan`TASK`. Label node kustom tidak didukung.
+ Amazon EMR membuat label node saat membuat cluster dan sumber daya penyediaan. Amazon EMR tidak mendukung penambahan label node saat Anda mengkonfigurasi ulang cluster. Anda juga tidak dapat memodifikasi label node saat mengonfigurasi penskalaan terkelola setelah meluncurkan cluster.
+ Skala skala terkelola inti dan node tugas secara independen berdasarkan proses aplikasi dan permintaan pelaksana. Untuk mencegah masalah kehilangan data HDFS selama penurunan skala inti, ikuti praktik standar untuk node inti. Untuk mempelajari lebih lanjut tentang praktik terbaik tentang node inti dan replikasi HDFS, lihat [Pertimbangan dan](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-considerations.html) praktik terbaik.
+ Anda tidak dapat menempatkan proses aplikasi dan pelaksana hanya pada `core` atau node. `ON_DEMAND` Jika Anda ingin menambahkan proses aplikasi dan pelaksana pada salah satu node, jangan gunakan konfigurasi. `yarn.node-labels.am.default-node-label-expression`
Misalnya, untuk menempatkan proses aplikasi dan pelaksana di `ON_DEMAND` node, atur komputasi maks sama dengan maksimum di node. `ON_DEMAND` Hapus juga `yarn.node-labels.am.default-node-label-expression` konfigurasi.
Untuk menambahkan proses aplikasi dan pelaksana pada `core` node, hapus konfigurasi. `yarn.node-labels.am.default-node-label-expression`
+ Saat Anda menggunakan penskalaan terkelola dengan label node, setel properti `yarn.scheduler.capacity.maximum-am-resource-percent: 1` jika Anda berencana untuk menjalankan beberapa aplikasi secara paralel. Melakukannya memastikan bahwa proses aplikasi Anda sepenuhnya memanfaatkan yang tersedia `CORE` atau `ON_DEMAND` node.
+ Jika Anda menggunakan penskalaan terkelola dengan label node, setel properti `yarn.resourcemanager.decommissioning.timeout` ke nilai yang lebih panjang dari aplikasi yang berjalan paling lama di cluster Anda. Melakukannya mengurangi kemungkinan penskalaan terkelola Amazon EMR perlu menjadwal ulang aplikasi Anda ke remisi atau node. `CORE` `ON_DEMAND`
+ Untuk mengurangi risiko kegagalan aplikasi karena kehilangan data acak, Amazon EMR mengumpulkan metrik dari cluster untuk menentukan node yang memiliki data shuffle transien yang ada dari tahap saat ini dan sebelumnya. Dalam kasus yang jarang terjadi, metrik dapat terus melaporkan data basi untuk aplikasi yang sudah selesai atau dihentikan. Hal ini dapat memengaruhi penurunan skala instans tepat waktu di klaster Anda. Untuk cluster yang memiliki sejumlah besar data shuffle, pertimbangkan untuk menggunakan EMR versi 6.13 dan yang lebih baru.
## Riwayat fitur
Tabel ini mencantumkan pembaruan untuk kemampuan penskalaan terkelola Amazon EMR.
| Tanggal rilis | Kemampuan | Amazon EMR versi |
| --- | --- | --- |
| November 20, 2024 | Penskalaan terkelola tersedia di il-central-1 wilayah Israel (Tel Aviv), Timur me-central-1 Tengah (UEA), dan ap-northeast-3 Asia Pasifik (Osaka). | 5.30.0 dan 6.1.0 dan lebih tinggi |
| November 15, 2024 | Penskalaan terkelola tersedia di Wilayah eu-central-2 Eropa (Zurich). | 5.30.0 dan 6.1.0 dan lebih tinggi |
| Agustus 20, 2024 | Label node sekarang tersedia dalam penskalaan terkelola, sehingga Anda dapat memberi label pada instance Anda berdasarkan tipe pasar atau tipe node untuk meningkatkan penskalaan otomatis. | 7.2.0 dan lebih tinggi |
| Maret 31, 2024 | Penskalaan terkelola tersedia di Wilayah ap-south-2 Asia Pasifik (Hyderabad). | 6.14.0 dan lebih tinggi |
| Februari 13, 2024 | Penskalaan terkelola tersedia di eu-south-2 Wilayah Eropa (Spanyol). | 6.14.0 dan lebih tinggi |
| Oktober 10, 2023 | Penskalaan terkelola tersedia di Wilayah ap-southeast-3 Asia Pasifik (Jakarta). | 6.14.0 dan lebih tinggi |
| Juli 28, 2023 | Peningkatan penskalaan terkelola untuk beralih ke grup instans tugas yang berbeda saat Amazon EMR mengalami penundaan peningkatan skala dengan grup instans saat ini. | 5.34.0 dan lebih tinggi, 6.4.0 dan lebih tinggi |
| Juni 16, 2023 | Peningkatan penskalaan terkelola untuk mengetahui node yang menjalankan master aplikasi sehingga node tersebut tidak diperkecil. Untuk informasi selengkapnya, lihat [Memahami strategi dan skenario alokasi node EMR Amazon](managed-scaling-allocation-strategy.md). | 5.34.0 dan lebih tinggi, 6.4.0 dan lebih tinggi |
| Maret 21, 2022 | Menambahkan kesadaran data shuffle Spark yang digunakan saat menskalakan cluster. Untuk klaster EMR Amazon dengan Apache Spark dan fitur penskalaan terkelola yang diaktifkan, Amazon EMR terus memantau pelaksana Spark dan lokasi data acak perantara. Dengan menggunakan informasi ini, Amazon EMR hanya mengurangi instance yang kurang dimanfaatkan yang tidak berisi data shuffle yang digunakan secara aktif. Ini mencegah perhitungan ulang data shuffle yang hilang, membantu menurunkan biaya dan meningkatkan kinerja pekerjaan. Untuk informasi selengkapnya, lihat [Panduan Pemrograman Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). | 5.34.0 dan lebih tinggi, 6.4.0 dan lebih tinggi |
# Konfigurasikan penskalaan terkelola untuk Amazon EMR
Bagian berikut menjelaskan cara meluncurkan cluster EMR yang menggunakan penskalaan terkelola dengan Konsol Manajemen AWS,, atau. AWS SDK untuk Java AWS Command Line Interface
**Topics**
+ [Gunakan Konsol Manajemen AWS untuk mengonfigurasi penskalaan terkelola](#managed-scaling-console)
+ [Gunakan AWS CLI untuk mengonfigurasi penskalaan terkelola](#managed-scaling-cli)
+ [Gunakan AWS SDK untuk Java untuk mengonfigurasi penskalaan terkelola](#managed-scaling-sdk)
## Gunakan Konsol Manajemen AWS untuk mengonfigurasi penskalaan terkelola
Anda dapat menggunakan konsol EMR Amazon untuk mengonfigurasi penskalaan terkelola saat membuat klaster atau mengubah kebijakan penskalaan terkelola untuk klaster yang sedang berjalan.
------
#### [ Console ]
**Untuk mengonfigurasi penskalaan terkelola saat Anda membuat klaster dengan konsol**
1. [Masuk ke Konsol Manajemen AWS, dan buka konsol EMR Amazon di https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. **Di bawah **EMR pada EC2** di panel navigasi kiri, pilih Clusters, lalu pilih **Create cluster**.**
1. **Pilih rilis EMR Amazon **emr-5.30.0 atau yang lebih baru, kecuali versi emr-6.0.0**.**
1. Di bawah **opsi penskalaan dan penyediaan klaster, pilih **Gunakan** penskalaan** yang dikelola EMR. Tentukan jumlah instans **Minimum** dan **Maksimum**, instans **node inti Maksimum**, dan instans Sesuai Permintaan **Maksimum**.
1. Pilih opsi lain yang berlaku untuk cluster Anda.
1. Untuk meluncurkan klaster Anda, pilih **Buat klaster**.
**Untuk mengonfigurasi penskalaan terkelola pada cluster yang ada dengan konsol**
1. [Masuk ke Konsol Manajemen AWS, dan buka konsol EMR Amazon di https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Di bawah **EMR pada EC2** di panel navigasi kiri, pilih **Cluster**, dan pilih cluster yang ingin Anda perbarui.
1. Pada tab **Instans** pada halaman detail klaster, temukan bagian **Pengaturan grup Instans**. Pilih **Edit penskalaan klaster** untuk menentukan nilai baru untuk Jumlah instans **Minimum** dan **Maksimum** serta batas **Sesuai** Permintaan.
------
## Gunakan AWS CLI untuk mengonfigurasi penskalaan terkelola
Anda dapat menggunakan AWS CLI perintah untuk Amazon EMR untuk mengonfigurasi penskalaan terkelola saat membuat klaster. Anda dapat menggunakan sintaks steno, menentukan konfigurasi JSON inline dalam perintah yang relevan, atau Anda dapat mereferensikan file yang berisi konfigurasi JSON. Anda juga dapat menerapkan kebijakan penskalaan terkelola ke klaster yang ada dan menghapus kebijakan penskalaan terkelola yang sebelumnya diterapkan. Selain itu, Anda dapat mengambil detail konfigurasi kebijakan penskalaan dari klaster berjalan.
**Mengaktifkan Penskalaan Terkelola Selama Peluncuran Cluster**
Anda dapat mengaktifkan penskalaan terkelola selama peluncuran klaster sebagaimana yang ditunjukkan oleh contoh berikut.
```
aws emr create-cluster \
--service-role EMR_DefaultRole \
--release-label emr-7.12.0 \
--name EMR_Managed_Scaling_Enabled_Cluster \
--applications Name=Spark Name=Hbase \
--ec2-attributes KeyName=keyName,InstanceProfile=EMR_EC2_DefaultRole \
--instance-groups InstanceType=m4.xlarge,InstanceGroupType=MASTER,InstanceCount=1 InstanceType=m4.xlarge,InstanceGroupType=CORE,InstanceCount=2 \
--region us-east-1 \
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=2,MaximumCapacityUnits=4,UnitType=Instances}'
```
Anda juga dapat menentukan konfigurasi kebijakan terkelola menggunakan managed-scaling-policy opsi -- saat Anda menggunakan`create-cluster`.
**Menerapkan Kebijakan Penskalaan Terkelola ke Cluster yang Ada**
Anda dapat menerapkan kebijakan penskalaan terkelola ke klaster yang ada sebagaimana yang ditunjukkan oleh contoh berikut.
```
aws emr put-managed-scaling-policy
--cluster-id j-123456
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=1,
MaximumCapacityUnits=10, MaximumOnDemandCapacityUnits=10, UnitType=Instances}'
```
Anda juga dapat menerapkan kebijakan penskalaan terkelola ke klaster yang sudah ada dengan menggunakan perintah `aws emr put-managed-scaling-policy`. Contoh berikut menggunakan referensi ke file JSON, `managedscaleconfig.json`, yang menentukan konfigurasi kebijakan penskalaan terkelola.
```
aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy file://./managedscaleconfig.json
```
Contoh berikut menunjukkan isi file `managedscaleconfig.json`, yang mendefinisikan kebijakan penskalaan terkelola.
```
{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 10,
"MaximumOnDemandCapacityUnits": 10
}
}
```
**Mengambil Konfigurasi Kebijakan Penskalaan Terkelola**
Perintah `GetManagedScalingPolicy` mengambil konfigurasi kebijakan. Sebagai contoh, perintah berikut ini mengambil konfigurasi untuk klaster dengan ID klaster `j-123456`.
```
aws emr get-managed-scaling-policy --cluster-id j-123456
```
Perintah tersebut menghasilkan output seperti berikut ini.
```
1. {
2. "ManagedScalingPolicy": {
3. "ComputeLimits": {
4. "MinimumCapacityUnits": 1,
5. "MaximumOnDemandCapacityUnits": 10,
6. "MaximumCapacityUnits": 10,
7. "UnitType": "Instances"
8. }
9. }
10. }
```
Untuk informasi selengkapnya tentang menggunakan perintah EMR Amazon di AWS CLI, lihat. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr)
**Menghapus Kebijakan Penskalaan Terkelola**
Perintah `RemoveManagedScalingPolicy` menghapus konfigurasi kebijakan. Sebagai contoh, perintah berikut menghapus konfigurasi untuk klaster dengan ID klaster `j-123456`.
```
aws emr remove-managed-scaling-policy --cluster-id j-123456
```
## Gunakan AWS SDK untuk Java untuk mengonfigurasi penskalaan terkelola
Kutipan program berikut menunjukkan cara mengkonfigurasi penskalaan terkelola menggunakan AWS SDK untuk Java:
```
package com.amazonaws.emr.sample;
import java.util.ArrayList;
import java.util.List;
import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.profile.ProfileCredentialsProvider;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduce;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClientBuilder;
import com.amazonaws.services.elasticmapreduce.model.Application;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimits;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimitsUnitType;
import com.amazonaws.services.elasticmapreduce.model.InstanceGroupConfig;
import com.amazonaws.services.elasticmapreduce.model.JobFlowInstancesConfig;
import com.amazonaws.services.elasticmapreduce.model.ManagedScalingPolicy;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowRequest;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowResult;
public class CreateClusterWithManagedScalingWithIG {
public static void main(String[] args) {
AWSCredentials credentialsFromProfile = getCreadentials("AWS-Profile-Name-Here");
/**
* Create an Amazon EMR client with the credentials and region specified in order to create the cluster
*/
AmazonElasticMapReduce emr = AmazonElasticMapReduceClientBuilder.standard()
.withCredentials(new AWSStaticCredentialsProvider(credentialsFromProfile))
.withRegion(Regions.US_EAST_1)
.build();
/**
* Create Instance Groups - Primary, Core, Task
*/
InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig()
.withInstanceCount(1)
.withInstanceRole("MASTER")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig()
.withInstanceCount(4)
.withInstanceRole("CORE")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig()
.withInstanceCount(5)
.withInstanceRole("TASK")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
List igConfigs = new ArrayList<>();
igConfigs.add(instanceGroupConfigMaster);
igConfigs.add(instanceGroupConfigCore);
igConfigs.add(instanceGroupConfigTask);
/**
* specify applications to be installed and configured when Amazon EMR creates the cluster
*/
Application hive = new Application().withName("Hive");
Application spark = new Application().withName("Spark");
Application ganglia = new Application().withName("Ganglia");
Application zeppelin = new Application().withName("Zeppelin");
/**
* Managed Scaling Configuration -
* Using UnitType=Instances for clusters composed of instance groups
*
* Other options are:
* UnitType = VCPU ( for clusters composed of instance groups)
* UnitType = InstanceFleetUnits ( for clusters composed of instance fleets)
**/
ComputeLimits computeLimits = new ComputeLimits()
.withMinimumCapacityUnits(1)
.withMaximumCapacityUnits(20)
.withUnitType(ComputeLimitsUnitType.Instances);
ManagedScalingPolicy managedScalingPolicy = new ManagedScalingPolicy();
managedScalingPolicy.setComputeLimits(computeLimits);
// create the cluster with a managed scaling policy
RunJobFlowRequest request = new RunJobFlowRequest()
.withName("EMR_Managed_Scaling_TestCluster")
.withReleaseLabel("emr-7.12.0") // Specifies the version label for the Amazon EMR release; we recommend the latest release
.withApplications(hive,spark,ganglia,zeppelin)
.withLogUri("s3://path/to/my/emr/logs") // A URI in S3 for log files is required when debugging is enabled.
.withServiceRole("EMR_DefaultRole") // If you use a custom IAM service role, replace the default role with the custom role.
.withJobFlowRole("EMR_EC2_DefaultRole") // If you use a custom Amazon EMR role for EC2 instance profile, replace the default role with the custom Amazon EMR role.
.withInstances(new JobFlowInstancesConfig().withInstanceGroups(igConfigs)
.withEc2SubnetId("subnet-123456789012345")
.withEc2KeyName("my-ec2-key-name")
.withKeepJobFlowAliveWhenNoSteps(true))
.withManagedScalingPolicy(managedScalingPolicy);
RunJobFlowResult result = emr.runJobFlow(request);
System.out.println("The cluster ID is " + result.toString());
}
public static AWSCredentials getCredentials(String profileName) {
// specifies any named profile in .aws/credentials as the credentials provider
try {
return new ProfileCredentialsProvider("AWS-Profile-Name-Here")
.getCredentials();
} catch (Exception e) {
throw new AmazonClientException(
"Cannot load credentials from .aws/credentials file. " +
"Make sure that the credentials file exists and that the profile name is defined within it.",
e);
}
}
public CreateClusterWithManagedScalingWithIG() { }
}
```
# Penskalaan Lanjutan untuk Amazon EMR
Dimulai dengan Amazon EMR pada EC2 versi 7.0, Anda dapat memanfaatkan Advanced Scaling untuk mengontrol pemanfaatan sumber daya klaster Anda. Advanced Scaling memperkenalkan skala kinerja pemanfaatan untuk menyetel pemanfaatan sumber daya dan tingkat kinerja Anda sesuai dengan kebutuhan bisnis Anda. Nilai yang Anda tetapkan menentukan apakah klaster Anda lebih tertimbang untuk konservasi sumber daya atau peningkatan skala untuk menangani beban kerja sensitif service-level-agreement (SLA), di mana penyelesaian cepat sangat penting. Saat nilai penskalaan disesuaikan, penskalaan terkelola menginterpretasikan maksud Anda dan menskalakan secara cerdas untuk mengoptimalkan sumber daya. Untuk informasi selengkapnya tentang penskalaan terkelola, lihat [Mengonfigurasi penskalaan terkelola untuk Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-configure.html).
## Pengaturan Penskalaan Tingkat Lanjut
Nilai yang Anda set untuk Advanced Scaling mengoptimalkan klaster sesuai kebutuhan Anda. Nilai berkisar dari **1** - **100**. Nilai yang mungkin adalah **1**, **25**, **50**, **75** dan **100**. Jika Anda mengatur indeks ke nilai selain ini, itu menghasilkan kesalahan validasi.
Nilai penskalaan dipetakan ke strategi pemanfaatan sumber daya. Daftar berikut mendefinisikan beberapa di antaranya:
+ **Pemanfaatan dioptimalkan [1]** - Pengaturan ini mencegah sumber daya melebihi penyediaan. Gunakan nilai rendah ketika Anda ingin menjaga biaya tetap rendah dan memprioritaskan pemanfaatan sumber daya yang efisien. Ini menyebabkan cluster meningkat kurang agresif. Ini berfungsi dengan baik untuk kasus penggunaan ketika ada lonjakan beban kerja yang terjadi secara teratur dan Anda tidak ingin sumber daya meningkat terlalu cepat.
+ **Seimbang [50]** — Ini menyeimbangkan pemanfaatan sumber daya dan kinerja pekerjaan. Pengaturan ini cocok untuk beban kerja yang stabil di mana sebagian besar tahapan memiliki runtime yang stabil. Ini juga cocok untuk beban kerja dengan campuran tahapan jangka pendek dan panjang. Sebaiknya mulai dengan pengaturan ini jika Anda tidak yakin mana yang harus dipilih.
+ **Kinerja dioptimalkan [100]** — Strategi ini memprioritaskan kinerja. Cluster meningkatkan skala secara agresif untuk memastikan bahwa pekerjaan selesai dengan cepat dan memenuhi target kinerja. Kinerja yang dioptimalkan cocok untuk beban kerja sensitif service-level-agreement (SLA) di mana waktu lari cepat sangat penting.
**catatan**
Nilai perantara yang tersedia menyediakan jalan tengah di antara strategi untuk menyempurnakan perilaku Penskalaan Lanjutan klaster Anda.
## Manfaat Advanced Scaling
Karena Anda memiliki variabilitas dalam lingkungan dan persyaratan Anda, seperti mengubah volume data, penyesuaian target biaya, dan implementasi SLA, penskalaan klaster dapat membantu Anda menyesuaikan konfigurasi klaster untuk mencapai tujuan Anda. Manfaat utama meliputi:
+ **Kontrol granular yang disempurnakan** - Pengenalan pengaturan pemanfaatan-kinerja memungkinkan Anda untuk dengan mudah menyesuaikan perilaku penskalaan klaster Anda sesuai dengan kebutuhan Anda. Anda dapat meningkatkan skala untuk memenuhi permintaan sumber daya komputasi atau menurunkan skala untuk menghemat sumber daya, berdasarkan pola penggunaan Anda.
+ **Optimalisasi biaya yang ditingkatkan** — Anda dapat memilih nilai pemanfaatan yang rendah karena persyaratan menentukan untuk lebih mudah memenuhi tujuan biaya Anda.
## Memulai dengan optimasi
**Pengaturan dan konfigurasi**
Gunakan langkah-langkah ini untuk mengatur indeks kinerja dan mengoptimalkan strategi penskalaan Anda.
1. Perintah berikut memperbarui cluster yang ada dengan strategi penskalaan yang dioptimalkan untuk pemanfaatan`[1]`:
```
aws emr put-managed-scaling-policy --cluster-id 'cluster-id' \
--managed-scaling-policy '{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 2,
"MaximumOnDemandCapacityUnits": 2,
"MaximumCoreCapacityUnits": 2
},
"ScalingStrategy": "ADVANCED",
"UtilizationPerformanceIndex": "1"
}' \
--region "region-name"
```
Atribut `ScalingStrategy` dan `UtilizationPerformanceIndex` baru dan relevan dengan optimasi penskalaan. Anda dapat memilih strategi penskalaan yang berbeda dengan menetapkan nilai yang sesuai (1, 25, 50, 75, dan 100) untuk `UtilizationPerformanceIndex` atribut dalam kebijakan penskalaan terkelola.
1. Untuk kembali ke strategi penskalaan terkelola default, jalankan `put-managed-scaling-policy` perintah tanpa menyertakan atribut dan. `ScalingStrategy` `UtilizationPerformanceIndex` (Ini opsional.) Contoh ini menunjukkan cara melakukan ini:
```
aws emr put-managed-scaling-policy \
--cluster-id 'cluster-id' \
--managed-scaling-policy '{"ComputeLimits":{"UnitType":"Instances","MinimumCapacityUnits":1,"MaximumCapacityUnits":2,"MaximumOnDemandCapacityUnits":2,"MaximumCoreCapacityUnits":2}}' \
--region "region-name"
```
**Menggunakan metrik pemantauan untuk melacak pemanfaatan cluster**
Dimulai dengan EMR versi 7.3.0, Amazon EMR menerbitkan empat metrik baru yang terkait dengan memori dan CPU virtual. Anda dapat menggunakan ini untuk mengukur pemanfaatan cluster di seluruh strategi penskalaan. Metrik ini tersedia untuk kasus penggunaan apa pun, tetapi Anda dapat menggunakan detail yang disediakan di sini untuk memantau Penskalaan Lanjutan.
Metrik bermanfaat yang tersedia meliputi:
+ **YarnContainersUsedMemoryGBSeconds**— Jumlah memori yang dikonsumsi oleh aplikasi yang dikelola oleh YARN.
+ **YarnContainersTotalMemoryGBSeconds**— Total kapasitas memori yang dialokasikan ke YARN di dalam cluster.
+ **YarnNodesUsedVCPUSeconds**— Total detik VCPU untuk setiap aplikasi yang dikelola oleh YARN.
+ **YarnNodesTotalVCPUSeconds**— Total detik VCPU gabungan untuk memori yang dikonsumsi, termasuk jendela waktu saat benang belum siap.
Anda dapat menganalisis metrik sumber daya menggunakan Wawasan Amazon CloudWatch Log. Fitur termasuk bahasa kueri yang dibuat khusus yang membantu Anda mengekstrak metrik khusus untuk penggunaan dan penskalaan sumber daya.
Kueri berikut, yang dapat Anda jalankan di Amazon CloudWatch konsol, menggunakan matematika metrik untuk menghitung pemanfaatan memori rata-rata (e1) dengan membagi jumlah berjalan dari memori yang dikonsumsi (e2) dengan jumlah total memori yang berjalan (e3):
```
{
"metrics": [
[ { "expression": "e2/e3", "label": "Average Mem Utilization", "id": "e1", "yAxis": "right" } ],
[ { "expression": "RUNNING_SUM(m1)", "label": "RunningTotal-YarnContainersUsedMemoryGBSeconds", "id": "e2", "visible": false } ],
[ { "expression": "RUNNING_SUM(m2)", "label": "RunningTotal-YarnContainersTotalMemoryGBSeconds", "id": "e3", "visible": false } ],
[ "AWS_EMR_ManagedResize", "YarnContainersUsedMemoryGBSeconds", "ACCOUNT_ID", "793684541905", "COMPONENT", "ManagerService", "JOB_FLOW_ID", "cluster-id", { "id": "m1", "label": "YarnContainersUsedMemoryGBSeconds" } ],
[ ".", "YarnContainersTotalMemoryGBSeconds", ".", ".", ".", ".", ".", ".", { "id": "m2", "label": "YarnContainersTotalMemoryGBSeconds" } ]
],
"view": "timeSeries",
"stacked": false,
"region": "region",
"period": 60,
"stat": "Sum",
"title": "Memory Utilization"
}
```
Untuk meminta log, Anda dapat memilih CloudWatch di AWS konsol. Untuk informasi selengkapnya tentang menulis kueri CloudWatch, lihat [Menganalisis data CloudWatch log dengan Wawasan Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) di Panduan Pengguna CloudWatch Log Amazon.
Gambar berikut menunjukkan metrik ini untuk cluster sampel:
![\[Grafik yang menunjukkan statistik pemanfaatan.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/scaling_graph_EMR.png)
## Pertimbangan dan batasan
+ Efektivitas strategi penskalaan dapat bervariasi, tergantung pada karakteristik beban kerja unik dan konfigurasi klaster Anda. Kami mendorong Anda untuk bereksperimen dengan pengaturan penskalaan untuk menentukan nilai indeks optimal untuk kasus penggunaan Anda.
+ Amazon EMR Advanced Scaling sangat cocok untuk beban kerja batch. Untuk beban kerja SQL/data-warehousing dan streaming, sebaiknya gunakan strategi penskalaan terkelola default untuk kinerja yang optimal.
+ Amazon EMR Advanced Scaling tidak didukung saat Konfigurasi Label Node diaktifkan di cluster. Jika Advanced Scaling dan Node Label Configurations diaktifkan bersama-sama dalam sebuah cluster, maka perilaku penskalaan akan seolah-olah pengaturan penskalaan terkelola default diaktifkan.
+ Strategi penskalaan yang dioptimalkan kinerja memungkinkan eksekusi pekerjaan lebih cepat dengan mempertahankan sumber daya komputasi tinggi untuk periode yang lebih lama daripada strategi penskalaan terkelola default. Mode ini memprioritaskan penskalaan dengan cepat untuk memenuhi permintaan sumber daya, sehingga penyelesaian pekerjaan lebih cepat. Ini mungkin menghasilkan biaya yang lebih tinggi jika dibandingkan dengan strategi default.
+ Dalam kasus di mana klaster sudah dioptimalkan dan dimanfaatkan sepenuhnya, mengaktifkan Advanced Scaling mungkin tidak memberikan manfaat tambahan. Dalam beberapa situasi, mengaktifkan Advanced Scaling dapat menyebabkan peningkatan biaya karena beban kerja dapat berjalan lebih lama. Dalam kasus ini, sebaiknya gunakan strategi penskalaan terkelola default untuk memastikan alokasi sumber daya dan efisiensi biaya yang optimal.
+ **Dalam konteks penskalaan terkelola, penekanan bergeser ke pemanfaatan sumber daya selama waktu eksekusi karena pengaturan disesuaikan dari kinerja yang dioptimalkan [**100**] ke pemanfaatan yang dioptimalkan [1].** Namun, penting untuk dicatat bahwa hasilnya mungkin bervariasi, berdasarkan sifat beban kerja dan topologi cluster. Untuk memastikan hasil yang optimal untuk kasus penggunaan Anda, kami sangat menyarankan untuk menguji strategi penskalaan dengan beban kerja Anda untuk menentukan pengaturan yang paling sesuai.
+ Hanya **PerformanceUtilizationIndex**menerima nilai-nilai berikut:
+ **1**
+ **25**
+ **50**
+ **75**
+ **100**
Nilai lain yang dikirimkan menghasilkan kesalahan validasi.
# Memahami strategi dan skenario alokasi node EMR Amazon
Bagian ini memberikan ikhtisar strategi alokasi node dan skenario penskalaan umum yang dapat Anda gunakan dengan penskalaan terkelola Amazon EMR.
## Strategi alokasi simpul
Penskalaan terkelola Amazon EMR mengalokasikan node inti dan tugas berdasarkan strategi scale-up dan scale-down berikut:
**Strategi penskalaan**
+ Untuk Amazon EMR merilis 7.2 dan yang lebih tinggi, penskalaan terkelola terlebih dahulu menambahkan node berdasarkan label node dan properti YARN pembatasan proses aplikasi.
+ Untuk Amazon EMR merilis 7.2 dan yang lebih tinggi, jika Anda mengaktifkan label node dan membatasi proses aplikasi ke node`CORE`, Amazon EMR mengelola skala skala node inti dan node tugas jika permintaan proses aplikasi meningkat dan permintaan pelaksana meningkat. Demikian pula, jika Anda mengaktifkan label node dan membatasi proses aplikasi ke `ON_DEMAND` node, skala terkelola meningkatkan skala node sesuai permintaan jika permintaan proses aplikasi meningkat dan meningkatkan skala node spot jika permintaan pelaksana meningkat.
+ Jika label node tidak diaktifkan, penempatan proses aplikasi tidak terbatas pada node atau tipe pasar apa pun.
+ Dengan menggunakan label node, penskalaan terkelola dapat meningkatkan dan menurunkan grup instans dan armada instance yang berbeda dalam operasi pengubahan ukuran yang sama. Misalnya, dalam skenario di mana `instance_group1` memiliki `ON_DEMAND` node dan `instance_group2` memiliki `SPOT` node, dan label node diaktifkan dan proses aplikasi dibatasi untuk node dengan `ON_DEMAND` label. Penskalaan terkelola akan menurunkan `instance_group1` dan meningkatkan skala `instance_group2` jika permintaan proses aplikasi menurun dan permintaan pelaksana meningkat.
+ Saat Amazon EMR mengalami penundaan peningkatan skala dengan grup instans saat ini, klaster yang menggunakan penskalaan terkelola secara otomatis beralih ke grup instans tugas yang berbeda.
+ Jika parameter `MaximumCoreCapacityUnits` diatur, maka Amazon EMR menskalakan simpul inti sampai unit inti mencapai batas maksimum yang diizinkan. Semua kapasitas yang tersisa ditambahkan ke simpul tugas.
+ Jika parameter `MaximumOnDemandCapacityUnits` diatur, maka Amazon EMR menskalakan klaster dengan menggunakan instans Sesuai Permintaan sampai unit Sesuai Permintaan mencapai batas maksimum yang diizinkan. Semua kapasitas yang tersisa ditambahkan menggunakan Instans Spot.
+ Jika kedua parameter `MaximumCoreCapacityUnits` dan `MaximumOnDemandCapacityUnits` diatur, Amazon EMR mempertimbangkan kedua batas selama penskalaan.
Misalnya, jika kurang dari`MaximumOnDemandCapacityUnits`, Amazon EMR pertama-tama menskalakan node inti hingga batas kapasitas inti tercapai. `MaximumCoreCapacityUnits` Untuk kapasitas yang tersisa, Amazon EMR pertama-tama menggunakan Instans Sesuai Permintaan untuk menskalakan node tugas hingga batas On-Demand tercapai, dan kemudian menggunakan Instans Spot untuk node tugas.
**Strategi penskalaan**
+ Mirip dengan strategi peningkatan skala, Amazon EMR menghapus node berdasarkan label node. Untuk informasi selengkapnya tentang label node, lihat [Memahami tipe node: node primer, inti, dan tugas](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html).
+ Jika Anda belum mengaktifkan label node, penskalaan terkelola menghapus node tugas dan kemudian menghapus node inti hingga mencapai kapasitas target penskalaan yang diinginkan. Penskalaan terkelola tidak pernah menurunkan skala klaster di bawah batasan minimum yang ditentukan dalam kebijakan penskalaan terkelola.
+ Amazon EMR versi 5.34.0 dan yang lebih tinggi, serta Amazon EMR versi 6.4.0 dan yang lebih tinggi, mendukung kesadaran data shuffle Spark, yang mencegah instance menurunkan skala sementara Penskalaan Terkelola mengetahui data acak yang ada. Untuk informasi selengkapnya tentang operasi shuffle, lihat Panduan [Pemrograman Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). Penskalaan Terkelola melakukan upaya terbaik untuk mencegah node penskalaan dengan data acak dari tahap saat ini dan sebelumnya dari aplikasi Spark aktif apa pun, hingga maksimum 30 menit. Ini membantu meminimalkan kehilangan data acak yang tidak diinginkan, menghindari kebutuhan untuk upaya ulang pekerjaan dan perhitungan ulang data perantara. Namun, pencegahan kehilangan data shuffle tidak dijamin. Untuk perlindungan shuffle Spark yang lebih baik, kami merekomendasikan kesadaran acak pada cluster dengan label rilis 7.4 atau lebih tinggi. Tambahkan flag berikut ke konfigurasi cluster untuk mengaktifkan perlindungan shuffle Spark yang ditingkatkan.
+ Jika salah satu `yarn.nodemanager.shuffledata-monitor.interval-ms` tanda (default 30000 ms) atau `spark.dynamicAllocation.executorIdleTimeout` (default 60 detik) telah diubah dari nilai default, pastikan kondisi `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` tetap `true` dengan memperbarui flag yang diperlukan.
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
}
},
{
"Classification": "spark-defaults",
"Properties": {
"spark.dynamicAllocation.enabled": "true",
"spark.shuffle.service.removeShuffle": "true"
}
}
]
```
+ Penskalaan terkelola pertama-tama menghapus node tugas dan kemudian menghapus node inti hingga mencapai kapasitas target penskalaan yang diinginkan. Kluster tidak pernah menskalakan di bawah batasan minimum yang ditentukan dalam kebijakan penskalaan terkelola.
+ Untuk cluster yang diluncurkan dengan Amazon EMR 5.x rilis 5.34.0 dan lebih tinggi, dan 6.x merilis 6.4.0 dan lebih tinggi, Amazon EMR Managed Scaling tidak menurunkan skala node yang memiliki Apache Spark, jika ada tahapan aktif dalam aplikasi `ApplicationMaster` yang berjalan di atasnya. Ini meminimalkan kegagalan pekerjaan dan percobaan ulang, yang membantu meningkatkan kinerja pekerjaan dan mengurangi biaya. Untuk mengonfirmasi node mana di cluster Anda yang sedang berjalan`ApplicationMaster`, kunjungi Spark History Server dan filter driver di bawah tab **Executors ID** aplikasi Spark Anda.
+ Sementara penskalaan cerdas dengan EMR Managed Scaling meminimalkan kehilangan data acak untuk Spark, mungkin ada contoh ketika data shuffle sementara mungkin tidak dilindungi selama scale-down. Untuk memberikan peningkatan ketahanan data shuffle selama penurunan skala, sebaiknya aktifkan **Graceful** Decommissioning for Shuffle Data di YARN. Ketika **Graceful Decommissioning for Shuffle Data** diaktifkan di YARN, node yang dipilih untuk scale-down yang memiliki data shuffle akan memasuki status **Donaktifkan** dan terus menyajikan file shuffle. YARN ResourceManager menunggu sampai node melaporkan tidak ada file shuffle yang ada sebelum menghapus node dari cluster.
+ Amazon EMR versi 6.11.0 dan yang lebih tinggi mendukung penonaktifan anggun berbasis Benang untuk data pengocokan **Hive** untuk Tez dan Shuffle Handler. MapReduce
+ Aktifkan Graceful Decommissioning untuk Shuffle Data dengan menyetel ke. `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` `true`
+ Amazon EMR versi 7.4.0 dan yang lebih tinggi mendukung penonaktifan anggun berbasis Benang untuk data shuffle Spark saat layanan pengocokan eksternal diaktifkan (diaktifkan secara default di EMR di EC2).
+ Perilaku default dari layanan shuffle eksternal Spark, saat menjalankan Spark on Yarn, adalah NodeManager agar Yarn menghapus file shuffle aplikasi pada saat penghentian aplikasi. Ini mungkin berdampak pada kecepatan dekomisioning node dan pemanfaatan komputasi. Untuk aplikasi yang berjalan lama, pertimbangkan pengaturan `spark.shuffle.service.removeShuffle` `true` untuk menghapus file acak yang tidak lagi digunakan untuk memungkinkan penonaktifan node yang lebih cepat tanpa data acak aktif.
+ Untuk meminimalkan kehilangan data Spark shuffle di Amazon EMR versi 7.4.0 dan yang lebih tinggi, pertimbangkan untuk menyetel flag berikut.
+ Jika salah satu `yarn.nodemanager.shuffledata-monitor.interval-ms` tanda (default 30000 ms) atau `spark.dynamicAllocation.executorIdleTimeout` (default 60 detik) telah diubah dari nilai default, pastikan bahwa kondisi `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` tetap `true` dengan memperbarui flag yang diperlukan.
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
}
},
{
"Classification": "spark-defaults",
"Properties": {
"spark.dynamicAllocation.enabled": "true",
"spark.shuffle.service.removeShuffle": "true"
}
}
]
```
Jika klaster tidak memiliki beban apapun, maka Amazon EMR membatalkan penambahan instans baru dari evaluasi sebelumnya dan melakukan operasi menurunkan skala. Jika klaster memiliki beban berat, Amazon EMR membatalkan penghapusan instans dan melakukan operasi menaikkan skala.
## Pertimbangan alokasi simpul
Kami merekomendasikan Anda menggunakan opsi pembelian Sesuai Permintaan untuk simpul inti untuk menghindari kehilangan data HDFS dalam kasus reklamasi Spot. Anda dapat menggunakan opsi pembelian Spot untuk simpul tugas untuk mengurangi biaya dan mendapatkan eksekusi pekerjaan yang lebih cepat ketika lebih banyak Instans Spot ditambahkan ke simpul tugas.
## Skenario alokasi simpul
Anda dapat membuat berbagai skenario penskalaan berdasarkan kebutuhan Anda dengan mengatur parameter maksimum, minimum, batas Sesuai Permintaan, dan maksimum simpul inti dalam kombinasi yang berbeda.
**Skenario 1: Saja Skala Node Inti**
Untuk menskalakan simpul inti saja, parameter penskalaan terkelola harus memenuhi persyaratan berikut:
+ Batas Sesuai Permintaan sama dengan batas maksimum.
+ Simpul inti maksimum sama dengan batas maksimum.
Ketika batas Sesuai Permintaan dan parameter simpul inti maksimum tidak ditentukan, kedua parameter default ke batas maksimum.
Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda agar hanya berjalan pada `CORE` node, karena penskalaan terkelola menskalakan node tugas untuk mengakomodasi permintaan pelaksana.
Contoh berikut menunjukkan skenario penskalaan simpul inti saja.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Skenario 2: Skalakan node tugas saja**
Untuk menskalakan simpul tugas saja, parameter penskalaan terkelola harus memenuhi persyaratan berikut:
+ Simpul inti maksimum harus sama dengan batas minimum.
Contoh berikut menunjukkan skenario penskalaan simpul tugas saja.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Skenario 3: Hanya Instans Sesuai Permintaan di klaster**
Untuk memiliki Instans Sesuai Permintaan saja, klaster Anda dan parameter penskalaan terkelola harus memenuhi persyaratan berikut:
+ Batas Sesuai Permintaan sama dengan batas maksimum.
Ketika batas Sesuai Permintaan tidak ditentukan, nilai parameter default ke batas maksimum. Nilai default menunjukkan bahwa Amazon EMR menskalakan Instans Sesuai Permintaan saja.
Jika simpul inti maksimum kurang dari batas maksimum, parameter simpul inti maksimum dapat digunakan untuk membagi alokasi kapasitas antara simpul inti dan tugas.
Untuk mengaktifkan skenario ini dalam sebuah klaster yang terdiri dari grup instans, semua kelompok simpul dalam klaster harus menggunakan tipe pasar Sesuai Permintaan selama konfigurasi awal.
Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda untuk hanya berjalan pada `ON_DEMAND` node, karena skala skala terkelola `Spot` node untuk mengakomodasi permintaan pelaksana.
Contoh berikut menunjukkan skenario dari memiliki Instans Sesuai Permintaan di seluruh klaster.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Skenario 4: Hanya Instance Spot di cluster**
Untuk memiliki Instans Spot saja, klaster Anda dan parameter penskalaan terkelola harus memenuhi persyaratan berikut:
+ Batas Sesuai Permintaan diatur ke 0.
Jika simpul inti maksimum kurang dari batas maksimum, parameter simpul inti maksimum dapat digunakan untuk membagi alokasi kapasitas antara simpul inti dan tugas.
Untuk mengaktifkan skenario ini dalam sebuah klaster yang terdiri dari grup instans, grup instans inti harus menggunakan opsi pembelian Spot selama konfigurasi awal. Jika tidak ada Instans Spot di grup instance tugas, penskalaan terkelola Amazon EMR akan membuat grup tugas menggunakan Instans Spot bila diperlukan.
Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda untuk hanya berjalan pada `ON_DEMAND` node, karena skala skala terkelola `ON_DEMAND` node untuk mengakomodasi permintaan proses aplikasi.
Contoh berikut menunjukkan skenario dari memiliki Instans Spot di seluruh klaster.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Skenario 5: Skala Instans Sesuai Permintaan pada node inti dan Instans Spot pada node tugas**
Untuk menskalakan Instans Sesuai Permintaan pada simpul inti dan Instans Spot pada simpul tugas, parameter penskalaan terkelola harus memenuhi persyaratan berikut:
+ Batas Sesuai Permintaan harus sama dengan simpul inti maksimum.
+ Batas Sesuai Permintaan dan simpul inti maksimum harus kurang dari batas maksimum.
Untuk mengaktifkan skenario ini dalam sebuah klaster yang terdiri dari grup instans, grup simpul inti harus menggunakan opsi pembelian Sesuai Permintaan.
Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda untuk hanya berjalan pada `ON_DEMAND` node atau `CORE` node.
Contoh berikut menunjukkan skenario penskalaan Instans Sesuai Permintaan pada simpul inti dan Instans Spot pada simpul tugas.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Skenario 6: Skala `CORE` instance untuk permintaan proses aplikasi dan `TASK` instance untuk permintaan pelaksana.**
Skenario ini hanya berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi agar hanya berjalan pada `CORE` node.
Untuk menskalakan `CORE` node berdasarkan permintaan proses aplikasi dan `TASK` node berdasarkan permintaan pelaksana, Anda harus mengatur konfigurasi berikut pada peluncuran cluster:
+ `yarn.node-labels.enabled:true`
+ `yarn.node-labels.am.default-node-label-expression: 'CORE'`
Jika Anda tidak menentukan `ON_DEMAND` batas dan parameter `CORE` node maksimum, kedua parameter default ke batas maksimum.
Jika `ON_DEMAND` node maksimum kurang dari batas maksimum, penskalaan terkelola menggunakan parameter `ON_DEMAND` node maksimum untuk membagi alokasi kapasitas antara dan node. `ON_DEMAND` `SPOT` Jika Anda mengatur parameter `CORE` node maksimum menjadi kurang dari atau sama dengan parameter kapasitas minimum, `CORE` node tetap statis pada kapasitas inti maksimum.
Contoh berikut menunjukkan skenario penskalaan instance CORE berdasarkan permintaan proses aplikasi dan instance TASK berdasarkan permintaan pelaksana.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**Skenario 7: Skala `ON_DEMAND` instance untuk permintaan proses aplikasi dan `SPOT` instance untuk permintaan pelaksana.**
Skenario ini hanya berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi agar hanya berjalan pada `ON_DEMAND` node.
Untuk menskalakan `ON_DEMAND` node berdasarkan permintaan proses aplikasi dan `SPOT` node berdasarkan permintaan pelaksana, Anda harus mengatur konfigurasi berikut pada peluncuran cluster:
+ `yarn.node-labels.enabled:true`
+ `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'`
Jika Anda tidak menentukan `ON_DEMAND` batas dan parameter `CORE` node maksimum, kedua parameter default ke batas maksimum.
Jika `CORE` node maksimum kurang dari batas maksimum, penskalaan terkelola menggunakan parameter `CORE` node maksimum untuk membagi alokasi kapasitas antara dan node. `CORE` `TASK` Jika Anda mengatur parameter `CORE` node maksimum menjadi kurang dari atau sama dengan parameter kapasitas minimum, `CORE` node tetap statis pada kapasitas inti maksimum.
Contoh berikut menunjukkan skenario penskalaan Instans Sesuai Permintaan berdasarkan permintaan proses aplikasi dan instans Spot berdasarkan permintaan pelaksana.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
# Memahami metrik penskalaan terkelola di Amazon EMR
Amazon EMR menerbitkan metrik resolusi tinggi dengan data pada rincian satu menit ketika penskalaan terkelola diaktifkan untuk suatu klaster. Anda dapat melihat peristiwa pada setiap inisiasi dan penyelesaian pengubahan ukuran yang dikendalikan oleh penskalaan terkelola dengan konsol EMR Amazon atau konsol Amazon. CloudWatch CloudWatch metrik sangat penting agar penskalaan terkelola Amazon EMR dapat beroperasi. Kami menyarankan Anda memantau CloudWatch metrik dengan cermat untuk memastikan data tidak hilang. Untuk informasi selengkapnya tentang cara mengonfigurasi CloudWatch alarm untuk mendeteksi metrik yang hilang, lihat Menggunakan alarm [Amazon CloudWatch ](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Untuk informasi selengkapnya tentang menggunakan CloudWatch peristiwa dengan Amazon EMR, lihat [Memantau CloudWatch](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html) peristiwa.
Metrik berikut menunjukkan kapasitas saat ini atau kapasitas target suatu klaster. Metrik ini hanya tersedia apabila penskalaan terkelola diaktifkan. Untuk klaster yang terdiri dari armada instans, metrik kapasitas klaster diukur dalam `Units`. Untuk klaster yang terdiri dari grup instans, metrik kapasitas klaster diukur dalam `Nodes` atau `vCPU` berdasarkan jenis unit yang digunakan dalam kebijakan penskalaan terkelola.
| Metrik | Deskripsi |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Jumlah total target units/nodes/vCPUs dalam sebuah cluster sebagaimana ditentukan oleh scaling terkelola. Unit: *Count (Jumlah)* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Jumlah total saat ini yang units/nodes/vCPUs tersedia di cluster yang sedang berjalan. Ketika ada permintaan perubahan ukuran klaster, metrik ini akan diperbarui setelah instans baru ditambahkan atau dihapus dari klaster. Unit: *Jumlah* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Jumlah target CORE units/nodes/vCPUs dalam sebuah cluster ditentukan oleh scaling terkelola. Unit: *Count (Jumlah)* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Jumlah CORE saat ini units/nodes/vCPUs berjalan dalam sebuah cluster. Unit: *Count (Jumlah)* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Jumlah target TASK units/nodes/vCPUs dalam klaster yang ditentukan oleh penskalaan terkelola. Unit: *Count (Jumlah)* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/managed-scaling-metrics.html) | Jumlah TASK saat ini units/nodes/vCPUs berjalan dalam sebuah cluster. Unit: *Jumlah* |
Metrik berikut menunjukkan status penggunaan klaster dan aplikasi. Metrik ini tersedia untuk semua fitur Amazon EMR, tetapi diterbitkan pada resolusi yang lebih tinggi dengan data pada rincian satu menit ketika penskalaan terkelola diaktifkan untuk sebuah klaster. Anda dapat mengkorelasikan metrik berikut dengan metrik kapasitas klaster di tabel sebelumnya untuk memahami keputusan penskalaan terkelola.
| Metrik | Deskripsi |
| --- | --- |
| `AppsCompleted` | Jumlah aplikasi yang dikirimkan ke YARN yang telah selesai. Kasus penggunaan: Memantau kemajuan klaster Unit: *Jumlah* |
| `AppsPending` | Jumlah aplikasi yang dikirimkan ke YARN yang berada dalam status tertunda. Kasus penggunaan: Memantau kemajuan klaster Unit: *Jumlah* |
| `AppsRunning` | Jumlah aplikasi yang dikirimkan ke YARN yang sedang berjalan. Kasus penggunaan: Memantau kemajuan klaster Unit: *Jumlah* |
| ContainerAllocated | Jumlah wadah sumber daya yang dialokasikan oleh. ResourceManager Kasus penggunaan: Memantau kemajuan klaster Unit: *Jumlah* |
| `ContainerPending` | Jumlah kontainer dalam antrean yang belum dialokasikan. Kasus penggunaan: Memantau kemajuan klaster Unit: *Jumlah* |
| ContainerPendingRatio | Rasio kontainer yang tertunda dengan kontainer yang dialokasikan (ContainerPendingRatio = ContainerPending / ContainerAllocated). Jika ContainerAllocated = 0, maka ContainerPendingRatio =ContainerPending. Nilai ContainerPendingRatio mewakili angka, bukan persentase. Nilai ini berguna untuk menskalakan sumber daya klaster berdasarkan perilaku alokasi kontainer. Unit: *Jumlah* |
| `HDFSUtilization` | Persentase penyimpanan HDFS yang saat ini digunakan. Kasus penggunaan: Menganalisis performa klaster Unit: *Persen* |
| `IsIdle` | Menunjukkan bahwa klaster tidak lagi melakukan pekerjaan, tetapi masih hidup dan menimbulkan biaya. Diatur ke 1 jika tidak ada tugas yang berjalan dan tidak ada pekerjaan yang berjalan, dan diatur ke 0 jika sebaliknya. Nilai ini diperiksa pada interval lima menit dan nilai 1 hanya menunjukkan bahwa klaster tersebut menganggur ketika diperiksa, bukan bahwa klaster tersebut menganggur selama lima menit tersebut. Untuk menghindari positif yang salah, Anda harus menyalakan alarm ketika nilai ini 1 selama lebih dari satu pemeriksaan lima menit berturut-turut. Misalnya, Anda mungkin menyalakan alarm pada nilai ini jika telah 1 selama tiga puluh menit atau lebih. Kasus penggunaan: Memantau performa klaster Unit: *Boolean* |
| `MemoryAvailableMB` | Jumlah memori yang tersedia untuk dialokasikan. Kasus penggunaan: Memantau kemajuan klaster Unit: *Jumlah* |
| `MRActiveNodes` | Jumlah node yang saat ini menjalankan MapReduce tugas atau pekerjaan. Setara dengan metrik YARN `mapred.resourcemanager.NoOfActiveNodes`. Kasus penggunaan: Memantau kemajuan klaster Unit: *Jumlah* |
| `YARNMemoryAvailablePercentage` | Persentase sisa memori yang tersedia untuk YARN (YARNMemoryAvailablePercentage = MemoryAvailable MB/MemoryTotalMB). Nilai ini berguna untuk menskalakan sumber daya klaster berdasarkan penggunaan memori YARN. Unit: *Persen* |
Metrik berikut memberikan informasi tentang sumber daya yang digunakan oleh wadah dan node YARN. Metrik dari manajer sumber daya YARN ini menawarkan wawasan tentang sumber daya yang digunakan oleh kontainer dan node yang berjalan di cluster. Membandingkan metrik ini dengan metrik kapasitas klaster tabel sebelumnya memberikan gambaran yang lebih jelas tentang dampak penskalaan terkelola:
| Metrik | Rilis terkait | Deskripsi |
| --- | --- | --- |
| `YarnContainersUsedMemoryGBSeconds` | Tersedia untuk merilis label 7.3.0 dan lebih tinggi | Memori kontainer yang dikonsumsi\$1 detik untuk periode penerbitan. **Satuan:** GB\$1 detik |
| `YarnContainersTotalMemoryGBSeconds` | Tersedia untuk merilis label 7.3.0 dan lebih tinggi | Total wadah benang\$1 detik untuk periode penerbitan. **Satuan:** GB\$1 detik |
| `YarnContainersUsedVCPUSeconds` | Tersedia untuk merilis label 7.5.0 dan lebih tinggi | Kontainer yang dikonsumsi VCPU \$1 detik untuk periode penerbitan. **Unit:** VCPU \$1 detik |
| `YarnContainersTotalVCPUSeconds` | Tersedia untuk merilis label 7.5.0 dan lebih tinggi | Total kontainer VCPU \$1 detik untuk periode penerbitan. **Unit:** VCPU \$1 detik |
| `YarnNodesUsedMemoryGBSeconds` | Tersedia untuk merilis label 7.5.0 dan lebih tinggi | Memori node yang dikonsumsi\$1 detik untuk periode penerbitan. **Satuan:** GB\$1 detik |
| `YarnNodesTotalMemoryGBSeconds` | Tersedia untuk merilis label 7.5.0 dan lebih tinggi | Total memori node \$1 detik untuk periode penerbitan. **Satuan:** GB\$1 detik |
| `YarnNodesUsedVCPUSeconds` | Tersedia untuk merilis label 7.3.0 dan lebih tinggi | Node VCPU yang dikonsumsi \$1 detik untuk periode penerbitan. **Unit:** VCPU \$1 detik |
| `YarnNodesTotalVCPUSeconds` | Tersedia untuk merilis label 7.3.0 dan lebih tinggi | Total node VCPU \$1 detik untuk periode penerbitan. **Unit:** VCPU \$1 detik |
## Membuat grafik metrik penskalaan terkelola
Anda dapat membuat grafik metrik untuk memvisualisasikan pola beban kerja klaster Anda dan keputusan penskalaan terkait yang dibuat oleh penskalaan terkelola Amazon EMR seperti yang ditunjukkan oleh langkah-langkah berikut.
**Untuk membuat grafik metrik penskalaan terkelola di konsol CloudWatch**
1. Buka [konsol CloudWatch](https://console.aws.amazon.com/cloudwatch/).
1. Di panel navigasi, pilih **Amazon EMR**. Anda dapat mencari di pengidentifikasi klaster pada klaster tersebut untuk memantau.
1. Gulir ke bawah ke metrik untuk membuat grafik. Buka metrik untuk menampilkan grafik.
1. Untuk membuat grafik pada satu metrik atau lebih, pilih kotak centang di samping setiap metrik.
Contoh berikut menggambarkan aktivitas penskalaan terkelola Amazon EMR dari sebuah cluster. Grafik menunjukkan tiga periode penskalaan otomatis, yang menghemat biaya ketika ada beban kerja yang kurang aktif.
![\[Buat grafik metrik penskalaan terkelola\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/Managed_Scaling_Decision.png)
Semua metrik penggunaan dan kapasitas klaster dipublikasikan pada interval satu menit. Informasi statistik tambahan juga dikaitkan dengan setiap data satu menit, yang memungkinkan Anda merencanakan berbagai fungsi seperti `Percentiles`, `Min`, `Max`, `Sum`, `Average`, `SampleCount`.
Misalnya, grafik berikut menggambarkan metrik `YARNMemoryAvailablePercentage` yang sama pada persentil yang berbeda, P10, P50, P90, P99, bersama dengan `Sum`, `Average`, `Min`, `SampleCount`.
![\[Membuat grafik metrik penskalaan terkelola dengan persentil yang berbeda\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/Managed_Scaling_Metrics.png)