PERF04-BP02 Mengevaluasi opsi yang tersedia - AWS Well-Architected Framework
Panduan implementasiTingkat usaha untuk rencana implementasi: Sumber daya

PERF04-BP02 Mengevaluasi opsi yang tersedia

Pahami opsi basis data yang tersedia serta bagaimana opsi-opsi ini dapat mengoptimalkan kinerja Anda sebelum memilih solusi manajemen data. Gunakan uji beban untuk mengidentifikasi metrik basis data yang berpengaruh pada beban kerja Anda. Saat mencoba opsi basis data, pertimbangkan beberapa aspek seperti grup parameter, opsi penyimpanan, memori, komputasi, replika baca, eventual consistency, pooling koneksi, dan opsi cache. Coba beberapa opsi konfigurasi ini untuk meningkatkan metrik.

Hasil yang diinginkan: Beban kerja dapat menggunakan satu atau beberapa solusi basis data, bergantung pada jenis datanya. Manfaat dan fungsionalitas basis data sangat sesuai dengan karakteristik data, pola akses, dan kebutuhan beban kerja. Untuk mengoptimalkan biaya dan kinerja basis data, Anda harus mengevaluasi pola akses data guna menentukan opsi basis data yang sesuai. Evaluasikan waktu kueri yang dapat diterima untuk memastikan bahwa opsi basis data yang dipilih dapat memenuhi persyaratan.

Antipola umum:

  • Tidak mengidentifikasi pola akses data.

  • Tidak memahami opsi konfigurasi pada solusi manajemen data yang Anda pilih.

  • Hanya mengandalkan peningkatan ukuran instans tanpa mempertimbangkan opsi konfigurasi lain yang tersedia.

  • Tidak menguji karakteristik penskalaan solusi yang dipilih.

Manfaat menerapkan praktik terbaik ini: Dengan menjelajahi dan mencoba berbagai opsi basis data, Anda mungkin dapat mengurangi biaya infrastruktur, meningkatkan kinerja dan skalabilitas, serta mengurangi upaya pengelolaan beban kerja.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Tinggi

  • Dalam mengoptimalkan basis data untuk segala ukuran, tentu ada yang dikorbankan.

  • Biaya yang lebih tinggi akibat konfigurasi solusi basis data yang tidak sesuai dengan pola lalu lintas.

  • Masalah penskalaan dapat menimbulkan masalah operasional.

  • Tingkat keamanan data mungkin tidak sesuai dengan yang diperlukan.

Panduan implementasi

Pahami karakteristik beban kerja Anda agar dapat menentukan opsi basis data. Jalankan uji beban untuk mengidentifikasi hambatan dan metrik kinerja utama. Gunakan karakteristik dan metrik ini untuk mengevaluasi opsi basis data dan coba konfigurasi yang berbeda.

