Pemetaan resource dari hardware lokal ke Google Cloud

Dokumen ini menunjukkan cara menemukan pemetaan resource yang tepat dari hardware lokal ke Google Cloud. Ketika aplikasi Anda berjalan di server bare metal dan Anda ingin memigrasikannya ke Google Cloud, pertimbangkan pertanyaan berikut:

  • Bagaimana cara inti fisik (pCPU) dipetakan ke CPU virtual (vCPU) di Google Cloud? Misalnya, bagaimana cara memetakan 4 inti fisik bare metal Xeon E5 ke vCPU di Google Cloud?
  • Bagaimana cara mempertimbangkan perbedaan performa antara platform CPU dan generasi pemroses yang berbeda? Misalnya, apakah Sandy Bridge 3,0 GHz 1,5 kali lebih cepat daripada Skylake 2,0 GHz?
  • Bagaimana Anda menyesuaikan ukuran resource yang tepat berdasarkan workload Anda? Misalnya, bagaimana cara mengoptimalkan aplikasi thread tunggal yang menggunakan memori secara intensif yang berjalan di server multi-inti?

Soket, CPU, inti, dan thread

Istilah soket, CPU, inti, dan thread seringnya digunakan secara bergantian, sehingga dapat menimbulkan kebingungan saat Anda bermigrasi antara lingkungan yang berbeda.

Sederhananya, server dapat memiliki satu soket atau lebih. Soket (juga disebut soket CPU atau slot CPU) adalah konektor pada motherboard yang menampung chip CPU dan menyediakan koneksi fisik antara CPU dan papan sirkuit.

CPU mengacu pada sirkuit terintegrasi (IC) yang sebenarnya. Operasi dasar CPU adalah mengeksekusi urutan instructions yang tersimpan. Pada dasarnya, CPU mengikuti langkah-langkah ambil, dekode, dan eksekusi, yang secara kolektif dikenal sebagai siklus petunjuk. Pada CPU yang lebih kompleks, beberapa instruksi dapat diambil, di-dekode, dan dieksekusi secara bersamaan.

Setiap chip CPU dapat memiliki satu atau beberapa inti. Inti pada dasarnya terdiri dari unit eksekusi yang menerima petunjuk dan melakukan tindakan berdasarkan petunjuk tersebut. Dalam sebuah sistem hyper-thread, inti pemroses fisik memungkinkan resource dialokasikan sebagai beberapa pemroses logis. Dengan kata lain, setiap inti pemroses fisik disajikan sebagai dua inti virtual (atau logis) pada sistem operasi.

Diagram berikut menunjukkan tampilan umum dari CPU quad-core dengan hyper-threading yang diaktifkan.

CPU quad-core dengan hyper-threading yang diaktifkan.

Di Google Cloud, setiap vCPU diterapkan sebagai hyper-thread tunggal di salah satu platform CPU yang tersedia.

Untuk menemukan jumlah total vCPU (CPU logis) dalam sistem, Anda dapat menggunakan formula berikut:

vCPUs = vCPUs × vCPUs × jumlah soket

Perintah lscpu mengumpulkan informasi yang mencakup jumlah soket, CPU, inti, dan thread. Perintah ini juga mencakup informasi tentang cache CPU dan cache bersama, kelompok, model, dan BogoMips. Berikut adalah beberapa output standar:

...
Architecture:           x86_64
CPU(s):                 1
On-line CPU(s) list:    0
Thread(s) per core:     1
Core(s) per socket:     1
Socket(s):              1
CPU MHz:                2200.000
BogoMIPS:               4400.00
...

Saat memetakan resource CPU antara lingkungan yang ada dan Google Cloud, pastikan Anda mengetahui berapa banyak inti fisik dan virtual yang dimiliki server Anda. Untuk informasi selengkapnya, lihat bagian Memetakan resource.

Kecepatan clock CPU

Agar dapat dieksekusi, program harus dipecah menjadi serangkaian petunjuk yang dipahami oleh pemroses. Pertimbangkan program C berikut yang menjumlahkan dua angka dan menampilkan hasilnya:

#include <stdio.h>
int main()
{
        int a = 11, b = 8;
        printf("%d \n", a+b);
}

Saat kompilasi, program akan dikonversi menjadi kode assembly berikut:

...
main:
.LFB0:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        subq    $16, %rsp
        movl    $11, -8(%rbp)
        movl    $8, -4(%rbp)
        movl    -8(%rbp), %edx
        movl    -4(%rbp), %eax
        addl    %edx, %eax
        movl    %eax, %esi
        movl    $.LC0, %edi
        movl    $0, %eax
        call    printf
        movl    $0, %eax
        leave
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
...

