Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pilar keandalan
Pilar keandalan dari AWS Well-Architected Framework mencakup kemampuan beban kerja untuk menjalankan fungsi yang dimaksudkan dengan benar dan konsisten ketika diharapkan. Ini termasuk kemampuan untuk mengoperasikan dan menguji beban kerja di seluruh siklus hidupnya.
Beban kerja yang andal dimulai dengan desain perangkat lunak dan infrastruktur yang diputuskan sejak awal. Pilihan arsitektur Anda akan memengaruhi perilaku beban kerja Anda di semua pilar Well-Architected. Untuk keandalan, terdapat beberapa pola tertentu yang harus diikuti.
Pilar keandalan berfokus pada bidang-bidang utama berikut:
-
Arsitektur beban kerja, termasuk kuota layanan dan pola penerapan
-
Manajemen perubahan
-
Manajemen kegagalan
Memahami kuota layanan Neptunus
Volume cluster Neptunus dapat tumbuh hingga ukuran maksimum 128 tebibytes (TiB) di semua yang didukung Wilayah AWS kecuali Tiongkok GovCloud dan, di mana kuotanya 64 TiB.
Kuota 128 TiB cukup untuk menyimpan sekitar 200-400 miliar objek dalam grafik. Dalam grafik properti berlabel (LPG), objek adalah simpul, tepi, atau properti pada simpul atau tepi. Dalam grafik Resource Description Framework (RDF), sebuah objek adalah quad.
Untuk cluster Neptunus Tanpa Server, Anda menetapkan jumlah minimum dan maksimum Unit Kapasitas Neptunus (). NCUs Setiap NCU terdiri dari 2 gibibytes (GiB) memori dan vCPU dan jaringan terkait. Nilai NCU minimum dan maksimum berlaku untuk setiap instance tanpa server di cluster. Nilai NCU maksimum tertinggi yang dapat Anda atur adalah 128,0 NCUs, dan minimum terendah adalah 1,0. NCUs Optimalkan rentang NCU yang paling sesuai untuk aplikasi Anda dengan mengamati CloudWatch metrik Amazon ServerlessDatabaseCapacity dan NCUUtilization menangkap rentang yang biasa Anda jalankan dan mengkorelasikan perilaku atau biaya yang tidak diinginkan dalam rentang tersebut. Jika Anda menemukan bahwa beban kerja Anda tidak berskala cukup cepat, tingkatkan minimum NCUs untuk menyediakan pemrosesan yang cukup untuk lonjakan awal saat skala.
Masing-masing Akun AWS memiliki kuota untuk setiap Wilayah pada jumlah sumber daya database yang dapat Anda buat. Sumber daya ini termasuk instans DB dan klaster DB. Setelah batas sumber daya tercapai, panggilan tambahan untuk membuat sumber daya itu gagal dengan pengecualian. Beberapa kuota adalah kuota lunak yang dapat ditingkatkan berdasarkan permintaan. Untuk daftar kuota yang dibagikan antara Amazon Neptunus dan Amazon RDS, Amazon Aurora, dan Amazon DocumentDB (dengan kompatibilitas MongoDB), bersama dengan tautan untuk meminta peningkatan kuota bila tersedia, lihat Kuota di Amazon RDS.
Memahami pola penyebaran Neptunus
Dalam klaster DB Neptune, terdapat satu instans DB utama dan hingga 15 replika Neptune. Instans DB primer mendukung operasi baca dan tulis, dan melakukan semua modifikasi data pada volume cluster. Replika Neptunus terhubung ke volume penyimpanan yang sama dengan instans DB utama, dan mereka hanya mendukung operasi baca. Replika Neptune juga dapat memindahkan beban kerja baca dari instans DB utama.
Untuk mencapai ketersediaan tinggi, gunakan replika baca. Memiliki satu atau lebih instance replika baca yang tersedia di Availability Zone yang berbeda dapat meningkatkan ketersediaan karena replika baca berfungsi sebagai target failover untuk instance utama. Jika instance penulis gagal, Neptunus mempromosikan instance replika baca untuk menjadi contoh utama. Ketika ini terjadi, ada gangguan singkat (umumnya kurang dari 30 detik) saat instance yang dipromosikan di-boot ulang, di mana permintaan baca dan tulis yang dibuat ke instance utama gagal dengan pengecualian. Untuk keandalan tertinggi, pertimbangkan dua replika baca di Availability Zone yang berbeda. Jika instance utama di Availability Zone 1 offline, instance di Availability Zone 2 dipromosikan ke primer, tetapi tidak dapat menangani kueri saat itu terjadi. Jadi instance di Availability Zone 3 diperlukan untuk menangani kueri baca selama transisi.
Jika Anda menggunakan Neptunus Tanpa Server, instance pembaca dan penulis di semua Availability Zone akan naik dan turun, secara independen satu sama lain, tergantung pada pemuatan database mereka. Anda dapat mengatur tingkat promosi instance pembaca ke 0 atau 1 sehingga skala naik dan turun bersama dengan kapasitas instance penulis. Ini membuatnya siap untuk mengambil alih beban kerja saat ini kapan saja.
Kelola dan skala cluster Neptunus
Anda dapat menggunakan auto-scaling Neptunus untuk secara otomatis menyesuaikan jumlah replika Neptunus dalam cluster DB untuk memenuhi persyaratan konektivitas dan beban kerja Anda berdasarkan ambang batas pemanfaatan CPU. Dengan auto-scaling, cluster DB Neptunus Anda dapat menangani peningkatan beban kerja yang tiba-tiba. Ketika beban kerja berkurang, auto-scaling menghapus replika yang tidak perlu sehingga Anda tidak membayar untuk kapasitas yang tidak digunakan. Ketahuilah bahwa startup instance baru dapat memakan waktu selama 15 menit, jadi auto-scaling saja bukanlah solusi yang cukup untuk perubahan permintaan yang cepat.
Anda dapat menggunakan auto-scaling hanya dengan cluster DB Neptunus yang sudah memiliki satu instance penulis utama dan setidaknya satu instance read-replica (lihat Amazon Neptunus DB Clusters and Instances). Juga, semua instance read-replica di cluster harus dalam keadaan tersedia. Jika ada replika baca dalam keadaan selain tersedia, auto-scaling Neptunus tidak melakukan apa pun sampai setiap replika baca di cluster tersedia.
Jika Anda mengalami perubahan permintaan yang cepat, pertimbangkan untuk menggunakan instance tanpa server. Instans tanpa server dapat menskalakan secara vertikal selama periode pendek sementara auto-scaling menskalakan secara horizontal selama periode yang lebih lama. Konfigurasi ini memberikan skalabilitas optimal karena instans tanpa server menskalakan secara vertikal sementara auto-scaling membuat instance replika baca baru untuk menangani beban kerja di luar kapasitas maksimum instans tanpa server tunggal. Untuk informasi selengkapnya tentang penskalaan kapasitas Amazon Neptunus Tanpa Server, lihat Penskalaan kapasitas di kluster DB Tanpa Server Neptunus.
Jika penskalaan Anda perlu berubah pada waktu yang dapat diprediksi, Anda dapat menjadwalkan perubahan pada instans minimum, instans maksimum, dan ambang batas untuk menangani kebutuhan pergeseran tersebut dengan lebih baik. Ingatlah untuk menjadwalkan acara penskalaan setidaknya 15 menit sebelumnya untuk memungkinkan contoh-contoh tersebut online saat diperlukan.
Anda mengelola konfigurasi database Anda di Amazon Neptunus dengan menggunakan parameter dalam grup parameter. Grup parameter bertindak sebagai wadah untuk nilai konfigurasi mesin yang diterapkan ke satu atau lebih instance DB. Saat memodifikasi parameter cluster dalam kelompok parameter, pahami perbedaan antara parameter statis dan dinamis, dan bagaimana dan kapan parameter tersebut diterapkan. Gunakan titik akhir status untuk melihat konfigurasi yang diterapkan saat ini.
Kelola pencadangan dan peristiwa failover
Neptunus mencadangkan volume cluster Anda secara otomatis, dan menyimpan data yang dicadangkan selama periode retensi cadangan. Cadangan Neptune bersifat terus-menerus dan bertahap, sehingga Anda dapat dengan cepat memulihkan ke titik mana pun dalam periode penyimpanan cadangan. Anda dapat menentukan periode retensi cadangan 1-35 hari saat membuat atau memodifikasi cluster DB.
Untuk menyimpan cadangan di luar periode retensi cadangan, Anda juga dapat mengambil snapshot data dalam volume cluster Anda. Menyimpan snapshot menimbulkan biaya penyimpanan standar untuk Neptune.
Saat Anda membuat snapshot Amazon Neptunus dari cluster DB, Neptunus membuat snapshot volume penyimpanan cluster, mencadangkan semua datanya, bukan hanya instance individual. Anda nantinya dapat membuat cluster DB baru dengan memulihkan dari snapshot cluster DB ini. Saat Anda memulihkan cluster DB, Anda memberikan nama snapshot cluster DB untuk dipulihkan, dan kemudian Anda memberikan nama untuk cluster DB baru yang dibuat oleh pemulihan.
Uji bagaimana sistem Anda merespons peristiwa failover. Gunakan Neptunus API untuk memaksa peristiwa failover. Reboot dengan failover bermanfaat ketika Anda ingin mensimulasikan kegagalan instans DB untuk pengujian atau untuk memulihkan operasi ke Availability Zone asli setelah failover terjadi. Untuk informasi selengkapnya, lihat Mengonfigurasi dan mengelola penerapan Multi-AZ. Saat Anda me-reboot instance DB writer, itu gagal ke replika siaga. Mereboot replika Neptune tidak memulai failover.
Rancang klien Anda untuk keandalan. Uji perilaku mereka selama peristiwa failover. Terapkan logika coba lagi di klien Anda dengan logika backoff eksponensial. Contoh kode yang menerapkan logika ini dapat ditemukan dalam contoh AWS Lambda fungsi untuk Amazon Neptunus.
Pertimbangkan untuk menggunakan AWS Backup