Layanan AWS Amazon RDS, Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Menskalakan Komputasi Perbesar ukuran instans, instans Nirserver Aurora menskalakan secara otomatis sesuai perubahan beban Penskalaan baca/tulis otomatis dengan mode kapasitas sesuai permintaan atau penskalaan otomatis kapasitas baca/tulis yang tersedia dalam mode kapasitas yang tersedia. Perbesar ukuran instans Perbesar ukuran instans, tambahkan simpul ke klaster Perbesar ukuran instans Menskalakan secara otomatis untuk menyesuaikan kapasitas Penskalaan baca/tulis otomatis dengan mode kapasitas sesuai permintaan atau penskalaan otomatis kapasitas baca/tulis yang tersedia dalam mode kapasitas yang tersedia. Menskalakan secara otomatis untuk menyesuaikan kapasitas
Menskalakan pembacaan Semua mesin mendukung replika baca. Aurora mendukung penskalaan otomatis instans replika baca. Tingkatkan unit kapasitas baca yang disediakan Replika baca Replika baca Replika baca. Mendukung penskalaan otomatis instans replika baca Menskalakan secara otomatis Tingkatkan unit kapasitas baca yang disediakan Menaikkan skala secara otomatis ke batas dokumentasi konkurensi
Menskalakan penulisan Memperbesar ukuran instans, membuat batch penulisan di aplikasi atau menambahkan antrean di depan basis data. Penskalaan horizontal melalui serpihan tingkat aplikasi di beberapa instans Tambah unit kapasitas baca yang tersedia. Memastikan kunci partisi yang optimal untuk mencegah throttling penulisan tingkat partisi Memperbesar ukuran instans utama Menggunakan Redis dalam mode klaster untuk mendistribusikan penulisan di semua serpihan Memperbesar ukuran instans Permintaan penulisan berpotensi mengalami throttling saat menskalakan. Jika Anda mendapati pengecualian throttling, lanjutkan mengirim data pada throughput yang sama (atau lebih tinggi) untuk menskalakan secara otomatis. Buat batch penulisan untuk mengurangi permintaan penulisan secara bersamaan Tambah unit kapasitas baca yang tersedia. Memastikan kunci partisi yang optimal untuk mencegah throttling penulisan tingkat partisi Menaikkan skala secara otomatis ke batas dokumentasi konkurensi
Konfigurasi mesin Grup parameter Tidak berlaku Grup parameter Grup parameter Grup parameter Tidak berlaku Tidak berlaku Tidak berlaku
Caching Caching dalam memori, dapat dikonfigurasikan melalui grup parameter. Pasangkan dengan cache khusus seperti ElastiCache for Redis untuk mengurangi beban permintaan item yang sering diakses Tersedia cache terkelola penuh DAX (DAX) Caching dalam memori. Atau pasangkan dengan cache khusus seperti ElastiCache for Redis untuk mengurangi beban permintaan item yang sering diakses Fungsi utamanya adalah caching Gunakan cache hasil kueri untuk melakukan cache pada hasil kueri hanya-baca Timestream memiliki dua tingkat penyimpanan, salah satunya adalah tingkat dalam memori berkinerja tinggi Lakukan deployment cache khusus seperti ElastiCache for Redis secara terpisah untuk mengurangi beban permintaan item yang sering diakses Tidak berlaku
Ketersediaan tinggi/pemulihan bencana Konfigurasi yang disarankan untuk beban kerja produksi adalah menjalankan instans siaga di Zona Ketersediaan kedua untuk memberikan ketahanan di dalam suatu Wilayah.  Untuk ketahanan di semua Wilayah, Anda dapat menggunakan Basis Data Global Aurora Ketersediaan tinggi di dalam suatu Wilayah. Tabel dapat direplikasikan ke semua Wilayah menggunakan tabel global DynanoDB Buat beberapa instans di seluruh Zona Ketersediaan untuk ketersediaan.  Snapshot dapat dibagikan ke seluruh Wilayah dan klaster dapat direplikasikan menggunakan DMS untuk menyediakan pemulihan bencana/Replikasi Lintas-Wilayah. Konfigurasi yang disarankan untuk klaster produksi adalah membuat setidaknya satu simpul di Zona Ketersediaan kedua.  Penyimpanan Data Global ElastiCache dapat digunakan untuk mereplikasi klaster di berbagai Wilayah. Replika baca di Zona Ketersediaan lainnya berfungsi sebagai target failover.  Snapshot dapat dibagikan ke seluruh Wilayah dan klaster dapat direplikasikan menggunakan aliran Neptune untuk mereplikasi data antara dua klaster di dua Wilayah yang berbeda. Sangat tersedia dalam suatu Wilayah. Replikasi Lintas-Wilayah memerlukan pengembangan aplikasi khusus menggunakan Timestream SDK Ketersediaan tinggi di dalam suatu Wilayah.  Replikasi Lintas Wilayah memerlukan logika aplikasi khusus atau alat pihak ketiga Ketersediaan tinggi di dalam suatu Wilayah.  Untuk mereplikasi di seluruh Wilayah, ekspor konten jurnal Amazon QLDB ke bucket S3 dan konfigurasikan bucket untuk Replikasi Lintas Wilayah.

