View a markdown version of this page

Pilar keberlanjutan - AWS Bimbingan Preskriptif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pilar keberlanjutan

Pilar keberlanjutan dari AWS Well-Architected Framework berfokus pada meminimalkan dampak lingkungan dari menjalankan beban kerja cloud. Topik utama mencakup model tanggung jawab bersama untuk keberlanjutan, memahami dampak, dan memaksimalkan penggunaan untuk meminimalkan sumber daya yang dibutuhkan dan mengurangi dampak hilir.

Pilar keberlanjutan berisi area fokus utama berikut:

  • Dampak Anda

  • Tujuan keberlanjutan

  • Penggunaan yang dimaksimalkan

  • Mengantisipasi dan mengadopsi penawaran perangkat lunak baru yang lebih efisien

  • Penggunaan layanan terkelola

  • Pengurangan dampak hilir

Panduan ini berfokus pada pemahaman dampak Anda. Untuk informasi lebih lanjut tentang prinsip desain keberlanjutan lainnya, lihat Kerangka Kerja AWS Well-Architected.

Pilihan dan persyaratan Anda berdampak pada lingkungan. Jika Anda dapat memilih Region AWS yang memiliki intensitas karbon lebih rendah, dan jika kebutuhan Anda mencerminkan kebutuhan beban kerja yang sebenarnya, bukan hanya memaksimalkan waktu kerja dan daya tahan, keberlanjutan beban kerja meningkat. Bagian selanjutnya membahas praktik dan pertimbangan terbaik yang akan memiliki dampak lingkungan yang positif jika diadopsi dalam desain beban kerja Anda dan operasi yang sedang berlangsung

Pertimbangkan AWS Region pilihan Anda

Beberapa Region AWS berada di dekat proyek energi terbarukan Amazon atau terletak di mana jaringan memiliki intensitas karbon yang diterbitkan yang lebih rendah daripada yang lain. Pertimbangkan dampak keberlanjutan untuk Wilayah yang mungkin layak untuk beban kerja Anda, dan rujuk silang daftar Anda dengan Wilayah tempat Analitik Neptunus tersedia.

Optimalkan konsumsi

Minimalkan konsumsi Neptunus Analytics dengan mempraktikkan hal-hal berikut:

  • Analytics sering bersifat fana. Grafik diperlukan hanya untuk waktu untuk menjalankan algoritma dan mencatat hasilnya. Jika ini masalahnya, snapshot dan hapus grafik ketika tidak lagi diperlukan. Anda dapat mengembalikannya dari snapshot nanti jika perlu.

  • Jika beban kerja bersifat sementara dan Anda memiliki fleksibilitas untuk memutuskan kapan menjalankan analitik, pertimbangkan day-to-day tren konsumsi daya. Permintaan listrik lebih tinggi selama waktu-waktu tertentu. Jika Anda berada di Amerika Serikat, lihat metrik konsumsi listrik harian di situs web Administrasi Informasi Energi AS (EIA). Jalankan beban kerja selama periode off-peak untuk Wilayah Anda jika memungkinkan.

  • Jika beban kerja tidak bersifat sementara tetapi hanya perlu tersedia untuk periode terbatas, hapus grafik dan pulihkan dari snapshot saat diperlukan. Jika ketersediaannya mengikuti jadwal, otomatiskan proses restorasi melalui skrip sehingga grafik siap pada waktu yang dijadwalkan.

  • Jika data hanya-baca atau tidak berubah sejak snapshot terakhir, jangan snapshot lagi sebelum dihapus.

  • Hentikan notebook Neptunus saat tidak digunakan.

  • Pantau CloudWatch metrik sepertiNumQueuedRequestsPerSec,NumOpenCypherRequestsPerSec,GraphStorageUsagePercent,GraphSizeBytes, dan CPUUtilization untuk menilai apakah grafik terlalu besar. Tentukan apakah kapasitas instans yang lebih kecil dapat mengakomodasi tingkat permintaan yang diamati, penggunaan CPU, dan ukuran grafik.

Optimalkan pengembangan perangkat lunak dan pola arsitektur

Untuk mencegah pemborosan, optimalkan model dan kueri, dan bagikan sumber daya komputasi sehingga Anda menggunakan semua sumber daya yang tersedia di instans dan cluster Neptunus. Praktik terbaik khusus meliputi:

  • Optimalkan kueri dan pemanggilan algoritma grafik. Gunakan kueri berparameter dan gunakan cache paket kueri, yang diaktifkan secara default. Untuk kueri yang lambat, jalankan rencana penjelasan untuk melakukan perbaikan. Jika Anda menggunakan pencarian kesamaan vektor, putuskan apakah penyematan yang lebih kecil menghasilkan hasil kesamaan yang akurat, karena penyematan yang lebih kecil dapat dibuat, disimpan, dan dicari dengan lebih efisien. Sebelum Anda memanggil algoritma grafik, gunakan MATCH klausa untuk meminimalkan set node input. Filter pada label simpul dan tepi jika memungkinkan.

  • Carilah cara paling efisien untuk memuat data ke dalam grafik. Jika Anda memuat dari data di Amazon S3, gunakan impor massal jika data berukuran lebih besar dari 50 GB. Gunakan beban batch untuk data yang lebih kecil.

  • Minta pengembang untuk membagikan instance notebook Neptunus alih-alih masing-masing membuat instance mereka sendiri. Buat folder notebook terpisah untuk setiap pengembang pada satu instance Jupyter. Matikan instance saat tidak digunakan.