Setiap petunjuk assembly dalam output sebelumnya sesuai dengan satu petunjuk mesin. Misalnya, petunjuk pushq menunjukkan bahwa konten register RBP harus dikirim ke stack program. Dalam setiap siklus CPU, CPU dapat menjalankan operasi dasar seperti mengambil petunjuk, mengakses konten dari register, atau menulis data. Untuk melalui setiap tahap siklus guna menambahkan dua angka, lihat simulator CPU ini.

Perhatikan bahwa setiap petunjuk CPU mungkin memerlukan beberapa siklus clock untuk dieksekusi. Jumlah rata-rata siklus clock yang dibutuhkan per petunjuk untuk sebuah program ditentukan oleh siklus per petunjuk (CPI) seperti:

siklus per instruksi = jumlah siklus CPU yang digunakan / jumlah instruksi yang dieksekusi

Sebagian besar CPU modern dapat mengeksekusi beberapa instruksi per siklus clock melalui pipeline petunjuk. Jumlah rata-rata petunjuk yang dieksekusi per siklus ditentukan oleh petunjuk per siklus (IPC), seperti:

petunjuk per siklus = jumlah instruksi yang dieksekusi / jumlah siklus CPU yang digunakan

Kecepatan clock CPU ditentukan oleh jumlah siklus clock yang dieksekusi pemroses per detiknya. Misalnya, pemroses 3.0 GHz dapat mengeksekusi 3 miliar siklus clock per detik. Artinya, setiap siklus clock memerlukan waktu ~0,3 nanodetik untuk dieksekusi. Dalam setiap siklus clock, CPU dapat menjalankan 1 petunjuk atau lebih seperti yang ditentukan oleh IPC.

Kecepatan clock biasanya digunakan untuk membandingkan performa pemroses. Berdasarkan definisi literalnya (jumlah siklus yang dieksekusi per detik), Anda mungkin menyimpulkan bahwa jumlah siklus clock yang lebih tinggi berarti CPU dapat melakukan lebih banyak pekerjaan dan memiliki performa yang lebih baik. Kesimpulan ini mungkin valid ketika membandingkan CPU dalam generasi pemroses yang sama. Namun, kecepatan clock tidak boleh digunakan sebagai satu-satunya indikator performa saat membandingkan CPU di berbagai kelompok prosesor. CPU generasi baru mungkin memberikan performa yang lebih baik meskipun berjalan pada kecepatan clock yang lebih rendah daripada CPU generasi sebelumnya.

Kecepatan clock dan performa sistem

Untuk lebih memahami performa pemroses, penting untuk tidak hanya melihat jumlah siklus clock tetapi juga jumlah pekerjaan yang dapat dilakukan CPU per siklus. Total waktu eksekusi program yang terikat dengan CPU tidak hanya bergantung pada kecepatan clock, tetapi juga faktor lain seperti jumlah petunjuk yang akan dieksekusi, siklus per petunjuk, atau petunjuk per siklus, arsitektur kumpulan petunjuk, penjadwalan dan dispatching algoritma, serta bahasa pemrograman yang digunakan. Faktor-faktor ini dapat sangat bervariasi dari satu generasi pemroses ke generasi lainnya.

Untuk memahami bagaimana eksekusi CPU dapat bervariasi di dua penerapan yang berbeda, lihat contoh program faktorial sederhana. Salah satu program berikut ditulis dalam C dan program lainnya dalam Python. Perf (alat pembuatan profil untuk Linux) digunakan untuk merekam beberapa metrik CPU dan kernel.

Program C

#include <stdio.h>
int main()
{
    int n=7, i;
    unsigned int factorial = 1;
    for(i=1; i<=n; ++i){
            factorial *= i;
    }

    printf("Factorial of %d = %d", n, factorial);
}

Performance counter stats for './factorial':

...
0             context-switches       #    0.000 K/sec
0             cpu-migrations         #    0.000 K/sec
45            page-faults            #    0.065 M/sec
1,562,075     cycles                 #    1.28 GHz
1,764,632     instructions           #    1.13  insns per cycle
314,855       branches               #    257.907 M/sec
8,144         branch-misses          #    2.59% of all branches
...

0.001835982 seconds time elapsed

Program Python

num = 7
factorial = 1
for i in range(1,num + 1):
  factorial = factorial*i
print("The factorial of",num,"is",factorial)

