Pilar keandalan

Pilar keandalan Well-Architected Framework mencakup kemampuan beban kerja untuk menjalankan fungsi yang dimaksudkan dengan benar dan konsisten ketika diharapkan. AWS Ini termasuk kemampuan untuk mengoperasikan dan menguji beban kerja melalui seluruh siklus hidupnya.

Beban kerja yang andal dimulai dengan desain perangkat lunak dan infrastruktur yang diputuskan sejak awal. Pilihan arsitektur Anda memengaruhi perilaku beban kerja Anda di semua pilar Well-Architected. Untuk keandalan, ada pola khusus yang harus Anda ikuti, seperti yang dibahas di bagian ini.

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

AWS Akun Anda memiliki kuota default (sebelumnya disebut sebagai batas) untuk masing-masing. Layanan AWS Kecuali dinyatakan lain, setiap kuota bersifat khusus per Wilayah. Anda dapat meminta kenaikan untuk beberapa, tetapi tidak semua, kuota.

Untuk menemukan kuota untuk Neptune Analytics, buka konsol Service Quotas. Di panel navigasi, pilih Layanan AWS, lalu pilih Amazon Neptune Analytics. Perhatikan kuota pada jumlah grafik dan snapshot, memori maksimum yang disediakan untuk grafik, dan tingkat permintaan API.

Jika memori maksimum yang disediakan tidak cukup untuk kumpulan data Anda, nilai tipe node dan edge mana yang penting untuk penggunaan analitis yang Anda maksudkan. Muat subset data sehingga analitik dimungkinkan dalam kapasitas yang disediakan yang diizinkan. Banyak beban kerja analitik, terutama yang menjalankan algoritme grafik, hanya membutuhkan topologi dengan seperangkat properti terbatas, bukan grafik transaksional lengkap. (Untuk diskusi tentang perbedaan antara beban kerja transaksional dan analitis, lihat bagian Pilar efisiensi kinerja.)

Jika jumlah maksimum grafik tidak cukup untuk tujuan penggunaan Anda:

• Pertimbangkan untuk menggabungkan grafik yang memiliki kegunaan serupa.

• Nilai berapa banyak grafik yang harus dijalankan pada waktu tertentu. Jika Anda memiliki kasus penggunaan analitik singkat, snapshot dan hapus grafik saat tidak lagi diperlukan. Ini mengurangi jumlah grafik terhadap kuota.

• Pertimbangkan penyediaan grafik secara berbeda. Akun AWS

Memahami pola penyebaran Neptunus

Pahami poin keputusan berikut saat Anda berencana menerapkan grafik Neptunus Analytics:

• Pembibitan: Putuskan apakah akan membuat grafik kosong atau memuat data ke dalamnya pada waktu pembuatan dengan data dari Amazon S3, kluster basis data Neptunus yang ada, atau snapshot database Neptunus yang ada.

  Rekomendasi: Jika sumbernya adalah cluster atau snapshot Neptunus, Anda harus memuat datanya pada waktu pembuatan grafik. Jika sumbernya adalah Amazon S3, muat data pada waktu pembuatan jika upaya pemuatannya signifikan dan paling baik dilakukan sebagai aktivitas penyediaan infrastruktur. Jika Anda lebih suka memuat data sebagai rekayasa data atau aktivitas aplikasi, buat grafik kosong dan muat data dari Amazon S3 nanti.

• Kapasitas: Perkirakan kapasitas penyediaan yang diperlukan untuk grafik, mengingat ukuran data dan penggunaan aplikasi yang diharapkan.

  Rekomendasi: Pada waktu pembuatan, tentukan memori maksimum yang disediakan untuk membatasi ukuran grafik. Pengaturan ini wajib. Anda dapat mengubah kapasitas nanti jika perlu.

• Ketersediaan dan toleransi kesalahan: Putuskan apakah replika diperlukan untuk ketersediaan. Replika bertindak sebagai siaga hangat untuk pemulihan jika terjadi kegagalan grafik. Grafik dengan replika pulih lebih cepat daripada grafik tanpa replika. Juga pertimbangkan berapa lama grafik diperlukan, apakah itu hanya untuk analitik singkat, dan, jika demikian, kapan akan dihapus.

  Rekomendasi: Tentukan persyaratan ketersediaan—seperti berapa lama grafik tidak tersedia dan kapan dapat dihapus—sebelum Anda membuat grafik.

• Jaringan dan keamanan: Tentukan apakah Anda memerlukan konektivitas publik, konektivitas pribadi, atau keduanya, dan apakah Anda ingin mengenkripsi data Anda.

  Rekomendasi: Pahami persyaratan organisasi—seperti apakah konektivitas publik diizinkan dan di mana aplikasi klien grafik akan dikerahkan—sebelum Anda membuat grafik.

• Pencadangan dan pemulihan: Tentukan apakah snapshot harus dibuat, dan, jika demikian, kapan atau dalam kondisi apa. Pertimbangkan apakah organisasi Anda memiliki persyaratan pemulihan bencana (DR).

  Rekomendasi: Membuat snapshot adalah aktivitas manual. Putuskan kapan harus membuat snapshot dan pertimbangkan persyaratan DR Anda sebelum Anda membuat grafik.

Kelola dan skala cluster Neptunus

Grafik Neptunus Analytics terdiri dari satu instance yang dioptimalkan untuk memori. Kapasitas (m-NCU) dari instance diatur pada waktu pembuatan. Instance dapat diskalakan secara vertikal dengan meningkatkan kapasitas yang disediakan melalui tindakan administratif; kapasitas yang disediakan juga dapat dikurangi. Replika adalah target failover pasif, sehingga tidak meningkatkan skala grafik. Dalam hal ini, replika grafik berbeda dari replika baca database Neptunus, yang merupakan instance aktif dalam cluster Neptunus yang dapat memproses operasi baca dari aplikasi.

Replika dikenakan biaya. Replika diberi harga pada tingkat m-NCu dari grafik. Misalnya, jika grafik disediakan untuk 128 m-NCU dan memiliki replika tunggal, biayanya dua kali lipat dari grafik ekivalen yang tidak memiliki replika.

Dalam analitik, ada dua alasan utama untuk meningkatkan skala:

• Untuk menyediakan lebih banyak memori dan CPU untuk kueri analitik dan algoritme, karena kueri individual mahal, algoritma grafik yang dijalankan secara inheren kompleks dan membutuhkan lebih banyak sumber daya mengingat inputnya, atau tingkat permintaan bersamaan tinggi. Jika kueri semacam itu mengalami out-of-memory kesalahan, penskalaan adalah solusi yang masuk akal.

• Untuk mendukung ukuran grafik yang lebih besar dari yang Anda rencanakan. Misalnya, jika kapasitas yang disediakan saat ini adalah 128 m-NCU untuk mendukung 60 GB data sumber dan Anda memerlukan tambahan 40 GB data sumber, peningkatan menjadi 256 m-NCU dijamin.

Pantau CloudWatch metrik untuk Neptunus Analytics, NumQueuedRequestsPerSec seperti,,,NumOpenCypherRequestsPerSec,, CPUUtilization dan GraphStorageUsagePercentGraphSizeBytes, untuk menentukan apakah penskalaan diperlukan. Anda dapat memperbarui konfigurasi grafik melalui konsol, AWS CLI, atau SDKs. (Untuk contoh dan praktik terbaik, lihat bagian pilar keunggulan operasional.)

Kelola pencadangan dan peristiwa failover

Gunakan replika untuk memastikan bahwa grafik tetap tersedia jika terjadi kegagalan. Grafik menggunakan persistensi berbasis log untuk melakukan perubahan di seluruh Availability Zone dalam file. Wilayah AWS Replika bertindak sebagai siaga hangat dan memiliki akses ke data ini. Jika ada kegagalan, grafik melanjutkan operasi pada replika. Aplikasi terus menggunakan titik akhir yang sama untuk terhubung ke grafik. Permintaan dalam penerbangan selama kegagalan menghasilkan kesalahan dengan pengecualian layanan yang tidak tersedia. Pertimbangkan untuk menggunakan coba lagi dengan pola backoff dalam kode aplikasi untuk menangkap kesalahan, dan coba lagi setelah interval singkat. Permintaan baru yang dibuat selama failover diantrian dan mungkin mengalami latensi yang lebih lama.

Jika tidak ada replika yang dikonfigurasi dan grafik gagal, Neptunus Analytics pulih dari penyimpanan yang tahan lama, tetapi pemulihan membutuhkan waktu lebih lama karena Neptunus harus menginisialisasi ulang sumber daya.

Buat snapshot dari grafik. (Neptune Analytics tidak mengambil snapshot otomatis.) Jika grafik dimodifikasi secara teratur setelah pembuatan, sering-seringlah mengambil snapshot untuk menangkap statusnya saat ini. Hapus snapshot lama jika pemulihan ke titik waktu sebelumnya tidak diperlukan.

Anda dapat berbagi snapshot dengan akun lain dan di seberang Wilayah AWS. Jika Anda memiliki persyaratan DR, pertimbangkan apakah memulihkan grafik di Wilayah yang berbeda dari snapshot memenuhi persyaratan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) Anda.