Langkah implementasi

  1. Apa saja opsi konfigurasi yang tersedia untuk basis data yang dipilih?

    1. Grup Parameter untuk Amazon RDS dan Aurora membantu Anda untuk menyesuaikan pengaturan umum di tingkat mesin basis data, seperti alokasi memori untuk cache atau menyesuaikan zona waktu basis data

    2. Untuk layanan basis data yang tersedia seperti Amazon RDS, Aurora, Neptune, Amazon DocumentDB, dan yang di-deploy di Amazon EC2, Anda dapat mengubah jenis instans dan penyimpanan yang tersedia, serta menambahkan replika baca.

    3. DynamoDB memungkinkan Anda untuk menentukan dua mode kapasitas: sesuai permintaan dan tersedia. Untuk mengatasi dua beban kerja yang berbeda, Anda dapat mengganti di antara dua mode ini dan memperbesar alokasi kapasitas di mode yang tersedia kapan pun.

  2. Apakah beban kerja pembacaan atau penulisannya berat? 

    1. Apa saja solusi yang tersedia untuk meringankan beban pembacaan (replika baca, caching, dll.)? 

      1. Untuk tabel DynamoDB, Anda dapat meringankan beban pembacaan menggunakan DAX untuk caching.

      2. Untuk basis data relasional, Anda dapat membuat klaster ElastiCache for Redis dan mengonfigurasikan aplikasi Anda untuk membaca dari cache terlebih dahulu, kembali ke basis data jika item yang diminta tidak tersedia.

      3. Basis data relasional seperti Amazon RDS dan Aurora, serta basis data NoSQL yang tersedia seperti Neptune dan Amazon DocumentDB semua mendukung penambahan replika baca untuk mengurangi porsi baca beban kerja.

      4. Basis data nirserver seperti DynamoDB akan menskalakan secara otomatis. Pastikan unit kapasitas baca (RSU) yang tersedia cukup untuk mengatasi beban kerja.

    2. Apa saja solusi yang tersedia untuk menskalakan pembacaan (serpihan utama partisi, pembuatan antrean, dll.)?

      1. Untuk basis data relasional, Anda dapat memperbesar ukuran instans untuk mengakomodasi tambahan beban kerja atau menambah IOPS yang tersedia untuk memfasilitasi kenaikan throughput pada penyimpanan yang mendasari.

        • Anda juga dapat membuat antrean di depan basis data, bukan menulis secara langsung ke basis data. Dengan pola ini, Anda dapat memisahkan penyerapan dari basis data dan mengontrol tingkat aliran, sehingga basis data tidak kewalahan. 

        • Mengganti pembuatan transaksi berdurasi pendek dengan pembuatan batch permintaan penulisan dapat membantu meningkatkan throughput dalam basis data relasional dengan volume penulisan tinggi.

      2. Basis data nirserver seperti DynamoDB dapat menskalakan throughput tulis secara otomatis atau dengan menyesuaikan unit kapasitas tulis (WCU) yang tersedia, bergantung pada mode kapasitasnya. 

        • Anda masih dapat mengalami masalah pada partisi panas, ketika mencapai batas throughput pada kunci partisi tertentu. Hal ini dapat dikurangi dengan memilih distribusi kunci partisi yang lebih merata atau dengan memisah penulisan kunci partisi. 

  3. Berapa puncak transaksi per detik (TPS) saat ini atau yang diharapkan? Uji menggunakan volume lalu lintas ini dan volume +X% ini untuk mengetahui karakteristik penskalaan.

    1. Alat asli seperti pg_bench for PostgreSQL dapat digunakan untuk menguji tekanan basis data dan mengetahui hambatan serta karakteristik penskalaan.

    2. Lalu lintas mirip produksi harus direkam agar dapat diputar ulang untuk menyimulasikan kondisi sebenarnya sebagai tambahan beban kerja sintetis.

  4. Jika menggunakan komputasi nirserver atau dapat diskalakan, uji dampak penskalaan ini pada basis data. Jika perlu, gunakan pooling atau manajemen koneksi untuk mengurangi dampak pada basis data. 

    1. Proksi RDS dapat digunakan dengan Amazon RDS dan Aurora untuk mengelola koneksi ke basis data. 

    2. Basis data nirserver seperti DynamoDB tidak terkait dengan koneksi apa pun, tetapi pertimbangkan kapasitas yang tersedia atau kebijakan penskalaan otomatis untuk mengatasi lonjakan beban.

  5. Apakah beban dapat diprediksi, apakah Anda lonjakan beban dan periode tidak aktif?

    1. Jika ada periode tidak aktif, coba turunkan skala kapasitas yang tersedia atau ukuran instans selama periode ini. Aurora Nirserver V2 akan otomatis menurunkan atau menaikkan skala sesuai beban.

    2. Untuk instans di luar produksi, coba jeda atau hentikan instans di luar jam kerja.

  6. Apakah Anda perlu menyegmentasikan atau membagi model data berdasarkan pola akses dan karakteristik data?

    1. Coba gunakan AWS DMS atau AWS SCT untuk memindahkan data Anda ke layanan lain.

Tingkat usaha untuk rencana implementasi: 

Untuk menerapkan praktik terbaik ini, Anda harus mengetahui metrik dan karakteristik data Anda saat ini. Mengumpulkan metrik, membentuk dasaran, kemudian menggunakan metrik tersebut untuk mengidentifikasi opsi konfigurasi basis data yang ideal merupakan tingkat usaha rendah ke tingkat usaha sedang . Hal ini divalidasi dengan eksperimen dan uji beban.

Sumber daya

Dokumen terkait:

Video terkait:

Contoh terkait: