Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Menggunakan AWS Lambda fungsi di Amazon Neptunus
AWS Lambda fungsi memiliki banyak kegunaan dalam aplikasi Amazon Neptunus. Di sini kami memberikan panduan umum untuk menggunakan fungsi Lambda dengan salah satu driver Gremlin populer dan varian bahasa, dan contoh spesifik fungsi Lambda yang ditulis dalam Java,, dan Python. JavaScript
catatan
Cara terbaik untuk menggunakan fungsi Lambda dengan Neptune telah diubah dengan rilis mesin baru-baru ini. Neptune yang digunakan untuk meninggalkan koneksi idle terbuka lama setelah konteks eksekusi Lambda telah didaur ulang, berpotensi menyebabkan kebocoran sumber daya pada server. Untuk mengurangi ini, kami merekomendasikan membuka dan menutup koneksi dengan setiap invokasi Lambda. Dimulai dengan mesin versi 1.0.3.0, namun, batas waktu koneksi siaga telah dikurangi sehingga koneksi tidak lagi bocor setelah konteks eksekusi Lambda tidak aktif telah didaur ulang, sehingga sekarang kami sarankan untuk menggunakan koneksi tunggal selama durasi konteks eksekusi. Ini harus mencakup beberapa penanganan kesalahan dan kode back-off-and-retry boilerplate untuk menangani koneksi yang ditutup secara tidak terduga.
Mengelola WebSocket koneksi Gremlin dalam fungsi AWS Lambda
Jika Anda menggunakan varian bahasa Gremlin untuk menanyakan Neptunus, driver terhubung ke database menggunakan koneksi. WebSocket WebSockets dirancang untuk mendukung skenario koneksi client-server yang berumur panjang. AWS Lambda, di sisi lain, dirancang untuk mendukung eksekusi yang relatif berumur pendek dan tanpa kewarganegaraan. Ketidakcocokan dalam filosofi desain dapat menyebabkan beberapa masalah tak terduga saat menggunakan Lambda untuk kueri Neptune.
AWS Lambda Fungsi berjalan dalam konteks eksekusi yang mengisolasi fungsi dari fungsi lain. Konteks eksekusi dibuat pertama kalinya saat fungsi dipanggil dan dapat digunakan kembali untuk invokasi berikutnya dari fungsi yang sama.
Namun, salah satu konteks eksekusi tidak pernah digunakan untuk menangani beberapa invokasi yang bersamaan dari fungsi. Jika fungsi Anda dipanggil secara bersamaan oleh beberapa klien, Lambda memutar sebuah konteks eksekusi tambahan untuk setiap instans dari fungsi. Semua konteks eksekusi baru ini pada gilirannya dapat digunakan kembali untuk invokasi berikutnya dari fungsi.
Pada titik tertentu, Lambda mendaur ulang konteks eksekusi, terutama jika mereka tidak aktif selama beberapa waktu. AWS Lambda mengekspos siklus hidup konteks eksekusi, termasuk, Invoke dan Shutdown faseInit, melalui ekstensi Lambda. Menggunakan ekstensi ini, Anda dapat menulis kode yang membersihkan sumber daya eksternal seperti koneksi basis data ketika konteks eksekusi di daur ulang.
Praktik terbaik yang umum adalah membuka koneksi basis data di luar fungsi handler Lambda sehingga dapat digunakan kembali dengan setiap panggilan handler. Jika koneksi basis data turun di beberapa titik, Anda dapat menyambung kembali dari dalam handler. Namun, ada bahaya kebocoran koneksi dengan pendekatan ini. Jika koneksi idle tetap terbuka lama setelah konteks eksekusi hancur, skenario invokasi Lambda berterusan atau berselang secara bertahap dapat membocorkan koneksi dan menghabiskan sumber daya basis data.
Batas koneksi Neptune dan timeout koneksi telah berubah dengan rilis mesin yang lebih baru. Sebelumnya, setiap instance mendukung hingga 60.000 WebSocket koneksi. Sekarang, jumlah maksimum WebSocket koneksi bersamaan per instance Neptunus bervariasi dengan jenis instance.
Juga, dimulai dengan rilis mesin 1.0.3.0, Neptune mengurangi batas waktu idle untuk koneksi dari satu jam ke sekitar 20 menit. Jika klien tidak menutup koneksi, koneksi ditutup secara otomatis setelah batas waktu idle 20 hingga 25 menit. AWS Lambda tidak mendokumentasikan masa pakai konteks eksekusi, tetapi eksperimen menunjukkan bahwa batas waktu koneksi Neptunus baru sejalan dengan batas waktu konteks eksekusi Lambda yang tidak aktif. Pada saat konteks eksekusi tidak aktif didaur ulang, ada kemungkinan koneksinya telah ditutup oleh Neptune, atau akan ditutup segera setelah itu.
Rekomendasi untuk digunakan AWS Lambda dengan Amazon Neptunus Gremlin
Kami sekarang merekomendasikan menggunakan koneksi tunggal dan sumber grafik traversal untuk seumur hidup dari konteks eksekusi Lambda, bukan satu untuk setiap invokasi fungsi (setiap fungsi invkasi hanya menangani hanya satu permintaan klien). Karena permintaan klien yang bersamaan ditangani oleh instans fungsi yang berbeda yang berjalan di dalam konteks eksekusi terpisah, maka tidak perlu mempertahankan kolam koneksi untuk menangani permintaan yang bersamaan dalam instans fungsi. Jika driver Gremlin yang Anda gunakan memiliki kolam koneksi, konfigurasikan driver tersebut untuk menggunakan hanya satu koneksi.
Untuk menangani kegagalan koneksi, gunakan logika coba lagi di sekitar masing-masing kueri. Meskipun tujuannya adalah untuk mempertahankan koneksi tunggal untuk seumur hidup konteks eksekusi, peristiwa jaringan tak terduga dapat menyebabkan koneksi tersebut dihentikan tiba-tiba. Kegagalan koneksi seperti itu terwujud sebagai kesalahan yang berbeda tergantung pada driver yang Anda gunakan. Anda harus melakukan kode fungsi Lambda Anda untuk menangani masalah koneksi ini dan mencoba koneksi ulang jika diperlukan.
Beberapa driver Gremlin secara otomatis menangani koneksi ulang. Driver Java, misalnya, secara otomatis mencoba untuk membangun kembali konektivitas ke Neptune atas nama kode klien Anda. Dengan driver ini, kode fungsi Anda hanya perlu mundur dan coba lagi kueri. Driver JavaScript dan Python, sebaliknya, tidak menerapkan logika koneksi ulang otomatis apa pun, jadi dengan driver ini kode fungsi Anda harus mencoba menyambung kembali setelah mundur, dan hanya mencoba lagi kueri setelah koneksi dibuat kembali.
Contoh kode di sini termasuk logika rekoneksi daripada menganggap bahwa klien mengurus itu.
Rekomendasi untuk menggunakan permintaan tulis Gremlin di Lambda
Jika fungsi Lambda Anda memodifikasi data grafik, pertimbangkan untuk mengadopsi back-off-and-retry strategi untuk menangani pengecualian berikut:
-
ConcurrentModificationException– Semantik transaksi Neptune berarti bahwa permintaan tulis terkadang gagal denganConcurrentModificationException. Dalam situasi ini, cobalah mekanisme coba lagi back-off-based eksponensial. -
ReadOnlyViolationException– Karena topologi klaster dapat berubah setiap saat sebagai akibat dari peristiwa yang direncanakan atau tidak direncanakan, menulis tanggung jawab dapat bermigrasi dari satu instans ke lainnya dalam klaster. Jika kode fungsi Anda mencoba untuk mengirim permintaan tulis ke instans yang bukan lagi instans utama (penulis), permintaan gagal denganReadOnlyViolationException. Ketika ini terjadi, tutup koneksi yang ada, sambung kembali ke titik akhir klaster, dan kemudian coba lagi permintaannya.
Selain itu, jika Anda menggunakan back-off-and-retry strategi untuk menangani masalah permintaan tulis, pertimbangkan untuk menerapkan kueri idempoten untuk membuat dan memperbarui permintaan (misalnya, menggunakan fold () .coalesce () .unfold ()
Rekomendasi untuk menggunakan permintaan tulis Gremlin di Lambda
Jika Anda memiliki satu replika baca atau lebih klaster Anda, itu ide yang baik untuk menyeimbangkan permintaan baca di seluruh replika ini. Salah satu pilihan adalah dengan menggunakan reader endpoint. Reader Endpoint menyeimbangkan koneksi di seluruh replika bahkan jika topologi klaster berubah ketika Anda menambahkan atau menghapus replika, atau mempromosikan replika untuk menjadi instans primer baru.
Namun, menggunakan Reader Endpoint dapat mengakibatkan penggunaan sumber daya klaster yang tidak merata dalam beberapa keadaan. Titik akhir pembaca bekerja dengan mengubah host yang ditunjuk oleh DNS entri secara berkala. Jika klien membuka banyak koneksi sebelum DNS entri berubah, semua permintaan koneksi dikirim ke satu instance Neptunus. Hal ini dapat menjadi kasus dengan skenario Lambda throughput tinggi di mana sejumlah besar permintaan bersamaan untuk fungsi Lambda Anda menyebabkan beberapa konteks eksekusi akan dibuat, masing-masing dengan koneksinya sendiri. Jika koneksi tersebut semuanya dibuat hampir bersamaan, koneksi cenderung ke semua titik pada replika yang sama dalam klaster, dan untuk tetap menunjuk ke replika itu sampai konteks eksekusi didaur ulang.
Salah satu cara Anda dapat mendistribusikan permintaan di seluruh instans adalah untuk mengkonfigurasi fungsi Lambda Anda agar terhubung ke titik akhir instans, dipilih secara acak dari daftar titik akhir instans replika, bukan Reader Endpoint. Kelemahan dari pendekatan ini adalah bahwa pendekatan ini memerlukan kode Lambda untuk menangani perubahan dalam topologi klaster dengan memantau klaster dan memperbarui daftar titik akhir setiap kali keanggotaan klaster berubah.
Jika Anda menulis fungsi Lambda Java yang perlu menyeimbangkan permintaan baca di seluruh instans di klaster Anda, Anda dapat menggunakan Klien Gremlin untuk Amazon Neptune
Faktor-faktor yang dapat memperlambat awal dingin dari fungsi Lambda Gremlin Neptune
Pertama kali AWS Lambda fungsi dipanggil disebut sebagai awal yang dingin. Ada beberapa faktor yang dapat meningkatkan latensi awal dingin:
-
Pastikan untuk menetapkan memori yang cukup untuk fungsi Lambda Anda. — Kompilasi selama start dingin dapat secara signifikan lebih lambat untuk fungsi Lambda daripada yang akan terjadi EC2 karena AWS Lambda mengalokasikan CPU siklus secara linier sebanding dengan memori yang Anda tetapkan ke fungsi tersebut. Dengan memori 1.769 MB, suatu fungsi menerima setara dengan satu v penuh CPU (satu v CPU -detik kredit per detik). Dampak dari tidak menetapkan memori yang cukup untuk menerima CPU siklus yang memadai terutama terlihat untuk fungsi Lambda besar yang ditulis di Jawa.
-
Ketahuilah bahwa mengaktifkan otentikasi IAM database dapat memperlambat cold start — AWS Identity and Access Management (IAM) otentikasi database juga dapat memperlambat cold start, terutama jika fungsi Lambda harus menghasilkan kunci penandatanganan baru. Latensi ini hanya memengaruhi cold start dan bukan permintaan berikutnya, karena begitu autentikasi IAM DB telah menetapkan kredenal koneksi, Neptunus hanya secara berkala memvalidasi bahwa mereka masih valid.
