Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Apa itu AWS Lambda?
**Tip**
Bergabunglah dengan pakar Tanpa Server untuk lokakarya langsung gratis untuk mempelajari cara membuat aplikasi Tanpa Server dengan praktik terbaik. [Klik di sini](https://aws-experience.com/amer/smb/events/series/Get-Hands-On-With-Serverless?trk=188abe3e-9f94-4e84-aefb-398d944ad567%26sc_channel%3Del) untuk mendaftar.
AWS Lambda adalah layanan komputasi yang menjalankan kode tanpa perlu mengelola server. Kode Anda berjalan, menskalakan naik dan turun secara otomatis, dengan pay-per-use harga. Untuk memulai, lihat [Buat fungsi pertama Anda](getting-started.md).
Anda dapat menggunakan Lambda untuk:
+ **Pemrosesan file: Memproses** file secara otomatis saat diunggah ke Amazon Simple Storage Service. Lihat [contoh pemrosesan file](example-apps.md#examples-apps-file) untuk detailnya.
+ **Alur kerja yang berjalan lama:** Gunakan [fungsi Lambda](durable-functions.md) yang tahan lama untuk membangun alur kerja multi-langkah stateful yang dapat berjalan hingga satu tahun. Sempurna untuk pemrosesan pesanan, alur kerja persetujuan, human-in-the-loop proses, dan jalur data kompleks yang perlu mengingat kemajuannya.
+ **Operasi database dan contoh integrasi**: Menanggapi perubahan database dan mengotomatiskan alur kerja data. Lihat [contoh database](example-apps.md#examples-apps-database) untuk detailnya.
+ **Tugas terjadwal dan berkala**: Jalankan operasi otomatis pada jadwal reguler menggunakan EventBridge. Lihat [contoh tugas terjadwal](example-apps.md#examples-apps-scheduled) untuk detailnya.
+ **Pemrosesan aliran: Memproses** aliran data waktu nyata untuk analitik dan pemantauan. Lihat [Kinesis Data](with-kinesis.md) Streams untuk detailnya.
+ **Aplikasi web**: Bangun aplikasi web yang dapat diskalakan yang secara otomatis menyesuaikan dengan permintaan.
+ **Backend seluler**: Buat backend API yang aman untuk aplikasi seluler dan web.
+ **Backend IoT**: Menangani permintaan API web, seluler, IoT, dan pihak ketiga. Lihat [IoT](services-iot.md) untuk detailnya.
Untuk informasi harga, lihat [Harga AWS Lambda](https://aws.amazon.com/lambda/pricing/).
## Bagaimana Lambda bekerja
Saat menggunakan Lambda, Anda hanya bertanggung jawab atas kode Anda. Lambda menjalankan kode Anda pada infrastruktur komputasi ketersediaan tinggi dan mengelola semua sumber daya komputasi, termasuk pemeliharaan server dan sistem operasi, penyediaan kapasitas, penskalaan otomatis, dan pencatatan.
Karena Lambda adalah layanan komputasi tanpa server, berbasis peristiwa, ia menggunakan paradigma pemrograman yang berbeda dari aplikasi web tradisional. Model berikut menggambarkan cara kerja Lambda:
1. Anda menulis dan mengatur kode Anda dalam [fungsi Lambda](concepts-basics.md#gettingstarted-concepts-function), yang merupakan blok bangunan dasar yang Anda gunakan untuk membuat aplikasi Lambda.
1. Anda mengontrol keamanan dan akses melalui [izin Lambda](lambda-permissions.md), menggunakan [peran eksekusi](lambda-intro-execution-role.md) untuk mengelola AWS layanan apa yang dapat berinteraksi dengan fungsi Anda dan kebijakan sumber daya apa yang dapat berinteraksi dengan kode Anda.
1. Sumber dan AWS layanan peristiwa [memicu](concepts-event-driven-architectures.md) fungsi Lambda Anda, meneruskan data peristiwa dalam format JSON, yang diproses fungsi Anda (ini termasuk pemetaan sumber peristiwa).
1. [Lambda menjalankan kode Anda](concepts-how-lambda-runs-code.md) dengan runtime khusus bahasa (seperti Node.js dan Python) di lingkungan eksekusi yang mengemas runtime, lapisan, dan ekstensi Anda.
**Tip**
Untuk mempelajari cara membuat **solusi tanpa server**, lihat Panduan Pengembang Tanpa [Server](https://docs.aws.amazon.com/serverless/latest/devguide/).
## Fitur utama
**Konfigurasikan, kontrol, dan terapkan aplikasi aman:**
+ [Variabel-variabel lingkungan](configuration-envvars.md)memodifikasi perilaku aplikasi tanpa penerapan kode baru.
+ [Versi](configuration-versions.md)uji fitur baru dengan aman sambil mempertahankan lingkungan produksi yang stabil.
+ [Lapisan Lambda](chapter-layers.md)mengoptimalkan penggunaan kembali dan pemeliharaan kode dengan berbagi komponen umum di berbagai fungsi.
+ [Penandatanganan kode](configuration-codesigning.md)menegakkan kepatuhan keamanan dengan memastikan hanya kode yang disetujui mencapai sistem produksi.
**Skala dan lakukan dengan andal:**
+ [Kontrol konkurensi dan penskalaan](lambda-concurrency.md) secara tepat mengelola respons aplikasi dan pemanfaatan sumber daya selama lonjakan lalu lintas.
+ [Lambda SnapStart](snapstart.md)secara signifikan mengurangi waktu mulai dingin. Lambda SnapStart dapat memberikan kinerja startup serendah sub-detik, biasanya tanpa perubahan pada kode fungsi Anda.
+ [Streaming respons](configuration-response-streaming.md)mengoptimalkan kinerja fungsi dengan memberikan muatan besar secara bertahap untuk pemrosesan waktu nyata.
+ [Image kontainer](images-create.md)fungsi paket dengan dependensi kompleks menggunakan alur kerja kontainer.
**Connect dan integrasikan dengan mulus:**
+ [Jaringan VPC](configuration-vpc.md) mengamankan sumber daya sensitif dan layanan internal.
+ [Sistem file](configuration-filesystem.md)integrasi yang berbagi data persisten dan mengelola operasi stateful di seluruh pemanggilan fungsi.
+ [Fungsi URLs](urls-configuration.md)membuat public facing APIs dan endpoint tanpa layanan tambahan.
+ [Ekstensi Lambda](lambda-extensions.md)meningkatkan fungsi dengan alat pemantauan, keamanan, dan operasional.
## Informasi Terkait
+ Untuk informasi tentang cara kerja Lambda, lihat. [Bagaimana Lambda bekerja](concepts-basics.md)
+ Untuk mulai menggunakan Lambda, lihat. [Buat fungsi Lambda pertama Anda](getting-started.md)
+ Untuk daftar contoh aplikasi, lihat[Memulai dengan contoh aplikasi dan pola](example-apps.md).
# Bagaimana Lambda bekerja
Fungsi Lambda adalah blok bangunan dasar yang Anda gunakan untuk membangun aplikasi Lambda. Untuk menulis fungsi, penting untuk memahami konsep inti dan komponen yang membentuk model pemrograman Lambda. Bagian ini akan memandu Anda melalui elemen dasar yang perlu Anda ketahui untuk mulai membangun aplikasi tanpa server dengan Lambda.
+ **[Fungsi Lambda dan penangan fungsi](#gettingstarted-concepts-function)**- Fungsi Lambda adalah blok kecil kode yang berjalan sebagai respons terhadap peristiwa. Fungsi dapat standar (hingga 15 menit) atau [tahan lama](durable-functions.md) (hingga satu tahun). Fungsi adalah blok bangunan dasar yang Anda gunakan untuk membangun aplikasi. Penangan fungsi adalah titik masuk untuk objek peristiwa yang diproses kode fungsi Lambda Anda.
+ **[Lingkungan eksekusi Lambda dan runtime](#gettingstarted-concepts-runtime)**- Lingkungan eksekusi Lambda mengelola sumber daya yang diperlukan untuk menjalankan fungsi Anda. Untuk [fungsi yang tahan lama](durable-functions.md), lingkungan eksekusi mencakup manajemen status otomatis dan kemampuan pos pemeriksaan. Runtime adalah lingkungan khusus bahasa yang menjalankan fungsi Anda.
+ **[Peristiwa dan pemicu](#gettingstarted-concepts-event)**- Lainnya Layanan AWS dapat memanggil fungsi Anda dalam menanggapi peristiwa tertentu. Untuk fungsi yang tahan lama, peristiwa juga dapat memicu dimulainya kembali alur kerja yang dijeda.
+ **[Izin dan peran Lambda](#gettingstarted-concepts-permissions)**- Kontrol siapa yang dapat mengakses fungsi Anda dan fungsi lain yang dapat berinteraksi dengan Layanan AWS Anda. Fungsi tahan lama memerlukan izin tambahan untuk manajemen negara dan eksekusi yang diperpanjang.
**Tip**
*Jika Anda ingin memulai dengan memahami pengembangan tanpa server secara lebih umum, lihat [Memahami perbedaan antara pengembangan tradisional dan tanpa server di Panduan Pengembang AWS Tanpa](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html) Server.*
## Fungsi Lambda dan penangan fungsi
Di Lambda, **fungsi** adalah blok bangunan dasar yang Anda gunakan untuk membuat aplikasi. Fungsi Lambda adalah bagian dari kode yang berjalan sebagai respons terhadap peristiwa, seperti pengguna mengklik tombol di situs web atau file yang diunggah ke bucket Amazon Simple Storage Service (Amazon S3). Dengan fungsi yang tahan lama, kode Anda dapat menjeda eksekusi antar langkah, mempertahankan status secara otomatis, menjadikannya ideal untuk alur kerja yang berjalan lama seperti pemrosesan pesanan atau moderasi konten. Anda dapat menganggap fungsi sebagai semacam program mandiri dengan properti berikut.
**Penangan fungsi** Lambda adalah metode dalam kode fungsi Anda yang memproses peristiwa. Ketika fungsi berjalan sebagai respons terhadap suatu peristiwa, Lambda menjalankan fungsi handler. Data tentang peristiwa yang menyebabkan fungsi berjalan diteruskan langsung ke handler. Sementara kode dalam fungsi Lambda dapat berisi lebih dari satu metode atau fungsi, fungsi Lambda hanya dapat memiliki satu handler.
Untuk membuat fungsi Lambda, Anda menggabungkan kode fungsi dan dependensinya dalam paket penerapan. [Lambda mendukung dua jenis paket penyebaran, [arsip file.zip](configuration-function-zip.md) dan gambar kontainer.](images-create.md)
+ Fungsi memiliki satu pekerjaan atau tujuan tertentu
+ Mereka berjalan hanya ketika diperlukan dalam menanggapi peristiwa tertentu
+ Mereka secara otomatis berhenti berjalan ketika selesai
## Lingkungan eksekusi Lambda dan runtime
Fungsi Lambda berjalan di dalam *[lingkungan eksekusi](lambda-runtime-environment.md)* yang aman dan terisolasi yang dikelola Lambda untuk Anda. Untuk [fungsi yang tahan lama](durable-functions.md), lingkungan eksekusi mencakup komponen tambahan untuk manajemen negara dan koordinasi alur kerja. Lingkungan eksekusi mengelola proses dan sumber daya yang diperlukan untuk menjalankan fungsi Anda. Saat fungsi pertama kali dipanggil, Lambda menciptakan lingkungan eksekusi baru untuk fungsi yang akan dijalankan. Setelah fungsi selesai berjalan, Lambda tidak langsung menghentikan lingkungan eksekusi; jika fungsi dipanggil lagi, Lambda dapat menggunakan kembali lingkungan eksekusi yang ada.
Lingkungan eksekusi Lambda juga berisi *runtime*, lingkungan khusus bahasa yang menyampaikan informasi peristiwa dan respons antara Lambda dan fungsi Anda. Lambda menyediakan sejumlah [runtime terkelola](lambda-runtimes.md#runtimes-supported) untuk bahasa pemrograman paling populer, atau Anda dapat membuatnya sendiri.
Untuk runtime terkelola, Lambda secara otomatis menerapkan pembaruan keamanan dan patch ke fungsi menggunakan runtime.
## Peristiwa dan pemicu
Anda juga dapat menjalankan fungsi Lambda secara langsung dengan menggunakan konsol Lambda [AWS CLI](https://aws.amazon.com/cli/),, atau salah satu Kit Pengembangan [Perangkat Lunak](https://aws.amazon.com/developer/tools/) ().AWS SDKs Ini lebih biasa dalam aplikasi produksi agar fungsi Anda dipanggil oleh orang lain sebagai Layanan AWS tanggapan atas peristiwa tertentu. Misalnya, Anda mungkin ingin fungsi berjalan setiap kali item ditambahkan ke tabel Amazon DynamoDB.
Untuk membuat fungsi Anda merespons peristiwa, Anda menyiapkan **pemicu**. Pemicu menghubungkan fungsi Anda ke sumber peristiwa, dan fungsi Anda dapat memiliki beberapa pemicu. Ketika suatu peristiwa terjadi, Lambda menerima data peristiwa sebagai dokumen JSON dan mengubahnya menjadi objek yang dapat diproses oleh kode Anda. Anda dapat menentukan format JSON berikut untuk acara Anda dan runtime Lambda mengonversi JSON ini menjadi objek sebelum meneruskannya ke handler fungsi Anda.
**Example acara Lambda kustom**
```
{
"Location": "SEA",
"WeatherData":{
"TemperaturesF":{
"MinTempF": 22,
"MaxTempF": 78
},
"PressuresHPa":{
"MinPressureHPa": 1015,
"MaxPressureHPa": 1027
}
}
}
```
Layanan streaming dan antrian seperti Amazon Kinesis atau Amazon SQS menggunakan pemetaan [sumber peristiwa alih-alih](invocation-eventsourcemapping.md) pemicu standar. Pemetaan sumber peristiwa polling sumber untuk data baru, catatan batch bersama-sama, dan kemudian memanggil fungsi Anda dengan peristiwa batch. Untuk informasi selengkapnya, lihat [Bagaimana pemetaan sumber peristiwa berbeda dari pemicu langsung](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference).
Untuk memahami cara kerja pemicu, mulailah dengan menyelesaikan tutorial [Gunakan pemicu Amazon S3](with-s3-example.md), atau untuk gambaran umum tentang penggunaan pemicu dan petunjuk cara membuat pemicu menggunakan konsol Lambda, lihat. [Mengintegrasikan layanan lain](lambda-services.md)
## Izin dan peran Lambda
Untuk Lambda, ada dua jenis [izin](permissions-granting-access.md) utama yang perlu Anda konfigurasikan:
+ Izin yang dibutuhkan fungsi Anda untuk mengakses lainnya Layanan AWS
+ Izin yang pengguna lain dan Layanan AWS butuhkan untuk mengakses fungsi Anda
Bagian berikut menjelaskan kedua jenis izin ini dan mendiskusikan praktik terbaik untuk menerapkan izin hak istimewa paling sedikit.
### Izin untuk fungsi untuk mengakses sumber daya lain AWS
Fungsi Lambda sering perlu mengakses AWS sumber daya lain dan melakukan tindakan pada mereka. Misalnya, fungsi mungkin membaca item dari tabel DynamoDB, menyimpan objek dalam bucket S3, atau menulis ke antrean Amazon SQS. Untuk memberikan fungsi izin yang mereka butuhkan untuk melakukan tindakan ini, Anda menggunakan *[peran eksekusi](lambda-intro-execution-role.md)*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
Setiap fungsi Lambda harus memiliki peran eksekusi, dan satu peran dapat digunakan oleh lebih dari satu fungsi. Ketika fungsi dipanggil, Lambda mengasumsikan peran eksekusi fungsi dan diberikan izin untuk mengambil tindakan yang ditentukan dalam kebijakan peran.
Saat Anda membuat fungsi di konsol Lambda, Lambda secara otomatis membuat peran eksekusi untuk fungsi Anda. Kebijakan peran memberikan izin dasar fungsi Anda untuk menulis output log ke Amazon CloudWatch Logs. Untuk memberikan izin fungsi Anda untuk melakukan tindakan pada AWS sumber daya lain, Anda perlu mengedit peran untuk menambahkan izin tambahan. Cara termudah untuk menambahkan izin adalah dengan menggunakan [kebijakan AWS terkelola](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies). Kebijakan terkelola dibuat dan dikelola oleh AWS dan memberikan izin untuk banyak kasus penggunaan umum. [Misalnya, jika fungsi Anda menjalankan operasi CRUD pada tabel DynamoDB, Anda dapat menambahkan AmazonDynamo DBFull kebijakan Access ke peran Anda.](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html)
### Izin untuk pengguna dan sumber daya lain untuk mengakses fungsi Anda
Untuk memberikan Layanan AWS izin lain untuk mengakses fungsi Lambda Anda, Anda menggunakan kebijakan berbasis sumber *[daya](access-control-resource-based.md)*. Di IAM, kebijakan berbasis sumber daya dilampirkan ke sumber daya (dalam hal ini, fungsi Lambda Anda) dan menentukan siapa yang dapat mengakses sumber daya dan tindakan apa yang diizinkan untuk dilakukan.
Agar fungsi lain Layanan AWS dapat menjalankan fungsi Anda melalui pemicu, kebijakan berbasis sumber daya fungsi Anda harus memberikan izin layanan tersebut untuk menggunakan tindakan tersebut. `lambda:InvokeFunction` Jika Anda membuat pemicu menggunakan konsol, Lambda secara otomatis menambahkan izin ini untuk Anda.
Untuk memberikan izin kepada AWS pengguna lain untuk mengakses fungsi Anda, Anda dapat menentukan ini dalam kebijakan berbasis sumber daya fungsi Anda dengan cara yang persis sama seperti untuk yang lain atau sumber daya. Layanan AWS Anda juga dapat menggunakan *[kebijakan berbasis identitas](access-control-identity-based.md)* yang terkait dengan pengguna.
### Praktik terbaik untuk izin Lambda
Saat Anda menetapkan izin menggunakan kebijakan IAM, [praktik terbaik keamanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) adalah hanya memberikan izin yang diperlukan untuk melakukan tugas. Ini dikenal sebagai prinsip *hak istimewa paling sedikit*. Untuk mulai memberikan izin untuk fungsi Anda, Anda dapat memilih untuk menggunakan kebijakan AWS terkelola. Kebijakan terkelola dapat menjadi cara tercepat dan termudah untuk memberikan izin untuk melakukan tugas, tetapi mereka mungkin juga menyertakan izin lain yang tidak Anda perlukan. Saat Anda beralih dari pengembangan awal melalui pengujian dan produksi, kami sarankan Anda mengurangi izin menjadi hanya yang diperlukan dengan menentukan kebijakan yang dikelola [pelanggan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) Anda sendiri.
Prinsip yang sama berlaku saat memberikan izin untuk mengakses fungsi Anda menggunakan kebijakan berbasis sumber daya. Misalnya, jika Anda ingin memberikan izin kepada Amazon S3 untuk menjalankan fungsi Anda, praktik terbaik adalah membatasi akses ke bucket individual, atau bucket pada khususnya Akun AWS, daripada memberikan izin menyeluruh ke layanan S3.
# Menjalankan kode dengan Lambda
Saat Anda menulis fungsi Lambda, Anda membuat kode yang akan berjalan di lingkungan tanpa server yang unik. Memahami bagaimana Lambda benar-benar menjalankan kode Anda melibatkan dua aspek utama: model pemrograman yang mendefinisikan bagaimana kode Anda berinteraksi dengan Lambda, dan siklus hidup lingkungan eksekusi yang menentukan bagaimana Lambda mengelola lingkungan runtime kode Anda.
## Model pemrograman Lambda
Model pemrograman berfungsi sebagai seperangkat aturan umum tentang cara Lambda bekerja dengan kode Anda, terlepas dari apakah Anda menulis dengan Python, Java, atau bahasa lain yang didukung. Model pemrograman mencakup runtime dan handler Anda.
**Untuk fungsi standar:**
1. Lambda menerima acara.
1. Lambda menggunakan runtime untuk menyiapkan acara dalam format yang dapat digunakan kode Anda.
1. Runtime mengirimkan event yang diformat ke handler Anda.
1. Handler Anda memproses acara menggunakan kode yang telah Anda tulis.
**Untuk Fungsi Tahan Lama:**
1. Lambda menerima acara
1. Runtime mempersiapkan acara dan DurableContext
1. Handler Anda dapat:
+ Langkah-langkah proses dengan pos pemeriksaan otomatis
+ Jeda eksekusi tanpa menghabiskan sumber daya
+ Lanjutkan dari pos pemeriksaan terakhir yang berhasil
+ Pertahankan status di antara langkah-langkah
Penting untuk model ini adalah *handler*, di mana Lambda mengirimkan peristiwa untuk diproses oleh kode Anda. Anggap saja sebagai titik masuk ke kode Anda. Ketika Lambda menerima acara, ia meneruskan acara ini dan beberapa informasi konteks ke handler Anda. Handler kemudian menjalankan kode Anda untuk memproses peristiwa ini - misalnya, mungkin membaca file saat diunggah ke Amazon S3, menganalisis gambar, atau memperbarui database. Setelah kode Anda selesai memproses suatu peristiwa, handler siap untuk memproses yang berikutnya.
## Model eksekusi Lambda
Sementara model pemrograman mendefinisikan bagaimana Lambda berinteraksi dengan kode Anda, lingkungan Eksekusi adalah tempat Lambda benar-benar menjalankan fungsi Anda — ini adalah ruang komputasi yang aman dan terisolasi yang dibuat khusus untuk fungsi Anda.
**Setiap lingkungan mengikuti siklus hidup yang bervariasi antara fungsi standar dan tahan lama:**
**Fungsi Standar (hingga 15 menit):**
1. **Inisialisasi:** Pengaturan lingkungan dan pemuatan kode
1. **Pemanggilan:** Eksekusi tunggal kode fungsi
1. **Shutdown: Pembersihan** lingkungan
**Fungsi Tahan Lama (hingga 1 tahun):**
1. **Inisialisasi:** Lingkungan dan pengaturan status tahan lama
1. **Doa:** Beberapa langkah dengan pos pemeriksaan otomatis
1. **Status Tunggu:** Jeda eksekusi tanpa konsumsi sumber daya
1. **Lanjutkan:** Mulai ulang dari pos pemeriksaan terakhir
1. **Shutdown:** Pembersihan kondisi tahan lama
Lingkungan ini menangani aspek-aspek penting dalam menjalankan fungsi Anda. Ini menyediakan fungsi Anda dengan memori dan `/tmp` direktori untuk penyimpanan sementara. **Untuk Fungsi Tahan Lama, ia juga mengelola:**
+ Persistensi status otomatis di antara langkah-langkah
+ Penyimpanan dan pemulihan pos pemeriksaan
+ Tunggu koordinasi negara
+ Pelacakan kemajuan di seluruh eksekusi yang berjalan lama
# Memahami model pemrograman Lambda
Lambda menawarkan dua model pemrograman: fungsi standar yang berjalan hingga 15 menit, dan Fungsi Tahan Lama yang dapat berjalan hingga satu tahun. Meskipun keduanya berbagi konsep inti, Fungsi Tahan Lama menambahkan kemampuan untuk alur kerja stateful yang berjalan lama.
Lambda menyediakan model pemrograman yang umum untuk semua runtime. Model pemrograman mendefinisikan antarmuka antara kode Anda dan sistem Lambda. Anda memberi tahu Lambda titik masuk ke fungsi Anda dengan mendefinisikan *handler* dalam konfigurasi fungsi. Runtime berlalu dengan objek ke handler yang berisi *acara* invokasi dan *konteks*, seperti nama fungsi dan ID permintaan.
**Untuk Fungsi Tahan Lama, handler juga menerima DurableContext objek yang menyediakan:**
+ Kemampuan Checkpointing melalui step ()
+ Tunggu manajemen negara melalui wait () dan waitForCallback ()
+ Persistensi status otomatis di antara pemanggilan
Setelah handler selesai memproses peristiwa pertama, runtime mengirimkan peristiwa lain. Untuk Fungsi Tahan Lama, handler dapat menjeda eksekusi antar langkah, dan Lambda akan secara otomatis menyimpan dan memulihkan status saat fungsi dilanjutkan. Kelas fungsi tetap di dalam memori, sehingga klien dan variabel yang dinyatakan di luar metode handler dalam *kode inisialisasi* dapat digunakan kembali. Untuk menghemat waktu pemrosesan pada peristiwa berikutnya, buat sumber daya yang dapat digunakan kembali seperti klien AWS SDK selama inisialisasi. Setelah diinisialisasi, setiap instans fungsi Anda dapat memproses ribuan permintaan.
Fungsi Anda juga memiliki akses ke penyimpanan lokal di `/tmp` direktori, cache sementara yang dapat digunakan untuk beberapa pemanggilan. Untuk informasi selengkapnya, lihat [Lingkungan eksekusi](lambda-runtime-environment.md).
Saat [AWS X-Ray pelacakan](services-xray.md) diaktifkan, runtime mencatat subsegmen terpisah untuk inisialisasi dan eksekusi.
Runtime menangkap output logging dari fungsi Anda dan mengirimkannya ke Amazon CloudWatch Logs. Selain mencatat output fungsi Anda, runtime juga mencatat entri saat invokasi fungsi dimulai dan berakhir. Ini termasuk catatan laporan dengan ID permintaan, durasi yang ditagih, durasi inisialisasi, dan perincian lainnya. Jika fungsi Anda menampilkan kesalahan, runtime mengembalikan kesalahan tersebut ke pemanggil.
**catatan**
Logging tunduk pada [kuota CloudWatch Log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html). Data log dapat hilang karena pelambatan atau, dalam beberapa kasus, ketika satu instans fungsi Anda dihentikan.
**Perbedaan utama untuk Fungsi Tahan Lama:**
+ Status secara otomatis bertahan di antara langkah-langkah
+ Fungsi dapat menjeda eksekusi tanpa menghabiskan sumber daya
+ Langkah-langkah secara otomatis dicoba ulang pada kegagalan
+ Kemajuan dilacak melalui pos pemeriksaan
Lambda memperluas fungsi Anda dengan menjalankan instans tambahannya seiring peningkatan permintaan, dan dengan menghentikan instans seiring dengan penurunan permintaan. Model ini mengarah pada variasi dalam arsitektur aplikasi, seperti:
+ Kecuali dinyatakan sebaliknya, permintaan masuk dapat diproses di luar pesanan atau bersamaan.
+ Jangan mengandalkan contoh fungsi Anda yang berumur panjang, alih-alih simpan status aplikasi Anda di tempat lain.
+ Gunakan penyimpanan lokal dan objek tingkat kelas untuk meningkatkan performa, tetapi jaga ukuran paket deployment Anda seminimum mungkin dan jumlah data yang Anda transfer ke lingkungan eksekusi.
Untuk pengenalan langsung model pemrograman dalam bahasa pemrograman pilihan Anda, lihat bab berikut.
+ [Membangun fungsi Lambda dengan Node.js](lambda-nodejs.md)
+ [Membangun fungsi Lambda dengan Python](lambda-python.md)
+ [Membangun fungsi Lambda dengan Ruby](lambda-ruby.md)
+ [Membangun fungsi Lambda dengan Java](lambda-java.md)
+ [Membangun fungsi Lambda dengan Go](lambda-golang.md)
+ [Membangun fungsi Lambda dengan C\$1](lambda-csharp.md)
+ [Membangun fungsi Lambda dengan PowerShell](lambda-powershell.md)
# Memahami siklus hidup lingkungan pelaksanaan Lambda
Lingkungan eksekusi Lambda mendukung fungsi standar (hingga 15 menit) dan Fungsi Tahan Lama (hingga satu tahun). Meskipun keduanya berbagi siklus hidup dasar yang sama, Fungsi Tahan Lama menambahkan kemampuan manajemen status untuk alur kerja yang berjalan lama.
Lambda melakukan invokasi fungsi dalam lingkungan eksekusi, yang menyediakan lingkungan waktu pengoperasian yang aman dan terisolasi. Lingkungan eksekusi mengelola sumber daya yang diperlukan untuk menjalankan fungsi Anda. Lingkungan eksekusi juga menyediakan dukungan siklus hidup untuk waktu pengoperasian fungsi dan [ekstensi eksternal](lambda-extensions.md) terkait fungsi Anda.
**Untuk Fungsi Tahan Lama, lingkungan eksekusi mencakup komponen tambahan untuk:**
+ Nyatakan ketekunan di antara langkah-langkah
+ Manajemen pos pemeriksaan
+ Tunggu koordinasi negara
+ Pelacakan kemajuan
**Lingkungan eksekusi Instans Terkelola Lambda**
Jika Anda menggunakan [Instans Terkelola Lambda](lambda-managed-instances-execution-environment.md), lingkungan eksekusi memiliki perbedaan penting dibandingkan dengan fungsi Lambda (default). Instans Terkelola mendukung pemanggilan bersamaan, menggunakan model siklus hidup yang berbeda, dan berjalan di infrastruktur milik pelanggan. Untuk informasi rinci tentang lingkungan eksekusi Instans Terkelola, lihat[Memahami lingkungan eksekusi Instans Terkelola Lambda](lambda-managed-instances-execution-environment.md).
Waktu pengoperasian fungsi tersebut berkomunikasi dengan Lambda menggunakan [API Waktu Pengoperasian](runtimes-api.md). Ekstensi berkomunikasi dengan Lambda menggunakan [API Ekstensi](runtimes-extensions-api.md). Ekstensi juga dapat menerima pesan log dan telemetri lain dari fungsi dengan menggunakan API [Telemetri](telemetry-api.md).
![\[Diagram arsitektur untuk lingkungan eksekusi.\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
Saat membuat fungsi Lambda, Anda menentukan informasi konfigurasi, seperti jumlah memori yang tersedia dan waktu eksekusi maksimal yang diizinkan untuk fungsi Anda. Lambda menggunakan informasi ini untuk menyiapkan lingkungan eksekusi.
Waktu pengoperasian fungsi dan setiap ekstensi eksternal adalah proses yang berjalan di dalam lingkungan eksekusi. Izin, sumber daya, kredensial, dan variabel lingkungan dibagikan di antara fungsi dan ekstensi.
**Topics**
+ [
## Siklus hidup lingkungan eksekusi Lambda
](#runtimes-lifecycle)
+ [
## Mulai dingin dan latensi
](#cold-start-latency)
+ [
## Mengurangi dingin dimulai dengan Provisioned Concurrency
](#cold-starts-pc)
+ [
## Mengoptimalkan inisialisasi statis
](#static-initialization)
## Siklus hidup lingkungan eksekusi Lambda
![\[Fase siklus hidup Lambda: Init, Invoke, Shutdown\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/Overview-Successful-Invokes.png)
Setiap fase dimulai dengan kejadian yang dikirimkan Lambda ke waktu pengoperasian dan ke semua ekstensi terdaftar. Waktu pengoperasian dan setiap ekstensi menunjukkan penyelesaian dengan mengirimkan permintaan API `Next`. Lambda membekukan lingkungan eksekusi saat waktu pengoperasian dan setiap ekstensi telah selesai dan tidak ada kejadian yang tertunda.
**Fase siklus hidup untuk Fungsi Tahan Lama meliputi:**
+ **Init: Inisialisasi** standar ditambah pengaturan status tahan lama
+ **Invoke:** Dapat menyertakan eksekusi beberapa langkah dengan pos pemeriksaan otomatis
+ **Tunggu:** Fungsi dapat menjeda eksekusi tanpa menghabiskan sumber daya
+ **Lanjutkan:** Fungsi dimulai ulang dari pos pemeriksaan terakhir
+ **Shutdown:** Pembersihan status dan sumber daya yang tahan lama
**Topics**
+ [
### Fase inisialisasi
](#runtimes-lifecycle-ib)
+ [
### Kegagalan selama fase Init
](#runtimes-lifecycle-init-errors)
+ [
### Fase pemulihan (hanya Lambda SnapStart )
](#runtimes-lifecycle-restore)
+ [
### Fase invokasi
](#runtimes-lifecycle-invoke)
+ [
### Kegagalan selama fase pemanggilan
](#runtimes-lifecycle-invoke-with-errors)
+ [
### Fase pematian
](#runtimes-lifecycle-shutdown)
### Fase inisialisasi
Di fase `Init`, Lambda melakukan tiga tugas:
+ Memulai semua ekstensi (`Extension init`)
+ Melakukan bootstrap waktu pengoperasian (`Runtime init`)
+ Menjalankan kode statis fungsi (`Function init`)
+ Jalankan [kait runtime](snapstart-runtime-hooks.md) sebelum pos pemeriksaan (hanya Lambda) SnapStart
Fase `Init` berakhir ketika waktu pengoperasian dan semua ekstensi menandakan bahwa ekstensi siap dengan mengirim permintaan API `Next`. Fase `Init` dibatasi 10 detik. Jika ketiga tugas tidak selesai dalam 10 detik, Lambda mencoba kembali `Init` fase pada saat pemanggilan fungsi pertama dengan batas waktu fungsi yang dikonfigurasi.
Ketika [Lambda SnapStart](snapstart.md) diaktifkan, `Init` fase terjadi ketika Anda menerbitkan versi fungsi. Lambda menyimpan snapshot memori dan status disk dari lingkungan eksekusi yang diinisialisasi, mempertahankan snapshot terenkripsi, dan menyimpannya dalam cache untuk akses latensi rendah. Jika Anda memiliki [hook runtime](snapstart-runtime-hooks.md) sebelum-checkpoint, maka kode berjalan di akhir fase. `Init`
**catatan**
Batas waktu 10 detik tidak berlaku untuk fungsi yang menggunakan konkurensi yang disediakan,, SnapStart atau Instans Terkelola Lambda. Untuk konkurensi yang disediakan SnapStart, dan fungsi Instans Terkelola, kode inisialisasi Anda dapat berjalan hingga 15 menit. Batas waktu adalah 130 detik atau batas waktu fungsi yang dikonfigurasi (maksimum 900 detik), mana yang lebih tinggi.
Saat Anda menggunakan [konkurensi yang disediakan,](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) Lambda menginisialisasi lingkungan eksekusi saat Anda mengonfigurasi pengaturan PC untuk suatu fungsi. Lambda juga memastikan bahwa lingkungan eksekusi yang diinisialisasi selalu tersedia sebelum pemanggilan. Anda mungkin melihat kesenjangan antara fase pemanggilan dan inisialisasi fungsi Anda. Bergantung pada runtime dan konfigurasi memori fungsi Anda, Anda juga dapat melihat latensi variabel pada pemanggilan pertama pada lingkungan eksekusi yang diinisialisasi.
Untuk fungsi yang menggunakan konkurensi sesuai permintaan, Lambda terkadang dapat menginisialisasi lingkungan eksekusi sebelum permintaan pemanggilan. Ketika ini terjadi, Anda juga dapat mengamati kesenjangan waktu antara fase inisialisasi dan pemanggilan fungsi Anda. Kami menyarankan Anda untuk tidak mengambil ketergantungan pada perilaku ini.
### Kegagalan selama fase Init
Jika fungsi macet atau habis waktu selama `Init` fase, Lambda memancarkan informasi kesalahan di log. `INIT_REPORT`
**Example — Log INIT\$1REPORT untuk batas waktu**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
```
**Example — Log INIT\$1REPORT untuk kegagalan ekstensi**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash
```
Jika `Init` fase berhasil, Lambda tidak memancarkan `INIT_REPORT` log kecuali [SnapStart](snapstart.md)atau konkurensi yang [disediakan diaktifkan](provisioned-concurrency.md). SnapStart dan fungsi konkurensi yang disediakan selalu memancarkan. `INIT_REPORT` Untuk informasi selengkapnya, lihat [Pemantauan untuk Lambda SnapStart](snapstart-monitoring.md).
### Fase pemulihan (hanya Lambda SnapStart )
Saat Anda pertama kali memanggil [SnapStart](snapstart.md)fungsi dan saat fungsi ditingkatkan, Lambda melanjutkan lingkungan eksekusi baru dari snapshot yang bertahan alih-alih menginisialisasi fungsi dari awal. Jika Anda memiliki [hook runtime](snapstart-runtime-hooks.md) after-restore, kode berjalan di akhir fase. `Restore` Anda dikenakan biaya untuk durasi kait runtime setelah pemulihan. Runtime harus dimuat dan kait runtime setelah pemulihan harus selesai dalam batas waktu tunggu (10 detik). Jika tidak, Anda akan mendapatkan SnapStartTimeoutException. Ketika `Restore` fase selesai, Lambda memanggil fungsi handler (the). [Fase invokasi](#runtimes-lifecycle-invoke)
#### Kegagalan selama fase Restore
Jika `Restore` fase gagal, Lambda memancarkan informasi kesalahan di log. `RESTORE_REPORT`
**Example — RESTORE\$1REPORT log untuk batas waktu**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
```
**Example — RESTORE\$1REPORT log untuk kegagalan hook runtime**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError
```
Untuk informasi lebih lanjut tentang `RESTORE_REPORT` log, lihat[Pemantauan untuk Lambda SnapStart](snapstart-monitoring.md).
### Fase invokasi
Saat fungsi Lambda diinvokasi untuk menanggapi permintaan API `Next`, Lambda mengirim kejadian `Invoke` ke waktu pengoperasian dan untuk setiap perpanjangan.
Pengaturan waktu habis fungsi membatasi durasi seluruh fase `Invoke`. Misalnya, jika Anda mengatur waktu fungsi habis sebagai 360 detik, fungsi dan semua ekstensi harus selesai dalam 360 detik. Perhatikan bahwa tidak ada fase pasca-invokasi yang independen. Durasi adalah jumlah semua waktu invokasi (waktu pengoperasian \$1 ekstensi) dan tidak dihitung hingga fungsi dan semua ekstensi selesai dijalankan.
Fase invokasi berakhir ketika waktu pengoperasian dan semua ekstensi menandakan bahwa ekstensi selesai dengan mengirim permintaan API `Next`.
### Kegagalan selama fase pemanggilan
Jika fungsi Lambda mengalami crash atau waktu habis selama fase `Invoke`, Lambda mengatur ulang lingkungan eksekusi. Diagram berikut menggambarkan perilaku lingkungan eksekusi Lambda ketika ada kegagalan pemanggilan:
![\[Contoh lingkungan eksekusi: Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
Pada diagram sebelumnya:
+ Fase pertama adalah fase **INIT**, yang berjalan tanpa kesalahan.
+ Fase kedua adalah fase **INVOKE**, yang berjalan tanpa kesalahan.
+ Pada titik tertentu, misalkan fungsi Anda mengalami kegagalan pemanggilan (penyebab umum termasuk batas waktu fungsi, kesalahan runtime, kelelahan memori, masalah konektivitas VPC, kesalahan izin, batas konkurensi, dan berbagai masalah konfigurasi). Untuk daftar lengkap kemungkinan kegagalan pemanggilan, lihat. [Menyelesaikan masalah invokasi di Lambda](troubleshooting-invocation.md) Fase ketiga, berlabel **INVOKE WITH ERROR**, menggambarkan skenario ini. Ketika ini terjadi, layanan Lambda melakukan reset. Reset berperilaku seperti kejadian `Shutdown`. Pertama, Lambda mematikan runtime, lalu mengirimkan `Shutdown` acara ke setiap ekstensi eksternal terdaftar. Kejadian ini mencakup alasan untuk pematian. Jika lingkungan ini digunakan untuk pemanggilan baru, Lambda menginisialisasi ulang ekstensi dan runtime bersama dengan pemanggilan berikutnya.
Perhatikan bahwa reset Lambda tidak menghapus konten `/tmp` direktori sebelum fase init berikutnya. Perilaku ini konsisten dengan fase shutdown reguler.
**catatan**
AWS saat ini menerapkan perubahan pada layanan Lambda. Karena perubahan ini, Anda mungkin melihat perbedaan kecil antara struktur dan konten pesan log sistem dan segmen pelacakan yang dipancarkan oleh fungsi Lambda yang berbeda di Anda. Akun AWS
Jika konfigurasi log sistem fungsi Anda disetel ke teks biasa, perubahan ini memengaruhi pesan log yang ditangkap di CloudWatch Log saat fungsi Anda mengalami kegagalan pemanggilan. Contoh berikut menunjukkan output log dalam format lama dan baru.
Perubahan ini akan diterapkan selama beberapa minggu mendatang, dan semua fungsi di semua Wilayah AWS kecuali China GovCloud dan wilayah akan bertransisi untuk menggunakan pesan log format baru dan segmen pelacakan.
**Example CloudWatch Keluaran log log (runtime atau ekstensi crash) - gaya lama**
```
START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
```
**Example CloudWatch Keluaran log log (batas waktu fungsi) - gaya lama**
```
START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3117 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms
```
Format baru untuk CloudWatch log mencakup `status` bidang tambahan di `REPORT` baris. Dalam kasus runtime atau ekstensi crash, `REPORT` baris juga menyertakan bidang`ErrorType`.
**Example CloudWatch Keluaran log log (runtime atau ekstensi crash) - gaya baru**
```
START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 214 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
```
**Example CloudWatch Keluaran log log (batas waktu fungsi) - gaya baru**
```
START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout
```
+ Fase keempat mewakili fase **INVOKE** segera setelah kegagalan pemanggilan. **Di sini, Lambda menginisialisasi lingkungan lagi dengan menjalankan kembali fase INIT.** Ini disebut *init yang ditekan*. **Ketika input yang ditekan terjadi, Lambda tidak secara eksplisit melaporkan fase INIT tambahan di Log.** CloudWatch Sebagai gantinya, Anda mungkin memperhatikan bahwa durasi di baris LAPORAN menyertakan durasi **INIT** tambahan\$1durasi **INVOKE**. Misalnya, Anda melihat log berikut di CloudWatch:
```
2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST
2022-12-20T01:00:02.500-08:00 END RequestId: XXX
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB
```
Dalam contoh ini, perbedaan antara stempel waktu REPORT dan START adalah 2,5 detik. Ini tidak cocok dengan durasi yang dilaporkan 3022,91 milldetik, karena tidak memperhitungkan **INIT ekstra (init** yang ditekan) yang dilakukan Lambda. Dalam contoh ini, Anda dapat menyimpulkan bahwa fase **INVOKE** yang sebenarnya membutuhkan waktu 2,5 detik.
Untuk wawasan lebih lanjut tentang perilaku ini, Anda dapat menggunakan[Mengakses data telemetri real-time untuk ekstensi menggunakan API Telemetri](telemetry-api.md). API Telemetri memancarkan`INIT_START`,`INIT_RUNTIME_DONE`, dan `INIT_REPORT` peristiwa dengan input yang ditekan `phase=invoke` setiap kali terjadi di antara fase pemanggilan.
+ Fase kelima mewakili fase **SHUTDOWN**, yang berjalan tanpa kesalahan.
### Fase pematian
Ketika Lambda akan mematikan runtime, ia mengirimkan `Shutdown` acara ke setiap ekstensi eksternal terdaftar. Ekstensi dapat menggunakan waktu ini untuk tugas pembersihan akhir. Kejadian `Shutdown` adalah respons terhadap permintaan API `Next`.
**Batas durasi**: Durasi maksimum fase `Shutdown` bergantung pada konfigurasi ekstensi terdaftar:
+ 0 ms - Fungsi tanpa ekstensi terdaftar
+ 500 md – Fungsi dengan ekstensi internal terdaftar.
+ 2.000 md – Fungsi dengan satu atau beberapa ekstensi eksternal terdaftar.
Jika waktu pengoperasian atau ekstensi tidak merespons kejadian `Shutdown` dalam batasan, Lambda mengakhiri proses menggunakan sinyal `SIGKILL`.
Setelah fungsi dan semua ekstensi selesai, Lambda mempertahankan lingkungan eksekusi selama beberapa waktu untuk mengantisipasi invokasi fungsi lain. Namun, Lambda menghentikan lingkungan eksekusi setiap beberapa jam untuk memungkinkan pembaruan dan pemeliharaan runtime — bahkan untuk fungsi yang dipanggil terus menerus. Anda tidak boleh berasumsi bahwa lingkungan eksekusi akan bertahan tanpa batas waktu. Untuk informasi selengkapnya, lihat [Menerapkan kewarganegaraan dalam fungsi](concepts-application-design.md#statelessness-functions).
Saat fungsi dipanggil lagi, Lambda mencairkan lingkungan untuk digunakan kembali. Menggunakan kembali lingkungan eksekusi memiliki implikasi berikut:
+ Objek yang dinyatakan di luar metode penangan fungsi tetap diinisialisasi, memberikan pengoptimalan tambahan ketika fungsi diinvokasi lagi. Misalnya, jika fungsi Lambda Anda menetapkan koneksi database, alih-alih menetapkan kembali koneksi, koneksi asli digunakan dalam invokasi berikutnya. Kami menyarankan Anda menambahkan logika dalam kode untuk memeriksa apakah ada koneksi sebelum membuat yang baru.
+ Setiap lingkungan eksekusi menyediakan antara 512 MB dan 10.240 MB, dalam peningkatan 1-MB, ruang disk di direktori. `/tmp` Isi direktori tetap ada ketika lingkungan eksekusi dibekukan, menyediakan cache sementara yang dapat digunakan untuk beberapa invokasi. Anda dapat menambahkan kode tambahan untuk memeriksa apakah cache memiliki data yang Anda simpan. Untuk informasi lebih lanjut tentang batas ukuran deployment, lihat [Kuota LambdaKuota Lambda](gettingstarted-limits.md).
+ Proses latar belakang atau panggilan balik yang diinisialisasi fungsi Lambda Anda dan tidak selesai ketika fungsi berakhir akan dilanjutkan jika Lambda menggunakan kembali lingkungan eksekusi. Pastikan setiap proses latar belakang atau panggilan balik dalam kode Anda selesai sebelum kode tersebut ditutup.
## Mulai dingin dan latensi
Ketika Lambda menerima permintaan untuk menjalankan fungsi melalui API Lambda, layanan terlebih dahulu menyiapkan lingkungan eksekusi. Selama fase inisialisasi ini, layanan mengunduh kode Anda, memulai lingkungan, dan menjalankan kode inisialisasi apa pun di luar penangan utama. Akhirnya, Lambda menjalankan kode handler.
![\[kinerja mengoptimalkan angka 1\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/perf-optimize-figure-1.png)
Dalam diagram ini, dua langkah pertama mengunduh kode dan mengatur lingkungan sering disebut sebagai “awal yang dingin”. Anda [dikenakan biaya untuk kali ini](https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/), dan itu menambah latensi ke durasi pemanggilan Anda secara keseluruhan.
Setelah pemanggilan selesai, lingkungan eksekusi dibekukan. Untuk meningkatkan manajemen dan kinerja sumber daya, Lambda mempertahankan lingkungan eksekusi untuk jangka waktu tertentu. Selama waktu ini, jika permintaan lain tiba untuk fungsi yang sama, Lambda dapat menggunakan kembali lingkungan. Permintaan kedua ini biasanya selesai lebih cepat, karena lingkungan eksekusi sudah sepenuhnya diatur. Ini disebut “awal yang hangat”.
Permulaan dingin biasanya terjadi di bawah 1% dari doa. Durasi awal dingin bervariasi dari di bawah 100 ms hingga lebih dari 1 detik. Secara umum, start dingin biasanya lebih umum dalam fungsi pengembangan dan pengujian daripada beban kerja produksi. Ini karena fungsi pengembangan dan pengujian biasanya lebih jarang dipanggil.
## Mengurangi dingin dimulai dengan Provisioned Concurrency
Jika Anda membutuhkan waktu mulai fungsi yang dapat diprediksi untuk beban kerja Anda, [konkurensi yang disediakan](provisioned-concurrency.md) adalah solusi yang disarankan untuk memastikan latensi serendah mungkin. Fitur ini melakukan pra-inisialisasi lingkungan eksekusi, mengurangi start dingin.
Misalnya, fungsi dengan konkurensi 6 yang disediakan memiliki 6 lingkungan eksekusi yang telah dipanaskan sebelumnya.
![\[kinerja mengoptimalkan angka 4\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/perf-optimize-figure-4.png)
## Mengoptimalkan inisialisasi statis
Inisialisasi statis terjadi sebelum kode handler mulai berjalan dalam suatu fungsi. Ini adalah kode inisialisasi yang Anda berikan, yang berada di luar penangan utama. Kode ini sering digunakan untuk mengimpor pustaka dan dependensi, mengatur konfigurasi, dan menginisialisasi koneksi ke layanan lain.
Contoh Python berikut menunjukkan mengimpor, dan mengonfigurasi modul, dan membuat klien Amazon S3 selama fase inisialisasi, sebelum fungsi berjalan selama pemanggilan. `lambda_handler`
```
import os
import json
import cv2
import logging
import boto3
s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
# Handler logic...
```
Kontributor latensi terbesar sebelum eksekusi fungsi berasal dari kode inisialisasi. Kode ini berjalan ketika lingkungan eksekusi baru dibuat untuk pertama kalinya. Kode inisialisasi tidak dijalankan lagi jika pemanggilan menggunakan lingkungan eksekusi yang hangat. Faktor-faktor yang mempengaruhi latensi kode inisialisasi meliputi:
+ Ukuran paket fungsi, dalam hal pustaka dan dependensi yang diimpor, dan lapisan Lambda.
+ Jumlah kode dan inisialisasi bekerja.
+ Kinerja perpustakaan dan layanan lainnya dalam menyiapkan koneksi dan sumber daya lainnya.
Ada sejumlah langkah yang dapat diambil pengembang untuk mengoptimalkan latensi inisialisasi statis. Jika suatu fungsi memiliki banyak objek dan koneksi, Anda mungkin dapat merancang ulang satu fungsi menjadi beberapa fungsi khusus. Ini secara individual lebih kecil dan masing-masing memiliki kode inisialisasi yang lebih sedikit.
Penting bahwa fungsi hanya mengimpor pustaka dan dependensi yang mereka butuhkan. Misalnya, jika Anda hanya menggunakan Amazon DynamoDB di AWS SDK, Anda dapat meminta layanan individual alih-alih seluruh SDK. Bandingkan tiga contoh berikut:
```
// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')
// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')
// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)
```
Inisialisasi statis juga sering merupakan tempat terbaik untuk membuka koneksi database untuk memungkinkan fungsi menggunakan kembali koneksi melalui beberapa pemanggilan ke lingkungan eksekusi yang sama. Namun, Anda mungkin memiliki sejumlah besar objek yang hanya digunakan di jalur eksekusi tertentu dalam fungsi Anda. Dalam hal ini, Anda dapat dengan malas memuat variabel dalam lingkup global untuk mengurangi durasi inisialisasi statis.
Hindari variabel global untuk informasi spesifik konteks. Jika fungsi Anda memiliki variabel global yang digunakan hanya untuk masa pakai satu pemanggilan dan disetel ulang untuk pemanggilan berikutnya, gunakan cakupan variabel yang bersifat lokal ke handler. Ini tidak hanya mencegah kebocoran variabel global di seluruh pemanggilan, tetapi juga meningkatkan kinerja inisialisasi statis.
# Membuat arsitektur berbasis acara dengan Lambda
Peristiwa adalah apa pun yang memicu fungsi Lambda untuk dijalankan. Peristiwa dapat memicu fungsi Lambda dengan dua cara: melalui pemanggilan langsung (push) dan pemetaan sumber peristiwa (tarik).
Banyak AWS layanan dapat langsung menjalankan fungsi Lambda Anda. Layanan ini *mendorong* acara ke fungsi Lambda Anda. Peristiwa yang memicu fungsi dapat berupa apa saja, mulai dari permintaan HTTP melalui API Gateway, jadwal yang dikelola oleh EventBridge aturan, AWS IoT peristiwa, atau peristiwa Amazon S3. Dengan pemetaan sumber peristiwa, Lambda secara aktif mengambil (*atau* menarik) peristiwa dari antrian atau aliran. Anda mengonfigurasi Lambda untuk memeriksa peristiwa dari layanan yang didukung, dan Lambda menangani polling dan pemanggilan fungsi Anda.
Ketika diteruskan ke fungsi Anda, peristiwa disusun dalam format JSON. Struktur JSON bervariasi tergantung pada layanan yang menghasilkannya dan jenis acara. Sementara pemanggilan fungsi Lambda standar dapat bertahan hingga 15 menit (atau hingga satu tahun dengan fungsi yang [tahan lama)](durable-functions.md), Lambda paling cocok untuk pemanggilan singkat yang berlangsung satu detik atau kurang. Hal ini terutama berlaku untuk arsitektur berbasis peristiwa, di mana setiap fungsi Lambda diperlakukan sebagai layanan mikro yang bertanggung jawab untuk melakukan serangkaian instruksi spesifik yang sempit.
**catatan**
Arsitektur berbasis peristiwa berkomunikasi di berbagai sistem menggunakan jaringan, yang memperkenalkan latensi variabel. Untuk beban kerja yang membutuhkan latensi sangat rendah, seperti sistem perdagangan real-time, desain ini mungkin bukan pilihan terbaik. Namun, untuk beban kerja yang sangat skalabel dan tersedia, atau yang memiliki pola lalu lintas yang tidak dapat diprediksi, arsitektur berbasis peristiwa dapat memberikan cara yang efektif untuk memenuhi tuntutan ini.
**Topics**
+ [
## Manfaat arsitektur berbasis peristiwa
](#event-driven-benefits)
+ [
## Pertukaran arsitektur yang digerakkan oleh peristiwa
](#event-driven-tradeoffs)
+ [
## Anti-pola dalam aplikasi berbasis peristiwa berbasis Lambda
](#event-driven-anti-patterns)
## Manfaat arsitektur berbasis peristiwa
Lambda mendukung dua metode pemanggilan dalam arsitektur berbasis peristiwa:
1. Pemanggilan langsung (metode push): AWS layanan memicu fungsi Lambda secara langsung. Contoh:
+ Amazon S3 memicu fungsi saat file diunggah
+ API Gateway memicu fungsi saat menerima permintaan HTTP
1. Pemetaan sumber peristiwa (metode tarik): Lambda mengambil peristiwa dan memanggil fungsi. Contoh:
+ Lambda mengambil pesan dari antrian Amazon SQS dan memanggil fungsi
+ Lambda membaca catatan dari aliran DynamoDB dan memanggil fungsi
Kedua metode berkontribusi pada manfaat arsitektur berbasis peristiwa, seperti yang dijelaskan di bawah ini.
### Mengganti polling dan webhook dengan acara
Banyak arsitektur tradisional menggunakan polling dan mekanisme webhook untuk mengkomunikasikan keadaan antara komponen yang berbeda. Polling bisa sangat tidak efisien untuk mengambil pembaruan karena ada jeda antara data baru yang tersedia dan sinkronisasi dengan layanan hilir. Webhook tidak selalu didukung oleh layanan mikro lain yang ingin Anda integrasikan. Mereka mungkin juga memerlukan otorisasi kustom dan konfigurasi otentikasi. Dalam kedua kasus, metode integrasi ini menantang untuk skala sesuai permintaan tanpa pekerjaan tambahan oleh tim pengembangan.
![\[arsitektur berbasis peristiwa gambar 7\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-7.png)
Kedua mekanisme ini dapat digantikan oleh peristiwa, yang dapat disaring, diarahkan, dan didorong ke hilir untuk mengkonsumsi layanan mikro. Pendekatan ini dapat menghasilkan konsumsi bandwidth yang lebih sedikit, pemanfaatan CPU, dan biaya yang berpotensi lebih rendah. Arsitektur ini juga dapat mengurangi kompleksitas, karena setiap unit fungsional lebih kecil dan seringkali ada lebih sedikit kode.
![\[arsitektur berbasis acara gambar 8\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-8.png)
Arsitektur berbasis peristiwa juga dapat mempermudah desain near-real-time sistem, membantu organisasi menjauh dari pemrosesan berbasis batch. Peristiwa dihasilkan pada saat status dalam aplikasi berubah, sehingga kode kustom layanan mikro harus dirancang untuk menangani pemrosesan satu peristiwa. Karena penskalaan ditangani oleh layanan Lambda, arsitektur ini dapat menangani peningkatan lalu lintas yang signifikan tanpa mengubah kode kustom. Saat peristiwa meningkat, begitu juga lapisan komputasi yang memproses peristiwa.
### Mengurangi kompleksitas
Microservices memungkinkan pengembang dan arsitek untuk menyederhanakan alur kerja yang kompleks. Misalnya, monolit e-niaga dapat dipecah menjadi penerimaan pesanan dan proses pembayaran dengan inventaris, pemenuhan, dan layanan akuntansi yang terpisah. Apa yang mungkin rumit untuk dikelola dan diatur dalam monolit menjadi serangkaian layanan terpisah yang berkomunikasi secara asinkron dengan peristiwa.
![\[arsitektur berbasis acara gambar 9\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-9.png)
Pendekatan ini juga memungkinkan untuk merakit layanan yang memproses data pada tingkat yang berbeda. Dalam hal ini, layanan mikro penerimaan pesanan dapat menyimpan volume tinggi pesanan masuk dengan buffering pesan dalam antrian Amazon SQS.
Layanan pemrosesan pembayaran, yang biasanya lebih lambat karena kompleksitas penanganan pembayaran, dapat mengambil aliran pesan yang stabil dari antrian Amazon SQS. Ini dapat mengatur coba ulang yang kompleks dan logika penanganan kesalahan menggunakan AWS Step Functions, dan mengoordinasikan alur kerja pembayaran aktif untuk ratusan ribu pesanan.
**Pendekatan alternatif:** [Untuk orkestrasi menggunakan bahasa pemrograman standar, Anda dapat menggunakan fungsi tahan lama Lambda.](durable-functions.md) Fungsi tahan lama memungkinkan Anda menulis penerimaan pesanan, pemrosesan pembayaran, dan logika notifikasi dalam kode dengan pos pemeriksaan otomatis dan coba lagi. Pendekatan ini bekerja dengan baik ketika alur kerja terutama melibatkan fungsi Lambda dan Anda lebih suka menyimpan logika orkestrasi dalam kode.
### Meningkatkan skalabilitas dan ekstensibilitas
Layanan mikro menghasilkan peristiwa yang biasanya dipublikasikan ke layanan perpesanan seperti Amazon SNS dan Amazon SQS. Ini berperilaku seperti penyangga elastis antara layanan mikro dan membantu menangani penskalaan saat lalu lintas meningkat. Layanan seperti Amazon kemudian EventBridge dapat memfilter dan merutekan pesan tergantung pada konten acara, sebagaimana didefinisikan dalam aturan. Akibatnya, aplikasi berbasis peristiwa dapat lebih terukur dan menawarkan redundansi yang lebih besar daripada aplikasi monolitik.
Sistem ini juga sangat dapat diperluas, memungkinkan tim lain untuk memperluas fitur dan menambahkan fungsionalitas tanpa memengaruhi pemrosesan pesanan dan layanan mikro pemrosesan pembayaran. Dengan menerbitkan acara menggunakan EventBridge, aplikasi ini terintegrasi dengan sistem yang ada, seperti layanan mikro inventaris, tetapi juga memungkinkan aplikasi masa depan untuk diintegrasikan sebagai konsumen acara. Produsen acara tidak memiliki pengetahuan tentang konsumen acara, yang dapat membantu menyederhanakan logika layanan mikro.
## Pertukaran arsitektur yang digerakkan oleh peristiwa
### Latensi variabel
Tidak seperti aplikasi monolitik, yang mungkin memproses segala sesuatu dalam ruang memori yang sama pada satu perangkat, aplikasi berbasis peristiwa berkomunikasi di seluruh jaringan. Desain ini memperkenalkan latensi variabel. Meskipun dimungkinkan untuk merekayasa aplikasi untuk meminimalkan latensi, aplikasi monolitik hampir selalu dapat dioptimalkan untuk latensi yang lebih rendah dengan mengorbankan skalabilitas dan ketersediaan.
Beban kerja yang membutuhkan kinerja latensi rendah yang konsisten, seperti aplikasi perdagangan frekuensi tinggi di bank atau otomatisasi robotika sub-milidetik di gudang, bukanlah kandidat yang baik untuk arsitektur berbasis peristiwa.
### Konsistensi akhirnya
Suatu peristiwa mewakili perubahan keadaan, dan dengan banyak peristiwa yang mengalir melalui layanan yang berbeda dalam arsitektur pada titik waktu tertentu, beban kerja seperti itu seringkali [pada akhirnya konsisten](https://en.wikipedia.org/wiki/Eventual_consistency). Ini membuatnya lebih kompleks untuk memproses transaksi, menangani duplikat, atau menentukan keadaan keseluruhan sistem yang tepat.
Beberapa beban kerja berisi kombinasi persyaratan yang pada akhirnya konsisten (misalnya, total pesanan dalam jam berjalan) atau sangat konsisten (misalnya, inventaris saat ini). Untuk beban kerja yang membutuhkan konsistensi data yang kuat, ada pola arsitektur untuk mendukung ini. Contoh:
+ DynamoDB dapat [memberikan pembacaan yang sangat konsisten](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html), terkadang pada latensi yang lebih tinggi, mengkonsumsi throughput yang lebih besar daripada mode default. DynamoDB [juga dapat mendukung](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html) transaksi untuk membantu menjaga konsistensi data.
+ Anda dapat menggunakan Amazon RDS untuk fitur yang membutuhkan [properti ACID](https://en.wikipedia.org/wiki/ACID), meskipun database relasional umumnya kurang skalabel daripada database NoSQL seperti DynamoDB. [Amazon RDS Proxy](https://aws.amazon.com/rds/proxy/) dapat membantu mengelola pengumpulan dan penskalaan koneksi dari konsumen sementara seperti fungsi Lambda.
Arsitektur berbasis peristiwa biasanya dirancang di sekitar peristiwa individu, bukan kumpulan data yang besar. Umumnya, alur kerja dirancang untuk mengelola langkah-langkah peristiwa individu atau alur eksekusi alih-alih beroperasi pada beberapa peristiwa secara bersamaan. Dalam serverless, pemrosesan peristiwa real-time lebih disukai daripada pemrosesan batch: batch harus diganti dengan banyak pembaruan tambahan yang lebih kecil. Meskipun ini dapat membuat beban kerja lebih tersedia dan terukur, itu juga membuatnya lebih menantang bagi acara untuk memiliki kesadaran akan peristiwa lain.
### Mengembalikan nilai ke penelepon
Dalam banyak kasus, aplikasi berbasis peristiwa bersifat asinkron. Ini berarti bahwa layanan penelepon tidak menunggu permintaan dari layanan lain sebelum melanjutkan pekerjaan lain. Ini adalah karakteristik mendasar dari arsitektur berbasis peristiwa yang memungkinkan skalabilitas dan fleksibilitas. Ini berarti bahwa meneruskan nilai pengembalian atau hasil alur kerja lebih kompleks daripada alur eksekusi sinkron.
Sebagian besar pemanggilan Lambda dalam sistem produksi bersifat [asinkron](invocation-async.md), menanggapi peristiwa dari layanan seperti Amazon S3 atau Amazon SQS. Dalam kasus ini, keberhasilan atau kegagalan memproses suatu peristiwa seringkali lebih penting daripada mengembalikan nilai. Fitur seperti [antrian surat mati](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) (DLQs) di Lambda disediakan untuk memastikan Anda dapat mengidentifikasi dan mencoba lagi peristiwa yang gagal, tanpa perlu memberi tahu penelepon.
### Debugging di seluruh layanan dan fungsi
Debugging sistem event-driven juga berbeda dibandingkan dengan aplikasi monolitik. Dengan berbagai sistem dan layanan yang melewati peristiwa, tidak mungkin untuk merekam dan mereproduksi status yang tepat dari beberapa layanan ketika kesalahan terjadi. Karena setiap layanan dan fungsi pemanggilan memiliki file log terpisah, akan lebih rumit untuk menentukan apa yang terjadi pada peristiwa tertentu yang menyebabkan kesalahan.
Ada tiga persyaratan penting untuk membangun pendekatan debugging yang sukses dalam sistem berbasis peristiwa. Pertama, sistem logging yang kuat sangat penting, dan ini disediakan di seluruh AWS layanan dan disematkan dalam fungsi Lambda oleh Amazon. CloudWatch Kedua, dalam sistem ini, penting untuk memastikan bahwa setiap peristiwa memiliki pengenal transaksi yang dicatat pada setiap langkah selama transaksi, untuk membantu saat mencari log.
Terakhir, sangat disarankan untuk mengotomatiskan penguraian dan analisis log dengan menggunakan layanan debugging dan pemantauan seperti. AWS X-Ray Ini dapat menggunakan log di beberapa pemanggilan dan layanan Lambda, membuatnya lebih mudah untuk menentukan akar penyebab masalah. Lihat [Panduan pemecahan masalah](lambda-troubleshooting.md) untuk cakupan mendalam tentang penggunaan X-Ray untuk pemecahan masalah.
## Anti-pola dalam aplikasi berbasis peristiwa berbasis Lambda
Saat membangun arsitektur berbasis peristiwa dengan Lambda, hindari anti-pola umum berikut. Pola-pola ini bekerja tetapi dapat meningkatkan biaya dan kompleksitas.
### Monolit Lambda
Dalam banyak aplikasi yang dimigrasi dari server tradisional, seperti instans Amazon EC2 atau aplikasi Elastic Beanstalk, pengembang “mengangkat dan menggeser” kode yang ada. Seringkali, ini menghasilkan fungsi Lambda tunggal yang berisi semua logika aplikasi yang dipicu untuk semua peristiwa. Untuk aplikasi web dasar, fungsi Lambda monolitik akan menangani semua rute API Gateway dan terintegrasi dengan semua sumber daya hilir yang diperlukan.
![\[arsitektur berbasis peristiwa gambar 13\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-13.png)
Pendekatan ini memiliki beberapa kelemahan:
+ **Ukuran paket** — Fungsi Lambda mungkin jauh lebih besar karena berisi semua kode yang mungkin untuk semua jalur, yang membuatnya lebih lambat untuk menjalankan layanan Lambda.
+ **Sulit untuk menerapkan hak istimewa paling sedikit** - [Peran eksekusi](lambda-intro-execution-role.md) fungsi harus memungkinkan izin ke semua sumber daya yang diperlukan untuk semua jalur, membuat izin menjadi sangat luas. Ini adalah masalah keamanan. Banyak jalur di monolit fungsional tidak memerlukan semua izin yang telah diberikan.
+ **Lebih sulit untuk ditingkatkan** — Dalam sistem produksi, setiap peningkatan ke fungsi tunggal lebih berisiko dan dapat merusak seluruh aplikasi. Memutakhirkan satu jalur dalam fungsi Lambda adalah peningkatan ke seluruh fungsi.
+ **Lebih sulit untuk mempertahankan** - Lebih sulit untuk memiliki beberapa pengembang bekerja pada layanan karena ini adalah repositori kode monolitik. Ini juga meningkatkan beban kognitif pada pengembang dan membuatnya lebih sulit untuk membuat cakupan tes yang sesuai untuk kode.
+ **Lebih sulit untuk menggunakan kembali kode** - Lebih sulit untuk memisahkan pustaka yang dapat digunakan kembali dari monolit, membuat penggunaan kembali kode menjadi lebih sulit. Saat Anda mengembangkan dan mendukung lebih banyak proyek, ini dapat mempersulit untuk mendukung kode dan meningkatkan kecepatan tim Anda.
+ **Lebih sulit untuk diuji** - Ketika baris kode meningkat, menjadi lebih sulit untuk menguji unit semua kemungkinan kombinasi input dan titik masuk dalam basis kode. Umumnya lebih mudah untuk menerapkan pengujian unit untuk layanan yang lebih kecil dengan kode yang lebih sedikit.
Alternatif yang lebih disukai adalah memecah fungsi Lambda monolitik menjadi layanan mikro individu, memetakan fungsi Lambda tunggal menjadi satu tugas yang terdefinisi dengan baik. Dalam aplikasi web sederhana ini dengan beberapa titik akhir API, arsitektur berbasis layanan mikro yang dihasilkan dapat didasarkan pada rute API Gateway.
![\[arsitektur berbasis acara gambar 14\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-14.png)
### Pola rekursif yang menyebabkan fungsi Lambda yang tak terkendali
AWS layanan menghasilkan peristiwa yang memanggil fungsi Lambda, dan fungsi Lambda dapat mengirim pesan ke layanan. AWS Umumnya, layanan atau sumber daya yang memanggil fungsi Lambda harus berbeda dengan layanan atau sumber daya yang dihasilkan fungsi tersebut. Kegagalan untuk mengelola ini dapat mengakibatkan loop tak terbatas.
Misalnya, fungsi Lambda menulis objek ke objek Amazon S3, yang pada gilirannya memanggil fungsi Lambda yang sama melalui acara put. Pemanggilan menyebabkan objek kedua ditulis ke bucket, yang memanggil fungsi Lambda yang sama:
![\[arsitektur berbasis acara gambar 15\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-15.png)
Sementara potensi loop tak terbatas ada di sebagian besar bahasa pemrograman, anti-pola ini memiliki potensi untuk mengkonsumsi lebih banyak sumber daya dalam aplikasi tanpa server. Baik Lambda dan Amazon S3 secara otomatis menskalakan berdasarkan lalu lintas, sehingga loop dapat menyebabkan Lambda menskalakan untuk mengkonsumsi semua konkurensi yang tersedia dan Amazon S3 akan terus menulis objek dan menghasilkan lebih banyak peristiwa untuk Lambda.
Contoh ini menggunakan S3, tetapi risiko loop rekursif juga ada di Amazon SNS, Amazon SQS, DynamoDB, dan layanan lainnya. Anda dapat menggunakan [deteksi loop rekursif](invocation-recursion.md) untuk menemukan dan menghindari anti-pola ini.
### Fungsi Lambda memanggil fungsi Lambda
Fungsi memungkinkan enkapsulasi dan penggunaan kembali kode. Sebagian besar bahasa pemrograman mendukung konsep kode serempak memanggil fungsi dalam basis kode. Dalam hal ini, pemanggil menunggu sampai fungsi mengembalikan respons.
**catatan**
Sementara fungsi Lambda secara langsung memanggil fungsi Lambda lainnya umumnya merupakan anti-pola karena masalah biaya dan kompleksitas, ini tidak berlaku untuk [fungsi tahan lama](durable-functions.md), yang secara khusus dirancang untuk mengatur alur kerja multi-langkah dengan menjalankan fungsi lain.
Ketika ini terjadi pada server tradisional atau instance virtual, penjadwal sistem operasi beralih ke pekerjaan lain yang tersedia. Apakah CPU berjalan pada 0% atau 100% tidak mempengaruhi keseluruhan biaya aplikasi, karena Anda membayar biaya tetap untuk memiliki dan mengoperasikan server.
Model ini sering tidak beradaptasi dengan baik untuk pengembangan tanpa server. Misalnya, pertimbangkan aplikasi e-commerce sederhana yang terdiri dari tiga fungsi Lambda yang memproses pesanan:
![\[arsitektur berbasis peristiwa gambar 16\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-16.png)
Dalam hal ini, fungsi *Buat pesanan* memanggil fungsi *Pembayaran proses*, yang pada gilirannya memanggil fungsi *Buat faktur*. Meskipun aliran sinkron ini mungkin bekerja dalam satu aplikasi di server, ini memperkenalkan beberapa masalah yang dapat dihindari dalam arsitektur tanpa server terdistribusi:
+ **Biaya** — Dengan Lambda, Anda membayar selama doa. Dalam contoh ini, saat fungsi *Create invoice* berjalan, dua fungsi lainnya juga berjalan dalam keadaan tunggu, ditunjukkan dengan warna merah pada diagram.
+ **Penanganan kesalahan** - Dalam pemanggilan bersarang, penanganan kesalahan bisa menjadi jauh lebih kompleks. Misalnya, kesalahan dalam *Create invoice* mungkin memerlukan fungsi *pembayaran Proses* untuk membalikkan tagihan, atau mungkin mencoba lagi proses *Create invoice*.
+ **Kopling ketat** — Memproses pembayaran biasanya membutuhkan waktu lebih lama daripada membuat faktur. Dalam model ini, ketersediaan seluruh alur kerja dibatasi oleh fungsi paling lambat.
+ **Penskalaan** — [Konkurensi](lambda-concurrency.md) ketiga fungsi harus sama. Dalam sistem yang sibuk, ini menggunakan lebih banyak konkurensi daripada yang dibutuhkan.
Dalam aplikasi tanpa server, ada dua pendekatan umum untuk menghindari pola ini. Pertama, gunakan antrean Amazon SQS antara fungsi Lambda. Jika proses hilir lebih lambat daripada proses hulu, antrian tahan lama mempertahankan pesan dan memisahkan dua fungsi. Dalam contoh ini, fungsi *Create order* akan memublikasikan pesan ke antrean Amazon SQS, dan fungsi *pembayaran Proses* menggunakan pesan dari antrian.
Pendekatan kedua adalah menggunakan AWS Step Functions. Untuk proses kompleks dengan beberapa jenis kegagalan dan logika coba lagi, Step Functions dapat membantu mengurangi jumlah kode kustom yang diperlukan untuk mengatur alur kerja. Akibatnya, Step Functions mengatur pekerjaan dan menangani kesalahan dan percobaan ulang dengan kuat, dan fungsi Lambda hanya berisi logika bisnis.
### Penantian sinkron dalam satu fungsi Lambda
Pastikan bahwa aktivitas yang berpotensi bersamaan tidak dijadwalkan secara sinkron dalam satu fungsi Lambda. Misalnya, fungsi Lambda mungkin menulis ke bucket S3 dan kemudian menulis ke tabel DynamoDB:
![\[arsitektur berbasis acara gambar 17\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-17.png)
Dalam desain ini, waktu tunggu diperparah karena aktivitasnya berurutan. Dalam kasus di mana tugas kedua tergantung pada penyelesaian tugas pertama, Anda dapat mengurangi total waktu tunggu dan biaya eksekusi dengan memiliki dua fungsi Lambda terpisah:
![\[arsitektur berbasis acara gambar 19\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-19.png)
Dalam desain ini, fungsi Lambda pertama merespons segera setelah meletakkan objek ke bucket Amazon S3. Layanan S3 memanggil fungsi Lambda kedua, yang kemudian menulis data ke tabel DynamoDB. Pendekatan ini meminimalkan total waktu tunggu dalam eksekusi fungsi Lambda.
# Merancang aplikasi Lambda
Aplikasi berbasis peristiwa yang dirancang dengan baik menggunakan kombinasi AWS layanan dan kode khusus untuk memproses dan mengelola permintaan dan data. Bab ini berfokus pada topik khusus Lambda dalam desain aplikasi. Ada banyak pertimbangan penting bagi arsitek tanpa server saat merancang aplikasi untuk sistem produksi yang sibuk.
Banyak praktik terbaik yang berlaku untuk pengembangan perangkat lunak dan sistem terdistribusi juga berlaku untuk pengembangan aplikasi tanpa server. Tujuan keseluruhannya adalah untuk mengembangkan beban kerja yaitu:
+ **Andal** - menawarkan pengguna akhir Anda tingkat ketersediaan yang tinggi. AWS layanan tanpa server dapat diandalkan karena mereka juga dirancang untuk kegagalan.
+ **Tahan lama** — menyediakan opsi penyimpanan yang memenuhi kebutuhan daya tahan beban kerja Anda.
+ **Aman** — mengikuti praktik terbaik dan menggunakan alat yang disediakan untuk mengamankan akses ke beban kerja dan membatasi radius ledakan.
+ **Performant** — menggunakan sumber daya komputasi secara efisien dan memenuhi kebutuhan kinerja pengguna akhir Anda.
+ **Hemat biaya** — merancang arsitektur yang menghindari biaya yang tidak perlu yang dapat diskalakan tanpa pengeluaran berlebihan, dan juga dinonaktifkan tanpa overhead yang signifikan.
Prinsip-prinsip desain berikut dapat membantu Anda membangun beban kerja yang memenuhi tujuan ini. Tidak setiap prinsip dapat berlaku untuk setiap arsitektur, tetapi mereka harus memandu Anda dalam keputusan arsitektur umum.
**Topics**
+ [
## Gunakan layanan alih-alih kode khusus
](#services-custom-code)
+ [
## Memahami tingkat abstraksi Lambda
](#level-abstraction)
+ [
## Menerapkan kewarganegaraan dalam fungsi
](#statelessness-functions)
+ [
## Minimalkan kopling
](#minimize-coupling)
+ [
## Bangun untuk data sesuai permintaan alih-alih batch
](#on-demand-batches)
+ [
## Pilih opsi orkestrasi untuk alur kerja yang kompleks
](#orchestration)
+ [
## Menerapkan idempotensi
](#retries-failures)
+ [
## Gunakan beberapa AWS akun untuk mengelola kuota
](#multiple-accounts)
## Gunakan layanan alih-alih kode khusus
Aplikasi tanpa server biasanya terdiri dari beberapa AWS layanan, terintegrasi dengan kode khusus yang dijalankan dalam fungsi Lambda. Sementara Lambda dapat diintegrasikan dengan sebagian besar AWS layanan, layanan yang paling umum digunakan dalam aplikasi tanpa server adalah:
| Kategori | AWS layanan |
| --- | --- |
| Hitung | AWS Lambda |
| Penyimpanan data | Amazon S3 Amazon DynamoDB Amazon RDS |
| API | Amazon API Gateway |
| Integrasi aplikasi | Amazon EventBridge Amazon SNS Amazon SQS |
| Orkestrasi | Lambda fungsi tahan lama AWS Step Functions |
| Streaming data dan analitik | Amazon Data Firehose |
**catatan**
Banyak layanan tanpa server menyediakan replikasi dan dukungan untuk beberapa Wilayah, termasuk DynamoDB dan Amazon S3. Fungsi Lambda dapat digunakan di beberapa Wilayah sebagai bagian dari pipeline penerapan, dan API Gateway dapat dikonfigurasi untuk mendukung konfigurasi ini. Lihat [contoh arsitektur](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/serverless-architecture-for-global-applications-ra.pdf?did=wp_card&trk=wp_card) ini yang menunjukkan bagaimana hal ini dapat dicapai.
Ada banyak pola umum yang mapan dalam arsitektur terdistribusi yang dapat Anda bangun sendiri atau terapkan menggunakan AWS layanan. Bagi sebagian besar pelanggan, ada sedikit nilai komersial dalam menginvestasikan waktu untuk mengembangkan pola-pola ini dari awal. Ketika aplikasi Anda membutuhkan salah satu pola ini, gunakan AWS layanan yang sesuai:
| Pola | AWS layanan |
| --- | --- |
| Antrean | Amazon SQS |
| Bus acara | Amazon EventBridge |
| Terbitkan/berlangganan (fan-out) | Amazon SNS |
| Orkestrasi | Lambda fungsi tahan lama AWS Step Functions |
| API | Amazon API Gateway |
| Aliran acara | Amazon Kinesis |
Layanan ini dirancang untuk berintegrasi dengan Lambda dan Anda dapat menggunakan infrastruktur sebagai kode (IAc) untuk membuat dan membuang sumber daya dalam layanan. Anda dapat menggunakan salah satu layanan ini melalui [AWS SDK](https://aws.amazon.com/tools/) tanpa perlu menginstal aplikasi atau mengkonfigurasi server. Menjadi mahir menggunakan layanan ini melalui kode dalam fungsi Lambda Anda adalah langkah penting untuk menghasilkan aplikasi tanpa server yang dirancang dengan baik.
## Memahami tingkat abstraksi Lambda
Layanan Lambda membatasi akses Anda ke sistem operasi, hypervisor, dan perangkat keras yang mendasari yang menjalankan fungsi Lambda Anda. Layanan terus meningkatkan dan mengubah infrastruktur untuk menambah fitur, mengurangi biaya, dan membuat layanan lebih berkinerja. Kode Anda seharusnya tidak mengasumsikan pengetahuan tentang bagaimana Lambda dirancang dan menganggap tidak ada afinitas perangkat keras.
Demikian pula, integrasi Lambda dengan layanan lain dikelola oleh AWS, dengan hanya sejumlah kecil opsi konfigurasi yang terpapar kepada Anda. Misalnya, ketika API Gateway dan Lambda berinteraksi, tidak ada konsep load balancing karena sepenuhnya dikelola oleh layanan. Anda juga tidak memiliki kontrol langsung atas [Availability Zone](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) yang digunakan layanan saat menjalankan fungsi kapan saja, atau bagaimana Lambda menentukan kapan harus meningkatkan atau menurunkan jumlah lingkungan eksekusi.
Abstraksi ini membantu Anda fokus pada aspek integrasi aplikasi Anda, aliran data, dan logika bisnis di mana beban kerja Anda memberikan nilai bagi pengguna akhir Anda. Memungkinkan layanan untuk mengelola mekanisme yang mendasarinya membantu Anda mengembangkan aplikasi lebih cepat dengan lebih sedikit kode khusus untuk dipelihara.
## Menerapkan kewarganegaraan dalam fungsi
Untuk fungsi Lambda standar, Anda harus berasumsi bahwa lingkungan hanya ada untuk satu pemanggilan. Fungsi harus menginisialisasi status yang diperlukan saat pertama kali dimulai. Misalnya, fungsi Anda mungkin memerlukan pengambilan data dari tabel DynamoDB. Ini harus melakukan perubahan data permanen ke toko yang tahan lama seperti Amazon S3, DynamoDB, atau Amazon SQS sebelum keluar. Seharusnya tidak bergantung pada struktur data yang ada atau file sementara, atau keadaan internal apa pun yang akan dikelola oleh beberapa pemanggilan.
Saat menggunakan Fungsi Tahan Lama, status secara otomatis dipertahankan di antara pemanggilan, menghilangkan kebutuhan untuk mempertahankan status secara manual ke penyimpanan eksternal. Namun, Anda tetap harus mengikuti prinsip stateless untuk data apa pun yang tidak dikelola secara eksplisit melalui. DurableContext
Untuk menginisialisasi koneksi database dan pustaka, atau status beban, Anda dapat memanfaatkan inisialisasi [statis](lambda-runtime-environment.md#static-initialization). Karena lingkungan eksekusi digunakan kembali jika memungkinkan untuk meningkatkan kinerja, Anda dapat mengamortisasi waktu yang dibutuhkan untuk menginisialisasi sumber daya ini melalui beberapa pemanggilan. Namun, Anda tidak boleh menyimpan variabel atau data apa pun yang digunakan dalam fungsi dalam lingkup global ini.
## Minimalkan kopling
Sebagian besar arsitektur harus lebih memilih banyak fungsi yang lebih pendek daripada yang lebih sedikit, yang lebih besar. Tujuan dari setiap fungsi harus untuk menangani peristiwa yang diteruskan ke dalam fungsi, tanpa pengetahuan atau harapan dari keseluruhan alur kerja atau volume transaksi. Hal ini membuat fungsi agnostik ke sumber acara dengan kopling minimal ke layanan lain.
Setiap konstanta lingkup global yang jarang berubah harus diimplementasikan sebagai variabel lingkungan untuk memungkinkan pembaruan tanpa penerapan. Setiap rahasia atau informasi sensitif harus disimpan di [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) atau [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) dan dimuat oleh fungsi. Karena sumber daya ini khusus akun, Anda dapat membuat pipeline build di beberapa akun. Pipeline memuat rahasia yang sesuai per lingkungan, tanpa mengeksposnya ke pengembang atau memerlukan perubahan kode apa pun.
## Bangun untuk data sesuai permintaan alih-alih batch
Banyak sistem tradisional dirancang untuk berjalan secara berkala dan memproses batch transaksi yang telah dibangun dari waktu ke waktu. Misalnya, aplikasi perbankan dapat berjalan setiap jam untuk memproses transaksi ATM menjadi buku besar pusat. Dalam aplikasi berbasis Lambda, pemrosesan kustom harus dipicu oleh setiap peristiwa, memungkinkan layanan untuk meningkatkan konkurensi sesuai kebutuhan, untuk menyediakan pemrosesan transaksi yang hampir real time.
Sementara fungsi Lambda standar dibatasi hingga 15 menit waktu eksekusi, Fungsi Tahan Lama dapat berjalan hingga satu tahun, membuatnya cocok untuk kebutuhan pemrosesan yang berjalan lebih lama. Namun, Anda tetap harus lebih memilih pemrosesan berbasis peristiwa daripada pemrosesan batch jika memungkinkan.
Meskipun Anda dapat menjalankan tugas [cron](https://en.wikipedia.org/wiki/Cron) dalam aplikasi tanpa server [dengan menggunakan ekspresi terjadwal untuk aturan](https://docs.aws.amazon.com/eventbridge/latest/userguide/scheduled-events.html) di Amazon EventBridge, ini harus digunakan dengan hemat atau sebagai pilihan terakhir. Dalam setiap tugas terjadwal yang memproses batch, ada potensi volume transaksi tumbuh melampaui apa yang dapat diproses dalam batas durasi Lambda 15 menit. Jika keterbatasan sistem eksternal memaksa Anda untuk menggunakan penjadwal, Anda biasanya harus menjadwalkan untuk periode waktu berulang yang masuk akal terpendek.
Misalnya, bukan praktik terbaik untuk menggunakan proses batch yang memicu fungsi Lambda untuk mengambil daftar objek Amazon S3 baru. Ini karena layanan dapat menerima lebih banyak objek baru di antara batch daripada yang dapat diproses dalam fungsi Lambda 15 menit.
![\[arsitektur berbasis peristiwa gambar 10\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-10.png)
Sebagai gantinya, Amazon S3 harus menjalankan fungsi Lambda setiap kali objek baru dimasukkan ke dalam ember. Pendekatan ini secara signifikan lebih terukur dan bekerja dalam waktu nyaris nyata.
![\[arsitektur berbasis acara gambar 11\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/event-driven-architectures-figure-11.png)
## Pilih opsi orkestrasi untuk alur kerja yang kompleks
Alur kerja yang melibatkan logika percabangan, berbagai jenis model kegagalan, dan logika coba lagi biasanya menggunakan orkestrator untuk melacak status eksekusi secara keseluruhan. Jangan membangun orkestrasi ad-hoc dalam fungsi Lambda standar. Ini menghasilkan kopling yang ketat, kode perutean yang kompleks, dan tidak ada pemulihan status otomatis.
Sebagai gantinya, gunakan salah satu opsi orkestrasi yang dibuat khusus ini:
+ **[Fungsi tahan lama Lambda](durable-functions.md):** Orkestrasi yang berpusat pada aplikasi menggunakan bahasa pemrograman standar dengan pos pemeriksaan otomatis, coba ulang bawaan, dan pemulihan eksekusi. Ideal untuk pengembang yang lebih suka menyimpan logika alur kerja dalam kode bersama logika bisnis dalam Lambda.
+ **[AWS Step Functions](with-step-functions.md):** Orkestrasi alur kerja visual dengan integrasi asli ke 220\$1 layanan. AWS Ideal untuk koordinasi multi-layanan, infrastruktur tanpa perawatan, dan desain alur kerja visual.
Untuk panduan memilih di antara opsi-opsi ini, lihat [Fungsi tahan lama atau Step Functions](durable-step-functions.md).
Dengan [Step Functions](https://aws.amazon.com/step-functions/), Anda menggunakan mesin status untuk mengelola orkestrasi. Ini mengekstrak penanganan kesalahan, perutean, dan logika percabangan dari kode Anda, menggantinya dengan mesin status yang dideklarasikan menggunakan JSON. Selain membuat alur kerja lebih kuat dan dapat diamati, Anda juga dapat menambahkan versi ke alur kerja dan menjadikan mesin status sebagai sumber daya terkodifikasi yang dapat Anda tambahkan ke repositori kode.
Adalah umum untuk alur kerja yang lebih sederhana dalam fungsi Lambda menjadi lebih kompleks dari waktu ke waktu. Saat mengoperasikan aplikasi tanpa server produksi, penting untuk mengidentifikasi kapan ini terjadi, sehingga Anda dapat memigrasikan logika ini ke mesin status atau fungsi tahan lama.
## Menerapkan idempotensi
AWS Layanan tanpa server, termasuk Lambda, toleran terhadap kesalahan dan dirancang untuk menangani kegagalan. Misalnya, jika layanan memanggil fungsi Lambda dan ada gangguan layanan, Lambda memanggil fungsi Anda di Availability Zone yang berbeda. Jika fungsi Anda memunculkan kesalahan, Lambda mencoba ulang pemanggilan.
Karena acara yang sama dapat diterima lebih dari sekali, fungsi harus dirancang untuk menjadi [idempoten](https://en.wikipedia.org/wiki/Idempotence). Ini berarti bahwa menerima acara yang sama beberapa kali tidak mengubah hasil di luar pertama kali acara diterima.
Anda dapat menerapkan idempotensi dalam fungsi Lambda dengan menggunakan tabel DynamoDB untuk melacak pengidentifikasi yang baru diproses untuk menentukan apakah transaksi telah ditangani sebelumnya. Tabel DynamoDB biasanya mengimplementasikan nilai [Time To Live (TTL) untuk](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) item kedaluwarsa untuk membatasi ruang penyimpanan yang digunakan.
## Gunakan beberapa AWS akun untuk mengelola kuota
Banyak [kuota layanan](gettingstarted-limits.md) AWS ditetapkan pada tingkat akun. Ini berarti bahwa saat Anda menambahkan lebih banyak beban kerja, Anda dapat dengan cepat menghabiskan batas Anda.
Cara efektif untuk mengatasi masalah ini adalah dengan menggunakan banyak AWS akun, mendedikasikan setiap beban kerja ke akunnya sendiri. Ini mencegah kuota dibagikan dengan beban kerja lain atau sumber daya non-produksi.
Selain itu, dengan menggunakan [AWS Organizations](https://aws.amazon.com/organizations/), Anda dapat mengelola penagihan, kepatuhan, dan keamanan akun ini secara terpusat. Anda dapat melampirkan kebijakan ke grup akun untuk menghindari skrip kustom dan proses manual.
Salah satu pendekatan umum adalah menyediakan setiap pengembang dengan AWS akun, dan kemudian menggunakan akun terpisah untuk tahap penerapan beta dan produksi:
![\[gambar desain aplikasi 3\]](http://docs.aws.amazon.com/id_id/lambda/latest/dg/images/application-design-figure-3.png)
Dalam model ini, setiap pengembang memiliki batasan sendiri untuk akun, sehingga penggunaannya tidak memengaruhi lingkungan produksi Anda. Pendekatan ini juga memungkinkan pengembang untuk menguji fungsi Lambda secara lokal pada mesin pengembangan mereka terhadap sumber daya cloud langsung di akun masing-masing.