Performance counter stats for 'python3 factorial.py':

...
7              context-switches      #    0.249 K/sec
0              cpu-migrations        #    0.000 K/sec
908            page-faults           #    0.032 M/sec
144,404,306    cycles                #    2.816 GHz
158,878,795    instructions          #    1.10  insns per cycle
38,254,589     branches              #    746.125 M/sec
945,615        branch-misses         #    2.47% of all branches
...

0.029577164 seconds time elapsed

Output yang ditandai menunjukkan total waktu yang diperlukan untuk mengeksekusi setiap program. Program yang ditulis dalam C dieksekusi ~15 kali lebih cepat daripada program yang ditulis dalam Python (1,8 milidetik vs. 30 milidetik). Berikut adalah beberapa perbandingan tambahan:

  • Pengalihan konteks. Saat scheduler sistem perlu menjalankan program lain atau saat gangguan memicu eksekusi yang sedang berlangsung, sistem operasi akan menyimpan konten register CPU program yang sedang berjalan dan menyiapkannya untuk eksekusi program baru. Tidak ada pengalihan konteks yang muncul selama eksekusi program C, tetapi 7 pengalihan konteks muncul selama eksekusi program Python.

  • Migrasi CPU. Sistem operasi mencoba mempertahankan keseimbangan workload di antara CPU yang tersedia dalam sistem multi prosesor. Penyeimbangan ini dilakukan secara berkala dan setiap kali antrean eksekusi CPU kosong. Selama pengujian, tidak ada migrasi CPU yang diamati.

  • Petunjuk. Program C menghasilkan 1.7 juta petunjuk yang dieksekusi dalam 1.5 juta siklus CPU (IPC = 1.13, CPI = 0.88), sedangkan program Python menghasilkan 158 juta petunjuk yang dieksekusi dalam 144 juta siklus (IPC = 1.10, CPI = 0.91). Kedua program mengisi pipeline, sehingga CPU dapat menjalankan lebih dari 1 petunjuk per siklus. Namun, dibandingkan dengan C, jumlah petunjuk yang dihasilkan untuk Python sekitar 90 kali lebih besar.

  • Kesalahan halaman. Setiap program memiliki bagian memori virtual yang berisi semua petunjuk dan datanya. Biasanya, menyalin semua petunjuk ini sekaligus dalam memori utama tidak akan efisien. Sebuah kesalahan halaman terjadi setiap kali program memerlukan bagian dari konten memori virtualnya untuk disalin dalam memori utama. Kesalahan halaman ditandai oleh CPU melalui gangguan.

    Karena penafsir yang dapat dieksekusi untuk python jauh lebih besar dari C, overhead tambahan terlihat jelas dalam hal siklus CPU (1.5 juta untuk C, 144 juta untuk Python) dan kesalahan halaman (45 untuk C, 908 untuk Python).

  • Cabang dan cabang tidak ditemukan. Untuk petunjuk kondisional, CPU mencoba memprediksi jalur eksekusi bahkan sebelum mengevaluasi kondisi percabangan. Langkah tersebut berguna untuk menjaga pipeline petunjuk tetap terisi. Proses ini disebut eksekusi spekulatif. Eksekusi spekulatif cukup berhasil dalam eksekusi sebelumnya: prediktor cabang hanya melakukan kesalahan sebanyak 2.59% untuk program di C, dan 2.47% untuk program di Python.

Faktor selain CPU

Sejauh ini, Anda telah melihat berbagai aspek CPU dan dampaknya terhadap performa. Namun, sangat jarang aplikasi dapat mempertahankan eksekusi CPU aktif 100% sepanjang waktu. Sebagai contoh sederhana, perhatikan perintah tar berikut yang membuat arsip dari direktori home pengguna di Linux:

$ time tar cf archive.tar /home/"$(whoami)"

Outputnya akan terlihat seperti ini: 

real  0m35.798s
user  0m1.146s
sys   0m6.256s

Nilai output ini didefinisikan sebagai berikut:

real time
Real time (real) adalah jumlah waktu yang dibutuhkan untuk melakukan eksekusi dari awal hingga akhir. Waktu berlalu ini mencakup irisan waktu yang digunakan oleh proses lain dan waktu saat proses diblokir, misalnya, saat menunggu operasi I/O selesai.
waktu pengguna
Waktu pengguna (user) adalah jumlah waktu CPU yang digunakan untuk mengeksekusi kode ruang pengguna dalam proses.
waktu sistem
Waktu sistem (sys) adalah jumlah waktu CPU yang digunakan untuk mengeksekusi kode ruang kernel dalam proses.

Pada contoh sebelumnya, waktu pengguna adalah 1,0 detik, sedangkan waktu sistem adalah 6,3 detik. Perbedaan ~28 detik antara waktu real dan user + sys mengarahkan ke waktu CPU nonaktif yang digunakan oleh perintah tar.

Waktu CPU nonaktif untuk eksekusi mengindikasikan proses tersebut tidak terikat pada CPU. Komputasi dikatakan terikat oleh sesuatu jika resource tersebut menjadi hambatan untuk mencapai performa yang diharapkan. Saat merencanakan migrasi, penting untuk memiliki gambaran menyeluruh tentang aplikasi dan mempertimbangkan semua faktor yang dapat memberikan dampak signifikan pada performa.

Peran workload target dalam migrasi

Untuk menemukan titik awal yang wajar untuk migrasi, penting untuk membandingkan resource yang mendasarinya. Anda dapat melakukan tolok ukur performa dengan berbagai cara:

  • Workload target aktual: Men-deploy aplikasi di lingkungan target dan membandingkan performa dari indikator performa utama (KPI). Misalnya, KPI untuk aplikasi web dapat mencakup hal berikut:

    • Waktu pemuatan aplikasi
    • Latensi pengguna akhir untuk transaksi end-to-end
    • Koneksi terputus
    • Jumlah instance penyaluran untuk traffic rendah, rata-rata, dan puncak
    • Penggunaan resource (CPU, RAM, disk, jaringan) dari instance penyaluran

    Namun, men-deploy aplikasi target lengkap (atau subset) dapat menjadi proses yang kompleks dan memakan waktu. Untuk pengukuran awal, tolok ukur berbasis program umumnya lebih diutamakan.

  • Tolok ukur berbasis program: Tolok ukur berbasis program berfokus pada komponen aplikasi individual, bukan alur aplikasi end-to-end. Tolok ukur ini menjalankan campuran profil pengujian, dengan setiap profil ditargetkan ke satu komponen aplikasi. Misalnya, profil pengujian untuk deployment LAMP stack dapat mencakup Apache Bench, yang digunakan untuk mengukur performa server web, dan Sysbench, yang digunakan untuk mengukur MySQL. Pengujian ini umumnya lebih mudah untuk disiapkan dibandingkan dengan workload target aktual dan sangat portabel untuk berbagai sistem operasi dan lingkungan.

  • Kernel atau tolok ukur sintetik: Untuk menguji aspek utama program nyata yang secara komputasi intensif, Anda dapat menggunakan tolok ukur sintetis seperti faktorisasi matriks atau FFT. Anda biasanya menjalankan pengujian ini selama fase awal desain aplikasi. Alat ini paling cocok untuk menjalankan tolok ukur hanya pada aspek tertentu dari mesin seperti VM dan daya tahan, sinkronisasi I/O, dan cache thrashing.

Memahami aplikasi Anda

Banyak aplikasi terikat oleh CPU, memori, I/O disk, dan I/O jaringan, atau kombinasi dari faktor-faktor ini. Misalnya, jika aplikasi mengalami kelambatan karena konflik pada disk, menyediakan lebih banyak inti ke server mungkin tidak dapat meningkatkan performa.

Perhatikan bahwa mempertahankan kemampuan observasi aplikasi di lingkungan yang besar dan kompleks bisa jadi sangat sulit. Ada sistem pemantauan khusus yang dapat melacak semua sumber daya yang terdistribusi di seluruh sistem. Misalnya, di Google Cloud Anda dapat menggunakan Cloud Monitoring untuk mendapatkan visibilitas penuh di seluruh kode, aplikasi, dan infrastruktur Anda. Contoh Cloud Monitoring akan dibahas lebih lanjut di bagian ini, tetapi sebaiknya pahami terlebih dahulu pemantauan resource sistem umum di server mandiri.

Berbagai aplikasi utilitas seperti top, IOStat, VMStat, dan iPerf dapat memberikan tampilan umum dari resource sistem. Misalnya, menjalankan top di sistem Linux menghasilkan output seperti ini:

top - 13:20:42 up 22 days,  5:25,         18 users,        load average: 3.93 2.77,3.37
Tasks:  818 total,        1 running,      760 sleeping,    0 stopped,       0 zombie
Cpu(s): 88.2%us,          0.0%sy,         0.0%ni,          0.3%id,          0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:    49375504k total,  6675048k used,  42700456k free,  276332k buffers
Swap:   68157432k total,  0k used,        68157432k free,  5163564k cached

