Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Melakukan pembuktian konsep dengan Amazon Aurora
Dalam informasi berikut ini, Anda dapat menemukan penjelasan tentang cara menyiapkan dan menjalankan bukti konsep untuk Aurora. *Pembuktian konsep *adalah penyelidikan yang Anda lakukan untuk melihat apakah Aurora cocok dengan aplikasi Anda. Pembuktian konsep dapat membantu Anda memahami fitur Aurora dalam konteks aplikasi basis data Anda sendiri dan perbandingan Aurora dengan lingkungan basis data Anda saat ini. Pembuktian konsep juga dapat menunjukkan tingkat upaya yang Anda butuhkan untuk memindahkan data, mem-porting kode SQL, menyetel performa, dan menyesuaikan prosedur manajemen Anda saat ini.
Dalam topik ini, Anda dapat menemukan gambaran umum serta garis besar langkah demi langkah dari prosedur dan keputusan tingkat tinggi yang diperlukan dalam menjalankan pembuktian konsep, sebagaimana tercantum berikut. Untuk petunjuk mendetail, Anda dapat membuka tautan ke dokumentasi lengkap untuk subjek spesifik.
## Gambaran umum bukti konsep Aurora
Saat Anda melakukan pembuktian konsep untuk Amazon Aurora, Anda akan mempelajari apa saja yang diperlukan untuk memindahkan data yang ada dan aplikasi SQL Anda ke Aurora. Anda mencoba aspek penting Aurora dalam skala besar, menggunakan volume data dan aktivitas yang sesuai dengan lingkungan produksi Anda. Tujuannya adalah untuk menjadi yakin bahwa kecanggihan Aurora memang cocok untuk mengatasi tantangan yang menyebabkan Anda tidak dapat lagi mengandalkan infrastruktur basis data sebelumnya. Pada akhir pembuktian konsep, Anda akan memiliki rencana yang andal untuk melakukan penilaian tolok ukur performa dan pengujian aplikasi berskala lebih besar. Pada tahap ini, Anda memahami item pekerjaan terbesar dalam proses menuju deployment produksi.
Saran berikut tentang praktik terbaik dapat membantu Anda menghindari kesalahan umum yang dapat menyebabkan masalah selama proses penilaian tolok ukur. Namun, topik ini tidak membahas proses langkah demi langkah dalam melakukan penilaian tolok ukur dan melakukan penyetelan performa. Prosedur tersebut bisa bervariasi, tergantung pada beban kerja Anda dan fitur Aurora yang Anda gunakan. Untuk informasi selengkapnya, baca dokumentasi yang terkait dengan performa seperti [Mengelola performa dan penskalaan untuk klaster DB Aurora](Aurora.Managing.Performance.md), [Peningkatan performa Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance), [Kinerja dan penskalaan untuk Amazon Aurora PostgreSQL](AuroraPostgreSQL.Managing.md), dan [Memantau muatan DB dengan Wawasan Performa di Amazon Aurora](USER_PerfInsights.md).
Informasi dalam topik ini berlaku terutama untuk aplikasi tempat organisasi Anda menulis kode dan mendesain skema, serta yang mendukung mesin basis data sumber terbuka MySQL dan PostgreSQL. Jika Anda menguji aplikasi komersial atau kode yang dihasilkan oleh kerangka kerja aplikasi, Anda mungkin tidak memiliki fleksibilitas untuk menerapkan semua pedoman. Dalam kasus seperti itu, tanyakan kepada AWS perwakilan Anda untuk melihat apakah ada praktik terbaik Aurora atau studi kasus untuk jenis aplikasi Anda.
## 1. Identifikasi tujuan Anda
Saat Anda mengevaluasi Aurora sebagai bagian dari pembuktian konsep, Anda perlu memilih jenis pengukuran apa yang akan dilakukan dan cara mengevaluasi keberhasilan percobaan ini.
Anda harus memastikan bahwa semua fungsionalitas aplikasi Anda kompatibel dengan Aurora. Karena versi mayor Aurora kompatibel kabel dengan versi mayor MySQL dan PostgreSQL, sebagian besar aplikasi yang dikembangkan untuk mesin tersebut juga kompatibel dengan Aurora. Meski demikian, Anda masih harus memvalidasi kompatibilitas per aplikasi.
Misalnya, beberapa pilihan konfigurasi yang Anda buat saat menyiapkan klaster Aurora akan memengaruhi apakah Anda bisa atau harus menggunakan fitur basis data tertentu. Anda dapat memulai dengan klaster Aurora yang paling umum, yang dikenal sebagai klaster *terprovisi*. Anda kemudian dapat memutuskan apakah konfigurasi khusus seperti kueri nirserver atau kueri paralel mampu memberi manfaat untuk menangani beban kerja Anda.
Gunakan pertanyaan-pertanyaan berikut untuk membantu mengidentifikasi dan mengukur tujuan Anda:
+ Apakah Aurora mendukung semua kasus penggunaan fungsional beban kerja Anda?
+ Berapa ukuran set data atau tingkat beban yang Anda inginkan? Bisakah Anda meningkatkan skala ke tingkat itu?
+ Apa persyaratan latensi atau throughput kueri spesifik Anda? Bisakah Anda memenuhi persyaratannya?
+ Berapa lama waktu henti minimum terencana atau tidak terencana yang Anda sanggupi untuk beban kerja Anda? Bisakah Anda mencapainya?
+ Apa metrik yang diperlukan untuk meraih efisiensi operasional? Bisakah Anda memantaunya secara akurat?
+ Apakah Aurora mendukung tujuan bisnis spesifik Anda, seperti pengurangan biaya, peningkatan deployment, atau kecepatan penyediaan? Apakah Anda memiliki cara untuk mengukur tujuan ini?
+ Dapatkah Anda memenuhi semua persyaratan keamanan dan kepatuhan untuk beban kerja Anda?
Luangkan waktu untuk membangun pengetahuan tentang mesin basis data dan kemampuan platform Aurora, serta tinjau dokumentasi layanan ini. Catat semua fitur yang dapat membantu Anda mencapai hasil yang Anda inginkan. Salah satunya mungkin konsolidasi beban kerja, dijelaskan dalam posting Blog AWS Database [Cara merencanakan dan mengoptimalkan Amazon Aurora dengan kompatibilitas MySQL untuk](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/) beban kerja terkonsolidasi. Fitur lainnya adalah penskalaan berbasis permintaan, yang dijelaskan dalam [Auto Scaling Amazon Aurora dengan Replika Aurora](Aurora.Integrating.AutoScaling.md) di *Panduan Pengguna Amazon Aurora.* Fiturnya yang lain adalah keuntungan performa atau operasi basis data yang disederhanakan.
## 2. Pahami karakteristik beban kerja Anda
Evaluasi Aurora dalam konteks kasus penggunaan yang Anda inginkan. Aurora adalah pilihan yang cocok untuk beban kerja pemrosesan transaksi online (OLTP). Anda juga bisa menjalankan laporan di klaster yang menyimpan data OLTP waktu nyata tanpa harus menyediakan klaster gudang data terpisah. Anda dapat mengenali apakah kasus penggunaan Anda termasuk dalam kategori ini atau tidak dengan melihat ciri-ciri berikut:
+ Konkurensi yang tinggi, dengan puluhan, ratusan, atau bahkan ribuan klien simultan.
+ Kueri berlatensi rendah dalam volume besar (milidetik hingga detik).
+ Transaksi singkat dan waktu nyata.
+ Pola kueri yang sangat selektif, dengan pencarian berbasis indeks.
+ Untuk HTAP, kueri analitik yang bisa memanfaatkan kueri paralel Aurora.
Salah satu faktor utama yang memengaruhi pilihan basis data Anda adalah kecepatan datanya. *Kecepatan tinggi *berkaitan dengan data yang sangat sering disisipkan dan diperbarui. Sistem seperti itu mungkin memiliki ribuan koneksi dan ratusan ribu kueri simultan yang membaca dan menulis ke basis data. Kueri dalam sistem berkecepatan tinggi biasanya akan memengaruhi jumlah baris yang relatif kecil, dan biasanya mengakses beberapa kolom dalam baris yang sama.
Aurora dirancang untuk menangani data berkecepatan tinggi. Bergantung pada beban kerjanya, klaster Aurora dengan satu instans DB r4.16xlarge dapat memproses lebih dari 600.000 pernyataan `SELECT` per detik. Sekali lagi, bergantung pada beban kerjanya, klaster seperti itu dapat memproses 200.000 pernyataan `INSERT`, `UPDATE`, dan `DELETE` per detik. Aurora adalah basis data penyimpanan baris dan sangat cocok untuk beban kerja OLTP yang memiliki volume tinggi, throughput tinggi, dan paralelisasi tinggi.
Aurora juga dapat menjalankan kueri pelaporan pada klaster yang sama yang menangani beban kerja OLTP. Aurora mendukung hingga 15 [replika](Aurora.Replication.md#Aurora.Replication.Replicas), yang masing-masing memiliki lag replikasi rata-rata 10-20 milidetik dari instans primer. Analis dapat mengueri data OLTP secara waktu nyata tanpa menyalin data ke klaster gudang data terpisah. Dengan menggunakan fitur kueri paralel untuk klaster Aurora, Anda dapat memindahkan sebagian besar pemrosesan, pemfilteran, dan agregasi ke subsistem penyimpanan Aurora yang didistribusikan secara masif.
Gunakan fase perencanaan ini untuk membiasakan diri dengan kemampuan Aurora, AWS layanan lain Konsol Manajemen AWS, dan. AWS CLI Selain itu, periksa bagaimana kecocokan fungsinya dengan alat-alat lain yang nantinya Anda gunakan dalam pembuktian konsep.
## 3. Berlatih dengan Konsol Manajemen AWS atau AWS CLI
Sebagai langkah selanjutnya, berlatih dengan Konsol Manajemen AWS atau AWS CLI, untuk menjadi akrab dengan alat-alat ini dan dengan Aurora.
### Berlatihlah dengan Konsol Manajemen AWS
Aktivitas awal berikut dengan cluster database Aurora terutama agar Anda dapat membiasakan diri dengan Konsol Manajemen AWS lingkungan dan berlatih menyiapkan dan memodifikasi cluster Aurora. Jika Anda menggunakan mesin PostgreSQL-compatible database MySQL-compatible dan Amazon RDS, Anda dapat membangun pengetahuan itu saat Anda menggunakan Aurora.
Dengan memanfaatkan model dan fitur penyimpanan bersama dari Aurora seperti replikasi dan snapshot, Anda dapat memperlakukan seluruh klaster basis data sebagai jenis objek lain yang dapat Anda manipulasi dengan bebas. Anda dapat menyusun, merombak, dan mengubah kapasitas klaster Aurora selama proses pembuktian konsep. Anda tidak akan terkunci pada pilihan awal tentang kapasitas, pengaturan basis data, dan tata letak data fisik.
Untuk memulai, siapkan klaster Aurora yang kosong. Pilih jenis kapasitas **terprovisi** dan lokasi **wilayah** untuk eksperimen awal Anda.
Hubungkan ke klaster tersebut menggunakan program klien seperti aplikasi baris perintah SQL. Awalnya, Anda akan terhubung menggunakan titik akhir klaster. Anda terhubung ke titik akhir tersebut untuk melakukan operasi tulis apa pun, seperti proses pernyataan bahasa definisi data (DDL) dan proses extract, transform, and load (ETL). Selanjutnya, dalam pembuktian konsep, Anda perlu menghubungkan sesi sarat kueri menggunakan titik akhir pembaca, yang mendistribusikan beban kerja kueri ke beberapa instans DB di klaster.
Skalakan ke luar klaster dengan menambahkan lebih banyak Replika Aurora. Untuk prosedurnya, lihat [Replikasi dengan Amazon Aurora](Aurora.Replication.md). Skala instance DB naik atau turun dengan mengubah kelas AWS instance. Pahami cara Aurora dapat menyederhanakan jenis operasi ini, sehingga jika perkiraan awal Anda untuk kapasitas sistem tidak akurat, Anda dapat menyesuaikannya nanti tanpa harus memulai dari awal.
Buat snapshot dan pulihkan ke klaster yang berbeda.
Periksa metrik klaster untuk melihat aktivitas dari waktu ke waktu, dan kecocokan metrik tersebut untuk instans DB di klaster.
Sangat berguna untuk menjadi akrab dengan bagaimana melakukan hal-hal ini Konsol Manajemen AWS di awal. Setelah memahami apa yang dapat Anda lakukan dengan Aurora, Anda dapat melanjutkan untuk mengotomatiskan operasi tersebut menggunakan AWS CLI. Di bagian berikut, Anda dapat menemukan detail selengkapnya tentang prosedur dan praktik terbaik untuk aktivitas ini selama periode pembuktian konsep.
### Berlatihlah dengan AWS CLI
Kami merekomendasikan otomatisasi prosedur deployment dan manajemen otomatis, bahkan dalam pengaturan bukti konsep. Untuk melakukannya, menjadi akrab dengan AWS CLI jika Anda belum melakukannya. Jika Anda menggunakan mesin PostgreSQL-compatible database MySQL-compatible dan Amazon RDS, Anda dapat membangun pengetahuan itu saat Anda menggunakan Aurora.
Aurora biasanya menangani grup instans DB yang disusun dalam klaster. Dengan demikian, banyak operasi akan mengharuskan Anda menentukan instans DB mana yang terkait dengan sebuah klaster, lalu melakukan operasi administratif dalam satu rangkaian untuk semua instans.
Misalnya, Anda dapat mengotomatiskan langkah-langkah seperti pembuatan klaster Aurora, lalu menaikkan skalanya dengan kelas instans yang lebih besar atau menskalakan klaster tersebut ke luar dengan instans DB tambahan. Dengan demikian, Anda akan dapat mengulangi tahapan mana pun dalam proses pembuktian konsep Anda dan mengkaji skenario bagaimana-jika dengan berbagai jenis atau konfigurasi klaster Aurora.
Pelajari kemampuan dan batasan alat deployment infrastruktur seperti AWS CloudFormation. Anda mungkin akan menemukan aktivitas yang Anda lakukan dalam konteks bukti konsep tidak sesuai untuk penggunaan produksi. Misalnya, CloudFormation perilaku modifikasi adalah membuat instance baru dan menghapus yang sekarang, termasuk datanya. Untuk detail selengkapnya tentang perilaku ini, lihat [Pembaruan perilaku sumber daya tumpukan](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html) dalam *Panduan Pengguna AWS CloudFormation *.
## 4. Buat klaster Aurora Anda
Dengan Aurora, Anda dapat mengkaji skenario bagaimana-jika dengan menambahkan instans DB ke klaster dan menaikkan skala instans DB ke kelas instans yang berperforma lebih tinggi. Anda juga dapat membuat klaster dengan pengaturan konfigurasi yang berbeda-beda untuk menjalankan beban kerja yang sama secara berdampingan. Dengan Aurora, Anda memiliki banyak fleksibilitas untuk menyiapkan, merombak, dan mengonfigurasi ulang klaster DB. Dengan demikian, teknik-teknik ini sebaiknya dilakukan pada tahap awal proses pembuktian konsep. Untuk prosedur umum membuat klaster Aurora, lihat [Membuat klaster DB Amazon Aurora](Aurora.CreateInstance.md).
Jika memungkinkan, mulailah dengan sebuah klaster yang menggunakan pengaturan berikut. Lewati langkah ini jika Anda memiliki kasus penggunaan khusus tertentu. Misalnya, Anda mungkin perlu melewati langkah ini jika kasus penggunaan Anda memerlukan jenis klaster Aurora khusus. Atau Anda dapat melewati langkah ini jika Anda memerlukan kombinasi mesin dan versi basis data khusus.
+ Nonaktifkan **Pembuatan mudah**. Sebagai pembuktian konsep, kami menyarankan Anda untuk mengetahui semua pengaturan yang Anda pilih sehingga Anda dapat membuat klaster yang identik atau sedikit berbeda nantinya.
+ Gunakan versi mesin DB terbaru. Kombinasi mesin database dan versi ini memiliki kompatibilitas yang luas dengan fitur Aurora lainnya dan penggunaan pelanggan yang substansif untuk aplikasi produksi.
+ Aurora MySQL versi 3.x (MySQL 8.0 kompatibilitas)
+ Aurora PostgreSQL versi 15.x atau 16.x
+ Pilih **Dev/Test**template. Pilihan ini tidak bersifat signifikan untuk aktivitas pembuktian konsep Anda.
+ Untuk **Kelas instans DB**, pilih **Kelas teroptimasi memori** dan salah satu kelas instans **xlarge**. Anda dapat menyesuaikan kelas instans ke atas atau ke bawah nantinya.
+ Di bawah **Multi-AZ Deployment**, pilih **Create an Aurora Replica atau Reader node di** AZ yang berbeda. Banyak aspek Aurora yang paling berguna menangani klaster yang terdiri dari beberapa instans DB. Sebaiknya mulai selalu dengan setidaknya dua instans DB di klaster baru. Penggunaan Zona Ketersediaan yang berbeda untuk instans DB kedua akan membantu menguji berbagai skenario ketersediaan tinggi.
+ Saat memilih nama untuk instans DB, gunakan konvensi penamaan yang generik. Jangan merujuk ke instans DB cluster apa pun sebagai “penulis,” karena instance DB yang berbeda mengambil peran tersebut sesuai kebutuhan. Kami merekomendasikan format seperti `clustername-az-serialnumber`, misalnya `myprodappdb-a-01`. Bagian-bagian ini mengidentifikasi secara unik instans DB dan penempatannya.
+ Tetapkan retensi cadangan yang tinggi untuk klaster Aurora. Dengan periode retensi yang lama, Anda dapat melakukan pemulihan titik waktu (PITR) untuk jangka waktu hingga 35 hari. Anda bisa mengatur ulang basis data Anda ke keadaan yang diketahui setelah menjalankan tes yang menangani DDL dan pernyataan bahasa manipulasi data (Data Manipulation Language atau DML). Anda juga dapat memulihkannya jika Anda tidak sengaja menghapus atau mengubah data.
+ Aktifkan fitur pemulihan, pencatatan log, dan pemantauan tambahan pada pembuatan klaster. Aktifkan semua pilihan yang tersedia di **Backtrack**, **Performance** Insights, Monitoring**,** **dan** ekspor Log. Dengan mengaktifkan berbagai fitur ini, Anda dapat menguji kesesuaian fitur seperti backtracking, Pemantauan yang Ditingkatkan, atau Wawasan Performa untuk beban kerja Anda. Anda juga dapat dengan mudah memeriksa performa dan melakukan pemecahan masalah selama proses pembuktian konsep.
## 5. Siapkan skema Anda
Pada klaster Aurora, siapkan basis data, tabel, indeks, kunci asing, dan objek skema lainnya untuk aplikasi Anda. Jika Anda pindah dari sistem lain MySQL-compatible atau PostgreSQL-compatible database, harapkan tahap ini sederhana dan mudah. Anda menggunakan sintaksis dan baris perintah SQL yang sama atau aplikasi klien lain yang Anda kenal untuk mesin basis data Anda.
Untuk mengeluarkan pernyataan SQL di klaster Anda, temukan titik akhir klasternya dan berikan nilai tersebut sebagai parameter koneksi ke aplikasi klien Anda. Anda dapat menemukan titik akhir klaster di tab **Konektivitas** di halaman detail klaster Anda. Titik akhir klaster adalah yang berlabel **Penulis**. Titik akhir lainnya, yang berlabel **Pembaca**, merepresentasikan koneksi hanya baca yang dapat Anda berikan kepada pengguna akhir yang menjalankan laporan atau kueri hanya baca lainnya. Untuk memperoleh bantuan atas masalah apa pun terkait koneksi ke klaster Anda, lihat [Menghubungkan ke klaster DB Amazon Aurora](Aurora.Connecting.md).
Jika Anda mem-porting skema dan data Anda dari sistem basis data yang berbeda, Anda perlu membuat beberapa perubahan skema pada saat ini. Perubahan skema ini harus sesuai dengan sintaksis dan kemampuan SQL yang tersedia di Aurora. Anda dapat menghapus kolom, batasan, pemicu, atau objek skema tertentu pada tahap ini. Dengan melakukannya, Anda akan memperoleh manfaat, terutama jika objek ini memerlukan pengerjaan ulang untuk kompatibilitas Aurora dan tidak signifikan untuk tujuan Anda dengan pembuktian konsep.
Jika Anda bermigrasi dari sistem database dengan mesin dasar yang berbeda dari Aurora, pertimbangkan untuk menggunakan AWS Schema Conversion Tool (AWS SCT) untuk menyederhanakan proses. Untuk detailnya, lihat [Panduan Pengguna AWS Schema Conversion Tool](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html). Untuk detail umum tentang aktivitas migrasi dan porting, lihat whitepaper [Migrasi Database Anda ke Amazon Aurora](https://d1.awsstatic.com/whitepapers/RDS/Migrating%20your%20databases%20to%20Amazon%20Aurora.pdf). AWS
Selama tahap ini, Anda dapat mengevaluasi apakah terdapat inefisiensi dalam penyiapan skema Anda, misalnya dalam strategi pengindeksan atau struktur tabel lain seperti tabel yang dipartisi. Inefisiensi seperti itu akan meningkat saat Anda men-deploy aplikasi Anda pada klaster dengan beberapa instans DB dan beban kerja yang berat. Pertimbangkan apakah Anda dapat menyempurnakan aspek performa tersebut sekarang, atau selama aktivitas selanjutnya seperti pengujian tolok ukur lengkap.
## 6. Impor data Anda
Selama pembuktian konsep, Anda akan membawa data, atau sampel representatif, dari sistem basis data sebelumnya. Jika memungkinkan, siapkan setidaknya beberapa data di setiap tabel Anda. Hal tersebut akan membantu menguji kompatibilitas semua jenis data dan fitur skema. Setelah Anda mencoba berbagai fitur Aurora dasar, tingkatkan jumlah datanya. Pada saat Anda menyelesaikan pembuktian konsep, Anda harus menguji alat ETL, kueri, dan beban kerja Anda secara keseluruhan dengan set data yang cukup besar untuk mengambil kesimpulan secara akurat.
Anda dapat menggunakan beberapa teknik untuk mengimpor data cadangan fisik atau logis ke Aurora. Untuk detail, lihat [Memigrasikan data ke klaster DB Amazon Aurora MySQL](AuroraMySQL.Migrating.md) atau [Memigrasikan data ke Amazon Aurora dengan kompatibilitas PostgreSQL](AuroraPostgreSQL.Migrating.md) sesuai dengan mesin basis data yang Anda gunakan dalam bukti konsep.
Bereksperimenlah dengan alat dan teknologi ETL yang Anda pertimbangkan. Lihat mana yang paling sesuai dengan kebutuhan Anda. Pertimbangkan throughput dan fleksibilitasnya. Misalnya, beberapa alat ETL dapat melakukan transfer satu kali, dan alat yang lainnya mendukung replikasi berkelanjutan dari sistem lama ke Aurora.
Jika Anda bermigrasi dari MySQL-compatible sistem ke Aurora MySQL, Anda dapat menggunakan alat transfer data asli. Hal yang sama berlaku jika Anda bermigrasi dari PostgreSQL-compatible sistem ke Aurora PostgreSQL. Jika Anda bermigrasi dari sistem database yang menggunakan mesin dasar yang berbeda dari Aurora, Anda dapat bereksperimen dengan AWS Database Migration Service ().AWS DMS Untuk detailnya AWS DMS, lihat [Panduan AWS Database Migration Service Pengguna](https://docs.aws.amazon.com/dms/latest/userguide/).
Untuk detail tentang aktivitas migrasi dan porting, lihat buku AWS putih buku pegangan migrasi [Aurora](https://d1.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf).
## 7. Lakukan porting kode SQL Anda
Mencoba SQL dan aplikasi terkait membutuhkan tingkat upaya yang berbeda-beda, tergantung jenis kasusnya. Secara khusus, tingkat upaya tergantung pada apakah Anda pindah dari PostgreSQL-compatible sistem MySQL-compatible atau jenis lain.
+ Jika Anda beralih dari RDS for MySQL atau RDS for PostgreSQL, perubahan SQL cukup kecil sehingga Anda dapat mencoba kode SQL asli dengan Aurora dan memasukkan secara manual perubahan yang diperlukan.
+ Demikian pula, jika Anda berpindah dari basis data on-premise yang kompatibel dengan MySQL atau PostgreSQL, Anda dapat mencoba kode SQL asli dan memasukkan perubahan secara manual.
+ Jika Anda awalnya menggunakan basis data komersial yang berbeda, maka perubahan SQL yang diperlukan akan bersifat lebih ekstensif. Dalam hal ini, pertimbangkan untuk menggunakan AWS SCT.
Selama tahap ini, Anda dapat mengevaluasi apakah terdapat inefisiensi dalam penyiapan skema Anda, misalnya dalam strategi pengindeksan atau struktur tabel lain seperti tabel yang dipartisi. Pertimbangkan apakah Anda dapat menyempurnakan aspek performa tersebut sekarang, atau selama aktivitas selanjutnya seperti pengujian tolok ukur lengkap.
Anda dapat memverifikasi logika koneksi basis data di aplikasi Anda. Untuk memanfaatkan pemrosesan terdistribusi Aurora, Anda mungkin perlu menggunakan koneksi terpisah untuk operasi baca dan tulis, dan menggunakan sesi yang relatif singkat untuk operasi kueri. Untuk informasi tentang koneksi, lihat [9. Hubungkan ke Aurora](#Aurora.PoC.Connections).
Pertimbangkan apakah Anda harus membuat kompromi dan pengorbanan untuk mengatasi masalah dalam basis data produksi Anda. Sisihkan waktu dalam jadwal pembuktian konsep untuk menyempurnakan desain skema dan kueri Anda. Untuk menilai apakah Anda dapat meraih keuntungan dari segi performa, biaya pengoperasian, dan skalabilitas yang baik, coba aplikasi asli dan yang dimodifikasi secara berdampingan di klaster Aurora yang berbeda.
Untuk detail tentang aktivitas migrasi dan porting, lihat buku AWS putih buku pegangan migrasi [Aurora](https://d1.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf).
## 8. Tentukan pengaturan konfigurasi
Anda juga dapat meninjau parameter konfigurasi basis data Anda sebagai bagian dari percobaan pembuktian konsep Aurora. Anda mungkin sudah mengatur konfigurasi MySQL atau PostgreSQL untuk performa dan skalabilitas di lingkungan Anda saat ini. Subsistem penyimpanan Aurora diubah dan diatur untuk lingkungan berbasis cloud terdistribusi dengan subsistem penyimpanan berkecepatan tinggi. Akibatnya, banyak pengaturan mesin basis data sebelumnya tidak berlaku. Kami merekomendasikan untuk melakukan eksperimen awal Anda dengan pengaturan konfigurasi Aurora default. Terapkan kembali pengaturan dari lingkungan Anda saat ini hanya jika Anda mengalami hambatan performa dan skalabilitas. Jika Anda tertarik, Anda dapat melihat lebih dalam subjek ini dalam [Memperkenalkan mesin penyimpanan Aurora](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) di Blog AWS Database.
Aurora memudahkan penggunaan kembali pengaturan konfigurasi optimal untuk aplikasi atau kasus penggunaan tertentu. Alih-alih mengedit file konfigurasi terpisah untuk setiap instans DB, Anda mengelola sekumpulan parameter yang Anda tetapkan ke seluruh klaster atau instans DB tertentu. Misalnya, pengaturan zona waktu berlaku untuk semua instans DB di klaster, dan Anda dapat menyesuaikan pengaturan ukuran cache halaman untuk setiap instans DB.
Anda memulai dengan salah satu set parameter default, dan menerapkan perubahan ke parameter yang perlu Anda sesuaikan saja. Untuk detail tentang menggunakan grup parameter, lihat [Parameter klaster DB dan instans DB Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups). Untuk pengaturan konfigurasi yang berlaku atau tidak berlaku untuk klaster Aurora, lihat [Parameter konfigurasi Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md) atau [Parameter Amazon Aurora PostgreSQL](AuroraPostgreSQL.Reference.ParameterGroups.md) tergantung mesin basis data Anda.
## 9. Hubungkan ke Aurora
Seperti yang Anda temukan saat membuat skema awal dan pengaturan data serta menjalankan kueri sampel, Anda dapat terhubung ke titik akhir yang berbeda-beda dalam klaster Aurora. Titik akhir yang akan digunakan bergantung pada apakah operasinya adalah pembacaan, seperti pernyataan `SELECT` atau penulisan, seperti pernyataan `CREATE` atau `INSERT`. Saat Anda meningkatkan beban kerja pada klaster Aurora dan bereksperimen dengan fitur Aurora, penting bagi aplikasi Anda untuk menetapkan setiap operasi ke titik akhir yang sesuai.
Dengan menggunakan titik akhir cluster untuk operasi penulisan, Anda selalu terhubung ke instans DB di cluster yang memiliki read/write kemampuan. Secara default, hanya satu instans DB di cluster Aurora yang memiliki read/write kemampuan. Instans DB ini disebut *instans primer*. Jika instans primer asli tidak tersedia, Aurora mengaktifkan mekanisme failover dan instans DB yang berbeda akan mengambil alih sebagai instans primer.
Demikian pula, dengan mengarahkan pernyataan `SELECT` ke titik akhir pembaca, Anda menyebarkan pemrosesan kueri di antara instans DB dalam klaster. Setiap koneksi pembaca ditetapkan ke instans DB yang berbeda menggunakan resolusi DNS round-robin. Melakukan sebagian besar pekerjaan kueri pada Replika Aurora DB hanya baca akan mengurangi beban pada instans primer, sehingga instans tersebut dapat menangani pernyataan DDL dan DML.
Menggunakan titik akhir ini akan mengurangi ketergantungan pada nama host yang di-hard-coding, dan membantu aplikasi Anda dipulihkan lebih cepat jika ada kegagalan instans DB.
**catatan**
Aurora juga memiliki titik akhir kustom yang Anda buat. Titik akhir tersebut biasanya tidak diperlukan selama proses pembuktian konsep.
Replika Aurora dapat mengalami lag replika, meskipun lag ini biasanya berlangsung 10 hingga 20 milidetik. Anda bisa memantau lag replikasi dan memutuskan apakah lag ini masih dalam kisaran persyaratan konsistensi data Anda. Dalam beberapa kasus, kueri baca Anda mungkin akan memerlukan konsistensi baca yang kuat (konsistensi baca-setelah-tulis atau read-after-write). Jika demikian, Anda dapat terus menggunakan titik akhir klaster dan bukan titik akhir pembaca.
Untuk memanfaatkan kemampuan Aurora secara utuh untuk eksekusi paralel terdistribusi, Anda mungkin perlu mengubah logika koneksinya. Tujuan Anda adalah menghindari pengiriman semua permintaan baca ke instans primer. Replika Aurora hanya baca akan bersiaga, dengan semua data yang sama, untuk menangani pernyataan `SELECT`. Kodekan logika aplikasi Anda untuk menggunakan titik akhir yang sesuai untuk setiap jenis operasi. Ikuti pedoman umum berikut:
+ Hindari menggunakan satu string koneksi hard-code untuk semua sesi basis data.
+ Jika memungkinkan, sertakan operasi tulis seperti pernyataan DDL dan DML dalam fungsi di kode aplikasi klien Anda. Dengan demikian, Anda dapat membuat berbagai jenis operasi menggunakan koneksi tertentu.
+ Buat fungsi terpisah untuk operasi kueri. Aurora menetapkan setiap koneksi baru dengan titik akhir pembaca ke Replika Aurora yang berbeda untuk menyeimbangkan beban aplikasi sarat baca.
+ Untuk operasi yang menangani sekumpulan kueri, tutup dan buka kembali koneksi ke titik akhir pembaca saat setiap kumpulan kueri terkait selesai. Gunakan pooling koneksi jika fiturnya tersedia di tumpukan perangkat lunak Anda. Mengarahkan kueri ke koneksi yang berbeda akan membantu Aurora mendistribusikan beban kerja baca di beberapa instans DB di klaster.
Untuk informasi umum tentang manajemen koneksi dan titik akhir untuk Aurora, lihat [Menghubungkan ke klaster DB Amazon Aurora](Aurora.Connecting.md). Untuk mempelajari lebih dalam tentang bahasan ini, lihat [Buku panduan administrator basis data Aurora MySQL – Manajemen koneksi](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
## 10. Jalankan beban kerja Anda
Setelah pengaturan skema, data, dan konfigurasi dilakukan, Anda dapat mulai mencoba klaster dengan menjalankan beban kerja Anda. Gunakan beban kerja sebagai bukti konsep yang mencerminkan aspek utama beban kerja produksi Anda. Kami merekomendasikan untuk selalu membuat keputusan tentang kinerja menggunakan tes dan beban kerja dunia nyata daripada tolok ukur sintetis seperti sysbench atau. TPC-C Di mana pun praktis, kumpulkan pengukuran berdasarkan skema, pola kueri, dan volume penggunaan Anda sendiri.
Sebisa mungkin, tiru kondisi sebenarnya yang akan dialami aplikasi yang berjalan nantinya. Misalnya, Anda biasanya menjalankan kode aplikasi di instans Amazon EC2 di AWS Region yang sama dan virtual private cloud (VPC) yang sama dengan cluster Aurora. Jika aplikasi produksi Anda berjalan pada beberapa instans EC2 yang mencakup beberapa Zona Ketersediaan, maka atur lingkungan bukti konsep Anda dengan cara yang sama. Untuk informasi selengkapnya tentang Wilayah AWS , lihat [Wilayah dan Zona Ketersediaan]( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html) dalam *Panduan Pengguna Amazon RDS.* Untuk mempelajari selengkapnya tentang layanan Amazon VPC, lihat [Apa Itu Amazon VPC?]( https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) dalam *Panduan Pengguna Amazon VPC.*
Setelah Anda memastikan bahwa fitur dasar aplikasi Anda berfungsi dan Anda dapat mengakses data melalui Aurora, Anda akan dapat mencoba berbagai aspek klaster Aurora. Beberapa fitur yang mungkin ingin Anda coba adalah koneksi konkuren dengan penyeimbangan beban, transaksi konkuren, dan replikasi otomatis.
Pada tahap ini, mekanisme transfer datanya seharusnya sudah dikenal, sehingga Anda dapat menjalankan pengujian dengan proporsi data sampel yang lebih besar.
Di tahap inilah Anda dapat melihat efek dari perubahan pengaturan konfigurasi seperti batas memori dan batas koneksi. Tinjau kembali prosedur yang Anda kaji dalam [8. Tentukan pengaturan konfigurasi](#Aurora.PoC.Config).
Anda juga dapat bereksperimen dengan mekanisme seperti membuat dan memulihkan snapshot. Misalnya, Anda dapat membuat cluster dengan kelas AWS instance yang berbeda, jumlah AWS Replicas, dan sebagainya. Kemudian, di setiap klaster, Anda dapat memulihkan snapshot yang sama yang berisi skema dan semua data Anda. Untuk detail tentang siklus tersebut, lihat [Membuat snapshot klaster DB](USER_CreateSnapshotCluster.md) dan [Memulihkan dari snapshot klaster DB](aurora-restore-snapshot.md).
## 11. Ukur performa
Praktik terbaik dalam aspek ini dirancang untuk memastikan bahwa semua alat dan proses disiapkan secara tepat untuk dapat mengisolasi perilaku abnormal selama operasi beban kerja. Praktik terbaik ini juga disiapkan untuk memastikan bahwa Anda dapat mengidentifikasi kemungkinan penyebab masalah yang berlaku.
Anda selalu dapat melihat status klaster Anda saat ini, atau memeriksa tren dari waktu ke waktu, dengan memeriksa tab **Pemantauan**. Tab ini tersedia dari halaman detail konsol untuk setiap klaster atau instans DB Aurora. Ini menampilkan metrik dari layanan CloudWatch pemantauan Amazon dalam bentuk bagan. Anda dapat memfilter metrik berdasarkan nama, instans DB, dan periode waktu.
Untuk memiliki lebih banyak pilihan di tab **Pemantauan**, aktifkan Pemantauan yang Ditingkatkan dan Wawasan Performa di pengaturan klaster. Anda juga dapat mengaktifkan pilihan tersebut nanti jika Anda tidak memilihnya saat menyiapkan klaster.
Untuk mengukur performa, Anda sebagian besar akan mengandalkan bagan yang menampilkan aktivitas untuk seluruh klaster Aurora. Anda dapat memastikan apakah Replika Aurora memiliki waktu pemuatan dan waktu respons yang sama. Anda juga dapat melihat bagaimana pekerjaan dibagi antara instance read/write utama dan Replika Aurora read-only. Jika ada ketidakseimbangan antara instans DB atau masalah yang hanya memengaruhi satu instans DB, Anda dapat memeriksa tab **Pemantauan** untuk instans yang bermasalah tersebut.
Setelah lingkungan dan beban kerja sebenarnya disiapkan untuk meniru aplikasi produksi Anda, Anda dapat mengukur seberapa baik performa Aurora. Berikut adalah pertanyaan terpenting yang perlu dijawab:
+ Berapa banyak kueri per detik yang diproses Aurora? Anda dapat memeriksa metrik **Throughput** untuk melihat angka untuk berbagai jenis operasi yang ada.
+ Berapa lama rata-rata waktu yang diperlukan Aurora untuk memproses kueri tertentu? Anda dapat memeriksa metrik **Latensi** untuk melihat angka untuk berbagai jenis operasi yang ada.
[Untuk melihat metrik throughput dan latensi, periksa tab **Pemantauan** untuk klaster Aurora tertentu di konsol Amazon RDS.](https://console.aws.amazon.com/rds/) **Tangkapan layar berikut menunjukkan contoh metrik **Select Latency, **DMLLatency****, **Select Throughput, dan DMLThroughput** **pada tab Monitoring**.**
Jika memungkinkan, tetapkan nilai acuan dasar untuk metrik ini di lingkungan Anda saat ini. Jika tidak memungkinkan, maka buat acuan dasar di klaster Aurora dengan menjalankan beban kerja yang setara dengan aplikasi produksi Anda. Misalnya, jalankan beban kerja Aurora Anda dengan jumlah pengguna dan kueri simultan yang sama. Kemudian, amati perubahan nilainya saat Anda bereksperimen dengan berbagai kelas instans, ukuran klaster, pengaturan konfigurasi, dan sebagainya.
Jika jumlah throughput lebih rendah dari yang Anda harapkan, periksa lebih lanjut faktor-faktor yang memengaruhi performa basis data untuk beban kerja Anda. Selain itu, lakukan pemeriksaan lebih lanjut jika angka latensi lebih tinggi dari yang Anda harapkan. Untuk melakukannya, pantau metrik sekunder untuk server DB (CPU, memori, dan sebagainya). Anda dapat melihat apakah instans DB mulai mendekati batasnya. Anda juga dapat melihat berapa banyak kapasitas ekstra yang dimiliki instans DB Anda untuk menangani lebih banyak kueri konkuren, kueri terhadap tabel yang lebih besar, dan sebagainya.
**Tip**
Untuk mendeteksi nilai metrik yang berada di luar rentang yang diharapkan, atur CloudWatch alarm.
Saat mengevaluasi ukuran dan kapasitas klaster Aurora yang ideal, Anda akan dapat menemukan konfigurasi yang mendekati performa aplikasi maksimal tanpa penyediaan sumber daya yang berlebihan. Salah satu faktor penting adalah menemukan ukuran yang sesuai untuk instans DB di klaster Aurora. Mulailah dengan memilih ukuran instans yang memiliki CPU dan kapasitas memori yang serupa dengan lingkungan produksi Anda saat ini. Kumpulkan angka throughput dan latensi untuk beban kerja pada ukuran instans tersebut. Kemudian, naikkan skala instans ini ke ukuran yang lebih besar berikutnya. Lihat apakah angka throughput dan latensi menjadi bertambah baik. Selain itu, turunkan ukuran instans, dan lihat apakah angka latensi dan throughput tetap sama. Sasaran Anda adalah mendapatkan throughput tertinggi, dengan latensi terendah, pada instans sekecil mungkin.
**Tip**
Tentukan ukuran klaster Aurora Anda dan instans DB terkait dengan kapasitas yang cukup untuk menangani lonjakan lalu lintas yang tiba-tiba dan tidak dapat diprediksi. Untuk basis data yang bersifat vital, sisakan setidaknya 20 persen kapasitas CPU dan memori cadangan.
Jalankan uji performa selama mungkin untuk mengukur performa basis data dalam kondisi siap dan stabil. Anda mungkin perlu menjalankan beban kerja selama beberapa menit atau bahkan beberapa jam sebelum mencapai kondisi stabil ini. Varians yang bermunculan di awal proses menjalankan beban kerja adalah hal yang normal. Varians tersebut terjadi karena setiap Replika Aurora menyiapkan cache-nya berdasarkan kueri `SELECT` yang ditanganinya.
Aurora beperforma paling baik untuk beban kerja transaksional yang menangani beberapa pengguna dan kueri secara bersamaan. Untuk memastikan bahwa Anda memiliki beban yang cukup untuk performa yang optimal, jalankan penilaian tolok ukur yang menggunakan multithreading, atau jalankan beberapa uji performa secara bersamaan. Ukur performa dengan ratusan atau bahkan ribuan thread konkuren klien. Simulasikan jumlah thread konkuren yang Anda perkirakan di dalam lingkungan produksi Anda. Anda juga dapat melakukan uji stres tambahan dengan lebih banyak thread untuk mengukur skalabilitas Aurora.
## 12. Coba ketersediaan tinggi Aurora
Sebagian besar fitur utama Aurora mendukung ketersediaan yang tinggi. Fitur-fitur ini meliputi replikasi otomatis, failover otomatis, pencadangan otomatis dengan pemulihan titik waktu, dan kemampuan untuk menambahkan instans DB ke klaster. Keamanan dan keandalan dari fitur-fitur seperti ini penting untuk aplikasi yang bersifat vital.
Pola pikir tertentu diperlukan untuk mengevaluasi fitur tersebut. Dalam aktivitas sebelumnya, seperti pengukuran performa, Anda mengamati bagaimana sistem berfungsi ketika semuanya dapat bekerja dengan benar. Menguji ketersediaan tinggi mengharuskan Anda mempertimbangkan perilaku kasus terburuk. Anda harus mempertimbangkan potensi berbagai macam kegagalan, sekalipun kondisi kegagalan tersebut jarang terjadi. Anda dapat sengaja menimbulkan masalah untuk memastikan bahwa sistem dipulihkan dengan benar dan cepat.
**Tip**
Untuk bukti konsep, siapkan semua instance DB di cluster Aurora dengan kelas instance AWS yang sama. Dengan melakukannya, Anda akan dapat mencoba fitur ketersediaan Aurora tanpa perubahan besar pada performa dan skalabilitas saat Anda membuat instans DB offline untuk mensimulasikan kegagalan.
Kami merekomendasikan penggunaan setidaknya dua instans di setiap klaster Aurora. Instans DB dalam klaster Aurora dapat mencakup hingga tiga Zona Ketersediaan (AZ). Tempatkan dua atau tiga instans DB pertama di AZ yang berbeda. Saat Anda mulai menggunakan cluster yang lebih besar, sebarkan instans DB Anda di semua AZ di Wilayah Anda. AWS Dengan melakukannya, kemampuan toleransi kesalahan akan meningkat. Bahkan jika ada masalah yang memengaruhi seluruh AZ, Aurora dapat beralih ke instans DB di AZ yang berbeda. Jika Anda menjalankan klaster dengan lebih dari tiga instans, distribusikan instans DB semerata mungkin di tiga AZ.
**Tip**
Penyimpanan untuk klaster Aurora tidak tergantung pada instans DB. Penyimpanan untuk setiap klaster Aurora selalu mencakup tiga AZ.
Saat Anda menguji fitur ketersediaan tinggi, selalu gunakan instans DB dengan kapasitas yang sama di klaster pengujian Anda. Hal tersebut akan menghindari perubahan yang tidak dapat diprediksi dalam performa, latensi, dan sebagainya setiap kali ada satu instans DB yang mengambil alih instans DB lain.
Untuk mempelajari cara mensimulasikan kondisi kegagalan untuk menguji fitur ketersediaan tinggi, lihat [Menguji Amazon Aurora MySQL menggunakan kueri injeksi kesalahan](AuroraMySQL.Managing.FaultInjectionQueries.md).
Sebagai bagian dari percobaan pembuktian konsep, salah satu tujuannya adalah menemukan jumlah instans DB yang ideal dan kelas instans yang optimal untuk instans DB tersebut. Untuk melakukannya, diperlukan keseimbangan antara ketersediaan tinggi dan performa.
Untuk Aurora, semakin banyak instans DB yang Anda miliki dalam sebuah klaster, semakin besar manfaat untuk ketersediaan tinggi. Memiliki lebih banyak instans DB juga meningkatkan skalabilitas aplikasi sarat baca. Aurora dapat mendistribusikan beberapa koneksi untuk kueri `SELECT` di beberapa Replika Aurora hanya baca.
Di sisi lain, membatasi jumlah instans DB akan mengurangi lalu lintas replikasi dari simpul primer. Lalu lintas replikasi akan menggunakan bandwidth jaringan, yang merupakan aspek lain dari performa dan skalabilitas secara keseluruhan. Jadi, untuk aplikasi OLTP sarat tulis, sebaiknya Anda memiliki sedikit instans DB besar dibandingkan dengan banyak instans DB kecil.
Dalam klaster Aurora umum, satu instans DB (instans primer) menangani semua pernyataan DDL dan DML. Instans DB lainnya (Replika Aurora) hanya menangani pernyataan `SELECT`. Meskipun instans DB tidak melakukan jumlah pekerjaan yang persis sama, kami merekomendasikan penggunaan kelas instans yang sama untuk semua instans DB dalam klaster. Dengan begitu, jika terjadi kegagalan dan Aurora menjadikan salah satu instans DB hanya baca sebagai instans primer yang baru, instans primer ini akan memiliki kapasitas yang sama seperti sebelumnya.
Jika Anda perlu menggunakan instans DB dengan kapasitas berbeda dalam klaster yang sama, maka atur tingkat failover untuk instans DB. Tingkatan ini menentukan urutan promosi Replika Aurora oleh mekanisme failover. Tempatkan instans DB yang jauh lebih besar atau lebih kecil dari yang lain ke tingkat failover yang lebih rendah. Dengan melakukannya, Anda akan memastikan bahwa instans tersebut akan dipilih terakhir untuk promosi.
Coba fitur pemulihan data Aurora, seperti pemulihan titik waktu otomatis, snapshot dan pemulihan manual, serta backtracking klaster. Jika sesuai, salin snapshot ke AWS Wilayah lain dan pulihkan ke AWS Wilayah lain untuk meniru skenario DR.
Selidiki persyaratan organisasi Anda untuk sasaran waktu pemulihan (RTO), sasaran titik pemulihan (RPO), dan redundansi geografis. Sebagian besar organisasi mengelompokkan item ini ke dalam kategori pemulihan bencana. Evaluasi fitur ketersediaan tinggi Aurora yang dijelaskan di bagian ini dalam konteks proses pemulihan bencana Anda untuk memastikan bahwa persyaratan RTO dan RPO Anda terpenuhi.
## 13. Apa yang harus dilakukan selanjutnya
Di akhir proses pembuktian konsep yang berhasil dilakukan, Anda mengonfirmasi bahwa Aurora adalah solusi yang sesuai untuk Anda berdasarkan beban kerja yang diantisipasi. Sepanjang proses sebelumnya, Anda telah memeriksa cara kerja Aurora dalam lingkungan operasional yang realistis dan mengukurnya dengan kriteria kesuksesan Anda.
Setelah lingkungan basis data Anda aktif dan berfungsi dengan Aurora, Anda dapat melanjutkan ke langkah evaluasi yang lebih mendetail, yang mengarah ke migrasi akhir dan deployment produksi. Sesuai situasi Anda, langkah-langkah lain ini mungkin atau mungkin tidak akan disertakan dalam proses pembuktian konsep. Untuk detail tentang aktivitas migrasi dan porting, lihat buku AWS putih buku pegangan migrasi [Aurora](https://d1.awsstatic.com/whitepapers/Migration/amazon-aurora-migration-handbook.pdf).
Di langkah berikutnya, pertimbangkan konfigurasi keamanan yang relevan dengan beban kerja Anda dan yang dirancang untuk memenuhi persyaratan keamanan Anda dalam lingkungan produksi. Rencanakan kontrol apa yang akan diterapkan untuk melindungi akses ke kredensial pengguna master klaster Aurora. Tentukan peran dan tanggung jawab pengguna basis data untuk mengontrol akses ke data yang disimpan di klaster Aurora. Pertimbangkan persyaratan akses basis data untuk aplikasi, skrip, dan alat atau layanan pihak ketiga. Jelajahi AWS layanan dan fitur seperti AWS Secrets Manager dan AWS Identity and Access Management (IAM) otentikasi.
Pada tahap ini, Anda akan memahami prosedur dan praktik terbaik untuk menjalankan pengujian penilaian tolok ukur dengan Aurora. Anda mungkin perlu melakukan penyesuaian performa tambahan. Untuk detailnya, lihat [Mengelola performa dan penskalaan untuk klaster DB Aurora](Aurora.Managing.Performance.md), [Peningkatan performa Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance), [Kinerja dan penskalaan untuk Amazon Aurora PostgreSQL](AuroraPostgreSQL.Managing.md), dan [Memantau muatan DB dengan Wawasan Performa di Amazon Aurora](USER_PerfInsights.md). Jika Anda melakukan penyesuaian tambahan, pastikan Anda memahami metrik yang Anda kumpulkan selama pembuktian konsep. Untuk langkah berikutnya, Anda mungkin perlu membuat klaster baru dengan pilihan berbeda untuk pengaturan konfigurasi, mesin basis data, dan versi basis data. Anda juga dapat membuat jenis klaster Aurora khusus untuk menyesuaikan dengan kebutuhan kasus penggunaan tertentu.
Misalnya, Anda dapat menjelajahi klaster kueri paralel Aurora untuk aplikasi transaction/analytical pemrosesan hibrida (HTAP). Jika distribusi geografis yang luas sangat penting untuk pemulihan bencana atau untuk meminimalkan latensi, Anda dapat mengkaji basis data global Aurora. Jika beban kerja Anda terputus-putus atau Anda menggunakan Aurora dalam sebuah development/test skenario, Anda dapat menjelajahi klaster. Aurora Serverless
Klaster produksi Anda mungkin juga perlu menangani koneksi masuk dalam jumlah yang besar. Untuk mempelajari teknik-teknik tersebut, lihat buku panduan administrator AWS database Aurora MySQL Aurora [MySQL — Manajemen](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf) koneksi.
Jika, setelah pembuktian konsep, Anda memutuskan bahwa kasus penggunaan Anda tidak sesuai untuk Aurora, pertimbangkan layanan AWS lainnya berikut ini:
+ Untuk kasus penggunaan analitik murni, beban kerja mendapat manfaat dari format penyimpanan kolumnar dan fitur lain yang lebih cocok untuk beban kerja OLAP. AWS layanan yang menangani kasus penggunaan tersebut meliputi:
+ [Amazon Redshift](https://docs.aws.amazon.com/redshift/)
+ [Amazon EMR](https://docs.aws.amazon.com/emr/)
+ [Amazon Athena](https://docs.aws.amazon.com/athena/)
+ Sebagian besar beban kerja akan mendapatkan keuntungan dari kombinasi Aurora dengan satu atau beberapa layanan ini. Anda dapat memindahkan data di antara layanan-layanan ini dengan menggunakan hal berikut ini:
+ [AWS Glue](https://docs.aws.amazon.com/glue/)
+ [AWS DMS](https://docs.aws.amazon.com/dms/)
+ [Mengimpor dari Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html), sebagaimana dijelaskan di *Panduan Pengguna Amazon Aurora *
+ [Mengekspor ke Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.SaveIntoS3.html), sebagaimana dijelaskan di *Panduan Pengguna Amazon Aurora*
+ Banyak alat ETL populer lainnya