Jika sistem memiliki beban dan persentase waktu tunggu yang tinggi, Anda mungkin memiliki aplikasi yang terikat dengan I/O. Jika salah satu atau kedua waktu persentase pengguna atau waktu persentase sistem sangat tinggi, kemungkinan Anda memiliki aplikasi yang terikat dengan CPU.

Di contoh sebelumnya, rata-rata beban (untuk 4 vCPU VM) dalam 5 menit, 10 menit, dan 15 menit terakhir adalah 3.93, 2.77, and 3.37 secara berurutan. Jika Anda menggabungkan rata-rata ini dengan persentase waktu pengguna yang tinggi (88.2%), waktu tidak ada aktivitas yang rendah (0.3%), dan tidak ada waktu tunggu (0.0%), Anda dapat menyimpulkan bahwa sistem tersebut terikat ke CPU.

Meskipun berfungsi dengan baik untuk sistem mandiri, alat ini umumnya tidak dirancang untuk memantau lingkungan terdistribusi yang besar. Untuk memantau sistem produksi, alat seperti Cloud Monitoring, .Nagios .Prometheus, dan Sysdig dapat memberikan analisis konsumsi resource mendalam terhadap aplikasi Anda.

Pemantauan performa aplikasi selama jangka waktu yang memadai memungkinkan Anda mengumpulkan data di berbagai metrik, seperti pemakaian CPU, penggunaan memori, I/O disk, I/O jaringan, waktu roundtrip, latensi, tingkat error, dan throughput. Misalnya, grafik Cloud Monitoring berikut menunjukkan tingkat pemuatan dan pemakaian CPU dengan penggunaan memori dan disk untuk semua server yang berjalan grup instance terkelola Google Cloud. Untuk mempelajari lebih lanjut tentang penyiapan ini, lihat ringkasan agen Cloud Monitoring.

Pemuatan CPU, tingkat pemakaian, dan penggunaan memori dan disk untuk semua server yang berjalan di grup instance terkelola.

Untuk analisis, periode pengumpulan data harus berjalan cukup lama untuk menunjukkan pemakaian resource yang mencapai puncak dan secara menyeluruh. Anda kemudian dapat menganalisis data yang terkumpul untuk menyediakan titik awal untuk perencanaan kapasitas di lingkungan target baru.

Memetakan resource

Bagian ini membahas cara menetapkan ukuran resource di Google Cloud. Pertama, Anda membuat penilaian ukuran awal berdasarkan tingkat pemakaian resource yang ada. Kemudian, jalankan pengujian tolok ukur performa spesifik per aplikasi.

Pengukuran berdasarkan penggunaan

Ikuti langkah berikut untuk memetakan jumlah inti server yang ada ke vCPU di Google Cloud.

  1. Temukan jumlah inti saat ini. Lihat perintah lscpu di bagian sebelumnya

  2. Temukan pemakaian CPU server. Penggunaan CPU mengacu pada waktu yang dibutuhkan CPU saat berada dalam mode pengguna (%us) atau mode kernel (%sy). Proses Nice (%ni) juga termasuk dalam mode pengguna, sedangkan gangguan software (%si) dan gangguan hardware (%hi) ditangani dalam mode kernel. Jika CPU tidak melakukan semua ini, bisa berarti CPU tidak ada aktivitas atau menunggu I/O selesai. Ketika suatu proses menunggu I/O selesai, proses itu tidak berkontribusi pada siklus CPU.

    Untuk menghitung penggunaan CPU server saat ini, jalankan perintah top berikut:

    ...
Cpu(s): 88.2%us,  0.0%sy,  0.0%ni,  0.3%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
...

    Penggunaan CPU didefinisikan sebagai berikut:

    CPU Usage = %us + %sy + %ni + %hi + %si

    Atau, Anda dapat menggunakan alat pemantauan apa pun seperti Cloud Monitoring yang dapat mengumpulkan inventaris dan pemakaian CPU yang diperlukan. Untuk deployment aplikasi yang bukan penskalaan otomatis (yaitu, dijalankan dengan satu atau beberapa server tetap), sebaiknya pertimbangkan untuk menggunakan pemakaian puncak untuk pengukuran CPU. Pendekatan ini mengamankan resource aplikasi dari gangguan saat workload berada pada puncak penggunaan. Untuk deployment penskalaan otomatis (berdasarkan penggunaan CPU), pemakaian CPU secara rata-rata merupakan dasar pengukuran yang aman untuk dipertimbangkan saat pengukuran. Dalam kasus ini, Anda menangani lonjakan traffic dengan penyebaran skala jumlah server selama durasi lonjakan.

  3. Alokasikan buffer yang memadai untuk mengakomodasi lonjakan. Saat Anda mengukur CPU, sertakan buffer yang memadai untuk mengakomodasi pemrosesan tidak terjadwal yang dapat menyebabkan lonjakan tak terduga. Misalnya, Anda dapat merencanakan kapasitas CPU sehingga ada kapasitas tambahan sebesar 10–15% dari penggunaan maksimum yang diharapkan, dan penggunaan CPU maksimum secara keseluruhan tidak melebihi 70%.

  4. Gunakan formula berikut untuk menghitung jumlah inti yang diharapkan di GCP:

    vCPU di Google Cloud = 2 × CEILING[(jumlah inti × utilization%) / (2 × threshold%)]

    Nilai ini didefinisikan sebagai berikut:

    • jumlah inti: Jumlah inti yang ada (seperti yang dihitung pada langkah 1).
    • utilization%: Pemakaian CPU server (seperti yang dihitung pada langkah 2).
    • threshold%: Penggunaan CPU maksimum yang diizinkan di server setelah memperhitungkan kapasitas tambahan yang memadai (seperti yang dihitung pada langkah 3).

Untuk contoh konkret, pertimbangkan skenario saat Anda harus memetakan jumlah inti server bare metal 4-core Xeon E5640 yang berjalan secara lokal ke vCPU di Google Cloud. Spesifikasi Xeon E5640 tersedia secara publik, tetapi Anda juga dapat mengonfirmasi hal ini dengan menjalankan perintah seperti lscpu pada sistem. Angkanya akan terlihat seperti berikut:

  • jumlah inti yang ada di infrastruktur lokal = soket (1) × inti (4) × thread per inti (2 ) = 8.
  • Misalkan pemakaian CPU (utilization%) yang diamati selama traffic puncak mencapai 40%.
  • Terdapat penyediaan buffer tambahan sebanyak 30%, yang berarti pemakaian CPU maksimum (threshold%) harus tidak melampaui 70%.
  • vCPU di Google Cloud = 2 × CEILING[(8 × 0.4)/(2 × 0.7)] = 6 vCPU
    (berarti, 2 × CEILING[3.2/1.4] = 2 × CEILING[2.28] = 2 × 3 = 6)

Anda dapat melakukan penilaian serupa untuk RAM, disk, I/O jaringan, dan resource sistem lainnya.

Pengukuran berbasis performa

Bagian sebelumnya membahas detail mengenai memetakan pCPU ke vCPU berdasarkan tingkat saat ini dan perkiraan tingkat penggunaan CPU. Bagian ini mempertimbangkan aplikasi yang berjalan di server.

Di bagian ini, Anda menjalankan rangkaian pengujian kanonis (tolok ukur berbasis program) untuk mengukur performa. Melanjutkan contoh skenario, anggaplah Anda sedang menjalankan server MySQL di mesin Xeon E5. Dalam hal ini, Anda dapat menggunakan Sysbench OLTP untuk mengukur performa database.

Pengujian baca-tulis sederhana di MySQL yang menggunakan Sysbench menghasilkan output berikut:

OLTP test statistics:
  queries performed:
    read:              520982
    write:             186058
    other:             74424
    total:             781464
  transactions:        37211 (620.12 per sec.)
  deadlocks:           2 (0.03 per sec.)
  read/write requests: 707040 (11782.80 per sec.)
  other operations:    74424 (1240.27 per sec.)

Test execution summary:
  total time:          60.0061s
  total number of events: 37211
  total time taken by event execution: 359.8158
  per-request statistics:
    min:            2.77ms
    avg:            9.67ms
    max:            50.81ms
    approx. 95 percentile: 14.63ms

Thread fairness:
  events (avg/stddev):         6201.8333/31.78
  execution time (avg/stddev): 59.9693/0.00

Dengan menjalankan tolok ukur ini, Anda dapat membandingkan performa dalam hal jumlah transaksi per detik, total baca/tulis per detik, dan waktu eksekusi end-to-end antara lingkungan Anda saat ini dan Google Cloud. Sebaiknya jalankan beberapa iterasi pengujian berikut untuk mencegah adanya pencilan. Untuk mengamati perbedaan performa dengan beban dan pola traffic yang bervariasi, Anda juga dapat mengulang pengujian ini menggunakan parameter yang berbeda, seperti tingkat konkurensi, durasi pengujian, dan jumlah simulasi pengguna atau kecepatan hatch yang bervariasi.

Angka performa antara lingkungan saat ini dan Google Cloud akan membantu merasionalisasikan penilaian kapasitas awal Anda lebih lanjut. Jika pengujian tolok ukur di Google Cloud memberikan hasil yang serupa atau lebih baik daripada lingkungan yang ada, Anda dapat menyesuaikan skala resource lebih lanjut berdasarkan peningkatan performa. Di sisi lain, jika tolok ukur di lingkungan yang ada lebih baik dari Google Cloud, lakukan hal berikut:

  • Tinjau kembali penilaian kapasitas awal.
  • Pantau resource sistem.
  • Temukan kemungkinan area konflik (misalnya, bottleneck yang teridentifikasi pada CPU dan RAM).
  • Ubah ukuran resource.

Setelah selesai, jalankan kembali pengujian tolok ukur spesifik per aplikasi Anda.

Tolok ukur performa end-to-end

Sejauh ini, Anda telah melihat skenario sederhana yang hanya membandingkan performa MySQL antara infrastruktur lokal dan Google Cloud. Di bagian ini, Anda akan mempertimbangkan aplikasi 3 tingkat terdistribusi berikut.

Aplikasi 3 tingkat terdistribusi.

Seperti yang ditunjukkan dalam diagram, Anda mungkin telah menjalankan beberapa tolok ukur untuk mendapatkan penilaian yang wajar terhadap lingkungan Anda saat ini dan Google Cloud. Namun, mungkin akan sulit untuk menetapkan subset tolok ukur mana yang memberikan estimasi paling akurat untuk performa aplikasi Anda. Selain itu, mengelola proses pengujian dari pengelolaan dependensi hingga penginstalan, eksekusi, dan agregasi hasil pengujian di lingkungan cloud or non-cloud yang berbeda dapat menjadi tugas yang membosankan. Untuk skenario semacam itu, Anda dapat menggunakan PerfKitBenchmarker. PerfKit terdiri dari berbagai set tolok ukur untuk mengukur dan membandingkan berbagai penawaran di beberapa cloud. PerfKit juga dapat menjalankan tolok ukur tertentu secara lokal melalui mesin statis.

Misalkan untuk aplikasi 3 tingkat di diagram sebelumnya, Anda ingin menjalankan pengujian untuk tolok ukur waktu booting cluster dan performa jaringan VM di Google Cloud. Dengan menggunakan PerfKitBenchmarker, Anda dapat menjalankan beberapa iterasi profil pengujian yang relevan, yang memberikan hasil berikut:

  • Waktu booting cluster: Memberikan tampilan waktu booting VM. Hal ini sangat penting jika aplikasi bersifat elastis dan mengharapkan instance ditambahkan atau dihapus sebagai bagian dari penskalaan otomatis. Grafik berikut menunjukkan waktu booting instance n1-standard-4 Compute Engine tetap cukup konsisten (hingga persentil ke-99) pada 40–45 detik.

    Waktu booting instance Compute Engine n1-standard-4.

  • Stress-ng: Mengukur dan membandingkan performa intensif komputasi dengan menguji daya tahan pemroses, subsistem memori, dan compiler sistem. Dalam contoh berikut, stress-ng menjalankan beberapa pengujian daya tahan seperti bsearch, malloc, matrix, mergesort, dan zlib di instance Compute Engine n1-standard-4. Stress-ng mengukur throughput pengujian daya tahan menggunakan operasi palsu (operasi bogo) per detik. Jika menormalisasi operasi bogo di berbagai hasil uji daya tahan yang berbeda, Anda akan mendapatkan output berikut, yang menunjukkan rata-rata geometris operasi yang dijalankan per detik. Di contoh ini, operasi bogo berkisar dari ~8,000 per detik pada persentil ke-50 hingga ~10,000 per detik pada persentil ke-95. Perhatikan bahwa operasi bogo umumnya digunakan untuk melakukan tolok ukur performa CPU mandiri saja. Operasi ini mungkin tidak memberikan representasi yang tepat untuk aplikasi Anda.

    Rata-rata geometris operasi yang dieksekusi per detik.

  • Netperf: Mengukur latensi dengan pengujian permintaan dan respons. Pengujian permintaan dan respons dijalankan pada lapisan aplikasi pada stack jaringan. Metode pengujian latensi ini melibatkan semua lapisan stack dan lebih disukai daripada pengujian ping untuk mengukur latensi VM ke VM. Grafik berikut menunjukkan latensi permintaan dan respons TCP (TCP_RR) antara klien dan server yang berjalan di zona Google Cloud yang sama. Nilai TCP_RR berkisar dari ~70 mikrodetik pada persentil ke-50 hingga ~130 mikrodetik pada persentil ke-90.

    Latensi permintaan dan respons TCP antara klien dan server yang berjalan di zona Google Cloud yang sama.

Mengingat sifat workload target, Anda dapat menjalankan profil pengujian lainnya menggunakan PerfKit. Untuk mengetahui detailnya, lihat tolok ukur yang didukung di PerfKit.

Praktik terbaik di Google Cloud

Sebelum menyiapkan dan mengeksekusi rencana migrasi di Google Cloud, sebaiknya ikuti praktik terbaik migrasi. Praktik ini hanyalah merupakan titik awal. Anda mungkin perlu mempertimbangkan banyak aspek lain dari aplikasi, seperti memisahkan dependensi, menerapkan fault tolerance, serta memastikan peningkatan dan penurunan skala berdasarkan workload komponen, serta cara setiap aspek tersebut dipetakan ke Google Cloud.

  1. Memahami batas dan kuota Google Cloud. Sebelum secara resmi memulai penilaian kapasitas, pahami beberapa pertimbangan penting untuk perencanaan resource di Google Cloud, misalnya:

    Cantumkan komponen infrastructure as a service (IaaS) dan platform as a service (PaaS) yang akan diperlukan selama migrasi dan pahami dengan jelas semua kuota dan batas serta setiap penyesuaian yang tersedia untuk setiap layanan.

  2. Pantau resource secara terus-menerus. Pemantauan resource berkelanjutan dapat membantu Anda mengidentifikasi pola serta tren dalam performa sistem dan aplikasi. Pemantauan tidak hanya membantu menbangun performa dasar pengukuran, tetapi juga menunjukkan perlunya upgrade dan downgrade hardware dari waktu ke waktu. Google Cloud menyediakan berbagai opsi untuk men-deploy solusi pemantauan end-to-end:

  3. Sesuaikan ukuran VM Anda. Identifikasi kapan penyediaan VM kurang atau disediakan secara berlebihan. Menyiapkan pemantauan dasar seperti yang dibahas sebelumnya akan memberikan insight ini dengan mudah. Google Cloud juga menyediakan rekomendasi penyesuaian ukuran berdasarkan histori penggunaan instance. Selain itu, berdasarkan sifat workload, jika jenis mesin yang telah ditetapkan tidak memenuhi kebutuhan, Anda dapat membuat instance dengan setelan hardware virtual khusus.

  4. Gunakan alat yang tepat. Untuk lingkungan berskala besar, deploy alat otomatis untuk meminimalkan upaya manual, misalnya:

Hasil

Memigrasikan resource dari satu lingkungan ke lingkungan lainnya memerlukan perencanaan yang cermat. Penting untuk tidak melihat resource hardware secara terpisah, melainkan melihat tampilan end-to-end aplikasi Anda. Misalnya, alih-alih berfokus pada apakah pemroses Sandy Bridge 3.0 GHz akan dua kali lebih cepat dari pemroses Skylake 1.5 GHz, fokuslah pada bagaimana indikator performa utama berubah dari satu platform komputasi ke platform lain.

Saat Anda menilai persyaratan pemetaan resource di berbagai lingkungan, pertimbangkan hal-hal berikut:

  • Resource sistem yang membatasi aplikasi Anda (misalnya, CPU, memori, disk, atau jaringan).
  • Dampak infrastruktur dasar (misalnya, generasi prosesor, kecepatan clock, HDD, atau SSD) terhadap performa aplikasi Anda.
  • Dampak pilihan software dan desain arsitektur (misalnya, workload tunggal atau multi-thread, deployment tetap atau penskalaan otomatis) terhadap performa aplikasi.
  • Tingkat pemakaian resource komputasi, penyimpanan, dan jaringan saat ini dan yang diharapkan.
  • Pengujian performa paling sesuai yang merepresentasikan aplikasi Anda.

Mengumpulkan data terhadap metrik ini melalui pemantauan berkelanjutan membantu Anda menentukan rencana kapasitas awal. Anda dapat menindaklanjutinya dengan melakukan tolok ukur performa yang sesuai untuk meningkatkan estimasi pengukuran awal Anda.

Langkah selanjutnya